Working Without Copyleft - O'Reilly Media

Listen Print

Working Without Copyleft
Pages: 1, 2

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.

The scope of the LGPL is too coarse-grained. The scope is furthermore open to interpretation. It is limited to some fuzzy notion of functional entities ("a collection of software functions and/or data prepared so as to be conveniently linked with application programs"). What if an LGPL-covered library is used by another library or a software component such as an embedded Web browser? [LGPL, section 0]
The LGPL contains a provision for anybody, at any time, to convert the license irreversibly to GPL, effectively creating a the GPL-only fork of the converted code. [LGPL, section 3]
The Free Software Foundation controls the license. They can release a new version of the license, which then will automatically apply to our software. Although we do not expect the Free Software Foundation of making changes that deviate from the spirit of the current versions, they could make clarifications that are contrary to our intentions. For example, they may clarify that the result of aspect-oriented weaving is subject to the terms of the LGPL, whereas we had intended that it is not. Another concern is who will be in charge of the Free Software Foundation 10 years from now, or what happens if the Free Software Foundation is discontinued? [LGPL, section 13]
Patent issues and restrictions imposed by law are dealt with by the LGPL in the GPL's "my way or no way" style, namely that such restrictions automatically terminate all your rights to use the LGPL-covered software. [LGPL, section 11]
Object files must be made available, when distributing executables. This may seem like a mere inconvenience, but it can impose a serious configuration management overhead, which can render the term impractical. [LGPL, section 6a]

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.

Use a license with the smallest copyleft scope that suits the project. For example, in an increasing order we have disclaimer licenses with no scope, the MPL with a file-based scope, the LGPL with a library-based scope, and the GPL with an executable-based scope.
If copyleft is necessary, then put only the application specific code under copyleft. For instance, a hash table or socket wrapper is not application specific and can be reused in other projects. Therefore, it should have less copyleft than the application specific code to prevent indirectly determining the copyleft scope of projects where this code is going to be reused. If you are going to use a mix of licenses, then please note that GPL-covered code can only be combined with code covered by GPL-compatible licenses.

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.