Policy DevCenter    
 Published on Policy DevCenter (http://www.oreillynet.com/policy/)
 See this if you're having trouble printing code examples


Working Without Copyleft

by Bjørn Reese and Daniel Stenberg
12/19/2001

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 [1] phenomenon has manifested itself as a viable development model, commercial corporations [2] 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 Transition

 

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 [3].

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 [4]. 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 [5], 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.

The Fear of Exploitation

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).

The Exploitation Hurdle

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

Assessment
A thorough survey is needed to find the software, and assess that it fulfills a given set of requirements.

Validity
The corporation must validate the correctness and quality of the software. This is usually a major task, because they have no intimate knowledge about the software, and thus are forced to construct more elaborate test suites. Poor documentation can make this even harder.

Integration
Once the software has been chosen, the corporation must learn to use and integrate it into their project.

Development Environment
A tight integration requires that their development environment and tools are compatible with that of the open-source software.

Non-Functional Requirements
It must be determined whether the software is sufficiently reliable, responsive, scalable, configurable, and so on. Error handling and other cross-cutting concerns must be compatible with the requirements of the commercial products.

Maintenance
Because the corporation has contractual obligations for its products, they must ensure the future maintenance of the software, even if the open-source project is abandoned.

Benefits of Exploitation

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.

Interoperability
If the corporate application is based upon our code, it has a better chance of being compatible with our application. This makes it significantly easier for us to maintain interoperability between their application and ours.

Reverse-Engineering
If a corporation uses our code in its product and adds their own extensions, then it is easier for us to reverse-engineer those extensions rather than having the corporation write its code from scratch. This is because we are intimately familiar with our code, and thus a portion of the corporate code.

Reverse Exploitation
Corporations often spend many resources trying to enhance product functionality or usability. Because our source code is similar to theirs, and thus our applications are likely to be alike, it is easier for us to reuse their ideas in our project, and thus leverage on their investments. Keep in mind that reuse is not limited to code; we can also reuse ideas, designs, and functionality.

Standardization
As our code becomes more widely used, it increases the chance that our interface or protocol becomes a de facto, and maybe eventually a de jure, standard. An example of this is the TCP/IP protocol.

Endorsement
A corporation has deemed our code good enough to be included in a product that they have to vouch for. We could put that on our curriculum vitae, or maybe even consider applying for a job there.

Why not LGPL?

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.

Conclusion

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.


Footnotes

[1] For convenience we use "open-source" (note the lower casing) to encompass Open Source , Free Software , and similar endeavours.

[2] Throughout this paper we will mainly assume commercial corporations with business models based on selling software as goods.

[3] quid pro quo: (Latin) One thing in return for another.

[4] quodque pro quo: (Latin) Everything in return for something.

[5] 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.