Standing Against License Proliferation
May 28th, 2008 | Published in Google Open Source
The proliferation of Open Source licenses has been a known problem in the community for a few years. As the number of licenses grows, the possible combinations and interactions skyrocket. This makes it very difficult to mix code from multiple sources because the licenses may be incompatible or create burdensome notification or publishing requirements. Many people in the community have been talking about how to stem the tide of new Open Source licenses, and how to reduce the existing set, in order to simplify the legal framework surrounding the Open Source universe.
When we set out to create the project hosting service on Google Code, I turned to my colleague Chris DiBona and said, "Dude. I think we have an opportunity here. What do you think if we offer only a limited set of licenses?" He replied, "Hunh... Cool idea!" Fifteen minutes later, we had a list of six licenses: Apache License v2.0, (New) BSD, MIT, GPLv2, LGPL, and MPL 1.1. About four weeks before launch, Robert Spier pointed out our oversight in not remembering the Artistic/GPLv2 dual-license used by the Perl community. Whoops! We launched with those seven licenses (and added GPLv3 a year later). Further, we do not allow any dual-licensing (other than the Artistic/GPLv2 combination), nor the dreaded tri-license. I'm not going to get started on what I think about that.
Two years later, we are nearing 100,000 projects hosted on Google Code. The trend around licensing is obvious: GPLv2/GPLv3 represent 42.6% of the projects, and Apache is 25.8%. MIT, BSD, and LGPL are at about 8% each, Artistic at 3.5%, and MPL 1.1 at a mere 2.7%. This follows my own observation about how people license their projects. If they are advocates of Free Software, they will choose GPL; advocates of Open Source will choose Apache (a more modern and thorough permissive license, compared to BSD or MIT). And this is exactly what I recommend to people: choose GPLv3 or Apache v2 based on your personal philosophy.
People very rarely choose licenses like MPL, EPL, or CDDL unless they are part of those communities (Mozilla, Eclipse, and Sun, respectively). Unfortunately, licenses that are typically community-specific also tend to create islands of code. And while there is no good reason that I cannot lift code from an EPL'd Eclipse plugin and incorporate it into some Apache-licensed server application that I'm writing, that kind of blending just does not happen. Based on the low popularity, and in an attempt to limit this artificial segregation of code, we plan to remove the MPL from the set of licenses on our project hosting service (for new projects; existing projects will not have to relicense).
At Google, we believe that the software community would be much better served by a reduction in the number of licenses used by software projects. We hope to steer people in that direction with our license choices on Google Code. We also highly recommend choosing the Apache License or GPLv3 for your projects.