Software: To Open Source, or Not to Open Source?
With at least half a million open source software (OSS) projects in the world1, OSS represents a significant aspect of contemporary software development. However, although there are advantages to be had from both using and releasing OSS, there are a number of issues to be kept in mind for the software innovator, in particular regarding how the use and distribution of OSS can interact with your intellectual property rights in a way that might be undesirable.
OSS guarantees particular freedoms, the most significant of which being that the user is free to:
- use the software in any way;
- access the human- readable source code;
- modify the program in any way; and
- redistribute the software (modified or unmodified) to anyone.
Also known as ‘free software’, it is a common misconception that OSS must be distributed without cost. In fact the term ‘free’ refers to the freedoms described above and OSS can certainly be sold provided that, as a result of selling the software, the above freedoms are ensured. However, since the buyer can freely redistribute it, the reality is that OSS is often distributed for free.
Contributing to OSS - Advantages
Firstly, OSS can quickly result in an industry standard. Since the source code is available and modifiable, there is no reliance on any particular company and the gravitation of participants, both code developers and end users, to a particular project can make its success a self-fulfilling prophecy. The opportunity to participate in, and therefore help define, such an industry standard can make OSS participation an extremely attractive, even unavoidable, commercial decision.
A second advantage of releasing OSS is the potential division of labour. As Bill Joy, cofounder of Sun Microsystems, put it, “No matter who you are, most of the smartest people work for someone else”. Encouraging others to contribute to and work on your project allows the involvement of people with wide ranging experience that many, particularly smaller, companies might otherwise never have access to.
Contributing to OSS - Considerations
Firstly, the above-mentioned gravitation of participants to a particular project is by no means guaranteed. Also, once released there is nothing to stop a competitor from taking your hard work and rebranding it as their own, or seeking to drive the project in a direction more suited to their business than yours.
Secondly, it is necessary to consider the ‘viral’ nature of many open source licences. The GNU Public Licence (GPL) is the most common open source licence, with over 50% of open source projects using it. Its viral nature comes from the fact that if you create software that links to or uses GPL licensed software, your software may only be released under the GPL – thereby granting all of the freedoms mentioned above.
Thirdly, the potential implications of releasing OSS with respect to related patents which you hold are particularly significant. Later versions of the GPL grant the OSS user an implicit (v2) or explicit2 (v3) licence to any patent claims held by the OSS contributor, which would be infringed in some manner by activity permitted by the GPL. The above-mentioned viral nature of the GPL thus extends that patent licence to all further users of the software.
This latter aspect of the GPL requires particular care to be taken by patent holders, in particular in organisations where the possibility exists for one department to be relying on continued patent protection, whilst another is participating in an OSS project. Ideally technologies being promoted via OSS participation and technologies which are being protected via patents would be kept clearly distinct, but in reality this is often not feasible and therefore clear internal communication with regard to what is being contributed to OSS projects is vital.
Using OSS - Advantages
The prime advantage to using OSS is, of course, to not recreate the wheel. Rather than expending time and money in programming, it may be possible to use or modify an existing project. It is also worth noting that the mere use of OSS generally makes no obligations on you. It is only by distributing software that contains OSS that particular restrictions may apply.
Using OSS removes reliance on a single distributor. If a company stops supporting its OSS, the source code remains available and other people are free to modify it. Consequently, the software may continue to be supported or, failing all else, you may modify it yourself.
OSS is generally deemed to be of high quality, reliability and security. A 2010 survey3 by Accenture indicates that over two-thirds of respondents cited these features as benefits of OSS. With a broad range of developers able to test, contribute to and use OSS, the range of platforms and scenarios in which it is used tends to be greater. Furthermore, with people able to contribute to the code at any time, inefficient code can be rewritten, buggy code can be fixed and code to improve compatibility can be added with relative ease. Features that are frequently requested are more likely to be developed and released back to the community.
Using OSS - Considerations
Perhaps the biggest consideration is what future obligations you may be agreeing to, as a result of using or starting to rely on OSS now.
As mentioned in the previous section, the mere use of OSS puts no obligations on you. However, the inclusion of a piece of software with a restrictive OSS licence may put you under certain obligations if you were to release a product containing that software. If there is an intention that the software be released to the public, a more thorough examination of the obligations is necessary than if it is merely used in-house. For example, it is not necessary to agree to the GPL in order to receive or use software covered by the GPL. However, if the same GPL software is then incorporated into software that is distributed to the public, you are obliged to release that software under the GPL – thus giving your customers the right to freely redistribute, sell and modify your software. Other OSS licenses are more permissive than the GPL and it is therefore crucial to understand the scope of the particular OSS licence that you are (implicitly) agreeing to before allowing the use of OSS in a project.
It is worth noting that in the UK OSS licences are largely untested. In the US, one known example of litigation has been the sequence of legal actions which the Software Freedom Law Centre (SFLC)4 has pursued on behalf of the developers of BusyBox, a popular software utility released under GPLv2. This software had been incorporated into a range of household components and the SFLC alleged that the terms of GPLv2 had not been met (typically that the source code had not been released). The majority of these cases have settled, typically involving an agreement to release the source code and an undisclosed sum being paid to the plaintiffs. It is interesting to consider that, in the fast-evolving world of consumer electronics and software, how much of a commercial burden such a retrospective release of the source code represents can strongly depend on the time that has elapsed between the marketing of the product and the settlement of the case.
As in the case of contributing to OSS projects, in order to prevent the creep of viral/restrictively licensed OSS into projects that are not intended to be released as OSS, internal communication in your organisation is key. It is recommended to implement a policy regarding what sort of OSS (if any) can be included within a given project, based on a clear understanding of the potential consequences of agreeing to the relevant licence(s).
There are clear advantages to be had from both the use and distribution of OSS. However, the decision to use OSS, and particularly the decision to release OSS, is not without some wide-reaching and perhaps unpredictable effects. In particular there is the potential for these effects to conflict with the intellectual property strategy of an organisation.
Consequently, it is important for companies in which the use or distribution of OSS is likely to implement an OSS policy. Such a policy should be made in conjunction with the company’s intellectual property strategy and should address, for any project, the licences that can be used and the licences that must not be used. Finally, the policy should consider the most appropriate licence under which software should be distributed, taking into account the strategy of the company together with what the release of the software is designed to achieve.