It's possible to be an ardent supporter of open source development and not be a fan of copyleft and the General Public License. In this article the authors -- software developers -- relate how they came to embrace copyleft, became disillusioned with its limitations, and consequently turned away from it.
We come in praise of voluntary contributions.
As the open-source  phenomenon has manifested itself as a viable development model, commercial corporations  should think out their position on the open-source development model, including licensing issues.
We believe the open source community should do the same, and that those who learn to cooperate will benefit the most. We believe that this cooperation should be based on mutually acceptable terms, and that the best basis for cooperation is voluntary contributions.
Given that, we have come to see copyleft as a hindrance to this cooperation, as it only addresses the concerns of one side. We believe copyleft licenses are selected too often on an unfounded fear of exploitation by commercial corporations. In this article, we will explain why we choose not to release our open-source software under a copyleft license.
It is important to understand that we are not arguing against copyleft per se. We acknowledge the role of copyleft as a catalyst, and we believe there continues to be a place for it.
We are are arguing that copyleft should not be the default choice when developers of open-source projects select a license. There are many different reasons for contributing to open-source software, and these reasons should be respected to the largest extend possible.
The changes in our life must come from the impossibility to live otherwise than according to the demands of our conscience [...] not from our mental resolution to try a new form of life.
|--Leo Tolstoy (1828-1910)|
When we started contributing to the open-source community nearly a decade ago, we put all our source code under the GNU General Public License (GPL), because it was widely used and we somehow felt that the concept of "software freedom" was important. As software developers we were especially enchanted by the idea of unlimited access to source code, as it provided an unparalleled opportunity to learn from others. Furthermore, we liked the protection against exploitation from commercial corporations, and we felt it was only fair to expect that whoever modified or expanded our software should return those changes: quid pro quo .
But when we chose the GPL as the license of our projects, we did not fully comprehend the implications it had, nor that we were indirectly supporting a radical and vocal political movement. Over the years, we gradually became more uncomfortable about using the GPL. Our most fundamental problem with the GPL was its extensive scope. The GPL required that the source code of everything that went into the executable should be made publicly available under terms that were compatible with the GPL. There was no notion of proportional fairness; the quid pro quo was in reality a quodque pro quo . We came to realize that it was unethical to impose our ideas on the efforts of others.
The first stage of our transition began when the Mozilla Public License (MPL) was released. This copyleft license with a file-based scope was much more in alignment with our perception of freedom, because it allowed more fine-grained distinction between "my work" and "your work". If nothing else had happened, then we would still use the MPL today.
But then another peculiarity of the GPL came back to haunt us. The GPL disallows combinations of GPL-covered code with code covered by other licenses, if those licenses have "further restrictions" [GPL section 6]. In the absense of legal precedence, the compatibility between the GPL and other licenses is being decreed by the Free Software Foundation.
To our dismay we found the MPL on the list of incompatible licenses, even though we felt that they shared the same spirit, only deviating in scope. For us, the compatibility problem was not a problem per se, because we had no intentions about using GPL-covered code in our projects. Instead, we wanted to be forthcomming toward the GPL-covered projects that wanted to use our MPL-covered code in their projects. So we started investigating alternatives.
The obvious alternative was to use a disjunctive GPL/MPL dual-license, which would allow anyone to fork off their own project using either one of the licenses. The Free Software Foundation has already endorsed disjunctive licenses. Our problem with the existing disjunctive dual-licenses was that they allowed the removal of one of the licenses. This could mean that our code could be forked as GPL-only code, which would re-introduce the compatibility problem by prohibiting the combination of this new fork with MPL-covered projects; or vice versa. We then investigated the possibility of adding a clause to ensure that both licenses would be an available option to anyone in the future. The Free Software Foundation claimed this was incompatible with the GPL, because (simply put) it was not possible to create GPL-only forks of the software. Although we disagreed, we decided not to proceed further with this idea.
The second stage of our transition came when we started looking into the more amendable disclaimer licenses , such as the modified BSD license and the MIT license. Initially, we felt apprehensive about abandoning copyleft completely, and we did not start looking at these disclaimer licenses because we felt attracted by them, but rather because we felt repelled by the uncooperative nature of the GPL. However, upon further reflection we came to the realization that our perception of software freedom did not harmonize with the copyleft enforcement mechanism. We believed in the freedom of developers to make their own choices about their own efforts. Contributors, not the original author, should decide if and how their own contributions should be made available. Copyleft would preclude such a choice.
Our fear of exploitation was overcome by observing that there is surprisingly little evidence of commercial exploitation, and that commercial corporations actually do contribute voluntarily.
A main motivation for choosing GPL is to prevent your code from being exploited. But rather than automatically choosing copyleft to prevent that exploitation, it's instructive to look at the issues around that, including whether you mind your code being exploited, and whether your code will gain or lose from developers in corporations using it. Also it's worth considering what it costs a corporation to exploit code, and even how code may benefit from such exploitation.
First, whether or not our code is exploited, we had fun developing it, we scratched our itch, and we learned a lot. We got ample feedback and met other developers through that feedback. While the "free riding" does nothing to further our project, it doesn't hinder it either. We weren't trying to make money off this project, and even if we were, copyleft wouldn't have offered us any protection since we could have been overshadowed by another organization using our code with better marketing resources.
Second, we believe most commercial corporations understand the need for contributing to open source projects. Even from a purely cynical point of view, contributing modifications back to the project makes sense, because it becomes easier to upgrade with future baselines of the software. This lets the open-source project take care of maintenance and future development, and lets the corporation leverage the work of the open-source contributors. Closed source forks do not gather as many contributors as open-source forks.
Fortunately, our experience is that most corporations are not purely cynical, and that they do contribute voluntarily unless there are strategical reasons against. We have received more corporate contributions, which generally are submitted by experienced developers and are of a high quality, on projects without copyleft. There are plenty of other examples where commercial corporations have contributed voluntarily (with or without copyleft), including the Mozilla web browser, the OpenOffice office suite, the Apache web server, the BSD operating systems ( FreeBSD , NetBSD , OpenBSD ), and the Enhydra application server to name some.
Next, we'll look at the costs a company must incur even to use free software, as well as some of the benefits to exploited code. Finally, we'll explain why we didn't go with the Lesser General Public License (LGPL).
Using open-source software has an inherent cost for commercial corporations. It is not simply a matter of downloading the software, plugging it into a project, and laughing all the way to the bank. Using open-source software in another project is akin to software or component reuse. This involves
Although we won't justify exploitation of code, it's worth pointing out that there are some positive effects, especially if you want to do business with the company doing the exploiting.
We are often asked why we don't use the GNU Lesser General Public License (LGPL). Although the LGPL is much more in alignment with our views -- so much so that we feel it ought to be called the Liberated General Public License -- there are a number of issues regarding the LGPL that we find sufficiently problematic to prefer other licenses.
We understand the reasoning behind the various issues, but we believe the disadvantages outweigh the advantages.
Our experience with developing open-source software without copyleft offers no support for the pervasive fear of exploitation. To the contrary, we have gained more in terms of contributions and collaborations by replacing copyleft with voluntariness.
Based on our experience, we advise open-source developers to use the least amount of copyleft necessary.
Although we believe that you are more likely to receive contributions from commercial corporations if you abandon copyleft, we can make no guarantees that this is going to happen. However, the use of copyleft does not guarantee contributions to your project either, as corporations may decide not to use your project because the scope of the copyleft is too extensive (quodque pro quo).
Intriguingly, when we changed the license of our software to be compatible with the GPL, we did not receive any contributions from the open-source people who had requested this change. We did receive contributions from commercial corporations, because our license allowed contributions to be made by their own volition.
 For convenience we use "open-source" (note the lower casing) to encompass Open Source , Free Software , and similar endeavours.
 Throughout this paper we will mainly assume commercial corporations with business models based on selling software as goods.
 quid pro quo: (Latin) One thing in return for another.
 quodque pro quo: (Latin) Everything in return for something.
We use the term "disclaimer license", because it most accurately
describes the purpose of the license.
These licenses consist of three parts:
(1) a copyright notice,
(2) a clause that says that the license must remain intact, and
(3) a warranty disclaimer.
The last part is intended to protect against legal actions if the software fails. These licenses are sometimes called "academic licenses" because of their origin.
Bjørn Reese is a software engineer working on complex cross-platform applications.
Return to the O'Reilly Network.
Copyright © 2009 O'Reilly Media, Inc.