How to determine "overall" license
bernhardreiter opened this issue · comments
On a few code platforms, only one License is shown. This makes sense if the License can be displayed that is the one where all code parts under different licenses are combined and compatible.
For example, one products has files with the licenses from
- Apache-2.0
- GNU LGPL
- GNU AGPL-3.0-or-later
then AGPL-3.0-or-later would be safe to display to give people an idea what the strongest freedom protecting license is that the whole repository could be used (or distributed) under.
I believe Reuse needs a way to give the information.
It there already one?
Maybe the https://spdx.github.io/spdx-spec/v2.3/package-information/#713-concluded-license-field
or declared licensing fields from SPDX could cover this?
No, here be dragons!
Unless a license allows you to relicense (or sublicense), you need to comply with all of them regardless. For starters, Apache-2.0 does have some interesting
The “overall” license in your example is correctly:
(Apache-2.0 AND LGPL-2.0-or-later AND AGPL-3.0-or-later)
What that means in terms of obligations is well outside of scope of REUSE.
There are other tools to handle that (e.g. based on REUSE output) – https://hermine-foss.org/ being one that I feel very optimistic about.
https://github.com/vinland-technology/flict is another, but is more leaning towards the license compatibility question.
What REUSE could offer would be a way to indicate a license where everything shall be compatible under, like the AGPL-3.0-or-later in this example.
Otherwise it is a drawback for all Free Software components to be compliant to REUSE 3.0 as they are displayed as a second class citizen, in e.g. Github (e.g. https://github.com/csaf-poc/csaf_distribution) and Go Package Directory: https://pkg.go.dev/github.com/csaf-poc/csaf_distribution/v3/csaf .
It will lead to less adoption for REUSE 3.0 as those and other platforms will not display a single license. And for someone that is searching if a Free Software component can be used for their product, they will only want to know the license with the strongest freedom protection to make their decision. They worry about the details for all licenses later, way after the decision.
Again, the “single license” theory is not just flawed, but false. It’s just a convenient lie everyone lives under, as it makes things seem much simpler than they are in practice.
This is more related to:
My view as a 20+years practitioneer is different. The license with the highest freedom protections is a very good and sufficient first approximation for the decision if I am possibly able to integrate that compoment into my product.
I take it your closing the issue means that REUSE is not considering the use case at all?
@bernhardreiter The use case is considered but not solvable, I think the
the “single license” theory is not just flawed, but false.
statement is true.
Automatic license heuristics is complicated and will never deliver reliable results for all the possible use cases. There were many discussion on this (I read them probably all when we introduced REUSE in our company) and I can say: every thinkable argument was already thought-out by someone somewhere. Therefore, I don't think it makes sense to keep such issues open as they are basically duplicates of older, finished discussions.
However, I also understand that it would be nice if all the broken license detection tools spit out something, even unreliable but working, for indexes and searches (for the sole reason of not having a disadvantages if inexperienced users are searching for projects and filter by often broken meta data).
If you need this, put the stated "license with the highest freedom protections" for indexes and GitHub in a LICENSE or COPYING file in the root directory of your project:
- GitHub uses Licensee to attempt to identify the license of a project and Licensee does not support the REUSE specification. A workaround to fix the automatic license detection of GitHub and others is to place an additional
LICENSEorCOPYINGfile in the root directory of your project. This is allowed by REUSE. These files are explicitly ignored by the toolset and do not need an additional.licensefile or header. - If you want to prevent a duplication of License texts beware of another issue with Licensee: You can place a symlink at
LICENSES/<your license>.txtpointing to theLICENSEorCOPYINGfile in the project's root directory asreuse lintfollows them. Licensee sadly does not even support symlinks, so a more logical symlink fromLICENSEorCOPYINGpointing toLICENSES/<your license>.txtis not solving the issue. We therefore recommend a real copy instead of a symlink to keep things accessible when using the workaround.
Thanks for the excellent summary @andreashaerter. I fully agree that REUSE is not the right toolset to interpret the licensing situation, that's out of scope.
It may be that @pombredanne is working on adding interpretation support in Scancode or adjacent tools.
Thanks for your comments @andreashaerter . I agree that we should profit from the wisdom gained by previous discussions. As it could become an FAQ it maybe interesting to write up that results and refer to it from the documentation. I've brought the use case up on the mailinglist as well, maybe the workaround should be mentioned as recommendation.
As to
The use case is considered but not solvable,
What were the arguments in the discussions against documenting the intention of the maintainers of the repositories?
This would solve the use case and could be done machine readable.
Making a statement like: We develop this Free Software product to be compatible under AGPL-3.0-or-later. should be fine, as implicitly it says if you find a dependency that is not, it is a defect and please file an issue.
Of course the documented intention is no guarantee, but License headers aren't either.
Of all the projects out there that try to fix this issue, I think Hermine (linked above) is the most promising. It concentrates on obligations of each license and then aggregates those a list of all obligations – kinda like an abstraction layer.