Open Source Software – Licensing Issues or Not
The Wikipedia Encyclopedia describes open source as “practices in production and development that promote access to the end product’s sources.” Before the label open source was coined, developers and producers used a variety of phrases to describe the concept. In fact, earlier researchers used a process which is similar to open standards to develop telecommunication network protocols. Characterized by contemporary open source work, this collaborative process led to the birth of the Internet in 1969. Its application to software gained popularity with the emergence of the Internet. It is said that the open source label came out of a strategy session held at Palo Alto, California, in reaction to Netscape’s announcement that it planned to release the source code for its browser Navigator.
The politically correct version is that to clarify a potential confusion caused by the ambiguity of the word “free”, so that the perception of free software is not anti-commercial, the label open source (contributed by Chris Peterson) stuck. The official version is that it was to shed the confrontational attitude that had been associated with free software in the past and sell the idea on pragmatic, business case grounds to the commercial world. Whatever it may be, Netscape listened and released their code as open source under the name of Mozilla. That was the beginning of the contemporary open source movement, whose main champion today allegedly is the Open Source Initiative (“OSI”) which makes and continues to make a case for the open source software to the commercial world. Consequently, we have seen the application of the open source philosophy in other fields including biotechnology. Linus Torvalds, a finnish software engineer who initiated the development of the Linux kernel went as far as saying “the future is open source everything”.
According to the OSI, the case for open source software is simple – free access to read, redistribute and modify the source code of a piece of software results in a rapid evolutionary process that produces better software. Advocates of open source argue that when programmers can read, redistribute, and modify the source code for a piece of software, the software evolves. People improve it, people adapt it, people fix bugs. And this can happen at a speed that, if one is used to the slow pace of conventional software development, seems astonishing.
However, evangelists of free software have been at pains to clarify that open source software is not synonymous with free software. The philosophy of the open source movement is based on practicality and not ethical considerations while free software is based on freedom, not price. Borrowing from Richard M. Stallman, “free software” and “open source” describe the same category of software, more or less, but say different things about the software, and about values. While the two are not synonymous, both have a common enemy – proprietary software.
Critics of open source say that open source fosters an ambiguity of a different kind, in that it confuses the mere availability of the source code with the freedom to use, modify, and redistribute it. But open source doesn’t just mean access to the source code; the use of open-source software must comply with a number of criteria including as to re-distribution, depending on the license under which it is distributed. Different licenses require different criteria. For instance, under the GNU General Public License (GPL) published by the Free Software Foundation (FSF) for licensing free software, any work based on the program or any other derivative work must be licensed as a whole at no charge at all to all third parties under the terms of the GNU GPL, whereas an Apache License does not require derivative works to be open source. You can add your own copyright statement to modifications of a source code under Apache License and provide additional or different license terms and conditions for use, reproduction, or distribution of your modifications, or for any derivative works as a whole, provided your use, reproduction, and distribution of the work otherwise complies with conditions of the Apache License. Similarly, there is no requirement that any derivative work created under an Academic Free License (AFL) or a Berkeley Software Distribution (BSD) License, should be distributed at all, or for free if distributed. Further, any derivative work need not be free and one can charge for it as you would for proprietary software.
The subtle licensing criteria between open source generally and free software is further highlighted when you consider that some licenses are not compatible. For instance, programs/source code distributed under PHP License is not compatible with GNU GPL since GNU GPL is a copyleft license. Which raises a couple of licensing issues:
(1) Why are there different criteria under different licenses for open source software? Presently, there are about 54 licenses certified by OSI as open source – a tribute to OSI’s philosophy – which many now see as an unnecessary proliferation of licenses, an issue that forced OSI to admit that –
“OSI’s approach on the development and distribution problems involved building as many different bridges as possible between developers and the corporate world. In doing this, we accepted a proliferation of new licenses. This is a problem in that although physical bridges between communities don’t interfere with each other, licenses do. Interference between different open-source licenses is now perceived as a sufficiently serious problem that OSI has become as a victim of its own earlier success.”
To address the issue of proliferation, OSI plans to take all existing OSI approved licenses and group them into three tiers: (i) preferred, (ii) recommended but not preferred, and (iii) not recommended. This is likely to create more confusion. One would then ask why an OSI certified license would be OSI “not recommended” license. Would a ‘not recommended’ tag not be deemed as de-approval (though OSI says its not). It would be ‘preferable’ not to have certified such license as OSI approved in the first place.
(2) Why are some licenses not compatible with others? We may well appreciate that compatibility goes beyond the issue of license proliferation. For example, the FSF considers all versions of the Apache License incompatible with Version 2 of the GNU GPL. About version 2.0 of the Apache License, they say:
“The Apache Software License is incompatible with the GPL because it has a specific requirement that is not in the GPL: it has certain patent termination cases that the GPL does not require. (We don’t think those patent termination cases are inherently a bad idea, but nonetheless they are incompatible with the GNU GPL.)”
Apache Software Foundation (ASF), which publishes the Apache License, has adequately replied to FSF’s statement, stating that ASF does not share the same goals as FSF. For the time being, the controversy rages on. Compatibility is really a relationship issue; free software movement and the open source movement can be likened to two political camps within the free software community. While it can be argued that GNU GPL is not compatible with a number of licenses because the philosophy behind GNU GPL is freedom – which proponents of free software have cried themselves hoarse from the rooftops for decades now – GNU GPL itself publishes a list of free/open source software licenses that are GPL incompatible, distinguishing between non-copyleft and ‘not strong copyleft’. Even, copyleft licenses like xinetd have also not been spared and was held incompatible because it places extra restrictions on redistribution of modified versions that contradict the redistribution requirements in the GPL. Don’t they share the same goals? Yet the free software movement has complained that to be lumped together with open source software is restrictive for free software since open source software allegedly has a much weaker criterion than free software. Then one may ask, what is the criteria for determining compatibility with GNU GPL even for copyleft free software licenses? At least FSF is not intending to classify licenses in the same manner as OSI – for now.
(3) Don’t some of these licenses support a ‘one way’ street attitude described by John Udell in the Open Source Citizenship where developers are encouraged to take and not give back to the community. Or it could be akin to the situation described by Stallman where commercial developers invited to the “Open Source Developers Day” meeting in August 1998 said they intend to make only a part of their work free software (or open source) since the focus of their business is on developing proprietary add-ons (software or manuals) to sell to the users of the free software. According to Stallman, those developers requested that this should be regarded as legitimate, as part of the community, because some of the money is donated to free software development. Whichever way you look at it, it is a dangerous trend for the future of open source software.
The ideals and philosophy of open source is threatened by the ‘marriage of convenience’ of open source with the commercial world, which makes a strong case for the traditional free software movement. It is, perhaps, taking the adage ‘making a case to the commercial world’ too far. Eventually, there may such a blend of both the open source movement and the commercial world that we are not able to distinguish between the two. The enemy would have sneaked in unawares and made sport of all ideals and philosophies of the open source movement.
These are all valid concerns that the open source community needs to address. In closing I have a word of advise for the open source movement from my grandmother which I find appropriate – If you don’t know where you’re going, remember where you’re coming from.
1. Wikipedia Encyclopedia
2. Open Source Initiative
3. The Free Software Foundation
4. The Apache Software Foundation
5. Richard M. Stallman in “Open Sources: Voices from the Open Source Revolution”
6. John Udell “Open Source Citizenship”.