What are open source license families, compliance risks, and use cases?

Open Source license families

Although there is no consistent definition on different license types, or license families, open source licenses commonly fall into two major license families. Depending on whether the license will mandate to make the source publicly available or leave that to the licensee, the user, to decide, licenses are broadly divided into the Copyleft license family or the Permissive license family.

Copyleft licenses

The Copyleft licenses, sometimes called ‘reciprocal licenses’, can in turn be divided into strong copyleft licenses or weak copyleft licenses. The strength of the copyleft license is determined by the extent its provisions can be imposed on all kinds of derived works.

A Strong copyleft license requires that other code that is used for adding, enhancing, and/or modifying the original work also must inherit all the original work’s license requirements such as to make the code publicly available. The most notably strong copyleft license is GPL, General Public License.

A Weak copyleft license only requires that the source code of the original or modified work is made publicly available, other code that is used together with the work does not necessarily inherit the original work’s license requirements. Some weak copyleft licenses allows for dynamic linking without the provision for making the other code to have to be publicly available (LGPL), other weak copyleft licenses are even ‘weaker’ and maintains the copyleft provision only for files that are under the license (Mozilla Public License 2.0 and Eclipse Public License 2.0).

Permissive licenses

The Permissive licenses are just that, very permissive in what the user may do with the code, sometimes even to relicense the code, though they all have in common the condition that the copyright attribution and permission notice, sometimes the full license text, is maintained in the distribution of binary and/or source code.

In addition, there is a sub-family of even more permissive licenses, the Public domain-like licenses. In most countries outside of the USA it is not technically possible to attribute a work to the public, to put it in the Public Domain. Though, you may abstain from all other rights except for being the originator / licensor through a license, thus achieving the same effect as an attribution to the Public Domain. Hence, works in the Public Domain and works under Public domain-like licenses can be seen as being under a sort of ‘super-permissive’ license. However, Public domain-like licenses still require the license text to be maintained in distributions. (Do The F*ck You Want License and CC0, Creative Commons Zero). 

Open Source License Compliance risks

Licenses introduce a varying degree of conditions to be fulfilled for using the licensed software. Open Source licenses gives indeed many freedoms, but seldom completely unconditionally:

• Almost all licenses require you to attribute the distributed software with a copyright and a permission notice, sometimes in addition with the entire license text.

• Some licenses require you to publish the source code as well, which add work to ensure that you are in compliance with the license.

• Some licenses add rights and conditions beyond the copyright, suchs as on patents, trademarks, data, and privacy which may make it more difficult to altogether achieve compliance of a license.

• And to complicate things even further, some Open Source licenses have conditions which makes them incompatible with other Open Source licenses. This is most notably with the GPL license.

The risks involved with the compliance are not necessarily higher because of their nature, but arguably some compliance requirements are more easy to fulfill as they require quite a low effort, whereas some others will require a much larger effort and substantial legal analysis. To grade the potential compliance risks involved with a license we use a kind of a traffic-light grading system. Though, it is important to note that the color grading represents the estimated amount and complexity of the compliance concerns, not that some licenses are riskier than others – if you understand all the compliance requirements of a license and are able to fulfill those then the license is practically risk free regardless of the grading.  

RED	Banned license, high compliance risk, not allowed | Unknown licenseThis grading is used for a license that is not allowed use in, e.g. in company or project context, or for a use-case reason (such as with GPLv3 in consumer electronics) because it will likely cause a breach of the license terms, hence exposing you for possible legal challenges.The same applies for an Unknown license; without knowing the conditions for the use of the code, you expose yourself for possible legal challenges.
ORANGE	Restricted license with substantial compliance risks. Such licenses should one only be allowed after getting some legal guidance and on a project or case-by-case basis, as the compliance considerations are generally difficult to fully comply with.
YELLOW	Approved license, with sizable compliance considerations, such as the source code must be made publicly available and there are restrictions in combining with other code under a different license, as with the licenses in the Copyleft license family.
GREEN	Approved license, with few compliance considerations, such as the copyright and permission notice must be maintained in distributions of code, as with most licenses of the Permissive license family.
BLUE	Non-OSS / Commercial / Proprietary license

Open Source License Use-cases

When Free Software licenses and later Open Source licenses were created in the late 80’s and 90’s the world of software was very much one that software was physically distributed.  The licenses that came to be drafted at that time  granted the licensee to use, modify, copy, etc., conditioned upon certain requirements being met at the point of the distribution.

With distribution means ‘when the software leaves the legal boundaries of your control’, regardless if that is that you are selling, lending, or generally making the software publicly available. As long as you are using the software by yourself you can for (almost) all licenses do whatever you want, but as soon you distribute the software in one form or another the conditions of license must be met. That leaves us with the first two distinctions of use-cases, the Distributed or Non-distributed use-cases.

At the time that most FOSS-licenses were drafted, the practice that software would be run in a server or the like and made accessible through networks were at the time not widely considered. That came to change in the late 90’s, in particular with the web services that came in light.

The Free Software-movement started to see the practice of putting an application on a server that was publicly accessible through networks was a way of circumventing the conditions of GPL of making the source code open and publicly available – the software was not distributed per see, it is only the results of the execution of the software that are distributed.

This so-called Application Service Provider loophole was addressed with the Affero General Public License, which is designed to close this loophole with a provision that requires the full source code to be made available to any network user of the AGPL-licensed work. As a handful of Open Source licenses have follow with this provision too, so we have to split the Non-distributed use-case into two: ‘(I) Non-distributed, internally used only’ and ‘(II) Non-distributed, though publicly available as a network service’.

As with the Non-distributed use-cases, we have to split the Distributed use-case into two as well. This arises from a single license, GPLv3, that introduced a specific provision for the cases that ‘device manufacturers’ had introduced security measures and locks for hindering that modified code would be able to be executed in said devices, even if the code was provided as Free and Open Source. The provision in GPLv3 requires the manufacturer a mechanism to remove or disable any locking in a ‘consumer (electronics) product’.

As this means that most manufacturers of consumer electronics would leave their devices wide open for any modifications, leads to the devices in practice would be unsellable. Such is the case with mobile handsets where the network operators would not allow for unsafe handsets to connect to their network – and so device manufacturers have almost unisonly banned the GPLv3 license from the device software.

Hence, we have to distinguish between the use-cases of ‘(III) Distributed, executed in a generic environment (such as PC, Linux, etc.)’ and ‘(IV) Distributed, executed in consumer electronics (GPLv3)’

I	Non-distributed, internally used only
II	Non-distributed, though publicly available as a network service (e.g. web or cloud), “ASP loophole” use-case
III	Distributed, executed in a generic environment (e.g. PC, Linux)
IV	Distributed, executed in consumer electronics (GPLv3)