Making the most of open source software

Most software developers nowadays will make use of some OSS for the obvious reason that it avoids them having to re-invent the proverbial wheel and that makes it particularly attractive to startups. It is unlikely to cause you problems if you use OSS in internal products, although the question of OSS may arise if the company is acquired. Where, however, it is used in your proprietary software which is licensed to or hosted by third parties, the situation becomes more complex.

What are the risks in using open source software in proprietary software?

Most OSS is supplied under licence. OSS licences range from very wide ‘permissive’ licences like the Berkeley licence (which has a requirement to reproduce the copyright notice, one clause of conditions and the specified disclaimer on any re-licence), to the GPL, which runs to around nine pages in its latest incarnation (version 3) and is a complex document which needs to be approached carefully.

The terms of an OSS licence may be wide but you essentially inherit a licence which will then apply to that OSS if used in products you supply to clients. The terms of the OSS licence are almost certain to conflict with the terms of the overall licence to your software and if you are using OSS governed by different licences, those licences will probably conflict with each other too. An OSS licence is likely to entitle your client or customer to ask for the OSS source code, to adapt it, modify it and re-license it. In addition, if you have modified the OSS to create what you might view as your own code, the licence terms of the original OSS are very likely to apply to the modified code.

Compliance issues for businesses using OSS typically fall into two main categories. The first (relevant, for example, under the GPL) is making the source code itself, together with the relevant licence terms, available to downstream users and inserting the required copyright notices. We see many companies which develop their own code but use OSS for specific tasks, fall down on these basic steps. This tends to act as a red flag to investors and buyers. While there have been enforcement actions, OSS projects have generally been content to see the issue put right so the threat of legal action and the ensuing negative PR is not always the main concern and this sort of risk is often curable in practice. Potential investors and buyers are, however, likely to see failure to get the house in order on OSS as an indication that the business does not take intellectual property rights seriously.

The most serious risk associated with OSS is that it ‘infects’ your own proprietary code (assuming you have any – this is not a concern for a ‘pure’ OSS business). If this happens, your own code will, effectively, become open source, governed by the terms of the relevant licence. In the worst case scenario, anyone to whom the software is distributed will be entitled to ask for its source code and adapt, modify or re-license it as they see fit.

This is a grey area with online discussion creating more heat than light. Infection may occur if proprietary code interfaces with or links to OSS but it can be difficult to determine whether or not code has been infected and it will also depend on which open source licence governs the OSS. Unfortunately, many of the open source licences are poorly drafted which makes knowing when they apply complicated. Good practice has emerged around how you implement the interoperation of OSS and proprietary elements to manage the infection risk. Experienced developers who have been through this before are a blessing and external legal advice from tech specialists will also help.

Having said this, if you have developed your own source code, while it is likely to contain some OSS, it is unlikely that your entire product will become infected and in most cases, the risk of a client being able to ask for the entire source code to your software, is low. We think the scare stories in this area have been overblown. Buyers and investors tend, however, to be less than sanguine on the issue of OSS so you cannot afford to ignore it.

They may very well ask you to identify all OSS and licences used in your proprietary software. If you are unable to do this (and in some cases, even if you are) they will ask for a set of indemnities and warranties in relation to any OSS contained in what they are buying or investing in. We have also seen buyers use fears of infection (whether real or opportunistic) to lower company valuations.

Mitigating risk

OSS is a fact of life in the software development world so the thing to do is mitigate the risks of using it in any software you intend to be proprietary. Helpful precautions include:

• not over-relying on OSS if you want your software to be proprietary;
• ensuring your developers know about the risks of using OSS and take steps to ring-fence it technically if they use it;
• if you are heavily dependent on OSS and you do not have an expert familiar with the licences and the main compliance issues, hiring one;
• having a firm-wide policy for use of OSS and other third party products, and ensuring the CTO (or a small tech committee) pre-approves the use of any OSS component;
• ensuring that customer/client licences carve out OSS expressly from the licence to your proprietary software; and
• using an OSS management programme like Black Duck Protex to track your use of OSS and the licences which govern that use.

These relatively simple steps can save you a great deal of trouble when you get to the stage of looking for further investment or selling your company.

If you have any questions on this article please contact us.