The following discussion includes descriptions of legal concepts. This is not intended, and should not be interpreted as, legal advice. If readers have questions about software law, copyright or patents, please consult an appropriate attorney.
In the context of open source and free software, copyright is quite possibly a necessity as many, if not all, open source and free software licenses are based on United States copyright law or copyright concepts. Copyright protects original creative works, which includes software code. Copyright protects a particular form of expression. Defining and protecting such creative works allows the author to receive appropriate attribution for the work as well as a certain level of profit, if that is what the author desires. The terms of a copyright license can be used to "enforce," or protect certain rights as well as restrict rights, and this is one of the main purposes of open source and free software licensing.
The concept of patent is similar to copyright, but based on a different rationale. Patents have historically been granted to inventions in the form of a physical device or a particular process that performs some specific task in a new and useful way. As opposed to copyright, which protects a particular expression of an idea, patent protects the process, the machine or operating object itself that performs the useful task. The concept of patent protection has been extended to include software code. While code has no physical manifestation, when written, arranged and executed in a specific way it certainly creates a process that can accomplish a useful task, so the argument has been made that software is patentable.
Both copyright and patent holders can grant licenses for their various works and inventions, so why the controversy over software patents? The granting of a patent gives the patent holder a complete monopoly on whatever process the patent covers. This leads to one aspect of patents that is very different from copyright, which is there is no "fair use" of patented processes. Without a license, one simply cannot use a patented process or arguably anything substantially similar to the patented process. This in itself goes against the desire to encourage the sharing of code and ideas among programmers that is at the heart of the open source and free software movements.
Patents can have an anticompetitive effect also. The system for obtaining a patent as it currently exists is extremely expensive, often requiring an attorney who has specialized knowledge of the subject area covered by the proposed patent as well as years of time to obtain approval of the patent. In this regard, the system favors corporations with large budgets. Virtually no small developers have the ability to go through this process from a financial perspective, to say nothing of having to wait years before being able to actually put out a final, patented product. Another argument against software patents is that they can be used "offensively" by larger companies via patent lawsuits to impede developers of competing products. Not only is the time and expense required to defend a patent lawsuit enormous, the penalties for infringing a patent can be equally daunting.
Some OSS developers have begun creatively using their own software patents in a "defensive" manner by dedicating the patents to a "patent commons" to protect the code from being patented by others and enforced offensively against OSS developers, while protecting its use by the community. Others in the OSS community have taken it upon themselves to police software patents by looking for ways to invalidate some patents, such as by finding and publicizing "prior art," which is an example of the existence of the patented process or method prior to the granting of a particular patent. The existence of prior art puts the "inventiveness" of the patent into question, and can lead to revocation of the patent.
The ease of obtaining a copyright, as well as the ability to protect the rights granted to downstream developers via OSS licensing terms, makes it the best method for preserving OSS ideals. Patents appear to have too many costs, both practically and financially, to be useful in encouraging the sharing and development of software code. This is a complicated issue with many polarized viewpoints. See below for links to just some of these.
Chris DiBona from Google suffered the slings and arrows of the OSS community when he rejected the AGPLv3 license for Google Code repository, citing license proliferation as one of hte reasons. Looking back, Chris challenged the wisdom of OSI years ago when he was on their board, still at the time fighting against yet another license.
An open source software license is specifically a copyright focused on types of use permitted for electronic media.
By introducing yet another license, it create more complexity to explain, understand, and enforce the use of software governed by these licenses.
The reality is that lack of clarity and confusing, or internally contradictory terms, makes the license potentially limited in worth, as the cost to actually enforce that license increases.
If we look at any open source software license, we realize that they all are governing copyright specific to the use of software.
Use type -
1. Copying: This is the term popularized by Free Software Foundation to describe the act of moving the software from a point of distribution to a local computer, solely for the purpose of personally using the software.
2. Distribution: Once software has been collected from a distribution point, the act of making it available, either by itself, repackaging, bundling, modifying configuration files specific to a platform, and then making the resulting software available for others to "copy".
3. Modification: When a user takes code that has been copied, and implements changes to the source code, such that the program is changed, and then makes the code available through a distribution channel for others to "copy".
4. Other: This refers to license clauses that set restrictions on actions of software uses for actions outside of the direct use, as described above, of the software. Typical "other" language defines restrictions of special restrictive language specific to the use of the original developer's name and branding in marketing done by a distributor/modifier of software copied.
Restrictions -
1. Limitations of liabilities, as is clauses
2. Advertising restrictions
3. Licensing fees, shared revenue, restriction of revenue activities
4. Export restrictions
5. and so on
6. Downstream licensing on modified code
"Restrictions" govern "use" type. Many restrictions also only exist for specific use type.
Revenue restrictions, downstream licensing requirements, and triggered by modification, and or distribution, as example.
Therefrore, if you are copying and distributing, many restrictions don't even apply.
In summary, open source software licensing has become needlessly complex, FUD evolves around rumors of compatibility and interoperability without consideration and understanding of use types and specific restrictions. Open source licensing is a copyright with specific use considerations, restrictions and terms defined within the license, rahter than by copyright law. The thousands of licenses that exist have complicated the issue of using open source software far too much than the issue requires. Practically, we need only one license that specifies the use types and associated governance. Anything beyong one simple license that we can clearly explain the use and restrictions around open source software fails the future use and growth of the adoption of such software.
Ernest Park
http://the-opensource.blogspot.com
http://gpl3.blogspot.com
*************************************************************************
Google Homepage
myAOL
