Foreword: This guest column by a representative of the Free Software Foundation Europe (FSFE) discusses proposed provisions in a future version 3 of the GNU General Public License (GPLv3) that are intended to reduce open-source license proliferation, by making the GPL more flexible.

---

How GPLv3 tackles license proliferation

by Ciaran O'Riordan

Spread the word: digg this story

The most obvious way to limit license proliferation is to write new licenses as rarely as possible. So while updating the GPL, it's good to be thorough so that it doesn't have to be done too often. What any one license can do to lessen the problem is less obvious, and this is an area where GPLv3 is breaking new ground. In case the more controversial provisions of GPLv3 have overshadowed the provisions that tackle license proliferation, I've put together this summary as a discussion primer.

The first way that GPLv3 tries to tackle license proliferation is by being adaptable to the needs of various projects. The second is that GPLv3 will be compatible with more Free Software licenses, which will ease one of the main problems created by license proliferation.

Reducing reasons for writing new licenses

The GPL's warranty and liability disclaimer is one example. It's not the only acceptable disclaimer, and no amount of time spent in public consultation will yield a disclaimer that is perfect for everyone. So, GPLv3 says that people can add any further disclaimers of their choosing to the software they write.

A simple idea, really. If people need some flexibility, and if the GPL can accommodate them without compromising its job, then the GPL will be flexible. The philosophy is that the GPL should be a viable option for as many people as possible. Hopefully this will mean fewer people feel the need to write new licenses.

Additional warranties are not the only additional requirement that can be added. Probably the most substantial additional requirement that GPLv3 allows is that regarding patent retaliation.

Patent retaliation works by terminating the distribution rights of people who initiate patent litigation against users of the software. The aim is to prevent people from distributing GPL'd software and then suing downstream recipients for doing things that the license permits.

The patent retaliation clause in GPLv3 is very narrow because it is not so clear when patent retaliation is beneficial, and it is clear that it can backfire in some cases. For the cases where it is clear it won't backfire, but it is not clear that it will be useful, GPLv3 permits the adding of further patent retaliation clauses.

So, if a project wants to use GPLv3, but thinks that broader patent retaliation is necessary, it can use GPLv3 and exercise this option rather than writing a new license (see section 7b5).

Compatibility

As well as tackling causes of license proliferation, GPLv3 also attempts to curb the problems created by license proliferation.

One of the main harms of license proliferation — probably the main harm — is license incompatibility. When two Free Software projects have incompatible licenses, they can't share code. This doesn't help Free Software developers at all.

To prevent distributors from subverting the GPL, the GPL has to state that no additional restrictions can be placed on modified versions. An unfortunate down side of this is that each license that says this is usually incompatible with each other similar license.

From version 3 onward, the GPL says certain, carefully defined, additional requirements that are described in the license can be added — and no more.

The GPL will not become compatible with all Free Software licenses. Doing that is not possible without compromising the goals of the GPL. But it should gain compatibility with some licenses, notably the Apache Software License.

I've seen the question asked in a few places, whether these options could be used in configurations that would make two GPLv3 projects incompatible, and the answer is no. The extent to which GPLv3 increases compatibility is the same as the extent to which it is more compatible.

Version 1 motivation

As an interesting historical note, version 1 of the GNU GPL was actually written, in 1989, to solve a license proliferation problem. Before 1989, the GNU project used different licenses for each project — there was the Emacs GPL, and the GCC GPL, and the GDB GPL — and these projects couldn't share code, because the licenses were incompatible.

So Richard Stallman wrote a single GPL for the GNU project, thus reducing the number of licenses in existence, and solving the problem of incompatibility.

That was a different scenario. Today's license proliferation problems didn't exist when GPL versions 1 or 2 were being written, so now we need new remedies.

Conclusion

A software license can't solve either problem completely, but the GPLv3 should do what it can. So, if you see how the flexibility should be better defined, or if you see a way it can do more, without compromising the goals of ensuring the all recipients are free to use, modify, and redistribute the software, please submit it to gplv3.fsf.org. Comments submitted there go to four teams comprising 130 people, who research each comment.

Please note: The opinions expressed in this guest column are those of its author, and not necessarily of the management of LinuxDevices.com.

---

About the author: Ciaran O'Riordan has been working with FSFE since April 2005 and is a contributor to the group's GPLv3 work. For more information on GPLv3, how to participate in the consultation process, and recordings and transcripts of previous events, see FSFE's GPLv3 project.

---

Talk back!

---

LinuxDevices.com's discussion board for GPL-related matters can be found here.

---

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.