What is Open Source Software (OSS)?
OSS is a type of software which allows users to copy, modify and redistribute its source code (ie pre-compilation human readable code). This is unlike the traditional software licensing model, which generally only allows use of machine-readable binary object code.
How is OSS Licensed?
There are over 70 different types of OSS licence, which can broadly be split into two categories: (1) academic licences; and (2) reciprocal/viral licences. Academic licences are generally permissive and often the only obligation placed on distributors is to indicate that OSS has been used in the software they distribute. Common examples of academic licences are Apache, BSD and MIT. Reciprocal licences are more restrictive and generally provide that source code can be used and modified for internal use, but that any modified code which is made available to the public must be distributed on the same terms as the original OSS code (hence its ‘viral’ nature). The most common viral licence is the General Public License (GPL), which is used in almost three quarters of all OSS projects.
What are the Advantages of OSS?
For developers and suppliers, the community-based approach to development and testing can mean more reliable and robust software products with shorter development life-cycles and lower development costs. For end-user organisations, OSS represents an opportunity to customise products for their own business use and to scale up the user base at very little additional cost. The OSS can usually be distributed to subsidiaries and other parts of the organisation freely, without incurring any further costs, provided the terms of the original OSS licence are adhered to.
What are the Drawbacks?
OSS may have its genesis in a variety of contributions and there is therefore a heightened risk of intellectual property rights infringement when compared with conventionally licensed software. This risk is exacerbated by the fact that OSS is almost always made available in the first instance on an ‘as is’ basis without warranties, given that onward distributors/contributors may not be in a position to give much by way of additional guarantees in relation to OSS code they did not develop themselves. Support for OSS may also be difficult to find, particularly for more bespoke modified versions of the software. Finally there is the risk of ‘contamination’, where code subject to a viral OSS licence is modified and ‘derivatives’ are publicly distributed, which inadvertently themselves become subject to the terms of the original OSS licence. Much of the debate around OSS surrounds what genuinely constitutes derivative software and the extent to which code can be linked to OSS code without becoming subject to the original OSS licence terms.
Practical Protective Steps
What practical steps can corporate licensees take to protect themselves against risks associated with OSS (and secure internal approvals which may be necessary to proceed)?
• Understand the terms upon which the OSS is being made available and the key features of the relevant OSS licence. Make sure that the licence (as well as the OSS itself) will be suitable for the business. Also bear OSS in mind when tendering for software solutions or development work (see below for more on this).
• Consider whether the supplier will be in a position to offer further assurances to mitigate the licensee’s risk. It will often be difficult to negotiate to any significant extent the terms upon which OSS software is being made available or to seek any additional assurances at the point of contracting. However, that is not to say it will be impossible in every case – the supplier may be prepared to share some of the risks associated with the supply and use of OSS with the customer in order to secure a deal (or an improved deal). Success will depend on a range of factors, such as the relative commercial bargaining strengths of the parties, and the supplier’s analysis of risk against reward (there could for example be a lucrative software support and maintenance contract in it for them). The nature of any further protections sought will also be a factor. For example, the supplier may be reluctant to give warranties as to the provenance of the OSS unless the chain of contributors is short and traceable. The supplier may also be prepared to give limited warranties as to the compliance of the OSS with applicable specifications where the specifications are clear and available, and where customer remedies are limited in the first instance to reasonable supplier obligations to repair or make good any non-compliance (and the supplier has the necessary expertise to do so).
• Carry out some due diligence on the provider of the OSS and other corporate customers to which that provider has supplied the OSS concerned. It may be possible to arrange reference site visits to such customers in some circumstances. Using trusted suppliers and well-established OSS software versions that have been around for some time will help to mitigate IPR infringement risks, as well as security and business continuity risks which might arise from the use of unstable unproven software that does not benefit from a broad support base.
• Ensure that IT policies and employee terms are up-to-date and define clearly any rules applying to both the use and development of OSS (including any supervision requirements). Ensure also that internal licence tracking systems are flexible enough to monitor compliance and that staff training programmes educate users and developers about the consequences of use of OSS within the organisation. Having effective systems in place will help to protect the interests of the organisation in subsequent business disposals and intellectual property disputes.
• Understand the consequences of any further modification of the software and, in particular, whether such modifications would be caught under the terms of a viral OSS licence. If modifications are caught, that could interfere with plans to patent protect the modified software or to commercially exploit it. It could also mean a requirement to disclose and make available key improvements to third parties including competitors.
• In particular, if the business employs or contracts developers to create or modify software (for internal use, but in particular for any external exploitation), it should take extra care to ensure that it understands such developers’ use of code libraries and developer forums. These often contain pre-programmed modules of code for incorporation into software projects (to avoid ‘re-inventing the wheel’), but the code may be subject to the terms of one or more OSS licences.
• Investigate with insurance brokers the organisation’s ability to insure cost-effectively against the risks associated with OSS use. Open Source Compliance Insurance has been introduced in response to recent litigation surrounding the use of OSS in commercial products and IT infrastructure. It aims to offer organisations protection from the particular business risks that OSS presents.
Impact when Tendering
How does OSS impact on corporate customers when tendering for software solutions or development work?
• Organisations should bear OSS in mind when seeking to procure software solutions or development work through a competitive tender process. It may not be in the customer’s interests to prepare its tender documentation in such as way as to effectively exclude or discourage submissions from suppliers offering OSS-based solutions (or with OSS elements) – after all, these could represent best value for money or the most innovative solution. If it is the intention to exclude responses with OSS elements, this should be made clear in the tender documentation.
• Customers will often include as part of their tender documentation their own standard licence terms or a set of key commercial principles (drafted from the licensee’s perspective) then invite suppliers to comment on these or mark them up when responding. This can of course be a helpful approach to set baseline customer expectations, to expose major supplier issues at an early stage and to maintain competitive tension. However, if the contract/principles documentation is based on a conventional ‘closed source’ licensing model, this could lead to unsatisfactory responses from suppliers with OSS-based solutions, eg where they heavily mark-up the proposed contract to reflect certain standard OSS licence provisions, or seek to include general comments to the effect that certain of the provisions will not apply to OSS elements. Flexible tender documentation and an early dialogue on approach with suppliers will help to manage expectations and save unnecessary effort on both sides. Again, if the intention is to exclude responses with OSS elements, the contract/key principles could make it clear that the selected supplier would be expected to give specific warranty assurances about the non-use of OSS in the solution.
• There are key differences between OSS licences and conventional ‘closed source’ licences – this means that an OSS supplier may seek a number of changes to such a conventional licence in its tender response. As well as seeking to limit the level of warranty assurance and indemnity protection and related liabilities, a supplier of OSS might also seek to revise other provisions – for example around testing and acceptance, sub-licensing and escrow – to better fit the OSS licensing model. It may be worth exploring with suppliers the possibility of applying distinct OSS licence terms to OSS elements of the solution, provided that this does not over-complicate matters.
As OSS-based software solutions increasingly gain boardroom recognition and acceptability, it is important for the corporate customer to recognise the associated risks (as well as rewards) and have effective corporate strategies for managing them.
Callum Sinclair is an Associate in the Intellectual Property and Technology Group at DLA Piper.
