Machine-readable license information with REUSE

[Volker-Weissmann]

Hello there,
REUSE is a standard that allows a project to specifiy license and copyright information in a machine-readable format (e.g. reuse lint --json now tells you which file has which license).

E.g. the ArchLinux project also likes REUSE.

Happy to hear what you are thinking about this!

[Volker-Weissmann]

I just noticed that I need to fix a few things first, so I temporarily converted this PR to a draft...

[Volker-Weissmann]

I did some fixups.

1. I mostly made the REUSE.toml state what the comments in the source files currently literally state, even if I think the comments are wrong. If you want I can make a seperate PR where I do some minor fixups to these comments.

2. I could also insert //SPDX-License-Identifier: ... and //SPDX-FileCopyrightText: ... comments into the source files instead of using a REUSE.toml file. Both the REUSE specification and me would actually even prefer this, since in the future people might forgot to need to update REUSE.toml when they e.g. move a file. The disadvantage is that we would have a commit that touches a lot of files. I you want to, I can make a sperate PR.

3. skipset.h included a comment that says "See MiniZip_info.txt for the license.". "MiniZip_info.txt" does not exist, but "MiniZip64_info.txt" does. The latter states that skipset.h has the same license as the rest of zlib, so I removed the "See MiniZip_info.txt for the license." comment.

[mtl1979]

Removing reference to license location from source file is usually frowned upon under DMCA. Instead path to the license file should be fixed if it has a typo or the license text is currently located in another file.

[mtl1979]

2. I could also insert //SPDX-License-Identifier: ... and //SPDX-FileCopyrightText: ... comments into the source files instead of using a REUSE.toml file. Both the REUSE specification and me would actually even prefer this, since in the future people might forgot to need to update REUSE.toml when they e.g. move a file. The disadvantage is that we would have a commit that touches a lot of files. I you want to, I can make a sperate PR.

PRs with a lot of multi-line changes usually take longer to review, but as long as the changes are isolated to added lines and patch doesn't modify existing lines, it will not grow too long to review. There can be (one) CI run that verify relevant files have valid SPDX identifiers. Tools that require modifying existing lines in a lot of files might need more discussion if the change is warranted.

[Volker-Weissmann]

2. I could also insert //SPDX-License-Identifier: ... and //SPDX-FileCopyrightText: ... comments into the source files instead of using a REUSE.toml file. Both the REUSE specification and me would actually even prefer this, since in the future people might forgot to need to update REUSE.toml when they e.g. move a file. The disadvantage is that we would have a commit that touches a lot of files. I you want to, I can make a sperate PR.

PRs with a lot of multi-line changes usually take longer to review, but as long as the changes are isolated to added lines and patch doesn't modify existing lines, it will not grow too long to review. There can be (one) CI run that verify relevant files have valid SPDX identifiers. Tools that require modifying existing lines in a lot of files might need more discussion if the change is warranted.

Then I will prepare the PR. (ETA: 2026-11-01)