Software developers have access to powerful libraries and frameworks that significantly accelerate the development process. Software developers do not have to “reinvent the wheel”. These libraries and code snippets can be proprietary software, but it can also be open source software. Actually, software development without Open Source Software (OSS) is unthinkable nowadays.
Just to be sure we’re on the same page: Open Source Software is NOT identical with free software. However, if both conditions apply, you speaks of Free Open Source Software (FOSS). Do you have any idea how much Open Source Software is available in total? It’s a jaw-dropping figure: The Open Source Scanner provider WhiteSource puts the number of available OSS components at 155 million open source components (both source and binary) in languages such as Java, Ruby, and Python, and another 11 billion open source files in languages such as C/C++, Javascript, PHP, and ObjectiveC!
But how freely can you actually use Open Source Software? It’s simple, if you use OSS for personal use only. But, even when using OSS within a company, you’ll have to carefully read the license terms of the OSS. And it doesn’t come as a surprise, that you need to take an even more careful look at license terms, if you use OSS within a commercialized (software) application. The latter software application product is generally sold to third parties, you need to make sure that the license conditions of OSS are observed.
If you violate license terms, this comes with the risk of penalties. Let’s take a look at court cases in the jurisdiction of Germany. Take the example of a case in June 2013 at the Hamburg Regional Court: It was about the violation of license terms / GNU General Public License, Version 2. In this decision, the defendant was sentenced to a penalty of EUR 5,000 plus pre-trial legal costs of EUR 2,000. Further cases of legal proceedings in connection with the copyright of open source software can be found here: copyright, open source court cases.
However, the risk of claims for damages is rather low, see the attorney’s commentary on a decision of the Higher Regional Court in the city of Hamm in a lawsuit concerning copyright infringement: damages for violation of an open source license: In this case, the court rejected the claim for damages because the plaintiff had not suffered any damage; the licensing of the software under the GNU General Public License was interpreted such that the plaintiff had completely waived the monetary exploitation of its exclusive right of use.
Let me also point out that Open Source Software Audits (OSS Audits) are a Must-Have for many M&A transactions and IPOs. Such OSS Audit is part of the due diligence to check whether the use of the FOSS is compliant with the licensing conditions.
FOSS can be subject to very different license terms, and in fact, these licenses vary widely. In the following article, some of the most important open source licenses are presented as well as the licensing challenges that arise when using FOSS.
Licensing terms of Open Source Software: The copyleft clause
A main criterion to categorized licenses is the following: Do they contain a so-called copyleft clause? Or not? Or do they contain a “light” version of the copyleft clause?
Licenses with a strict copyleft clause: These require that all modifications must be subject to the original license when they are passed on. If you use for your self-developed (commercial) software a FOSS that is subject to a license with copyleft effect, there is a substantial risk that the self-developed software must entirely be subject to the very license conditions of the open source software. This could result in the obligation to disclose the source code of self-developed software. This is – in short – a Worst Case Scenario.
Wikipedia explains /justifies the basic idea of copyleft as follows: Copyleft originally came up in free software licenses. It enforces/ensures that further developments of the original Open Source program are free, too, and remain free. It thus prevents licensees from transferring the program into the proprietary domain by means of proprietary extensions.
The most common copyleft license is the GNU General Public License (here: 3.0). It’s worth reading the paragraph on “modified versions” (i.e.: further developments):
You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply (…) to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.
This principle cannot be considered “absolute”, i.e. you have to apply the principle of proportionality. There is, however, a lack of clarity in the interpretation and thus a risk under licensing law. It reads further: A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation’s users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
Due to the legal (residual) risk mentioned above, open source components that are subject to the GNU General Public License are simply no longer used in quite a few software companies.
Let’s take a look at Licenses with a limited copyleft clause: Licenses with a limited copyleft effect also have a copyleft effect, but this permits exceptions from the licensing obligation for adaptations.
Licenses without a copyleft clause (non-copyleft licenses): The above restrictions do not apply. You may, however, have to observe some minimum obligations.
More generally and independently of copyleft-clause or non-copyleft-clause: When passing on OSS to third parties, at least the following requirements must be met: (a) The third party is informed of the use of the open source software and the name of the rights holder is provided. (b) The license terms are provided (Disclosure and notification obligations). For the GNU General Public License it specifically states: You may convey verbatim copies of the Program’s source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice; keep intact all notices stating that this License and any non-permitted conditions added under section 7 apply to the code; keep intact all notices stating that no warranty of any kind exists; and give all recipients a copy of this License along with the Program..
Licensing terms of Open Source Software: License compatibility
A specific challenge when using (several) FOSS components is the so-called license compatibility. The crucial question: Are the licensing conditions of different FOSS components compatible with each other? What if a licensing condition of one FOSS stipulates something that excludes the use of another FOSS? In short: Can all license conditions be fulfilled without contradiction?
As a rule of thumb, you don’t need to worry of license compatibility, if you integrate FOSS FOSS components, that are subject to a non-copyleft license. Whereas Copyleft software (“strict” or “with limited copyleft clause”) in general cannot be combined with other copyleft software to form a new program. Because this new software cannot then be offered simultaneously under different licenses. There is exceptions to the latter case, e.g. a special compatibility clause.
If copyleft software (“strict” or “with limited copyleft clause”) is to be combined with non-copyleft software, you’ll have to do a case-by-case assessment. Let’s take an example, namely the compatibility between non-copyleft licenses and a license with limited copyleft: The Mozilla Public License 2.0 (MPL 2.0) is a license with a limited copyleft. The following applies: Not all derivative works are subject to this license, but software that is considered a “modification” in the sense of paragraph 1.10 of the license terms. The definition of “modification” is as follows
1.10. “Modifications” means any of the following:
(a) any file in Source Code Form that results from an addition to, deletion from, or modification of the contents of Covered Software; or
(b) any new file in Source Code Form that contains any Covered Software.
In other words, according to MPL 2.0 license conditions the requirement to subject the self-developed software using an MPL 2.0-FOSS component to the MPL 2.0 licensing terms depends on a formal element: Whether or not the software is available in separate or in uniform files. A simple recommendation can be derived from this: Keep the MPL 2.0-FOSS component in a separate file.
The Mozilla Public License 2.0 (the same is true for Mozilla Public License 1.1) is therefore basically compatible with non-copyleft licenses on the condition that the code is not integrated into the same files (e.g. dynamic linking).
Let us consider another case of the type compatibility between non-copyleft licenses and a limited copyleft license: The GNU Lesser General Public License 3.0 (“LGPL-3.0”), which is also a limited copyleft license.
Unlike the MPL 2.0, however, the copyleft is not connected to the same criterion: Rather the LPGL stipulates that LPGL-FOSS components be used as a library. You must not subject your self-developed Software to the original license of LGPL-3.0, if you integrate LGPL-3.0-FOSS components as libraries, without changing these. However, if you make changes to the library itself then the entire software must be made subject to the LGPL licensing conditions.
Tips for license and compliance management with open source software
For companies that frequently use open source software for their own software products, it is advisable to assign a manager that that task. He/She would be responsible for license and compliance management; he/she will be responsible of clarifications on open source software, as well as defining an open source policy for the company.
The first step in such a license and compliance management is to take stock of the FOSS in use and to determine the license terms of the FOSS components used. As indicated above, so-called OSS scanners are helpful for such task. Common OSS scanners are: OSS Discovery Project (Open Source Tool under the Affero GNU Public License), Black Duck (a pioneer in OSS scanners, commercial tool) or Flexera (formerly: Palamida, commercial tool). These tools do not only identify used open source code, but also detect (possible) license incompatibilities. The provider WhiteSource goes one step further and integrates its solution directly into the Software Development Lifecylce (SDLC).
