Within the body of this document, I outline a reasonable set of guidelines that can be implemented to insure reasonable adherence to clear licensing policies for OSS.
From another perspective, a development team works for a year to build a cool project that solves a business problem. They like some ideas of the GPLv3 and choose to support it on the web page. The maintainer of the code repository never put the license in the code tree, but they opened the project up to the world. Third parties now download the code, modify it, and it becomes the core of the next big thing, and starts selling. However, the source never contained a license. Who is correct?The issue of ambiguous licensing got me thinking of some basic ideas to create clarity with the specific license associations to any given application, version and release for open source software. In the end, software licensing is the way that a maintainer/developer of a given project governs how the project is incorporated into the OSS community. The licensing creates the framework for the evolution and growth of the project, and should reasonably express the wishes of the creator of the project for recognition, financial consideration, and other basic points.
Let’s discuss the following OSS licensing conditions:
2. Unclear and ambiguous
Contradictory licensing – internal (conflicting language within license file)
Note: A funny situation that I saw was to include the “heading” from the GPLv2 license, or the BSD license, while using the text from yet another license. I am sure that in some way, the developer/maintainer may have considered “reviewing” one license, with the intent of modifying it to become a custom license, or it could have been a mistake. In either case, imagine the situation where, on a quick review of the COPYING file in the source, you see the beginning of the BSD license, and choose to move forward, without realizing that a large part of the GPLv3 license was appended to the bottom.
Contradictory licensing presents a real problem for developers. A developer may have already chosen to use a project as core to a proprietary project. A great deal of time and effort may have been invested by the time that the licensing issues arose. The intent to use source governed by impossibly contradictory terms, I would believe, is less to do with intentional circumvention of licensing, and more to do with a lack of understanding of licensing that is poorly crafted and unclear. As such, the user/developer made a choice to use OSS with a vague understanding of the usage terms. The maintainer of the same project may have attempted to modify the license in order to refine his vision for usage of the project. The maintainer probably does not realize that the license legally renders the code unusable. In the spirit of OSS usage, I believe that it is the goal of the community to publicly disclose these licenses, and in the event that a developer has started using such code, it is in the best interest of both the maintainer and the user to get together, rationalize the licensing, and publicly disclose the mistake, just as if it was a bug.
Contradictory licensing – external (multiple license files or references)
I have seen numerous examples of an inconsistency between what is disclosed on the project home page, in the compiled code, and in the source tree. A great deal of these inconsistencies became apparent as the GPLv3 license came out. Some projects intentionally did not want to support the GPLv3, others publicly wanted to release under GPLv3. In researching for GPLv3, links from the project page would take a user to the GPLv3 license page at FSF. The compiled code had the GPLv2 license text in many cases, but contained links to the GPLv3. The source would contain an unpredictable array of references either to explicit license text at the developer’s site, the text embedded within a file in the source, or links to third party sites, like FSF. What is interesting is that the license references in many cases deviated from both the stated licensing on the home page, the licensing references in the readme file of the compiled code, and in some cases was even incorrect internally. (Keep in mind that I was looking at versions pending release in cases of unclear licensing – I was not always inspecting the source for the binaries currently available).
A much more common contradiction that we see all the time is the case where the GPLv2 license was included with the source, the GPLv2, “or later” is referenced in the Readme.txt file for the compiled project, and the COPYING file contains the GPLv3 text. In the case that multiple valid references to multiple and valid use licenses exist, which license governs? In the event where there are multiple licenses that by themselves are valid, but compared to one another, are contradictory, which license governs? Whose responsibility is it to deal with externally incompatible licensing, the user or the maintainer? Can the user “selectively” choose to use the license of their preference, since multiple choices are presented in parallel?
In this case, the problem lies with the development community, but the fault lies with the maintainer. However, in the spirit of OSS, when we see this situation where multiple parallel licensing choices exist, we must reach out to the maintainer immediately in order to prevent conflicting simultaneous development paths to start within the community. Within OSS, we realize that while a mistake may be the fault of the maintainer, it is the responsibility of the community to keep OSS development clear and on a common path.
Unclear or ambiguous terms –
The fact that terms or provisions are unclear does not necessarily mean they are unenforceable, it just means one cannot have reliable expectations about what rights or restrictions exist as a result of those terms or provisions. The lack of reliable expectations goes against the entire purpose of having written agreements, so presumably written agreements with unclear terms will be weeded out by a natural selection-type of process: the more times the unclear provisions don’t do what the drafter wants them to do, the less likely a rational drafter will use similar terms in future agreements.
My personal opinion is that the project maintainer has the ultimate responsibility to: 1) carefully consider which license gives users/developers the desired rights and abilities; 2) choose a license that is easy for users/developers to understand; 3) make sure the project distribution complies with the license requirements; and 4) make the fact that a particular license governs a project obvious.
If a maintainer does not do these things, I don’t see how he can complain later if he can’t enforce some right in the license that he didn’t care enough about to explain clearly.
It was surprising and sometimes quite frustrating to see all of the open source project pages that either had no mention of a license or only referred to a general license, like “GPL.”
As an aside, the GPL seems to answer this parallel question. Right from the Terms and Conditions of the GPLv2 (para. 9) and with slight modification, the GPLv3 (para. 14):
“Each version is given a distinguishing version number. If the Program specifies that a certain numbered version of the GNU General Public License “or any later version” applies to it, you have the option of following the terms and conditions either of that numbered version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of the GNU General Public License, you may choose any version ever published by the Free Software Foundation.”
Summary Going forward, I am sure that the “market” will drive which OSS projects succeed, and which ones become obsolete, due to risks associated with unclear, contradictory and nonexistent licenses. In the interim, I would like to suggest a common sense “rule of thumb” for qualifying if a project is licensed in a way clear enough that it can be used:
Ernie’s Clear OSS Licensing Guidelines
1. Project must have a distinct homepage that is not a repository. Domains are cheap and user pages are free in many cases. This provides a place where the maintainer can manage a freeform data exchange with users, and is a site unique from any repository and its goals.
2. Maintainer needs to provide a URL to the license(s) used. I suggest http:///license.html. Under this file, identify the applications, versions and releases, all hyperlinked. Within the hyperlinks, allow a user to follow distinct hyperlinks to the specific license text. Name the URL for the license text using the name of the core license, like http:///licenses/license-Apache_License_Version_2.0.html
3. License text must reference file from which it derived by URL, like http://www.opensource.org/licenses/apache2.0.php
4. Project homepage MUST provide a link called LICENSES that goes to the main license page, described above.
5. Each download file MUST be compressed with a file called license.txt and license-.txt, along with a hash fileof the text license file.
6. License.txt needs to described the licensing hierarchy for licensing per application/version/release .
7. license-.txt includes the explicit text of the license, and includes pointers to where the SAME license can be found on the website, within the source code (by the same name), and in the binary
8. license-.md5 MUST be included to allow absolute verification that the user has the license that was intended to be included with the specific release
9. Unless the maintainer has a Juris Doctorate and specializes in software licensing law, stick with OSI licenses, or use them as the CORE. In the event that the maintainer uses the OSI license, congratulations. In the event that a maintainer chose to reinvent the wheel, identify such. In the license URL, change the URL to read as follows:
– OSI license: license-.txt
– modified OSI license: license-Modified_.txt (this requires identification of the core license that was modified)
– license newly developed by maintainer or third party: license-custom-.txt
10. Finally, a license should be basic, and easy enough to understand that a layperson could understand the idea of it. In the event that a maintainer customizes licenses, or chooses one that is available, make sure it is easy to understand. Think of it this way, if you can’t explain this to your mother, you probably can’t explain this to a judge any easier.
In the end, a license for the use of open source software is an agreement between a maintainer/developer who created the project, and a user/developer who plans to use it. The agreement represents the rules of a relationship.
– Make it clear and easy to understand.
– Put multiple copies of the same thing in many places
– Register your licensing for a release on your own site (described above), and register your release and its license at http://gpl3.palamida.com:8080/ , even if it is not GPLv3.
– Take responsibility for making your desires for use clear enough that others can comply without prohibiting use
– For user/developers, if you see something that is unclear, contradictory, or not there, communicate, let the maintainer know. Cooperation by the community will ease the creation of simple and easy to understand licensing that can be verified.
Ultimately, it is the strength of the community that makes OSS succeed. If projects don’t meet the basic measure of clear licensing as I define above, insist that the maintainer implement changes to support clear licensing, or do not support the OSS project by using it.