The recent publication of version 3 of the Free Software Foundation’s (FSF) GNU General Public License (GPL) (http://www.fsf.org/news/gplv3_launched) was an event that probably was not even noticed by most users or SW companies. The fact is, however, there are some changes here with the new version (v3) that could fundamentally diminish the present benefits the industry enjoys from the open source paradigm.
First, let me clarify what I mean by “Open Source”. At the highest level I believe “Open Source” is a development process whereby a community of developers collaborate, innovate and share code to produce software. Of special importance is that each community determines its own business models and software licensing policies. Open Source is often free to license but that does not imply, of course, this there are no costs to deploying this software. Companies and individuals generally make money in other ways – usually by providing services and support. While I said the code is “usually” free, I do also believe that if a community wants to allow its software to be licensed for money then it should be able to do so, even if the code is freely available. You might think that this would stifle innovation, but it actually does the opposite.
Caveats and incentives have always existed with most open source licenses to insure that code that directly enhances a given open source project would always be “given” back to the community. This is clearly desirable to maintain consistent functionality, reliability and drive competitiveness (of the open source project). This works well for almost everyone. It gives companies the ability to contribute to the “core” while innovating in their particular area or application. The company can add value and maintain the right to sell its own applications.
About The GPL
There are many licenses that can be used for open source projects, over 50 licenses alone are listed by the Open Source Initiative (http://www.opensource.org/licenses/alphabetical). One of the most popular ones is the GPL. The GPL was first published in February, 1989, with version 2 released in June, 1991.
I don’t want to go into a lengthy history of GPLv2 here, but suffice it to say that by a combination of intent and accident, GPLv2 created a very broad software community of diverging political and economic beliefs. GPLv2 created a world in which not only is core software technology actively maintained and improved by its users, but also one in which all sorts of proprietary innovation beyond the core software technology is leveraged based on that core technology.
The results of these efforts, I believe, have been to accelerate innovation. Companies have been able to focus their “proprietary” efforts on specialized functions while sharing from (and contributing to) core technology via open source and collaborative efforts.
The net result has been broad sharing of development costs and efforts across large communities that benefits all users of the core software in terms of cost, features, and compatibility across systems.
So What is the Big Deal About GPL v3?
There are three primary areas that concern me about GPLv3:
- New restrictions on combining open source and proprietary code
- Incompatibility between GPL v2 and GPL v3
- Patent licensure
New restrictions on combining open source and proprietary code
The newly aggressive provisions about what code combinations must be covered by GPLv3 create cumbersome issues for anyone, proprietary or open, who wants to combine code under another license with GPLv3. GPLv3 provided only an eleventh-hour one-way compatibility with Apache. So Apache code can be combined with GPLv3 code under the GPLv3 license but not under the Apache license. This is not a gift to the open source community.
For developers who use GPL code for “nuts and bolts” and innovate around it, GPLv3 is harder to work with than GPLv2 and much, much harder than Apache or BSD. It isn't impossible - just the equivalent of a full employment contract for many lawyers. This is not a direction I see as useful, it’s just added confusion.
Also by clamping down on the allowed means of mixing software, GPLv3 rules out some of the current types of proprietary innovation, thereby removing some existing incentives to contribute to the maintenance and improvement of open source software. This sacrifices investment in open source software in order to pursue political principles, and I wonder whether that tradeoff is the wisest move.
Incompatibility between GPLv2 and GPLv3
GPLv3 is a new license in some important respects and not a graceful evolution of GPLv2. The two are incompatible, so there’s a definite “my way or the highway” feel. All of the projects that are currently licensed under GPLv2 must make a decision whether a migration to v3 is worthwhile. As observers there’s no knowing when, if and how long that might take.
In the interim, this incompatibility restricts combinations of GPLv2 code with GPLv3 code. Open source developers and distributors must carefully track the GPL licensing of software that passes through their hands, as GPLv3 prohibits distribution of some GPLv2/GPLv3 code combinations that are acceptable when all the code is under GPLv2. This expenditure of effort by open source participants is an unfortunate side effect of GPLv3’s incompatibility with GPLv2, and it may rise to the level of rewriting code that cannot be re-licensed.
With GPL v3 the FSF attempted to clarify issues related to software patents, but writing tactical patent provisions into a new license is not a good strategic move. Two examples of tactical provisions are the grandfathering of the Microsoft/Novell agreement, and the special exemption of broad patent cross-licensing from requirements that patent licenses are accompanied code. Only a few very large companies, such as IBM make money from the practice of broad patent cross-licensing, so why should this provision be in there?
Sooner or later, the decision to have GPLv3 pick and choose among the means of exploiting software patents will rebound to the license’s detriment; having a fundamental software license become a tactical weapon in software patent battles is not a good strategic move because it risks that software license becoming a shaky foundation.
Summary – A Step Backwards?
It’s too early to tell whether the FSF went too far with GPL v3, but I’m starting to think so. I’m worried about the heavy handed stance on mixed uses; I’m concerned with license compatibility confusion and I think adding tactical patent provisions will degrade the value of the license of time. All of these changes could ultimately undermine the level of collaborative innovation that has happened under the present licensing systems. Ultimately the success of GPL v3 rests in the hands of the open source community, so let’s see whether they adopt it or not.