Make requirements apply to the same set of files

[Jayman2000]

Before this change, the License File requirement applied to all files in a Project, but the Copyright and Licensing Information requirement applied to only some of the files in a Project. This change makes it so that:

• If a file needs a License File, then it also needs Copyright and Licensing information.
• If a file needs Copyright and Licensing Information, then it also needs a License File.

Fixes #84.

Compared to #86, this PR has simpler language but has looser rules on excluded files.

[silverhook]

I think this makes sense. It seems to avoid the (unlikely, but possible) interpretation that for certain files you need to include the license texts, but not headers.

@carmenbianca , @mxmehl thoughts? It seems like it’s just re-shuffling of some parts mainly to the definitions, but let’s make double sure that nothing unexpectedly breaks.

[mxmehl]

Let me also refer to fsfe/reuse-tool#410 where this problem originated.

This change here seems fine for me. It solves my concern that people think they have to add the license of their license text files (e.g. CC-BY-SA for CC0 as stated in the issue).

However, it does not explicitely cover the case that someone WANTS to add a license text file for one of their license text file. The spec says that only license text files for licenses used in the repo MUST be added, but it does not forbid to add one for the files on the exception list.

I am unsure whether we need this level of detail though.

[silverhook]

I also don’t think that REUSE spec should decide one way or another regarding having a license text for a license text.

If the tool should provide for that possibility, I’m not sure. I’d say it’s a niche enough use case that the reuse lint tool should safely ignore it. And there are good reasons not to support it.

If we’re going into the whole license text of license text issue, things can spiral out of control quite soon and suddenly we’re going to have REUSE (and SPDX) data for projects that will become much less manageable and useful due to including – frankly pretty useless – licenses of licenses (of licenses …), that are unrelated to the code base or artwork that the projects consists of itself.

[Jayman2000]

I think that I’ve found a flaw with this PR. With this PR, the rules are a little bit loose with non-Covered Files. You could have a non-Covered File that has Copyright and Licensing Information but doesn’t have a License File. You could also have a non-Covered File that has a License File but doesn’t have Copyright and Licensing Information.

I’ve opened #86 as a hopefully better option.

[silverhook]

See my comment to #86. Personally I prefer #85 as the basis of the change.

[mxmehl]

I agree to Matija, and would also prefer this PR. Shall I merge, or does any of you still see a bug with this PR?

I don't think we have to mandate everything and fix theoretical problems that don't have an immediate effect on the understandability, adoptability, simplicity and actual goal of REUSE. So unless there are serious concerns with this PR, I'd merge it.

[silverhook]

@mxmehl It looks OK to me, but if you haven’t yet, I’d still ask you to read through the whole text as well if there’s anything it brakes that I didn’t see.

[mxmehl]

I also went over it again and I don't see any loopholes :)

[mxmehl]

Thanks @Jayman2000 for these fixes!