"Open source" software in proprietary products FOSS compliance

When developing proprietary software, open source software is often used to avoid "reinventing the wheel". For example, a free JPG library is integrated into proprietary software or the Linux kernel is included in embedded software or firmware. The open source software in question is subject to its own open source license conditions, which must be adhered to. In the event of license violations, third parties can demand injunctive relief and damages, among other things. In the open source sector, however, an even more serious consequence can occur: All of your own software may have to be published free of charge in source code. This is known as the copyleft effect or the "infection" of your own software by the open source license.

What is open source software?

Open source software or "free and open source software" (FOSS) is - in the simplest sense - software whose source code is generally accessible and may be used free of charge. One of the following licenses is often used for open source software:

  • GPL (GNU General Public License)

  • LGPL (GNU Lesser General Public License)

  • CDDL (Common Development and Distribution License)

  • MPL (Mozilla Public License)

  • EPL (Eclipse License)

  • BSD (Berkeley Software Distribution)

  • APL / ASL (Apache License)

  • MIT / X11

  • AFL-2.1 (Academic Free License)

Copyleft effect / "infection"

Some open source licenses provide for a copyleft effect. This means - with differences in detail - that the open source software may be edited free of charge and used in your own proprietary software, thus creating a "derived work". However, in return for free use, some open source licenses require that all or part of the proprietary software is not placed under proprietary license conditions, but under an open source license. This can mean that the entire proprietary software and all the know-how contained therein must be published in source code free of charge. This is known as "infecting" your own software or the copyleft effect. Copyleft is the antonym of copyright. With regard to GPL version 2, the relevant provision can be found in § 2 GPLv2:

"You must ensure that any work you distribute or publish that is derived in whole or in part from the Program or parts thereof is made available to third parties as a whole under the terms of this License without royalties."

Depending on the exact provisions of the open source license, a distinction is made between licenses with a strong copyleft effect, licenses with a weak copyleft effect and licenses without a copyleft effect, e.g:

It should be noted that a "derived work" can be created very quickly. Under the GPL, for example, in addition to a static integration of a library, the prevailing opinion is that a mere dynamic linking / integration of a library also leads to the occurrence of the copyleft effect. Any other too close dependency of one's own software on - in the example - GPL software can also lead to the existence of a derived work and thus to the occurrence of the copyleft effect.

In order to avoid undesirable effects, some open source software contains additions and exceptions to the actual open source license conditions. With regard to the GCC compiler software, for example, the "GPL linking exception" is provided. The "GNU Classpath Exception" is often included specifically for Java applications. Even the Linux kernel, which is licensed under the GPL, contains an exception so that application programs do not constitute derivative works and therefore not every Linux user program is automatically "infected" by the GPL.

License notice obligations

The open source licenses contain numerous other obligations that must be complied with in order to avoid a license violation. Many open source licenses, such as the GPL, even stipulate that the license as a whole ceases to apply as soon as a license violation is committed.

License notice obligations are included in almost all open source licenses. This obliges the user to provide certain notices or information each time the open source software is distributed. Numerous applications therefore contain long documents in the "About" section in which these notices and information are provided, e.g. in the Android operating system.

The compilation of notes and information is often associated with considerable effort, as not only a single open source software is usually integrated. In addition, most open source components are dependent on other open source components and therefore the information and notes on these components must also be observed. For possibilities and risks of an automated compilation of license information, see here.

License information as general terms and conditions

The reproduction of license notices often includes the obligation to print or display disclaimers. As a rule, however, these are disclaimers that have been formulated in accordance with another legal system and are almost always ineffective under German law. If the license information is therefore reproduced in such a way that the disclaimer is understood as a separate provision, an ineffective GTC liability provision would be used. In addition to the consequence of ineffectiveness, there is also the threat of costly warnings from third parties with demands for injunctive relief and contractual penalties.

License compatibility

Various open source components are often to be combined with one another in software. This is possible in principle. However, different open source licenses are incompatible with each other. For example, the LGPL and GPL licenses are incompatible. An overview with a - legally non-binding - assessment can be found on the gnu.org website.

Public Domain License

The "Public Domain" license is a special case. It is not a license in the strict sense, but rather the "release" of software into the "public domain", which is possible under US law, so that the software becomes generally available. In a sense, the author waives his copyrights. However, this is not possible under German copyright law. Although the author therefore expresses the intention not to assert any rights, the use of "public domain" software in the German legal area is not yet legally secure.

Dual licensing

Some open source software manufacturers allow the user to choose between two or more possible open source licenses. The user can then choose, for example, whether a particular open source software should be licensed under the GPL or under the CDDL. As the choice of license has a considerable impact on the user's own obligations, the choice of license should be carefully considered and documented.

Development environment and development tools

Proprietary software is often developed with the help of development environments and development tools from the open source sector. This raises the question of whether the open source license of the development environment or development tool alone also has an effect on the proprietary software. This question must ultimately be answered according to the exact license under which the development environment or development tool is licensed. However, the basic rule is that if the development environment or development tool integrates its own code into the end product, the license of the development environment or development tool must also be observed. Such code is often integrated without those responsible being aware of this. A detailed technical check should therefore be carried out.

Docker and container solutions

Please see our separate article here on the licensing implications of using Docker images and other container virtualization solutions.

Date: 7. Sep 2016