Should we allow a LICENSES/ directory as a way to implement criterion license_locatiion?

David A. Wheeler

The criterion “license_location” says:
> The project MUST post the license(s) of its results in a standard location in their source repository. {Met URL} [license_location]

Issue #1544 proposes to also allow files in a directory named “LICENSES/“ to be considered a “standard location”.

I’m not fundamentally opposed to the idea; there are certainly projects with multiple licenses, so having a directory for those files (and explaining their relationships) doesn’t seem insane. The proposed name makes sense & is already in use in at least one project - maybe many.

What do others think?

By way of background, the FSFE “reuse-tool” uses this directory LICENSES. It’s discussed here:

The “details” for the criterion license_location <> currently ysays:

> Details:
> E.g., as a top-level file named LICENSE or COPYING. License filenames MAY be followed by an extension such as ".txt" or ".md". Note that this criterion is only a requirement on the source repository. You do NOT need to include the license file when generating something from the source code (such as an executable, package, or container). For example, when generating an R package for the Comprehensive R Archive Network (CRAN), follow standard CRAN practice: if the license is a standard license, use the standard short license specification (to avoid installing yet another copy of the text) and list the LICENSE file in an exclusion file such as .Rbuildignore. Similarly, when creating a Debian package, you may put a link in the copyright file to the license text in /usr/share/common-licenses, and exclude the license file from the created package (e.g., by deleting the file after calling dh_auto_install). We do encourage including machine-readable license information in generated formats where practical.

Comments welcome, here or in the issue tracker:

--- David A. Wheeler