Open source in practice

Open source software is a collective name for all kinds of software for which the source code is freely available. The license permits everyone to extend or improve the software and to distribute it. Software packages such as the Linux operating system, the Firefox web browser or the Apache web server software are the most well-known examples of open source.

Open source has clear benefits. However, figuring out what is allowed can be difficult. Open source licenses differ in several key aspects from traditional, proprietary licenses or EULAs. Most notable is the requirement to release one's own software as open source software itself, if that software incorporates open source software.

What is open source

Open source is software that is freely available to all. Because the idea of freely offering not only software, but also its source code, is alien to many in the software industry, there are many myths and misunderstandings around open source.

To dispel a few popular myths:

• Open source can be and is being used by businesses.
• Using open source in a product does not mean the product has to be made available as open source in its entirety.
• It is perfectly allowed to charge fees for the distribution of open source.

The use of open source software as alternative to commercially developed software is strongly growing in popularity. The main reasons for this growth are the high quality and availability of this type of software, and of course the license cost: zero.

The use of open source software is not just restricted to software companies or consultancy firms. Hardware manufacturers are also turning more and more to open source software to implement basic functionality in their products and to reduce time to market.

However, open source is not public domain. The software is licensed, and the license needs to be complied with before the software can be used and distributed. Because the license conditions can be quite different from typical proprietary software licenses, it is important to have the right checks and processes in place to ensure open source license conditions are complied with.

Open source as a development model

Although typically used to refer to software, the term open source is more accurately defined as a software development model by which the source code to a computer program is made available publicly under a license that gives users the right to modify and redistribute the software. Users are expected (although not required) to also make their modifications and improvements available for inclusion in the "official" distribution.

The open source development process involves a co-operative way of working that proves to be very successful in developing high quality software at an impressive speed. Although it is best known for its use in projects on a world-wide scope such as the Linux kernel and the Apache web server, it can also be used within the scope of a single company. This variant is sometimes referred to as "Inner Source".

The open source community

Open source is not managed by a company, foundation or other single organization. The open source community consists of a large number of individuals and groups of individuals who contribute to a particular open source product or technology. Only a small portion of this community - who identify themselves as "free software" supporters - is politically active. Most are software developers or distributors who recognize the benefits of open source software.

Many open source software developers are more practical and rarely want to get deeply involved in licensing issues or political debate. This distinction becomes quite clear when looking at the two most prominent groups: the Free Software Foundation (FSF) and the Open Source Initiative (OSI).

The Free Software Foundation

The Free Software Foundation (FSF), founded in 1985, is dedicated to promoting computer users' right to use, study, copy, modify, and redistribute computer programs. The FSF promotes the development and use of what they call free software (as in "free speech", not "free beer"). The FSF also helps to spread awareness of the ethical and political issues of freedom in the use of software.

The FSF believes that every person should have the unlimited right to run, copy, distribute, study, change and improve any piece of software. They consider it morally wrong to deny users of software access to the source code or the ability to improve the software. Software should not be owned or otherwise controlled by its author. To achieve this goal, Richard Stallman, leader of the FSF, developed the GNU General Public License (GPL).

The GPL states that any GPL-licensed software can be used, distributed and adapted without any payments to the copyright holders, but distribution of any software that incorporates GPL-licensed software must be licensed under the terms of the GPL as well. This self-propagating clause ensures that any "free" software remains free, and that any software using free software must also be made free. The intent -and political goal of the FSF- is that eventually all software in the world will be free.

The Open Source Initiative

The FSF is a political organization with a quite confrontational attitude towards businesses that keep their software confidential (.morally tainted. is one of their more polite phrases in this regard). This attitude, together with the largely misguided fear of having to make available one's entire software stack when using free software, has long stifled the use of free software in commercial environments.

In 1998 Netscape Communications announced that it would make the source code of its Web browser freely available. A group of prominent free software developers decided that this was an opportunity to sell the concept of this open development process to the corporate world, and coined the more neutral term open source to describe it.

The Open Source Initiative (OSI) was subsequently founded as a public benefit corporation, which amongst other things offers a certification program for open source software licenses. Certified licenses wear the label "OSI Certified Open Source".

Benefits of open source software

The free availability of the source code allows everyone to contribute to the further development of the software. Many people do. This continuous development and testing cycle often results in a large number of additions and improvements in a short period of time.

The free availability is also an advantage for users. A user of open source software is not dependent on the author of the software to get certain improvements or additions, but he can make them himself. Should the supplier ever discontinue support for the program, the user is able to take over development himself or to seek another supplier for that software. And of course the fact that the license costs are zero is quite interesting.

Risks of open source software

There are several unique risks associated with open source software. The license conditions imposed by open source licenses can be quite peculiar. Complying with these conditions can be difficult or costly. Not complying with these conditions may lead to a lawsuit or bad publicity.

For example, one may have to include a copyright notice identifying some third party open source software in the manual of one's own product. Some licenses require one to release one's own software as open source software itself, if that software incorporates open source software. The conditions under which this is required differ from license to license and in some cases it is difficult to determine when these conditions apply.

Because of the risks, a company may be tempted to avoid open source software altogether. Unfortunately this is not a realistic option from a business point of view. The use of open source software is gaining more and more popularity in commercial environments and even in commercial products. By ignoring this, a company locks itself out from all the available high-quality software and does not benefit from the reduced costs and time to market that open source software implies.

In some cases it is simply not feasible for a commercial product to keep up feature-wise with open source alternatives. The only viable option therefore is to understand the licenses and how to manage them.

Open source software licensing principles

Open source software is freely available for anyone, including source code. The license grants everyone permission to adapt or improve the source code, for example to fix errors, to make a more efficient implementation or to add completely new functionality. The software may also be copied and distributed freely, even in modified form. The author does not charge for this. The software is freely available on the Internet. It is even allowed to charge for distributing somebody else's open software without having to share any of the revenue with the original author.

No license contracts necessary

With open source licenses it is not required to explicitly sign an agreement with the author. The software is readily available, and the license is included in the software distribution. One of course does not have to adhere to the license conditions, but in that case there is no permission from the author to use the software at all.

Open source license categories

There are over 40 different open source licenses, each with their own conditions and implications. Roughly they can be classified into these three categories:

• Free-for-all licenses: these licenses only require licensees to give credit to the original authors. Derivative works can be kept proprietary. Sometimes these licenses are referred to as "academic licenses". Examples are the so-called BSD and MIT licenses as well as the license used for the Apache Web server.
• Keep-open licenses: modifications to software under these licenses have to be made available as open source as well. Larger works incorporating such software can be kept proprietary. The GNU Lesser GPL (used for Linux system libraries) and the Mozilla Public License (used for the Firefox Web browser) are Keep-open licenses.
• Share-alike licenses: when software under such a license is modified or extended, the result as a whole has to be made available as open source. The term copyleft is sometimes used to characterize this kind of license. The most famous example is the GNU GPL, which applies e.g. to the Linux operating system. Another example is the Open Software License (OSL).

Formulating open source license policy

A company may be tempted to avoid having to share software it considers proprietary by disallowing use of Share-alike and even Keep-open licensed open source. This will severely limit the ability to use open source at all.

About 65% of all open source software is covered by the GNU GPL, with an additional 20% being covered by the GNU Lesser GPL. These two licenses thus cover virtually all key components of devices with embedded software. Hence an open source policy should be about where and how, not if, the different types of open source can be used in a product.

Interpreting license conditions

Interpreting an open source license can be difficult. Open source licenses differ in several key aspects from traditional, "proprietary" licenses or EULAs. This can create unexpected problems for developers or distributors when they are confronted with the consequences of open source license conditions after the fact.

Open source license conditions usually include having to give someone credit in the documentation, having to distribute the license itself with one's own product or having to make the source code of the open source software available to anyone who asks. In some cases one's own software has to be made available as open source, when that software is derived from the open source software.

Using license FAQs

Some authors provide an explanation of the license conditions or spell out the consequences in particular situations. IBM offers a FAQ (Frequently Asked Questions) on the IBM Public License, and the FSF has a dedicated e-mail address for licensing questions. This advice should not be taken as gospel however. When the author of the software is not the same person as the writer of the license, only the software author's opinion counts. More impomrtantly only he can grant exceptions to the obligations imposed by the license.

A common type of error is a statement like "This software is licensed under the GPL, which means you cannot use it for commercial purposes". The GPL permits commercial use and distribution (including selling) of the software, as long as the software is distributed under the terms of the GPL. So did the author equate "commercial" with "proprietary", or is this an additional restriction imposed by the author?

It is therefore recommended to be very careful when trying to follow open source license conditions. One must keep in mind the spirit of the open source movement and interpret the conditions in this light.

The most important license conditions are:

• Giving credit to the author
• Reproducing license and disclaimer
• Distributing source code of the work
• No warranties are provided

Giving credit to the author

A common requirement with open source licenses is an obligation to credit the original author(s) when using the software in one's own work. This should normally not pose a problem, although it may be difficult to find out who all the original authors and contributors are. Usually one can simply ask the author regarding a preferred form of this statement.

Furthermore, care should be taken to distinguish the open source portions from the rest of the work, preferably by clearly stating "Portions copyright by Joe Hacker" when the requested credit is to insert a copyright statement identifying Joe Hacker.

The license may require that such credit is given in the documentation and/or in the program itself, for example during program startup or in the "About" box typically found in the help menu. In case the program produces no output (for example embedded software), it may be difficult to comply with this requirement. One should check with the author in such a case to determine an acceptable alternative.

Reproducing license and disclaimer

In addition to including a copyright notice or giving credit, one sometimes also has to reproduce the license and the warranty disclaimer provided with the license. This can usually be done in the manual or other materials provided with the distribution.

The text of the license should be reproduced verbatim. It is recommended that such a reduction is accompanied by a statement clarifying that this license applies only to specific portions and not to the work as a whole. Such a statement could take the form "This software contains the ABC library by Joe Hacker. The license conditions for the ABC library are as follows:"

Distributing source code of the work

Most open source licenses require that the source code of the open source work is made available whenever the work is made available in executable form. The easiest way to fulfil this requirement is to simply supply the source code on the CD-ROM on which the work is provided, or to allow downloading the source code from the same location as from which the executable can be downloaded. Such a download location must remain under the control of the distributor. One cannot simply point to the web site from which the code was originally downloaded. Should this web site shut down at some point in the future, then suddenly the distributor is no longer in compliance with the license.

If this form of making source code available is not desirable or feasible, the available alternatives greatly depend on the specific license. For example, the Mozilla Public License permits distribution of the work in executable form if accompanied by a statement identifying a location such as the web site from which the source code can be downloaded.

The GPL and LGPL considers including a written offer to supply the source code to anyone who asks to be an acceptable substitute. This written offer must be valid for at least three years. Note that merely referring a recipient to a web site where he can download such software is not enough! The offer must provide a postal mail address, and the source code must be mailed on CD-ROM or similar medium. Of course printing a Web download address next to the offer likely will reduce the number of written requests.

No warranties are provided

Almost all open source software comes without any warranty. Usually the best you can get is a warranty that the licensor is permitted to license the software. Sometimes the recipient must even agree to hold the author of the open source software harmless against third party claims.

This situation is comparable to some commercial off the shelf suppliers, but many product managers are used to ordering custom software from suppliers they can sue if the software does not live up to specification. But with open source software, the liability lies entirely with the redistributor.

Recognizing open source

A small but nevertheless serious risk is that software is not always distributed with the correct license. There have been instances in which distributors "forgot" to include the license, or put the software on a site with an indication that all the software was public domain. Others distribute executables without complying with the license, for example by not distributing source code as well. The recipient is then not allowed to use or redistribute the executable.

Furthermore, the license of a particular piece of open source software may be changed between versions. If the license changes from the simple, permissive BSD license to the GPL, then suddenly the licensee needs to comply with the more complex GPL requirements.

And finally, it is worth noting that when outsourcing software development to an external software company, the possibility that such a supplier delivers open source without notifying the principal is real. The principal might end up being liable for not complying with the open source license when he subsequently distributes the commissioned software. Most supplier contracts do not deal with this possibility, so recovering damages from the software supplier may be difficult.