Open source software is widely used in commercial environments. The risks associated with it must be adequately covered in IT contracts.
Open source software (often abbreviated as "OSS") has become an integral part of today's IT landscape. From web frameworks and audio formats to libraries for machine learning, open source solutions can be found for many technical challenges.
Definition: open source vs. closed source
"Source" refers to the source code of a program, i.e. the program code that is written in a human-readable programming language and can only be executed on a computer after translation into machine-readable code using a "compiler". The question as to when software is considered "open source" is not always easy to answer. There is no universal or statutory definition of the term. In fact, different organisations and interest groups use different definitions, some of which vary in terms of detail.
However, what these definitions generally have in common is that OSS is understood to mean software with a source code that is available to everyone and is licensed in a way that grants the user the right to use, modify and distribute the software under the respective licence conditions. Part of the definition of "open source" may even include the obligation to disclose the source code if the user of the OSS makes modifications to the source code or embeds it in other software.
The counterpart to OSS (i.e. software that is only distributed by the respective developer under restrictive rights of use and the source code of which the developer typically keeps secret) is usually referred to as "closed source" or "proprietary software" in contrast to "open source". Instead of the source code, the developer of proprietary software usually only provides the program itself, which has already been translated into machine-readable code and is ready to run. The source code cannot be easily derived from this and, for technical reasons alone, it is very difficult for the user to make changes to the software.
Open source offers both opportunities and risks
In the vast majority of cases, OSS is offered free of charge by its developers. However, this does not automatically mean that OSS can be used in any way without restrictions. When deciding whether to use OSS in a project, it is important to bear in mind that "open source" does not mean "free of legal restrictions". The use of OSS is only permitted by its developers on the condition that the provisions of the relevant licence under which the software was published are complied with. A legally binding licence agreement is therefore concluded between the developers (as licensors) and the users (as licensees). This licence agreement is then subject to the conditions of the respective OSS licence.
Many OSS licences (and thus also many user agreements between developers and users) contain extensive obligations for users, who use, modify or integrate OSS into their own software. Breaching these obligations can have significant legal and economic consequences. These range from injunctive relief to the obligation to disclose the complete source code of the software in which the OSS was implemented. These can also be enforced in court if necessary.
The advantages of using OSS for a project are clear: For many problems, there are existing and optimised solutions that are immediately available and can thus significantly reduce the development time for the project. There are generally no direct licence costs for the use of OSS components, which keeps the project costs low compared to licensing commercial software. In addition, OSS is often backed by a large developer community that contributes considerable expertise to its development. This often results in high-quality software and allows for short update cycles, which enable a quick response when vulnerabilities or new software requirements emerge.
Examples of obligations under OSS licence agreements
As explained above, OSS is not used without legal restrictions, but on the basis of a licence agreement. The content of this licence agreement and the resulting obligations of the licensee are governed by the licence under which the OSS is made available. Due to the large number of OSS licences in use, some of which may also be applied in modified form, it is not possible to draw up a definitive and universally applicable list of obligations that apply to all users of OSS. The specific obligations that apply to the user must be thoroughly examined in each individual case before the OSS is used.
However, most OSS licences require that, when redistributing the OSS (whether as standalone and, if applicable, modified software or integrated into a larger software product), the licence text be provided, existing copyright notices in the source code be retained, and the source code be made accessible.
The obligation to make the source code accessible is particularly risky for companies, as the scope of this obligation is often greater than users realise: With so-called "copyleft" licences such as the GPL, there is a risk of "infection" of proprietary source code: If OSS is integrated into proprietary software, a copyleft licence can stipulate that the proprietary part is also subject to the same disclosure obligations and is thus essentially "infected" by the OSS licence. This means that the use of a single OSS code module in a comprehensive piece of software that otherwise consists entirely of self-developed code could result in the entire source code of this software having to be disclosed and made available to third parties free of charge. Such scenarios are difficult for any company. For software start-ups, whose company value often lies solely in the software they have developed, such an "infection" is particularly critical, as it could significantly hamper the marketing of the company's only product and massively reduce the company value.
Another aspect that is particularly relevant in the development of firmware for electrical devices is discussed under the keyword "tivoization". This involves the possibility of running versions of the OSS components originally installed on the device that have been modified by the customer on that device. This concerns classic device categories such as multimedia devices, but potentially also critical components such as engine control units, ABS systems or pacemakers. While this aspect was often not explicitly regulated in the past, newer licence conditions sometimes explicitly include the obligation to enable this.
Using OSS in projects
In many projects, the use of OSS is completely ruled out by contract. In this case, developers are contractually obliged not to use any OSS components, so that the client can be granted exclusive and unlimited rights to the work result. This approach ensures clear and straightforward IP legal relationships, so that it is clear from the outset that any use of the software developed in the project is permitted and that the client is not restricted in any way. However, companies pay for this with the need to develop their own solutions even for routine problems, which involves a considerable amount of time and money.
Particularly in newer and less sensitive projects, a different approach is often taken: The use of OSS with "permissive" licences (e.g. BSD, MIT or Apache 2.0) is then usually permitted, i.e. licences that do not impose any significant obligations on the user of the OSS and, in particular, do not provide for any copyleft effect with regard to the user's proprietary source code. This enables the use of OSS components and, as a result, faster and cheaper development with limited disclosure obligations. However, this approach requires increased attention to effective licence management. In addition, (unlike when it is clear from the outset that OSS may not be used at all), there is a greater risk of unintentional use of OSS that is actually covered by a copyleft licence if it is mistakenly assumed that this OSS is covered by a permissive licence.
In some cases, however, clients also make a conscious decision to use OSS and develop the commissioned software product under an open source licence. There are many possible reasons for this: The intention may be to build a community with resources that can be used in the future for the further development of the product, which would significantly reduce the cost and speed up the development process. Providers who are trying to establish their software as the standard (or, conversely, to replace a competitor's expensive standard with an attractive alternative) also have an interest in distributing their own product under an OSS licence, as the use of their OSS offering is perceived as advantageous for their customers for the reasons outlined above. The low economic barrier for third parties can also create an incentive to build a third-party ecosystem around the developed product. On the flip side, providers must accept the loss of exclusive exploitation rights and considerable challenges in monetising their software.
Contractual provisions are crucial when using open source
Regardless of the client's position on the opportunities and risks involved, as soon as they outsource development services within the scope of IT projects, the relevant aspects should be regulated in detail in the corresponding project or development contract.
In general, such a contract should contain a clear definition of what is meant by "open source" in each individual case where this term is used. In view of the wide range of OSS licences under which software can be licensed, this requires precision. This point is particularly relevant if the client does not wish to exclude OSS in general, but would like to allow or even promote it under certain conditions. In this context, it is particularly useful to draw up a "whitelist", i.e. a definitive list of licence types that the client has deemed to be acceptable. The contractor may then only use OSS that is covered by one of the licences included in the whitelist. Alternatively, the framework conditions under which the contractor wishes to use and distribute the development at a later date can also be described in abstract terms. The contractor can then be obliged (ideally in the form of a guarantee) to ensure that the end product can be used or distributed as desired, in compliance with all licence conditions of the components used in the software.
Unless the use of OSS is generally prohibited, the contractor should be obliged to document the OSS used, including the licence and version, and to keep this documentation up to date. This is the only way for the client to ensure that they themselves can carry out proper licence management, which is necessary in order to keep track of the licence agreements existing in the company and to be able to comply with the obligations arising from them.
You can find out more about this in our blog series on IT projects (in German). You can subscribe to this blog series via the RSS feed to be informed about new posts.
