Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 604108 - [Future EAPI] Provide a flexible mechanism to combine licenses with exceptions
Summary: [Future EAPI] Provide a flexible mechanism to combine licenses with exceptions
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: PMS/EAPI (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: PMS/EAPI
Depends on:
Blocks: future-eapi
  Show dependency tree
Reported: 2016-12-30 03:49 UTC by Göktürk Yüksek
Modified: 2017-03-01 14:54 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Göktürk Yüksek archtester gentoo-dev 2016-12-30 03:49:17 UTC
Right now, if a package uses a license (such as the GPL-3) that allows certain exceptions (like the GPL-3 section 7), we have to create a completely new license file (such as GPL-3+-with-opencl-exception). To make matters worse, if a source file contains the same license with the same exception with another exception clause, we make yet another license file for it (such as GPL-3+-with-opencl-openssl-exception). Furthermore, using the same exception with different versions from the same license family results in one extra file for each combination (such as GPL-2-with-font-exception vs. GPL-3-with-font-exception). There is also the situation of an exception being combined with a license that allows the package to be relicensed using future versions of the license (GPL-3 vs GPL-3+, combined with exceptions).

A syntax for the LICENSE variable that allows licenses to be combined with exceptions would simplify the situation greatly. Something like '&& ( GPL-3+ opencl-exception openssl-exception )'. I am not necessarily advocating for the '&&' operator and would be happy with anything.

There are a few problems that need to be tackled:
- Where to store the exception files? They are not licenses and cannot be treated as such. An exception alone without a license has no meaning.
- The ACCEPT_LICENSE mechanism defined in GLEP 23 does not accommodate well for the exceptions. i.e. how to make sure that GPL-3 with openssl-exception is ok, but GPL-2 with openssl-exception is not.
- What is the legality of such an approach?

CC'ing the licenses team for their opinion on the matter as well.
Comment 1 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2016-12-31 23:17:49 UTC
I think it would be worthwhile to entirely rethink how we handle licenses.
Both Yocto and SPDX provide useful direction in this regard.
NEITHER of them store the licenses with the package repo (This would provide an ~7MB saving in gentoo repo), but provide separate reference archives of known licenses, and allow users to request licenses be explicitly installed.

Exceptions are just a special case of recognizing multiple licenses in a single file.

We should be capturing location/identity of full license texts AND short license texts on in files (the statement that the file is covered under XYZ license, which may or may not be included in the distfile).

Yocto has this:

It's a line-based selection of license text, with checksums on the text to uniquely identify it; the packaging system verifies the licenses in the distfile on extraction.

This is really useful, because it allows detection of some of the very subtle wording differences in licenses. For example, the GPL-2 text contains the various addresses of FSF as they've moved over the years, and it can refer to the LGPL as "GNU Library General Public License" or "GNU Lesser General Public License" instead.

This occurs frequently in the BSD license family, where you're expected to change the copyright ownership & date line at the top of the license file. In BSD-3, you also put the ownership's name in the 3rd clause (the no-endorsements clause).

In the scope of Gentoo, we'd be declaring something the following.

I'm using using Wireshark-2.2.3 ebuild as my example.
It also seems that our license on Wireshark, LICENSE="GPL-2", is wrong, and needs updating.
It should be at LEAST: LICENSE="GPL-2+ GPL-3+ BSD-2 BSD-3 LGPL-2.1+ GPL-3+-with-bison-2.2-exception"
("GPL-3+-with-bison-2.2-exception" is a new exception we need to add).

Most packages are going to have a MUCH smaller example than this, with at most a few entries.



OpenEmbedded/Yocto have a lot of the tooling to detect license text already to build these variables.

ACCEPT_LICENSE would remain mostly the same, as would our license groups.

Exceptions should be tied to the original license, and not be mixed & matched. (Eg the "XYZ" part of GPL2+exception-XYZ is not the same as the "XYZ" part of GPL3+exception-XYZ).
This allows cases of multiple exceptions to be easily declared.
I would declare the exception fragments with the original license at the start of their name:
The text might happen to be identical, but the combined effect of GPL2+XYZ and GPL3+XYZ might not be identical.

The exceptions should ALSO be added to the appropriate license groups (eg a given GPL exception might NOT be FSF-Approved)
Comment 2 Matija "hook" Šuklje 2017-03-01 14:54:05 UTC
If we are to change our licensing syntax, I would propose to adopt SPDX expressions, as it is becoming the de facto industry standard (even Yocto is using it in Yocto+SPDX) and widely supported by licensing scanners.

Robbat’s suggestion would then read in SPDX annotation as:

(GPL-2.0+ AND GPL-3.0+ AND BSD-2-Clause AND BSD-3-Clause AND LGPL-2.1+ AND (GPL-3.0+ WITH Bison-exception-2.2))

Relevant links to the SPDX license info on these, that match the SPDX short identifiers as used above: – there are several 2-clause BSD licenses, this is the standard one – there are several 2-clause BSD licenses, this is the standard one

Also I fully agree with Robbat that exceptions would have to be categorised whether they are FSF or OSI approved, are considered Free or not.