Making project REUSE compliant (OSS licensing)

[rugk]

The problem

Licensing is complicated, if you want to do it right. And if you were to really do it right you would have to mark each file.

And our licensing is a huge mix… 🙈
https://github.com/PrivateBin/PrivateBin/blob/master/LICENSE.md

The solution

https://reuse.software/tutorial/ makes this easy. I just discovered this and thought it may be a good solution (by the FSFE and others).

I guess running the tool may be the best. It seems it can do a lot of things…

And there are even CI tools/integrations: https://reuse.software/dev/
And you can register your project for being compliant.

Alternatives

• keep licenses as is
• just do some steps, as splitting up the "one big license file"

Additional context

[elrido]

So, having re-read the tutorial several times, now... We do provide all the licenses in one file, where github can find it and people expect it, including a short explanation that the project itself is zlib licensed, but includes third party libraries with other licenses, etc.

The tutorial also suggests to add license headers to all sources, which we also provide and don't strip from the included libraries either. So the only difference is that with this tool the license live in a folder LICENSE instead of at the top level? Would splitting up the file not make it more difficult to find the right license for each component or understand which of the files applies to our own code?

[rugk]

Well… it's also about details like using SPDYX (uhm did not recall how it is named correctly; edit: SPDX) identifiers for licenses etc.

Also, binary files need license info attached. (Thinking of webassembly etc.) The tool should do that, AFAIK, though. And the licenses then need to be correctly attached.

I just requested a check on https://api.reuse.software/register, so then we can maybe see what is missing. (Used a PrivateBin mail here.) One should see the result here then: https://api.reuse.software/info/github.com/PrivateBin/PrivateBin

We do provide all the licenses in one file, where github can find it and people expect it, including a short explanation that the project itself is zlib licensed,

This sounds critical. However we can keep the license file and I would also argue for doing that for the reasons you've stated. One just does not use one license file, but refers to the multiple licenses then or so.
And I would keep all that explanation there, too.

Would splitting up the file not make it more difficult to find the right license for each component or understand which of the files applies to our own code?

Well… as far as I understand it the project wants to do exactly that way easier. You have identifiers/references for each file in your reporsitory, so that this is very clear. These use a standardized ID (or in case of custom licenses like our MIT licenses a custom unique identifier) to refer to the license, which you can find in the license directory.

The main LICENSE readme could be kept, but would just refer to the license files itself to keep the "big legal blub" out of focus and just mention the important facts in short. It could also made to link to these files.