Open Source Compliance
Benefits and risks of using open source software
Companies face an increasing push to use of open source software, both in their own software development and in the procurement of software from third parties.
The use of open source software or “free and open source software” has become standard in software development. Open source software is freely available on the internet, saves time and allows typical standard functions to be integrated without any development effort.
The term Free and Open Source Software suggests when the software is “free” in every respect. However, the use of the software requires acceptance of and compliance with the underlying licence conditions. Frequently, however, these are observed little or not at all, which can lead to considerable economic risks (including injunctive relief, claims for damages).
Therefore, it is essential, especially for software development companies, to fully comply with the obligations associated with the use of open source software. In order not to be surprised by the negative consequences of non-compliance, it is advisable to introduce internal processes for monitoring compliance within the framework of an open source compliance management.
What is Open Source Software?
Open source software is freely available, but can only be used under restrictions that are intended to enable further free use. For example, the Open Source Initiative (https://opensource.org/) published requirements to classification as open source software. Among other things, the source code must be available or be made available. Changes to the software must be permitted. The licence conditions used must not restrict distribution, no licence fee may be charged for the open source software and it must be permitted to market changes under the same conditions.
The various open source developers have gone different ways. Some use licences that allow use in conjunction with commercial products. Some oblige the user to combine the open source software only in conjunction with compatible licences or stipulate that their own licence conditions must apply to further developments or derivative works. This is also called “copyleft” or viral effect.
What impact does this have on commercial use?
For companies that only use open source software internally for their own purposes, there are hardly any restrictions preventing use. Occasionally, however, certain types of use are exempted.
However, if the open source software is made available to third parties or if it is incorporated into commercial software, it must be checked whether use and distribution in the intended way is covered by the underlying licence.
On the one hand, there are many licences that make this possible and even allow the use of commercial licence terms for the larger work. In contrast to commercial third-party products, the possibilities for use are usually more flexible here.
On the other hand, depending on the licence, the use of open source software can lead to restrictions. For example, if an open source software licenced under GNU General Public License (GNU GPL), is integrated the larger work cannot be distributed commercially or without disclosing the source code.
However, the type of use also plays a role here. Some licences (e.g. Affero General Public License) restrict commercial use to such an extent that use in connection with commercial SaaS services is restricted.
Other commitments
In addition to the fundamental question of the permissibility of use, some licences also provide for further obligations, e.g. passing on the licence conditions, disclosure of use, making available the source code of the open source software, naming the author.
Often, the developers know the concept of open source software, but not the associated restrictions and obligations. The consequences are usually a violation of the licence conditions and a resulting ban on using the open source software.
How do I reduce my risks?
First of all, an inventory should be made. Open source audits are a good way to do this, in which the source code of the own software and all open source components used are scanned. This allows you to find both obviously used open source software and so-called snipits that have been copied into the own code. The open source software should also be scanned completely in order to find third-party components it may contain.
There are various tools on the market that support the scan. Some of these can also be integrated into the development process. In this way, problematic developments can be discovered and eliminated at an early stage. In addition, the tools facilitate the creation of a Bill of Materials (BoM), a list of all matches with pieces of code, the version of the open source software, the respective download source and the applicable licence conditions.
It makes sense to whitelist unproblematic licences and blacklist problematic ones. All licences not listed would then have to be checked as necessary.
Awareness should be raised to the responsible employees and appropriate contractual regulations should be concluded with external developers.
In addition, the documentation measures should be summarised in a compliance programme.
Conclusion
The use of open source software brings both advantages and challenges. However, when the right components are selected and used in accordance with the conditions, it is often more interesting than commercial third-party products or in-house developments.