Compliant use of open source software in embedded systems - Part 2: What are the obligations regarding copyright notices and source code?

Modern cloud, embedded and mobile computing technologies are largely based on solutions with open source code. Open source software (OSS) is also an important component of so-called embedded systems. Such embedded systems can be found in automation and automotive technology, production machines, telecommunications systems and household appliances.

The second part of this article deals with the distribution of copyright notices and source code as well as the special problem of the copyleft effect (for part 1 of the article, see Open source in embedded systems.

Passing on the copyright notices

In addition to the license text, existing copyright notices must also be passed on unchanged. Compliance with this obligation becomes problematic if the embedded system is to be transmitted in binary code. The vast majority of copyright notices are distributed in the individual source files of the OSS.

Thus, anyone who distributes the software in binary code only must gather the copyright notices from the source files and merge them into a separate document. If there are several software components, the copyright notices must also be assigned to individual files. In the case of complex embedded systems, this can easily add up to several hundred thousand source files, which then have to be individually scanned for copyright notices. Even though some scanning tools specialize in finding such copyright notices, they do not find all the notices and require a lot of manual rework.

In most devices with embedded systems, the user does not have full access to the file system. He cannot access and read source files stored there with on-board means. Copyright notices may be stored on the device. Whether they are "appropriate" and above all recognizable in front of the user is doubtful, but conspicuous or unmissable in the sense of the English term "conspicuously" they may not be.

Sharing the source code

Not all OSS licenses require the distribution of source code. But those that do impose an obligation cause problems in practice. Finally, clause 3 of the GPLv2 requires the availability of the source code. This obligation can be fulfilled either by shipping the source code directly with the embedded system or terminal device, or by making an offer to the general public to obtain the source code for a period of at least three years on a data carrier in return for reimbursement of the reproduction costs.

In practice, this means either supplying the source code or making an offer. At least under the widespread GPLv2, it is not sufficient to refer to a download option; rather, the source code must be sent on a standard data carrier. Of course, it does no harm to refer to a download option nevertheless, since this will be the most frequently used way in practice. From a legal point of view, however, those who do not directly supply the source code cannot avoid such an offer.

Special problem copyleft effect

If a manufacturer uses so-called copyleft licenses in an embedded system, it must be ensured during development that the corresponding components do not infect the complete embedded system. After all, in most cases it also consists of proprietary software components.

During development, it must be clarified at each step which criteria can lead to the OSS license affecting the processing. This would infect the complete embedded system, so to speak. Here it is crucial whether the original program was edited or an independent program addition was added. Due to the lack of supreme court rulings and ambiguous criteria in the license texts, it is difficult to draw a precise line between the two and it is ultimately not possible to answer this question conclusively.

Whether the copyleft effect can occur can be checked in three steps. First, it must be determined whether changes have been made to the original program copy or parts thereof, i.e. whether a so-called "derivative work" has been created. The second step is to determine whether the files to be distributed contain parts of the work that are functionally independent and autonomous from the original program copy. If there are independent works, the last step is to examine whether the distribution form is separate or as a whole.

The infection effect of certain OSS licenses presents companies with considerable challenges. They have to conduct comprehensive and sometimes - due to a lack of clear regulations - difficult investigations of their programs and software developments and thereby bear the risk of high economic losses and serious damage to their image.

In addition to a blanket reservation of consent for the use of any OSS, it is conceivable that only the use of copyleft licenses requires consent. In addition, requirements for the architecture of the embedded system are conceivable, which are intended to avoid infection of any proprietary components.

Who checks the source code?

If the source code must be provided, the delivery obligation should include the transfer of all source code files, including makefiles and scripts, as well as the provision of instructions for compiling the source code. In a decision, the Regional Court of Hamburg stated that a distributor may not rely exclusively on assurances from the supplier, but that there are also duties to inspect and inquire. This applies both to the manufacturers of embedded systems and to those customers who install such systems in their end devices. In order to ensure that not all participants in a supply chain have to perform technical inspections to the same extent, the contract design should take into account who performs which tasks and assumes which obligations.

Assurances and indemnification clauses

As a rule, the contractual partners will not (want to) manage without assurances and indemnification clauses. When drafting them, the provisions of Section 307 et seq. of the German Civil Code (BGB) must also be observed. Distribution agreements are to be regarded as general terms and conditions - unless they have been fully negotiated in the individual case. Consequently, an unreasonable disadvantage should not arise. Notwithstanding this, an assurance should cover the following topics:
• The materials and information provided are complete and accurate,
• the OSS components used are under OSS licenses that are compatible with each other, i.e. the use of one OSS license must not result in violating the provisions of another OSS license,
• the use of the OSS components must not lead to a copyleft effect for the entire product,
• all relevant license obligations are fulfilled at the time of distribution.
In the event of a breach of the warranties, the supplier should be obliged to remedy the situation and indemnify against damages.

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
witzel@web-partner.de

• 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?