Spec: Mandate that licenses be in the LICENSES/ directory

[carmenbianca]

Just linking threads here because copying all replies would be really, really tedious.

#23 (comment)

#23 (comment)

#23 (comment)

Also #24

Basic gist is: If all licenses are in LICENSES/[idstring].[ext], the need for Valid-License-Identifier disappears.

Also it would be pretty uniform.

Downside is that it would break heavily with convention.

@mxmehl @silverhook @carmenbianca

[carmenbianca]

In favour, please thumbsup this reply.

Not in favour, please reply below, because we haven't really figured out a solid counter-argument yet.

[carmenbianca]

Text from #24 by @silverhook

As an additional positive side-effect, if we agree to this, we could further simplify the requirement of how to properly store License Files (see #23 (comment)), and simply mandate for all license (and exception) texts to be stored as LICENSES/[spdx-short-id].[extension], where “[extension]” must be that of a plain text format (e.g. .txt, .md, .markdown, .asciidoc, .html). Perhaps with a preference for simple .txt.

I am opening this as a separate issue to collect feedback, if anyone sees any (excusable) use cases of 1) when one could not store all license (and exception) texts in plain text, and 2) with a specific file name (its SPDX Short Identifier) in a specific folder (LICENSES/).

[mxmehl]

No expert here, but wasn't another reason for this e.g. BSD licenses which require to add the author inside the license text, so that multiple BSD licenses can exist in one project? How would we deal with that?

Otherwise, I'd be happy to make it as easy as possible.

[carmenbianca]

@mxmehl This was a recommendation under the previous (or current) spec, and I really want to undo that recommendation because it is impossibly tedious. See also #16.

This PR wouldn't affect that issue, though. You would simply name those licenses LICENSES/LicenseRef-BSD-Alice and LICENSES/LicenseRef-BSD-Bob.

[silverhook]

Regarding breaking convention, I have two thoughts.

1. The convention of storing (and looking for) the license in one single file was often the cause for compliance issues down the line, as it turned out that the LICENSE says one thing, while there are different licenses (or their names in headers) scattered throughought the code itself. So the data there is often incomplete or even wrong.
2. The “convention” itself is not really coherent itself, as different people use different files for different info (e.g. LICENSE, LICENCE, COPYRIGHT, COPYING, README, NOTICE, GPL.txt, …)

We could still allow (or recommend) for an additional single LICENSE (and/or other) file(s) to explain the license situation of the package/project, while all the License Files MUST be in LICENSES/ folder.

[carmenbianca]

We could still allow (or recommend) for an additional single LICENSE (and/or other) file(s) to explain the license situation of the package/project, while all the License Files MUST be in LICENSES/ folder.

I agree with this, but I'm not sure if that recommendation should go into the spec or not. I haven't yet written the relevant section in the FAQ, but I intend(ed) to write something along the lines of "you should describe the licensing situation in the README".

[silverhook]

I’m OK with having that in FAQ as well.

BTW, any feedback from GitHub (and/or other code forges) regarding if/how they could implement REUSE into their license detector? That seems to me that currently the biggest reason projects use a singular LICENSE file is because GitHub (and GitLab, etc.) scan that file for valid licenses to tag the repos with them.

[mxmehl]

BTW, any feedback from GitHub (and/or other code forges) regarding if/how they could implement REUSE into their license detector? That seems to me that currently the biggest reason projects use a singular LICENSE file is because GitHub (and GitLab, etc.) scan that file for valid licenses to tag the repos with them.

Not yet. It's kinda complicated since we are still working heavily on the spec, and I don't wanted to confront them with a proposal that will eventually be different from the idea 2 weeks later ;)

But yes, we can open some communication about the idea of supporting the LICENSES/ directory and therefore multi-license projects. It's a matter of fact that these exist, and I don't expect that our spec will change drastically in this regard. If I am wrong, please correct me :)

[carmenbianca]

Here's what won't change:

• There's a LICENSES/ directory.

• There can be files in there that are called [idstring].[ext], where [idstring] is an SPDX License Identifier.

The Valid-License-Identifier thing may change.

[carmenbianca]

Adopted this in ae37aa4 because nobody could think of a reason why not to do this.