| How GPLv3 tackles license proliferation |
by Ciaran O'Riordan (Nov. 10, 2006)
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
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.
Related Stories:
(Click here for further information)
|
|
|
7 Advantages of D2D Backup
For decades, tape has been the backup medium of choice. But, now, disk-to-disk (D2D) backup is gaining in favor. Learn why you should make the move in this whitepaper.
4 Legal Reasons to Control Internet Access
The Internet is obviously a valuable resource for many organizations. However, many are exposed to legal liability concerns because they fail to control Internet access. Learn if you're safe in this white paper.
Rapidly Resolve J2EE Application Problems
Whether you are in the process of building J2EE applications or have J2EE applications already running in production, you must ensure that they deliver the expected ROI. Learn how in this white paper.
Load Testing 2.0 for Web 2.0
There are many unknowns in stress testing Web 2.0 applications. Find out how to test the performance of Web 2.0 in this white paper.
Build Better Games Online
For the game infrastructure providers, life is complex. Making money from games has become more complicated. Why? Find out in this white paper.
Building a Virtual Infrastructure from Servers to Storage
This white paper discusses the virtual storage solutions that reduce cost, increase storage utilization, and address the challenges of backing up and restoring Server environments.
Gaining Faster Wireless Connections with WiMAX
Welcome to what is quickly becoming the hyperconnected world where anything that would benefit from being connected to the network will be connected. Learn more in this white paper.
Is Your Desktop a Security Threat?
The new wave of sophisticated crimeware not only targets specific companies, but also targets desktops and laptops as backdoor entryways into those business’ operations and resources. Learn how to stay safe in this white paper.
Increasing SAN Reliability by 100 Percent
Storage area networks (SAN) are a strong part of storage plans. Learn how to increase your reliability and uptime by 100 percent in this case study.
|
|
|
|
|
Use of this site is governed by our Terms of
Service and Privacy Policy.
Except where otherwise specified, the contents of this site are copyright © 1999-2008
Ziff Davis Enterprise Holdings Inc. All Rights Reserved.
Reproduction in whole or in part in any form or medium without express written permission of Ziff Davis Enterprise is
prohibited. Linux is a registered trademark of Linus Torvalds. All other marks are the property of their respective owners.
news feed