This is the original article O'Reilly published on the 20th of December 2001. The O'Reilly one is slightly edited.
Copyright © 2001 Bjørn Reese and Daniel Stenberg
We come in praise of voluntary contributions.
As the open source  phenomenon has manifested itself as a viable development model, commercial corporations  should excogitate their position on the open source development model, and the open source community should do vice versa. 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 is voluntary contributions.
We see copyleft as a hindrance to this cooperation, as it only addresses the concerns of one side. It is our impression that copyleft licenses are selected much too often due to an unfounded fear of exploitation by commercial corporations. In the following 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; that we acknowledge the role of copyleft as a catalyst, and that we believe that there continues to be a place for copyleft. Instead we are arguing that copyleft should not be the default choice when open source projects select a license; there are many different reasons for contributing to open source software, and that 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 unparallelled 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 .
When we initially chose the GPL as the license of our projects, we did not fully comprehend the implications it had, and that we were indirectly supporting a radical and vocal political movement. Over the years we gradually became more and more uncomfortable about using the GPL. Our most fundamental problem with the GPLwas 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 were no notion of proportional fairness; the quid pro quo was in reality a quodque pro quo . We realized 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, we would still have been using 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 towards 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 had already been endorsed by the Free Software Foundation. Our problem with the existing disjunctive dual-licenses were 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 abandonning 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.
Let us investigate the fear of exploitation in further detail.
We find it instructive to start by considering whether our motives for developing open source software is compromised by exploitation. Whether or not exploitation takes place, we did scratch our itch, we did have fun during development, we did learn something, and we did get ample feedback. Although "free riding" does nothing to further our motives, it does nothing to hinder them either. We are not on a crusade against proprietary software. Economics is not a motive for us either, and even if it were, copyleft would not offer any protection as we could easily be ousted by any entity with more marketing experience, better financial backing, or better branding.
Most commercial corporations do understand the need for contributions. They are well aware that "scorched earth" tactics will hurt themselves in the long run. Even from a purely cynical point of view, it makes sense to contribute modifications back to the open source project, as it becomes easier to upgrade with future baselines of the open source software. This makes it possible to let the open source project take care of maintenance and future development, and thus to leverage on 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) - 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.
There are two more issues to take into consideration, namely the costs and benefits of exploitation.
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
There are some positive effects of such an exploitation. We are not trying to justify the exploitation, but are simply trying to make the best of the situation.
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 advice 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 the commercial 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.
We are almost always asked why we do not use the GNU Lesser General Public License (LGPL). Although the LGPL is much more in alignment with our views, so much 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 would like to emphasize that we do understand the reasoning behind the various issues, but that we feel the disadvantages outweights the advantages.
 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 which 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.