GPLv3: Overwhelming support if you know where to look

My concern is that external viewers of our gpl3.palamida.com site see that the numbers “appear” sluggish for GPLv3 adoption. Am I the only one that sees what is happening? Two weeks have passed, 15 days later, one US holiday, two weekends, and we have over 3000 OSS projects that either directly or by choice of the user will now be governed by the GPLv3. I argue that the adoption is fast, consistent with OSS software development release cycles, and representative of what over time will be a large and all encompassing support for the GPLv3 and LGPLv3 licenses, and continued support for the FSF.

Strategic support for GPLv3, and the real meaning of “or later”
GNU and Rubyforge jumped on the GPLv3 bandwagon early. However, Rubyforge was the ONLY one to really do it, or were they?

Rubyforge carefully planned the announcement of new releases for 68 core projects to align with the announcement of the GPLv3 license. This coordination was a clear effort to show strong support for the FSF and the new license. The licensing has a parasitic effect, especially when the core components that Ruby developers use are now GPLv3. Rubyforge’s commitment to being out front with GPLv3 support will drive new contributions to enter the OSS world with similar licensing. The Rubyforge components are core the Ruby development and will clearly have an impact on GPLv3 license adoption over a short time. I am sure we will start to see new projects, or new releases of existing Ruby projects that inherit GPLv3 and LGPLv3 licensing as a direct result of the strategic move made by Rubyforge.

Despite the bluster, GNU support for GPLv3 was not clear and apparent. On July 29th, we only found a handful of projects professing GPLv3 licensing, and the reality was that the links may have been erroneous – a problem that we have all noted (http://gpl3.blogspot.com/2007/07/more-thoughts-regarding-invalid-gplv3.html ). The unseen support for the GPLv3 actually came from FSF and developers support of recommended licensing strategies. Upon the recommendation of the FSF and language embedded within their GPLv2 license, many of the active GNU projects already showed STRONG support for the GPLv3 license. The licenses were worded to state that basically, at the choice of the user of the software, the user could use the software under the existing license, or any GPL license yet to come, otherwise, the “or later” clause (http://hritcu.wordpress.com/2007/01/06/gplv2-or-later/ ). Therefore, very quietly, in the years prior to the announcement of the GPLv3 license, the FSF built a strong constituency of support by encouraging developers and GNU to use the “GPLv2, or later” as a standard licensing clause.

The unseen impact of the “or later” clause means that the day that FSF released the final version of the GPLv3 license, it was supported IMMEDIATELY by almost 3000 projects that at that moment could be licensed under the GPLv3 license. While Rubyforge was strategic in timing the announcement of new GPLv3 releases, some of which may not have been available as anything other than CVS or source checkout, GNU and other FSF supporters in reality rallied quietly by allowing existing releases to be licensed under the GPLv3 the second it was announced.


Lackluster support, or is this a landslide?
Sourceforge lists over 60,000 projects with GPL licensing right now (http://sourceforge.net/softwaremap/trove_list.php?form_cat=15 ). Third party estimates would have us expecting over 70% of these, or about 40,000 projects, to “convert” to GPLv3. What happened? Nothing. Licensing does not really represent conversion. Licensing is part of the evolutionary process of software development. A new license can be incorporated into a new release like new modules that improve security, connectivity, data parsing and so on. Finally, how many of those 60,000+ GPL projects are truly being actively maintained?

The evolution of a license is not extraordinary. The expectation that 40,000 OSS projects or a reasonable fraction thereof, most of which have no direct funding and nominal staffing, will immediately announce new releases is extraordinary.

While it is interesting to look for that "big bang" of support, where suddenly GPLv3 is everywhere, support in real life is slow, deliberate and pervasive. It does make better headlines to quote big numbers and move on to the next thing, the reality is that the GPLv3 license is an updated tool used in the creation of open source software, and the big numbers of support have been there from the start.

A software developer managing a project may choose to “support” GPLv3, but his support will be reflected with its governance of a specific release. Either, a developer will choose to relicense an existing release. This could cause problems with incompatible code trees for the same code, thereby stifling growth of the project. It could also impact the ability of the developer to provide support and fixes for both code trees identical aside from licensing. From what we have seen in practice, GPLv3 can be supported by a project, but such support is associated to a specific release.

Taking into account that of the 60,000+ projects listed as GPL, perhaps only 30% of these are “active”( http://asay.blogspot.com/2005/09/analyst-nature-and-size-of-open-source.html ), this gives a clearer picture of what support for GPLv3 should look like (http://blogs.cnet.com/8301-13505_1-9744527-16.html?part=rss&subj=TheOpenRoad). After allowing for only 30% of current Sourceforge projects to be “active”, and if 70% of these convert to GPLv3 (http://newsvac.newsforge.com/newsvac/07/04/13/2115242.shtml) , this means that we are really watching 12,600 active GPL projects that may consider GPLv3 licensing. If each of these have 2 significant releases annually on the average, this means that in the next 6 months, half of these projects will have the opportunity to show their support for the GPLv3, and the other half can show their support within six months to follow. Taken further, if there are 6,300 releases over the next 6 months, we would expect to see around 1050 per month. This would translate to around 35 per day in any given month. This week, we added nearly 50 new projects to our GPLv3 list, or almost 10 per day, more than doubling our rate from the week prior, and indicating our increased ability to attract contributed information from developers as well as find new GPLv3 projects. The GPLv3 was announced on July 29th, 15 days ago including a US holiday. Since that time, we started with ZERO and have added nearly 3000 “or later” projects, and over 170 GPLv3 and LPGLv3 projects. While we are not seeing 35 new GPLv3 releases per day yet, the site is new, the license is new, and our current rate is around 10 per day of just GPLv3 projects, or 200 per day including the “or later” projects.

Looking at these numbers, I will make the following closing analogy. Many sources seemed to expected a tidal wave, a torrent to rush in, of GPLv3 early adopters. Considering the reality of software development in the OSS world, small developers are quietly supporting the GPLv3, and such support is visible in the steady river of announced GPLv3 releases that we continue to discover daily. While I may be proven wrong over time, I feel that early estimates were conservative for GPLv3 adoption. I tend to believe that the license, like its predecessor, already is showing signs of strong and sweeping support. Time will tell, but the numbers tell the real story – while everyone fails to see the big wave, if we look down, the river of GPLv3 releases continues to flow at a steady and increasing rate.


Ernie Park

Correct your GPL License Links

Please double check your links on your site. If you make changes to your site, please keep us posted at http://gpl3.palamida.com:8080/searchResults.jsp. Just enter your project in the search field. If it is there, please select to edit, if new, give us the pertinent data. Under comments, let us know that you fixed the invalid URL.

Here is a quick list to help you make sure that you are pointing to the license that you intend to point to:


GNU General Public License (GPL) version 1 - http://www.gnu.org/licenses/old-licenses/gpl-1.0.txt

GNU General Public License (GPL) version 2 - http://www.gnu.org/licenses/old-licenses/gpl-2.0.html

GNU General Public License (GPL) version 3 - http://www.gnu.org/licenses/gpl.html

GNU Lesser General Public License (LGPL) version 2.1 - http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html

GNU Lesser General Public License (LGPL) version 3 - http://www.gnu.org/licenses/lgpl.html

More thoughts regarding invalid GPLv3 URL issue

My general thoughts, and personal opinion on the matter is as follows.I have seen several permutations of this phenomenon where the license in the distribution is different from that on the project's web site.

For example:

1. the GPLv2 is in the downloaded distribution, and the project web site specifically states the project is released under GPLv2, but links to the generic http://www.gnu.org/licenses/gpl.html which of course now links to the text of GPLv3;
2. the GPLv2 is in the downloaded distribution and the project web site says to either check the LICENSE.TXT file in the distribution for license info or to go to a link on the project web site, which it states *supersedes* what is included in the distribution (I've been looking, but at the moment I cannot find the project that did this);
3. the GPLv2 is in the downloaded distribution and the project web site says only that the GPL (no version number specified) applies to the project but actually shows the full text of the GPLv3 license on the project web site.

I am fairly certain that the license included in the distribution governs the user who downloads and installs software from that distribution. Otherwise there would be no certainty or consistency for end users about what license terms they are bound by, particularly if they receive the distribution via CD or some other media not downloaded and no files within the distribution give notice that any "later" or other version of a license applies. However, if a file in the distribution gives notice that current license terms are on the project web site, the end user may be obligated to check there before accepting and using the software. Then the issue of the generic GPL link comes into play. The generic link to the GPL license that so many projects use probably needs to be reevaluated and clarified by each project lead on a project-per-project basis. This is an additional burden on project leaders, probably unintentional on the part of the Free Software Foundation, but each project needs to determine whether they want to be pointing their GPL link to the GPLv3 or the GPLv2. I think that unless an end user is given notice within the project distribution that they need to go to the project web site for license terms or that some other license or version of a license applies, the end user can only be bound by what they find in the distribution.This is a tricky issue, and I'd be interested to see what, if anything, the FSF has to say about it.

Ernie Park

Check your GPLv3 link

We’re noticing quite a number of sites using the GPL license that have not updated their license information since the GPLv3 release. As a result, users may be unsure of which license version the site intends to use. Here’s the situation – many sites have a license FAQ or similar section in which they say “we use the GPL” or maybe the LGPL, and link to the FSF site. The FSF link now takes them to a license page which has been updated from GPLv2 to GPLv3. If the license FAQ page doesn’t specify a version, and we are noticing many don’t, the implication is that the project is now GPLv3. This may be what the project intended, but if not, it would be wise to include a GPL version number on the FAQ site, and update the link.

If you make this type of change, please let us know and we’ll update our site with your info.

Opinions on GPLv3 Adoption

Matt Asay always has thoughtful commentary on the market, and we found his opinion on the GPLv3 license interesting. There is also an interesting TalkBack to Matt's blog from Giovani Spagnolo


For what's it's worth, our research indicates that GPLv3 adoption is likely going to be tied to new releases, since it is incompatible with existing GPLv2 licenses and most other licenses. A number of the GPLv3 releases that were announced do not exist beyond a roadmap and their presence along with a license file in a CVS repository.

Therefore, the “or later” does give us an indication of a conditional adoption, the near future will start to more clearly show the signs as many of the projects that we are watching, the ones that have 2 – 4 milestone releases a year, will have their next milestone release represent the new licensing.

Based on the signs so far, we are seeing a slight increasing rate of adoption over the short time since the license has been released.

--Ernie Park

Thanks for the feedback

We have had some excellent feedback and suggestions in the couple of days since we launched the site, thanks. A couple of quick responses. First, our reported numbers were incorrect briefly over the weekend after we modified our query. It has been fixed, sorry for the glitch. Second, several people have asked why we removed the number of projects with 'intent to adopt'. We are still tracking projects that have indicated they are considering a license switch, but our intent is to focus on actual conversions, which we can do now that the GPLv3 and LGPLv3 licenses has been finalized and released. Finally, we will be adding a few features to make the site more transparent, so please stand by for those. We appreciate your comments, please let us know how we are doing at info@palamida.com.