Ninety-nine per cent of all commercial software includes open source components and, on the average, 75 per cent of all codebases are composed of open source. These are the findings of Synopsys Inc based on 1.546 Black Duck code scans in 2020. Open source components are "free" in the sense that there is no fee to pay to the owners of the components. However, the usage is conditional on meeting certain terms and conditions. The terms and conditions are set out in open source licenses.
If you do use open source, you must comply with the licenses. If not, you are infringing the intellectual property rights of the owner. In such circumstances, an owner can demand an immediate cessation of use, and make economic claims for compensation or damages. In the worst case, a user must retract or cease to use a product until infringing components are replaced. We are not aware of any such case in Norway, so the risk of receiving a claim is probably low. If the claim is made however, we think the owner may very well succeed. In many jurisdictions, the courts have confirmed that conformance with open source licenses is required.
If a software product company is for sale or tries to attract investment, often there will be open source due diligence, with any open source related risks being set out in a due diligence report. We have not had experience of any transactions which has being cancelled due to non-compliance and risk related to open source. However, we have seen non-compliance with open source licenses or other open source issues resulting in time and cost consuming dialogue, demands for additional warranties or indemnities, and insurance companies refusing to insure open source risk in relation to a transaction.
Therefore, it is a good investment for any software product company to ensure that open source is being used correctly and in compliance with the open source licenses. It goes without saying that it is also the right thing to do as no software product company should infringe intellectual property rights.
One key step to ensure the correct use of open source is to create, maintain and enforce an open source policy. What is an open source policy? It is a written document defining what to do and what not to do, in relation to open source. Normally there are also rules regarding decision making and setting out the decision makers. The open source policy should not only be used internally, it should also form part of all external software development contracts such that external developers also comply. The policy may need to be adapted for external usage under such contracts.
Responsibility for the open source policy and its update and enforcement should rest with a suitably experienced person within the company. We do not consider that this person must hold a particular title but he or she should have in-depth competence in open source and open source licensing.
The simpler the open source policy the more likely it will be complied with. In our view a good open source policy is a short one. We set out below examples of what could be part of an open source policy which may assist those who are tasked with creating an open source policy.
The following points may be included in the section of the policy relating to product developers.
- The developer shall not include in its deliverables any open source components for which no license is known.
- The developer shall not paste any open source into its own developed source code. Open source components shall always be separated from all other code, in a directory separated from our own developed code.
- The developer shall not modify any open source component without the prior written permit of [responsible@domain].
- The developer may include in its deliverables any components licensed under the permissive open source licenses MIT, BSD, Apache License 2, zlib license, ISC and JSON. Components licensed under any other open source licenses requires the prior written permit of [responsible@domain].
- If permission is granted for use of a component subject to the GNU Lesser General Public License (LGPL) license, then the component shall solely be used as a library and only by dynamic linking.
- No code shall be made available outside the company as open source without the prior written consent of [responsible@domain].
- Note that the above applies to all materials subject to open source licenses, including data, fonts, pictures and databases.
The following points may be included in thesection of the policy relating to the person charged with managing open source matters.
- Under no circumstance shall permission be granted for the use in our products of any components licensed under the Affero General Public License (AGPL) or the Sleepycat license.
- For products being distributed in part or in full, under no circumstances shall the use of components licensed under the GNU General Public License (GPL) license (that has no applicable exception) be permitted, unless a qualified lawyer has assessed the use case.
- For products being distributed in part or in full or being delivered as a software-as-a-service, under no circumstances shall the use of components licensed under the Creative Commons Share-Alike licenses (CC-BY-SA), the Open Source License 3.0 or the European Union Public License be permitted, unless a qualified lawyer has assessed the use case.
- We shall properly attribute owners of open source software and provide such information required according to open source licenses. A tool shall be used to generate proper license information each time a new build of a product is made.
The above is not a complete open source policy nor is it necessarily appropriate for all companies.
Please do not hesitate to contact us if you would like our assistance in drafting an open source policy, training in open source matters, or if you have any open source related questions.