1. Introduction
From a practical perspective, open source software represents a departure from traditional principles of intellectual property protection in software development and licensing. Typically, software development agreements expressly provide that the intellectual property rights in the software (specifically in the source code of the software) pass to the commissioner of the software.[1] Licensing of open source software is becoming more prevalent as developers increasingly make use of open source software in developing new software for their customers (one well-known example is the operating system LINUX). No longer is open source the domain of cutting-edge ‘high-risk’ business, with the UK Government joining the growing ranks of open source users.[2]
A commissioner of software will be driven by its business requirements and the functionality of the software, as well as its intentions for on-selling of the software. Consequently, the commissioner may have grave concerns if it is obliged (due to the software incorporating open source code) to make the source code available for its licensees to use, modify and develop. A developer, on the other hand, may be more focussed upon the technical merit of any underlying software solution (or, indeed, the philosophical stand-point of using open source software) which it is using for development, and may not consider adequately the implications of using open source software for its customer. Therefore, for both software commissioners and developers alike, it is important to understand the legal significance of open source software – there are many commonly held misconceptions surrounding the use, development and licensing of open source software.
This article seeks to give a summary of the legal and practical issues associated with open source software and to give some practical responses. It must be stressed that ‘open source’ is a general concept and as such there are a multitude of standard form open source licences (or a developer may write his own), with new forms of licence being added all the time. These licences are complex (often drafted without legal guidance) and it is difficult to make generalised comments. With each licence, the terms should carefully be scrutinised to determine whether its provisions are suitable for the particular circumstances – as indicated below, certain open source licence requirements may be incompatible with what the commissioner of the software wants.
2. What is Open Source Software?
Open source software is often referred to as ‘free software’. This means, as the pioneer of the open source philosophy, Richard Stallman, puts it: “free as in free speech, not as in free beer”.[3] For example, companies like Redhat charge fees for both licensing and support of open source software. The open source software should not be mistaken for other types of ‘free’ software, for example:
· ‘Public Domain’ software – this is software which is freely placed in the public domain. In its ultimate form, the copyright in such software is waived expressly by the owner when it is placed in the public domain.
· ‘Freeware’ – this is software which is available free of charge. It may still be protected by copyright. This should not be confused with open source software, for which a charge may be made. Use of ‘freeware’ may still, however, raise licensing issues that need consideration, but such considerations are outside the ambit of this article.
The notion of open source software stems from the concept of ‘copyleft’[4] – a copyright owner of software grants a licence and access to the source code of the software without the usual copyright restrictions, subject to no restrictions being placed upon the access to source code in any onward licensing of that software. In other words, where the licensee chooses to distribute the software, he must not place any restrictions on the use of the open source software, thus perpetuating the open source licence. Where the licensee also makes developments to the software, he may be obliged to include such developments within the software in any onward distribution (see sections 3 and 4 below for further discussion on this point).
3. Practical Issues: Type of Licence
There is a multitude of standard form open source licences, or a developer may write his own. The general principles in this article should be read in conjunction with the particular licence in question. With each licence, the terms must be analysed to determine whether its provisions are suitable for the particular deal – as indicated below, certain open source licence requirements may be unacceptable to a licensee.
Broadly, the types of licences split into two types: “full” and “limited”:
· Under a “full” licence (eg the GNU General Public Licence), where the licensee makes amendments or developments to the open source software, the entire piece of software becomes open source. This means that the whole software must be subject to the terms of the open source licence (ie the source code must be made available without restriction) when it is distributed. A simple analogy can be made to a snowball which grows larger as it collects snow on its way down the hill.
· Under a “limited” licence, the developments or modifications made by the licensee remain his own and he is free to exploit it as he sees fit. However, the open source part of the software remains open source and where it is licensed onwards this must be done without restrictions.
4. Practical Issues: Developments
As we have seen, the type of open source licence will determine how developments will be treated under the licence. It is important to remember that the open source licence does not, of itself, affect the ownership of intellectual property rights in any developments, but rather it affects the ability of the owner to place restrictions upon the use of the source code of developments in any onward distribution. A key issue with both types of open source licence will be the definition of such “developments”. Both developer and commissioner may have their own ideas of what will constitute a “development”, but ultimately the terms of the relevant open source licence must be consulted – these will often contain substantial technical definitions.
Clearly, where a person (the “commissioner”) commissions a developer to produce software and expects intellectual property rights to vest in the commissioner, and that developer uses open source software, it will be crucial to establish the type of licence subject to which the open source software was made available to the developer (because this will determine on what terms he will make such open source software available to the commissioner). Similarly, developers need to check carefully what restrictions apply to any open source code which they may use (or be obliged to use by the commissioner, where the commissioner has particular requirements for, say, interoperability with existing software) – developers’ obligations under an open source licence may not accord with their customers’ requirements.
Where the developer is using the open source software under a “full” licence, it may be that the entirety of the software developed for the commissioner will be caught by the terms of the open source licence (see also below). In other words, the commissioner, where it distributed the developed software, would be obliged to make the developed source code available to its licensees without restrictions, something which may be contrary to the commissioner’s aims, especially where it wishes to market the developed software and prevent access to the source code.
Of course, with the “full” licence, the distinction must be made between developed software which is derived from the open source software (which does become part of it) and developed software which is not. However, even where the developments are independent, where the package (open source software plus independent developments) as a whole is distributed, the terms of the “full” open source licence may apply to the whole.[5] In other words, where developed software is to be commercially exploited in conjunction with open source code, care should be taken not to release (or be required to release) proprietary software/information unwittingly.
5. Practical Issues: Intended Use
Another key practical issue is establishing what a commissioner wants to do with any developed software: Broadly, the commissioner could:
· Retain the developed software for internal use only: where this is the case, the commissioner would have unfettered use of the source code of the software (including the right to modify/improve it) and the type of open source licence is almost unimportant – the commissioner is not obliged to distribute the developed software (whether fully open source or not).
· Distribute the developed software (eg by licensing the software to its customers): by making the software commercially available, the source code of the open source portion of the software (see above) would have to be distributed without restrictions on its use, in accordance with the terms of the applicable open source licence. The type of licence (as discussed above) would be of particular importance.
The type of licence will determine whether all or only part of the developed software will be open source. Where the commissioner intends to make the developed software commercially available, it may be unacceptable if the open source software is made available under the “full” licence and the entire software becomes open source: this would mean, in principle, that the commissioner must make the software available without restriction (although they could still charge for it). The commissioner would not be able to place typical restrictions (exploitation of intellectual property rights, etc) on the access to the source code of the software in the onward licences.
6. Practical Responses
There are a number of responses a party contemplating software development can put in place. Chiefly, a would-be commissioner must have a firm view on what uses will be made of the developed software. If on-selling is a possibility, use of open source software by the developer may be inappropriate. The commissioner would need to weigh this against the advantages of open source software (enhanced reliability, interoperability, etc). Because of the potential risks posed by the use of open source software, would-be commissioners should consider putting in place a policy covering the use of such software. For example, whenever a software development project is anticipated, the policy could require the relevant staff to establish what the intended uses for the software are, whether the developer intends to use open source software and, if so, which open source licence has been imposed on that software.
Of course, where open source software is to be used, a commissioner should take specific legal advice in relation to the particular licence being proposed.
7. Looking forward
The recent SCO claim highlights the importance of understanding the risks as well as the benefits of open source software.[6] Traditional software houses, it would seem, are not ready yet fully to embrace the rise of open source.
Martin Lau is a Solicitor at Bird & Bird.
[1] Such express provisions are important since the default position in statute is that intellectual property rights in the software will be owned by the “author” – the software developer not the commissioner.
[2] In April 2003, the Office of Government Commerce (OGC) announced the establishment of “Purchase & Pay”, a LINUX-based operating system to be rolled out in the Department of Work & Pensions. The system aims to allow public bodies to purchase products (initially stationery and printed forms) in a quick and efficient manner.
[3] Source: www.gnu.org
[4] It must be stressed that “copyleft” is not a legal concept and, in reality, the basis of protection is still in copyright: a copyright owner is simply agreeing, by way of contractual provisions in the open source licence, not to enforce his copyright in the usual way.
[5] In the words of the GNU GPL: “If identifiable sections of that work are not derived from the [open source software], and can be reasonably considered independent and separate works in themselves, then the [GNU GPL] License, and its terms, do not apply to those sections when [the commissioner] distribute[s] them as separate works. But when [the commissioner] distribute[s] the same sections as part of a whole which is a work based on the [open source software], the distribution of the whole must be on the terms of the [GNU GPL] License…”
[6] In March of this year, the SCO Group filed a US$1bn claim against IBM for alleged infringement of its Unix licence. In general terms, SCO claimed that IBM had breached its UNIX licence with SCO and leaked code to the open source community further to develop the LINUX operating system. On this basis, SCO sent a letter in early May to nearly 1,500 global LINUX-using businesses. The letters warned the businesses to seek legal advice, as their use of LINUX could leave them liable for damages after SCO’s pending intellectual property infringement claim against IBM.
