Hello, in https://github.com/fsfe/reuse-docs/issues/147 How to determine "overall" license
I've asked for the use case to be considered that I want my Free Software component to be attractive for others. Especially to those that look for something they can integrate into their product and is compatible with their current licenses.
As there are many Free Software products, I'll need a first indication to either look elsewhere or to take a deeper look. If a repository indicates the license that everything will be compatible under a license, which usually is the one with the highest freedom protection, that is the needed info.
However REUSE 3.0 cannot indicate such a license (at least I do not know how). Thus a repository which is fully REUSE compatible currently is at a disadvantage compared to other repos on popular code platforms. Some platforms do not understand the information per file coming from Reuse. And even if those platforms could deal with the more complex information provided by a REUSE compatible repos, they still could not display this important summary info about licensing in a repo, as it is not expressed.
Is Matija's closing of the issue 147 showing that this use case is irrelevant to REUSE?
Regards, Bernhard
Hi Bernhard,
On 13/05/2024 15:05, Bernhard Reiter wrote:
Hello, in https://github.com/fsfe/reuse-docs/issues/147 How to determine "overall" license
I've asked for the use case to be considered that I want my Free Software component to be attractive for others. Especially to those that look for something they can integrate into their product and is compatible with their current licenses.
As there are many Free Software products, I'll need a first indication to either look elsewhere or to take a deeper look. If a repository indicates the license that everything will be compatible under a license, which usually is the one with the highest freedom protection, that is the needed info.
However REUSE 3.0 cannot indicate such a license (at least I do not know how). Thus a repository which is fully REUSE compatible currently is at a disadvantage compared to other repos on popular code platforms. Some platforms do not understand the information per file coming from Reuse. And even if those platforms could deal with the more complex information provided by a REUSE compatible repos, they still could not display this important summary info about licensing in a repo, as it is not expressed.
I'm not a REUSE expert, but I believe that the typical practice would be to have a top-level COPYING or LICENSE file which is the symlink to the "highest compatible" license in the licenses directory.
Is Matija's closing of the issue 147 showing that this use case is irrelevant to REUSE?
I think it was closed because:
- the concept of a concluded license is out of scope for REUSE (AFAIU); - your "highest compatible" license is something different than a concluded license.
Regards, Arnout
Hi Arnout,
thanks for your response!
Am Montag 13 Mai 2024 15:34:04 schrieb Arnout Vandecappelle:
I believe that the typical practice would be to have a top-level COPYING or LICENSE file which is the symlink to the "highest compatible" license in the licenses directory.
it somehow a bit against the spirit of the current specification in my view. And an implementation details prevents this from working for go and github, see https://github.com/golang/go/issues/40586
If this is recommended practice, then I think Reuse should mention it.
Is Matija's closing of the issue 147 showing that this use case is irrelevant to REUSE?
I think it was closed because:
- the concept of a concluded license is out of scope for REUSE (AFAIU);
- your "highest compatible" license is something different than a concluded
license.
Do you think it makes sense to open a new issue then? (I had hoped to explain the problem in that issue and it could have been refocussed as well.)
Best, Bernhard
Hi Bernhard,
Computing and communicating the concluded or highest compatible licence is indeed out of scope for REUSE. There lie dragons that way. REUSE just communicates the status quo of a project's licensing---downstream consumers of a REUSE-compatible package can easily [sic] work out the highest compatible licence given the metadata provided by REUSE.
That's not to say you can't help downstream along. reuse-tool includes a 'Licensing' section at the bottom of the README that spells out the licensing situation in more detail than you can divine from `ls LICENSES/`.
But there is no standardised way to communicate that information, for a few reasons:
- Out of scope. - A concluded licence may be useless without information on how you arrived at that conclusion, which cannot be easily expressed in a machine-readable way, which is one of REUSE's core goals. - Downstream may _disagree_ about how you concluded your highest compatible licence. You may in turn disagree with downstream, but for all intents and purposes, you would be distributing false or contentious information. - It adds more duplicated work (and thus more vectors for getting this wrong), because people have to manually add their licensing situation to e.g. package.json anyway, and they probably also want to add it to their README.
However, there is obviously _some_ use-case for communicating this information. REUSE will not standardise this, but we already have provisions for this in v3.2 of the spec (unmerged).
You MAY include a `COPYING` or `LICENSE` file (with or without file extensions) in your project for compliance with other standards, conventions, or tools. These files MAY contain a copy of the license text, a summary of your licensing, or anything else. These files are ignored by the REUSE Tool.
See https://github.com/fsfe/reuse-docs/pull/133.
It may be prudent to add a note about this to the FAQ.
I hope that answers your questions, even if there's no real satisfactory 'this is how you do it' solution.
As a note, I'm going to be working on improving documentation on the website for the coming weeks. That area desperately needs a little love. These improvements won't be live for a while until v3.2 is released, but enfin. If you have suggestions for improvements of the documentation (something missing, something poorly phrased, something wrong), by all means feel free to open issues against the reuse-docs repository[1].
Yours with kindness, Carmen
[1]: This will be merged with the reuse-website repository soon-ish, hopefully, but I'll transfer the issues when that happens.