This guide is based on UK law. It was last updated in February 2008.
The use of Open Source Software (OSS) is becoming increasingly prevalent and, indeed, a number of mainstream software products (e.g. Linux, Apache, Firefox) are based on the OSS model. The UK Government is increasingly implementing OSS alternatives, stemming from an Action Plan of the European Commission in June 2000 suggesting that Member States promote the use of OSS in the public sector and e-government. So what exactly is OSS?
There are many OSS licences ranging from the GNU General Public License (GPL) to short licences containing virtually no express terms. Although OSS licences come in many shapes and sizes, some common themes emerge.
In contrast to more traditional licences of standard (so-called 'proprietary') software, users of OSS are generally permitted (and encouraged) by the licensor to access, copy, modify and distribute the underlying source code (being the code in human-readable form before it is compiled into machine-readable, binary 'object code'). Such wide rights are usually subject to the proviso that users do not place any additional restrictions on access to the source code in any onward distribution of the software; such onward licensing is often required to be on the original licence terms and at no cost. Further, some OSS licences require users to submit any modifications made to the source code to the licensor for potential inclusion in a subsequent version of the software. These requirements may not be appropriate for some software developers, depending on their business plan and their dependency on deriving revenue from software (as opposed to associated services).
From a practical perspective, the key thing is to identify the OSS concerned and the licence terms under which it is made available and then to assess whether the licence attaches any particular terms.
Copyright (and, to some extent, patents) exists as a means of protection for the underlying rights in software. Copyright can subsist in a number of elements of software, for example, preparatory design materials, source and object code, screen displays, manuals and documentation, etc., and prevents the copying of the whole or a substantial part of the software. OSS would seem to go against one of the fundamental assumptions of intellectual property law, being that inventors are incentivised for their creativity by rewarding them with a property right, which can then be exploited. Are we wrong in this country to regard copyright as the cornerstone of software protection? In short, no: both the proprietary and OSS models rely on copyright to a greater or lesser extent; however, OSS licences grant rights and privileges over and above those permitted by copyright, which legitimise otherwise infringing acts and 'reverse' the copyright protection (a concept known as 'copyleft').
From a user perspective, the advantages are that OSS is licensed at no cost and there is widespread use and testing by an extensive user-base. The idea is that, with a widespread community of users with full access to the source code, any defects and bugs are quickly spotted and rectified and the product continuously develops and improves. However, there have been questions as to the reliability, robustness and security of some OSS products; given the fact that comprehensive support is not normally included as part of the offering, this can cause problems. Likewise, OSS licences typically lack the warranty protection and other comforts normally included in a proprietary licence.
For software developers, there are a number of implications of using OSS . Whilst the obvious advantages are widespread distribution and an extensive user-base, developers need to be extremely wary of inadvertently including OSS in their proprietary code, particularly where a dual licensing model (both open source and proprietary) is offered. Such an ' OSS contamination' could prove disastrous, as the developer could be obliged to make available and disclose the source code of software it intended to be proprietary.
Having observed the initial trends and developments in OSS from the sidelines, a number of big players in the market have now climbed aboard the bandwagon (primarily by packaging Linux with their hardware). OSS is seen by some as a valuable asset, not only from a PR perspective, but also to be used as a 'loss -leader' for the sale of other products and services (primarily consultancy and support).
For both users and software developers using OSS in their products, the biggest concern often relates to the ownership of the underlying rights in the OSS and assurances in relation to infringement of such rights. Whilst a widespread community of developers contributing to an OSS product has its advantages, there are obvious risks. Some products will include contributions from numerous sources (for example, over 200 people are thought to have contributed to Linux); as the majority of these will have day jobs as software developers for commercial entities or universities, etc., there are bound to be issues around the originality of code April 2004 contributed to OSS products. It would be extremely difficult (if not impossible) to verify the source and originality in each case.
Conventional OSS licenses typically contain only limited warranty and no Intellectual Property Rights (IPR) infringement indemnity protection. Whilst a licensor of a proprietary software product would be expected to assume the risk that a product is non-infringing, OSS licensees have limited recourse if faced with an IPR infringement claim from a third party.
Whilst there is always some degree of risk (e.g. IPR infringement, security) involved in using a third party's software products, there are different, and potentially greater, risks with OSS . As such, companies should put in place effective procedures and policies for addressing issues as they arise.
There is no single 'quick fix' open source policy, as companies will vary in their approach. For some, OSS will be a central element of their business plan and licensing model; such companies may have a greater tolerance to the uncertainty and risks involved. Others may take the decision to avoid OSS as much as possible, particularly if they are software developers faced with the risk of ' OSS contamination' requiring the disclosure of source code and the granting of broad licences.
As a first step, companies developing software products should consider which products they license to end-users for a fee and how dependent the company is on such revenues. If the company generates revenue through the sale of consultancy and other services and/or hardware and is not hugely dependent on revenues from software sales, then it may not be of huge detriment to incorporate OSS (on a royalty free basis) as part of its products if it is unlikely to affect the company's bottom line.
Companies' own 'internal' use of OSS should also be considered, as a number of development tools as well as common applications are licensed under open source licences. Whilst some may only be used in the development process and not incorporated into products, it may be worth including a list of approved tools that are known not to cause code to be incorporated into the product under development.
For any company considering the use of OSS , extensive technical and legal due diligence is required to review the software components to reduce the level of risk. The extent to which this is feasible will depend on the product and could be a huge task. However, recent indemnification programmes offered by major suppliers reduce risks for users. In February 2006, Red Hat announced it would offer an Open Source Assurance Program to protect all existing and future Red Hat Enterprise Linux customers; Novell is indemnifying SuSE Linux customers against possible action from SCO. Such indemnities also help with due diligence risks.
In some circumstances, use of OSS may be outside of a company's control; for example, in an outsourcing situation. Generally, an outsourced provider will assume responsibility for software licences and provide the customer with a service. In order to benefit from the service, the customer may require access to the software to some extent, depending on the specific circumstances. This can clearly expose the company to risk, which should be managed by means of a specific provision in the outsourcing agreement, requiring the company's consent where the outsourced provider is considering using OSS , with a risks/benefits assessment to justify the use of OSS over a proprietary product.
GPL 3 is a major development in OSS circles. Version 3 was released in June 2007. Before that, GPL 2 had been in effect since about 1991. GPL 3 addressed three key issues:
A final comment on GPL 3. Most of the code that is out there under GPL Version 2 says that the licensee can, at his or her choice, take the code under GPL Version 2 or any later version. Therefore, if a project still has GPL Version 2, you, as the licensee, have the choice to take it under GPL Version 2 or GPL Version 3. However, in relation to those projects that have actually migrated to GPL 3, you could only take under GPL 3, or presumably any later version if there is one.