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
- A thorough survey is needed to find the software, and assess that it fulfills a given set of requirements.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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]