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.
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.
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:
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.
The UK has a well-established suite of reliefs designed to incentivise equity investment in companies in the early stages of their existence. This article focuses on developments in these venture capital schemes, particularly the Enterprise Investment Scheme (EIS), the Seed Enterprise Investment Scheme (SEIS) and Venture Capital Trust regime (VCTs) and recent trends and developments, with a particular focus on the changes introduced in the Finance Act 2018.
1 of 5 Insights
There is a lot to think about when setting up a new business. It's crucial to take protecting your intellectual property rights seriously from the outset. Don't believe the following myths!
3 of 5 Insights
This article looks at the wider implications of the General Data Protection Regulation (GDPR), how SMEs are affected and sets out a short term compliance plan for startups seeking to prioritise before 25 May 2018.
4 of 5 Insights
One of the key issues an investor or buyer will look at is whether a company owns the intellectual property rights used in the course of its business. Securing this right at the beginning will save you money and time in the long run but may be more complicated than you might suppose.
5 of 5 Insights