The fundamentals of free and open source software

by OSS Watch on 11 August 2009 , last updated

Archived This page has been archived. Its content will not be updated. Further details of our archive policy.

Introduction

This article sets the free and open source software (FOSS) scene before moving on to discuss issues impacting on the long-term sustainability of FOSS.

The early days

The story begins in the 1970s, when software invariably came supplied (or bundled) with purchased hardware. Vendors made their money from hardware purchases, and the software was seen as a low- value item that would need to be customised by the individual user. Consequently, when the software was supplied to customers it was accompanied by its source code and a licence that permitted modifications. This all took place before the arrival of the personal computer and the free and open source licensing model.

In February 1976, Bill Gates, then a 20-year-old founding partner of Microsoft, wrote an open letter to early personal computer hobbyists, taking issue with the ‘theft’ of personal computer software within the hobbyist community. He asked: ‘Hardware must be paid for, but software is something to share […] Is this fair?’ Although many hundreds of people had used his Altair BASIC software, Gates estimated that only 10 per cent had actually paid for it. He was of the opinion that software should be sold, regardless of whether it was bundled with hardware. Reaction to the Gates open letter was strong and varied, with many arguing for alternatives. For example, Jim Warren, then editor of _ Dr. Dobb’s Journal_, wrote in the July 1976 ACM Programming Language newsletter: ‘There is a viable alternative to the problems raised by Bill Gates in his irate letter to computer hobbyists concerning “ripping off” software. When software is free, or so inexpensive that it’s easier to pay for it than to duplicate it, then it won’t be “stolen”.’

The birth of FOSS

Almost a decade later, 1984 saw the start of GNU Emacs, a project created by Richard Stallman. This was the first free software application. Shortly afterwards, in 1985, the Free Software Foundation (FSF) was founded. The foundation is committed to the freedom of software users. The FSF outlines and maintains the Free Software Definition: ‘Free software is a matter of liberty, not price. To understand the concept, you should think of free as in free speech, not as in free beer.’ The definition also refers to four kinds of freedom; if users have all of these freedoms, a program is free software.

Some years later, in the late 1990s, Eric Raymond presented and published ‘The Cathedral and the Bazaar’, an essay based on his experiences managing an open source project, fetchmail. Two distinct models of software development are presented and compared: the ‘cathedral’ model and the ‘bazaar’ model. In the cathedral model, software is developed by a restricted group of software developers while source code is not made generally available between releases. In the bazaar model, software is developed via the Internet in view of the public, who have access to the source code in development. Raymond credits Linus Torvalds, the creator of the Linux Kernel project, as the inventor of the bazaar model.

In 1998 Netscape, the most widely used browser before the browser wars of the 1990s, was released as free software. It later became Firefox, the key product of the Mozilla Foundation, which is also responsible for the Thunderbird email client and many other web-related technologies and products.

Open Source Initiative licence criteria

Another important milestone in the development of open source was the creation, also in 1998, of the Open Source Initiative (OSI), an apolitical organisation that promotes FOSS from a business point of view. Eric Raymond became the first OSI president.

One of the first things to emerge from the newly formed OSI was the Open Source Definition, which in turn was based on the Debian Social Contract. The Open Source Definition listed ten criteria that an open source licence must comply with:

  • licence must allow for free redistribution of the software
  • source code of software must be made available
  • licence permits the creation of derived works
  • integrity of author’s source code is maintained
  • software can be used by any person or group
  • software can be used in any field of endeavour
  • rights attached to the program are transferable
  • licence must not be specific to a product
  • licence must not restrict other software
  • licence must be technology-neutral

The OSI also undertook to accredit open source licences against the open source definition. Today, more than 70 OSI-accredited licences are in use, a quite unwieldy number. To simplify and consolidate the licensing situation, a licence proliferation committee has been tasked with encouraging licence authors to retire duplicate licences. The committee also categorises licences by perceived level of utility. At the present time, eight licences are categorised as widely used and/or have strong communities associated with them.

Main types of FOSS licence

There are four main types of FOSS licence: permissive, copyleft, partial copyleft and badgeware. From the point of view of a user or developer who has no intention of distributing their modifications, these licences are almost identical. From the point of view of a developer who wishes to distribute their modifications, each of these licence types affects how the modifications are to be licensed.

A permissive licence allows inclusion of FOSS in non-FOSS projects and is most suited to scenarios where the widest uptake is required. Examples of permissive licences include the Apache License and the BSD License.

A copyleft licence differs considerably from a permissive licence: derivative works, should they be distributed, must inherit the same licence as their parent project. This means that copyleft-licensed works cannot be incorporated into non-FOSS products, in direct contrast to permissive licences. Where permissive licences are ideal for wide uptake, a copyleft licence is more suited to situations where FOSS status is required for derivatives. The GNU General Public License is the best-known copyleft licence.

A variation of copyleft licensing is partial or weak copyleft. As the name implies, there are similarities between copyleft and partial copyleft licensing, including the inheritance of the licence for distributed derivative works. However, partial copyleft-licensed work can, under certain conditions, be incorporated into non-FOSS products. A partial copyleft licence could be described as a compromise between, or a hybrid of, copyleft and permissive licences. The Mozilla Public License v1.1 and GNU Lesser General Public License (LGPL) are examples of partial copyleft licences.

Although there is only one OSI-approved licence considered to be ‘badgeware’ , its conditions are notable. The Common Public Attribution License is an adaptation of a partial copyleft licence (the Mozilla Public License), to which a clause requiring that derivatives must prominently display the original author’s details and/or organisation at runtime has been added.

One of the most important issues to address when setting up a FOSS project is that of copyright ownership. There are two primary models in use: centralised and aggregated ownership. In both cases, the project owner releases software under their chosen FOSS licence. In the case of centralised ownership, however, copyright is owned by the project owner, and contributors assign copyright of their own work to the project owner. Aggregated ownership permits original authors to retain copyright of their work, while contributors license their work to the project owner for redistribution as open source.

A third model, distributed ownership , also exists, and is common in the academic world. The characteristics of distributed ownership include individually licensed contributions and collaboration agreements. Despite its academic proliferation, this model is not recommended by OSS Watch, because it is difficult to coordinate legal action against infringers, and for project owners to coordinate a defence against legal action. Furthermore, outbound licence changes require agreement from all participants, which can be difficult to obtain in widely distributed projects.

One solution to the problems associated with distributed ownership are Contributor Licence Agreements, or CLAs. A CLA is a simple, clearly worded agreement ensuring that the expectations of both contributors and project owners are met. In a well-run project, CLAs are an important step towards the prevention of future problems relating to IPR.

In addition to managing IP contributions to the project, the contributor must be certain that they have the authority to assign the necessary copyrights and licences. Although employment contracts may dictate which party owns the contribution that an academic or an employee has made to a project, especially an internal one, the default position is that an employer owns an employee’s work. Contractors generally own their own work, although some contracts are explicitly written to pass ownership of works to the employer. Academics’employment contracts often allow them to retain ownership of certain kinds of copyright work to facilitate academic publishing; in some cases this may include software. To avoid doubt in any of the above cases, refer to your contract and your institution’s regulations.

Revision control systems

OSS Watch’s experience of UK education software development has shown that many projects have encountered issues with recording and retrieving ownership information accurately, leading to problems when software is released. The use of version control software is critical, even in a single-developer project, if such problems are to be avoided. Version control systems, coupled with lightweight processes for contribution, make it possible to track activity and thus manage intellectual property in an automated way.

Version control provides many other source management advantages. Version control systems are therefore key to the good management of IP and of the resources being developed. Arguably, they are the single most important tool in a software developer’s toolkit.

Conclusion

The role of community in the development of sustainable FOSS cannot be over-stated. While open source software can be developed and maintained by a small number of employed developers, as closed source software is, the open source development approach provides alternative methods. In the words of the Open Source Initiative, Open source is a development method for software that harnesses the power of distributed peer review and transparency of process.

In summary, open source is a methodology for software development and not restricted to software licence terms. The FOSS ethos and associated accredited licences go beyond just the terms of use and distribution. So, the adoption of an open source licence alone will result in the freedom to reuse the software, but will not significantly impact the sustainability of the software unless it is accompanied by the adoption of an open development methodology.

Further reading

Links:

Related information from OSS Watch: