fsfe / reuse-docs

REUSE recommendations, tutorials, FAQ and specification
https://reuse.software
19 stars 20 forks source link

Better clarify the three options of how to store a license text #7

Closed silverhook closed 5 years ago

silverhook commented 6 years ago

Reading the REUSE spec 2.0 carefully shows that when there are more than one licenses in a repository/package, there are three options on how to store license text in a file (in §1):

  1. Copy the license text from a LICENSE file or from SPDX license list) and (re)name it accordingly to its SPDX license shorthand (or LicenseRef-*, if there is none or the text is modified).
  2. If you cannot or want not to rename the license file (e.g. because you want to keep it as LICENSE or COPYING), add the Valid-License-Identifier tag followed by the License-Text tag.
  3. If you cannot or want not to even edit the (existing) license file, create a new file with a .license extension (e.g. COPYING.license or perhaps even Cool Custom License.pdf.license) and insert the Valid-License-Identifier and License-Text tags there.

Solution 3 has a problem already that it clashes with how §2 says you can add copyright and license info to files (e.g. icon.png) you cannot insert comment headers into by creating a separate file with .license extension appended to the filename (e.g. icon.png.license). If nothing else, this double-use of *.license files could confuse license scanning tools.

Solution 3 is also missing from the “Keep in mind” summary at the end of the §1.

Unless there are good reasons for Solution 3 to stay, I would suggest removing it. If there are reasons for it to stay, we should work on refining it and explaining more prominently that it introduces an exception to the general use of *.license.

In any case, I think adding more structure to this part of §1 would benefit clarity that there are three options that may be used.

silverhook commented 5 years ago

@carmenbianca, @mxmehl, I think this issue does not exist any more in the 3.0 Spec. Can any of you two clarify?

carmenbianca commented 5 years ago

If we adopt #27 it is certainly solved. Otherwise I think that the spec in #23 is really unambiguous.

mxmehl commented 5 years ago

Yeah, I also think that we solved this ambiguity, or are on the best way to do so :)