- Week Summary
- New Projects
- Are Software Patents Incompatible With Open Source And Free Software Ideals?
- License Proliferation: Less is more, one is best
- User Contributions
We would like to thank everyone for their continued support of the GPL3 project. Currently, we are transitioning not only managers, but the GPLv3 collection team as well. Along with former manager Antony Tran and current manager Edwin Pahk, the GPLv3 project has been maintained and supported by a number of interns checking hundreds of projects daily to provide the OSS community a reliable source for GPLv3 adoption. As we move forward, we will be restaffing our team and reviewing our approach. We thank you for your patience during this time.
This week our GPL v3 count is at 2931 GPL v3 projects, and increase of 56 GPL v3 projects. The AGPL v3 count is at 130 AGPL v3 projects. The LGPL v3 number is at 273 LGPL v3 projects.
New project conversions this week include:
- Voice Keyboard: Voice keyboard/dictation. Aims to be a total substitute for a keyboard. Spell out words letter by letter (using code: alpha, bravo, ..). Arrow keys, modifiers work. Speak whole words (but whole word accuracy is not good). Attach commands to some words.
- OpenModeller: openModeller is a static spatial distribution modelling tool originally conceived to predict species distribution (fundamental niche).
- Sudoku Savant: A simple GUI-driven application to solve and generate sudoku puzzles through logical means. Also supports manual solving, with pencil marks and cell colouring. Should be able to solve any standard sudoku from a newspaper or magazine.
Are Software Patents Incompatible With Open Source And Free Software Ideals?
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.
References and further information:http://perens.com/Articles/
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.
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.
If you are willing to copy and tranlate the content weekly, please let me know - you will receive the content as soon as it is available, and you site will be listed as a translation. I can send you a bit of tracking code so that you get credit for your contribution to the readership of this site
Post your link on the bottom of the blog page.
Send me a note at firstname.lastname@example.org that you are using some or all of the content
I will make sure that we host links to your sites, and we will be able to use your content within this site as well.
The Research Group actively takes submissions from visitors on updates on new GPL v3/LGPL 3 projects. We are amazed at the number of submissions we have gotten to date, but even more so, we are incredibly grateful to over 100 core contributors who have devoted their time and resources at helping us provide up-to-date information.
For more information, go to http://gpl3.blogspot.com/.
To stop receiving these weekly mailings, please send a message to email@example.com with the subject "unsubscribe:gpl3".
To start receiving these weekly mailings, please send a message to firstname.lastname@example.org with the subject "subscribe:gpl3".
Our Sponsor, Palamida, Inc.
The GPL3 project, sponsored by Palamida, Inc (http://palamida.com/ ), is an effort to make reliable publicly available information regarding GPLv3 license usage and adoption in new projects.
The opinions expressed within the GPL3 Information Blog are exlusively those of Ernest Park, the subjects interviewed and the contributing authors, and are not intended to reflect the positions of Palamida, Inc and its employees.
This work is licensed under a Creative Commons Attribution-Noncommercial-
Palamida was launched in 2003 after its founders learned first-hand what happens when companies don't have full visibility into the code base of their software applications based on Open Source Software. Their experiences inspired them to create a solution to streamline the process of identifying, tracking and managing the mix of unknown and undocumented Open Source that comprises a growing percentage of today's software applications. Palamida is the industry's first application security solution targeting today's widespread use of Open Source Software. It uses component-level analysis to quickly identify and track undocumented code and associated security vulnerabilities as well as intellectual property and compliance issues and allows development organizations to cost-effectively manage and secure mission critical applications and products.
For more information about FOSS management solutions, go to http://palamida.com/, or send a note to email@example.com.
Please mention the GPL3 site when you reach out to Palamida.
The Research Group (firstname.lastname@example.org)