front | blog | photos | contact | projects

This is the original article O'Reilly published on the 20th of December 2001. The O'Reilly one is slightly edited.

Working Without Copyleft

Bjørn Reese

Daniel Stenberg

This paper does not offer any legal advice.

Introduction

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

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

Exploitation

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.

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 is forced to construct more elaborate test suites.

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 if the software is sufficiently reliable, responsive, scalable, configurable, etc. 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 their products, they must ensure the future maintenance of the software, even if the open source project is abandonned.

Benefits of Exploitation

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.

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, it is easier for us to reverse-engineer those extensions, than if the corporation had written their 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 spent 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 widespreadly 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.

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

Appendix: Why not LGPL?

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.



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