Open Source Software

 Last update: 2005/03/10

If art is defined as something that people take pleasure in producing, that contains something intrinsically beautiful and, therefore, that connoisseurs can admire, some pieces of software could be defined as pieces of art. As for all arts, you have the practitioners and the professionals. There are people who produce an artistic piece just because they like to do that and take pleasure in seeing others nod in approval at it and then others who do the same in hope or certainty of receiving a reward. 

Probably there is nothing more emblematic than the great project that built the Internet. You could see people taking pleasure in inventing protocols, debating the merits of their own ideas, and implementing them in some smart piece of software knowing other colleagues would look at it and find other smart ideas on how complex processing could be expressed with a handful of computer instructions. Add to it the sense of fulfillment that came from the idea of contributing to building the communication infrastructure of tomorrow serving the whole of mankind. Finally also add that all this happened largely in the academic environment where people were paid based on a contract and that performance review, at the time the contract work was due, just had to check how smart protocol ideas and software implementations had been. These few hints suggest how the world that produced the Internet can be considered as a sort of realisation of Plato's political ideas. 

On another occasion I have compared - absit iniuria verbis - that memorable venture with the work that my ancestors who lived in the lower parts of the Western Alps near the city of Turin had done when they cobble-stoned the paths criss-crossing the mountains behind their houses. They did that with the same zeal and sense of duty because it was more comfortable for everybody to have cobble-stoned paths instead of leaving them in the state in which the steps of millions of passengers had molded them. And everybody tried to to his best in the hope that others would admire the perfection of the work done. The only difference may be doing that work was probably not the free decision of those mountain dwellers but more due to the local communal authority that imposed corvées on them during winter when work in the fields was minimal. 

Next to the world of people taking pleasure in writing smart computer code, however, there were other people who just dealt with this particular form of art in a more traditional way. In the early 1960s, computer manufacturers freely distributed computer programs with mainframe hardware. This was not done because those manufacturers did not value their software, but because those programs could only operate on the specific computer platform that software went with. But already in the late 1960s, manufacturers had begun to distribute their software separately from the hardware. The software was copyrighted and "license", instead of "sale", was the legal form under which the developer of the software allowed use of his product. 

Copyrighted software is the type of software for which the author retains the right to control the program's use and distribution, not unlike what authors and/or publishers have done for centuries with their books. In the 1970s "public domain" software in source code came to the stage. This type of software has the exact opposite status of copyrighted software because by putting the software in the public domain, the rights holder gives up ownership and anyone can use it in any way he chooses and the original rights holder has no say over its use. In the rest of this page I will mention several categories of software. The reader may like to consult http://www.gnu.org/philosophy/categories.html for a more extended treatment of the subject.

Since early Internet times, access to User Groups and Bulletin Board Systems (BBS) was already possible. These groups passed around software for which the programmers did not expect to be paid, either because the program was small, or the authors offered no support or for other reasons such as because the author just wanted the rest of the world to see how smart he was or how good he was in donating something that benefited other people. One should not be too surprised if, besides public domain software, such user groups and BBSs passed around pirated commercial software. 

In 1982, two major programs for the IBM PC were published: a communication program called PC-Talk developed by Andrew Fluegelman and a database program called PC File developed by Jim Knopf. Even though these were substantial programs, the authors decided to try the spontaneous distribution networks, instead of marketing the programs through normal commercial channels. Users could freely copy their programs, but were reminded that if they wanted the authors to be motivated to continue producing valuable software that people could freely use, they should send money to the authors. 

Fluegelman called this new software distribution method "Freeware" and trademarked the name, but lost control over PC-Talk source code when several "improved" versions of the program appeared. So Fluegelman did little to continue to develop and promote PC-Talk, while Knopf eventually built a multi-million dollar database company with his PC-File. This idea set a pattern that others followed. One of them was Bob Wallace with his PC-Write, a word processing program, which he also developed into a successful business. PC-Write was free to try, but required a payment if the user continued to use it. These three major applications became popular with major businesses and established the credibility of Freeware as a source of high quality, well-supported software. As the name "Freeware" had been trademarked, the user community settled on "shareware", the name used by Bob Wallace for his PC-Write. 

In 1984, Richard Stallman promoted the idea of "Free Software" and formed the Free Software Foundation. With the help of lawyers he developed the Gnu's Not Unix (GNU) General Public License (GPL) and called the license "copyleft". This grants that the software is available for use and further development by others. GNU followers, starting from the founder of the movement, like to say that GNU software is free. This adjective does not represent unambiguous categories - not just the well-known ambiguity of the English language between "gratis" and "freedom" - and therefore I will refrain from using it. I will use instead the term "GNU license" because, even though most people would agree that the GNU license gives users "more" rights than, say, Microsoft gives users of its Word program, the GNU license is by no means "unrestricted". 

In summary the rights are: the freedom to distribute copies of the software, to receive the software or get it, to change the software or use pieces of it in new programs; and the obligations are: to give a recipient all the rights acquired and to make sure that recipient is able to receive or get the software. There is no warranty for free software and if the software is modified, recipient must be made aware that it is a modification. Finally any software patent must be licensed to everybody. 

A justification of the Open Source Software (OSS) approach is that it is a more effective way of developing software. If software is Open Source, this is the thesis, its evolution is facilitated because programmers can improve it, make adaptations, fix bugs, etc. All this can happen at a speed and effectiveness that conventional software development in corporate environments cannot match. 

The Open Source Initiative (OSI), a California not-for-profit corporation, has produced an Open Source Definition according to which OS does not just mean access to the source code, but also that the distribution terms must comply with a set of general criteria. These are summarised below with the intention of providing a general overview of the approach. Interested readers are advised to see the official document. 

1. Free Redistribution. There should be no restriction to sell or give away the software as a component of a complete package containing programs from other sources and there should be no royalty or other fee for such sale. 
2. Source Code. The program must include source code (or a means of obtaining it at little or no cost) and it must be possible to distribute it in both source code and compiled form. However, it is not allowed to distribute deliberately obfuscated source code, or in an intermediate form such as the output of a preprocessor or translator. 
3. Derived Works. Modifications and derived works must be possible and they can be distributed under the same terms as the license of the original software. 
4. Integrity of The Author's Source Code. It must be possible to have non-modifiable source-code if the license allows the distribution of "patch files" by means of which modifications at build time are possible. It must be possible to distribute software built from modified source code. Derived works may carry a different name or version number from the original software. 
5. No Discrimination Against Persons or Groups
6. No Discrimination Against Fields of Endeavour. 
7. Distribution of License. Those to whom the program is distributed need no other license. 
8. License Must Not Be Specific to a Product. 
9. License Must Not Contaminate Other Software. The license must not place restrictions on other software that is distributed along with the licensed software, e.g. there should not be an obligation for the other software to be open-source. 

An interesting case combining collaborative software development and standardisation in the context of a proprietary environment is the Java Community Process (JCP) started by Sun Microsystems in 1998 and revised in 2000. Companies, organisations or even individuals who have signed the Java Specification Agreement (JSPA) form the Community. Legally, JSPA is created by an agreement between each member of the Community and Sun that sets out rights and obligations of a member participating in the development of Java technology specifications in the JCP. 

Below is a brief description given for the purpose of understanding the spirit of the process. Those interested in knowing more about this environment are invited to see JSPA directly. The process works through the following steps:

1. Initiation is when a specification is initiated by one or more community members and approved for development by an Executive Committee (EC) - there are two such ECs targeting different Java markets - as a Java Specification Request (JSR). Sun, ten ratified members and five members elected for 3 years hold seats in the ECs. Once the JSR is approved, an Expert Group (EG) is formed. JCP members may nominate an expert to serve on the EG that develops the specification. 
2. The first draft produced by the EG, called Community Draft, is made available for review by the Community. At the end of the review, the EC decides if the draft should proceed to the next step as a Public Draft. During this phase, the EC can preview the licensing and business terms. This Public Draft is posted on a web site, openly accessible and reviewed by anyone. The Expert Group further revises the document using the feedback received by anyone. 
3. Eventually the EC approves the document but for that to happen there must be a reference implementation and an associated Technology Compatibility Kit (TCK), that would be called conformance testing in MPEG. A TCK must test all aspects of a specification that impact how compatible an implementation of that specification would be, such as the public API and all mandatory elements of the specification. 
4. The specification, reference implementation, and TCK will normally be updated in response to requests for clarification, interpretation, enhancements and revisions. This Maintenance process is managed by the EC who reviews proposed changes to a specification and indicates those that can be carried out immediately and those that will require a revision by an expert group. 

Aside from considering some elements that are specific to the Java environment, the process described is very similar to the one that MPEG has been following since MPEG-4 times.

Of late Microsoft has taken quite a strong position vis-à-vis OSS, claiming that OSS contains elements that undermine software companies' business. Some of the reasons put forth are the possibility to have "forking", i.e. the split of the code base into separate directions (exactly what the MPEG-4 license does not allow) enabled by the possibility for anybody to modify a piece of OSS, and the risk of contaminating employees working in non-OSS companies.

As an alternative, Microsoft proposes a different approach that it calls Shared-Source Software (SSS) which is expected to encourage commercial software companies to interact with the public, and to allow them to contribute to open technology standards without losing control of their software. This basically means that the company is ready to license, possibly at no charge, some parts of its software to selected entities, such as universities for research and educational purposes, or Original Equipment Manufacturers (OEM) to assist in the development and support of their products.

Copyright © 2003 chiariglione.org