I remember when the big open source debate was whether a piece of software was really open source, meaning it was released under an OSI-approved license. The tides are shifting, debates now center around which open source license to use. Adding to the complexity of the debate is proliferation of OSI-approved licenses. Now discussions are rising over the open source licenses that are in the best interest of all stakeholders of an open source project. In the case of collective software works there is also the added intricacies of license compatibility.
Part of the problem is that companies are trying to drive their own vanity licenses that reinforce their branding and leverage the goodwill associated with the open source seal of approval. SugarCRM once mounted an offensive asking for acceptance of their Sugar Public License (a derivative of the OSI-Approved Mozilla Public License) that for a brief time was gaining popularity among commercial open source developers. The license was rejected and Sugar has since moved to the GPLv3. Ironically the Common Public Attribution License (CPAL) submitted by Social Text, which bears many similarities to the Sugar Public License, was accepted by the OSI. Even Microsoft has successfully lobbied the OSI-board for approval of two licenses. The Microsoft Public License (M-PL) and the Microsoft Reciprocal License (Ms-RL) which are very similar to the BSD and GPL licenses.
According to Black Duck Software knowledgebase the most common open source license used by open source projects is the GPL version 2.0. According to that same source 94% of open source projects use 10 licenses.
|GNU General Public License
|GNU Lesser General Public
License (LGPL) 2.1
|Artistic License (Perl)||7.46%|
|Apache License 2.0||2.92%|
|GNU General Public Liense (GPL) 3.0||1.64%|
|Mozilla Public License (MPL) 1.1||1.37%|
|Common Public License||0.83%|
Currently the decision to move from GPL v2 to GPL v3 is being hotly debated by many open source projects. According to Palamida, a provider of IP compliance software, there have been roughly 2489 open source projects that have moved from GPL v2 to later versions.
Apparently there are many people thinking about using the AGPL because unlike the GPL it also extends its requirement from software redistribution to networked services like those provided by ASPs (see Section 13 of the license – Remote Network Interaction):
Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.
Ubuntu is considering the use of the AGPL for their Launchpad service but the jury is still out.
In the case of Launchpad, we do view you as a co-owner of the data, so the resolution of this problem is important to us. As you point out, there’s no really clear best practice that works well and has been shownto be commercially sustainable. That’s different to the GPL (even v3). I think the Affero GPL is a strong candidate for the front line of thinking on the subject, and that’s what I am inclined to use when we publish Launchpad’s source code.
Google has refused to allow AGPL licensed on Google code, citing license proliferation as the issue.
In fact we do not support the AGPL on code.google.com. We are actively trying to fight the proliferation of licenses that are considered open source and the AGPL both has very little market share and has not been certified as being open source by the OSI.
However, AGPL provisions for hosting services doesn’t exactly jive with their business either. For example, any modifications Google makes to AGPL code would require them to provide source code when delivered as a service.
Software licensing is complex open source or not. I suspect that most users are not well versed in the license for the software they download. I find it somewhat disheartening that while I feel strongly that open source development is superior the licensing of open source software for the most part is no easier to understand or apply.