Compliant use of open source software in embedded systems - Part 1: Which licensing obligations must be met?
Open source software (OSS) has become an indispensable part of software development. The development of modern cloud systems, embedded and mobile computing technologies is largely based on solutions which contain open source code. OSS is also an important component of so-called embedded systems. These are computer systems that are embedded in devices, tools and machines and run special applications within such devices, tools and machines. Such embedded systems can be found in automation and automotive technology, production machines, telecommunications systems and household appliances.
The licensing obligations impose particular challenges for both the manufacturers of these embedded systems and the manufacturers who incorporate such software components in their end products. The first part of this article deals with the practical problems involved in implementing these licensing obligations.
Compliance with licensing obligations for embedded systems can be challenging!
Embedded systems that include OSS are subject to their own rules. On the one hand, the user, i.e. the manufacturer of such a system, the distributor and even the end user are granted extensive rights that they do not receive with a classic proprietary product. On the other hand, there are also licensing obligations for which there is no equivalent in the proprietary world.
Distribution of open source software triggers licensing obligations!
The manufacturer of an embedded system and the manufacturer of the final device containing such embedded systems must above all comply with the relevant licensing obligations triggered by the distribution. This is particularly complex because it usually involves several hundred components under different OSS licenses. Even in the relationship between the manufacturer of an embedded system and its customer, the (contractual) compliance is not easy. At the latest when the end product is distributed to the purchaser, it becomes clear that the contents of the current OSS licenses are not designed for this constellation and the compliance of the obligations is almost impracticable if you follow the wording of the OSS licenses.
Consolidate the license texts
Many manufacturers cannot answer the question of which open source software is contained in a software application or in an embedded system. Many embedded systems easily have several hundred thousand files, between which hundreds of license texts are hidden, which are available in a wide variety of formats.
There are scanners that search the source code for license texts or individual copyright notices. However, they do not work error-free, which is not least due to the lack of standards on the developer side in dealing with OSS licenses. Anyone who wants to ensure that all license texts have been recorded is therefore largely dependent on manual work.
Submission of license texts
Once the license texts have been consolidated, the manufacturer of the embedded system and the manufacturer of the end device must consider how the license texts can be made available in a transparent and practical manner. The procedure must also be feasible with economically justifiable effort. The following variants are under discussion:
Submission of a classic hardcopy,
Submission in electronic format on a data carrier,
Provision of the license texts on a (disclosure) web page of the manufacturer,
Making the license texts available via a web server to which the respective product has a connection,
Installation on the product itself and making it available via a display.
The practical implementation problems that can arise when using OSS in household appliances, vehicles and other items were not in anyone's mind when the OSS licenses still in use today were created.
Alternatives to a submission via hardcopy
The legal literature considers the transfer of license texts as hardcopy to be in compliance with the license. For the manufacturers of embedded systems and even more so of end devices, this procedure is hardly practicable.
An alternative can be to demonstrate the license text on the display of the embedded system or end device - if said device has such a display. This solution is found primarily on smartphones and tablets. The smaller the display, the greater the risk of a confusing display. It may no longer be possible to fulfill the purpose of this license requirement if the user has to scroll for minutes and ends up with no overview of which OSS license belongs to which open source component.
A presentation of the licenses on a website would have to be license-compliant at least when it comes to embedded systems and end devices without a display. After all, the purpose of the obligation is to inform the end user of his rights with regard to the corresponding software component.
Liability and warranty exclusions
Most OSS licenses provide for an almost complete exclusion of liability and warranty for the components licensed below them. Under German law, a complete exclusion of liability and warranty cannot be effectively agreed even in the case of a license grant free of charge (considered as a gift). Thus, the donor is regularly liable only for intent and gross negligence; with regard to material defects, warranty claims are regularly limited to cases of fraudulent intent.
Manufacturers and purchasers of embedded systems installed in end devices must address the issue of open source in their contractual agreements. This also applies to those for whom software has not been an issue to date. Without the provision of comprehensive information on the OSS components used, the license obligations described cannot be fulfilled.
We advise manufacturers of embedded systems and manufacturers of end devices with embedded systems on identifying and minimizing legal risks and support them in all licensing and copyright issues.
Michaela Witzel, LL.M. (Fordham University School of Law), Certified Expert for IT Law
• Open Source Software – Teil 1: Welche Geschäftsmodelle stehen dahinter?
• Open Source Software -Teil 2: Welche rechtlichen Risiken drohen?
• Open Source Software -Teil 3: Worauf kommt es bei der Compliance an?