Open source software: minimising the risks
This guide is based on UK law. It was last updated in
February 2008.
Software and how to minimise such risks
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?
What 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.
OSS
and intellectual property
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').
Weighing up the pros and cons
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).
The Intellectual Property Rights issue
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.
Managing the risks
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 version 3.0
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:
- Under the second version of GPL, there was a
considerable amount of controversy over which kinds of changes had
to be included in source code that was released under the copyleft
requirements of the GPL.. GPL 3 clarified the language concerning
the scope of the licence and what had to be released.
- The “tivoisation” problem. Basically this is
the creation of a system that incorporates software under the terms
of a copyleft software license, but uses hardware to prevent users
from running modified versions of the software on that hardware.
TiVo had complied with the terms of GPL 2, but had placed certain
technical limitations on changing the software. Although this is a
massive oversimplification, the general gist is if you changed the
software, thereby exercising your rights under the licence, the
TiVo box wouldn't work anymore. The box would not work because it
was checking to see if you had modified the software. This was
thought to be counter to the spirit of GPL and so some specific
terms were put in GPL 3 to address this.
- GPL 3 has express patent licences and other
patent provisions to address general issues regarding software
patents. When GPL Version 2 was written, software patents were not
nearly as predominant as they are today, and that version of the
licence did not have an express patent grant.
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.
Practical recommendations
- Particular attention should be paid to the
licence terms of any OSS used by a company, in particular the ' OSS
contamination' risk is likely to be of concern.
- Companies, particularly software developers,
should formulate an open source policy, dealing with some of the
common issues or scenarios that are likely to arise, e.g.
incorporation of OSS into proprietary product; use of an open
source development tool.
- f considering using an OSS product, as much
technical and legal due diligence as to the origins of the software
should be carried out. Consider trying to obtain IPR indemnity
protection from licensor, although this may not be possible.
- Educate employees as to both the benefits and
risks of using OSS .
- Keep records of all instances of OSS being
used, particularly where incorporated into a product. Even on
Outsourcing the risks of OSS need to be managed.
Contacts
