[REUSE] Support / repurpose central LICENSE file

Max Mehl max.mehl at fsfe.org
Thu Mar 5 11:34:15 UTC 2020


There has been the wish to officially support "traditional" LICENSE
files in the root of a repository, so a license text of the license
being used in the project. This is supposed to lower the threshold for
REUSE adopters and license compliance projects.

REUSE currently requires to have a license texts stored inside the
LICENSES/ directory named after their SPDX License Identifiers. We see
two main reasons for this:

* If there is more than one license being used in a project, it
  automatically would require two LICENSE files. That is why REUSE chose
  the LICENSES/ directory.
* Identifying the license of the LICENSE file requires heuristic license
  scanners. With the REUSE solution, it is possible to identify the
  covered license by its file name, so e.g.
  "LICENSES/AGPL-3.0-or-later.txt". There is still no warranty that no
  one wrongly names the license text file, but we primarily assume good
  faith.

Using a LICENSE file is not denied by the REUSE specification, however
it would require that a copy of the file is stored under the LICENSES/
directory under its respective name.

We recognise that this new paradigm might increase the threshold of
adopters and for instance clash with GitHub's repository creation wizard
that can automatically create the traditional license file. That is why
I would like to propose *two options* for a compromise.


## Option 1: LICENSE file valid for one-license repositories

The LICENSE file alone (so not LICENSES/ directory) is a valid option in
case the repository only contains files with one SPDX license
identifier. REUSE would then assume that the found identifier matches
the actual license in LICENSE.

Pros:
  - Projects using only one license would not have to think about moving
    the license text file or create a potential duplicate license text.
    Adoption would be easier therefore.
  - License scanners could rely on the existence of the LICENSE file in
    case of one-license repos.

Cons:
  - If projects introduce a second license (e.g. because of adding an
    external component, or dual-licensing), REUSE have to mandate
    introducing the LICENSES/ directory because only that offers the
    transparency it seeks. So REUSE would carry another threshold down
    the road if projects evolve license-wise. Currently, as soon as a
    project is REUSE compliant, keeping the status is rather trivial.
  - If a second license is introduced, how to deal with the "old"
    LICENSE file then?
  - License scanners supporting REUSE would have to be prepared for two
    scenarios: LICENSE file existent, only the LICENSES/ directory, and
    both being existent.
  - In case of a change of license, the user would perhaps only update
    the license identifiers but not the LICENSE file. With the current
    REUSE way, the linter would complain about a missing license text,
    and a superflous one.
  - Additionally, it is harder for REUSE to assume good faith that the
    LICENSE file's license matched the found SPDX license identifier.


## Option 2: Repurpose LICENSE file to explain general licensing situation

In combination with debates how to declare the preferred inbound and
outbound license (a.k.a. "default license" or "main license"), there is
the suggestion to repurpose the LICENSE file to explain the general
licensing information of the repository. It would be an optional file
though to not introduce breaking changes for already REUSE compliant
repos.

So a REUSE-compliant LICENSE file could contain the following text:

```
This repository follows the REUSE best practices for clear copyright and
licensing information.

The license texts for all used licenses can be found in the LICENSES/
directory under the root of this repository.

Preferred inbound license: Apache-2.0

Preferred outbound license: Apache-2.0
```

Pros:
  - The LICENSE file would still be the main point for people to learn
    about the licensing of a project. It would also be obvious where to
    look for the actual license texts.
  - Even in a project containg multiple licenses, it would be possible
    to define the preferred inbound and outbound licenses in a more or
    less standardised way (so not in the README or so).
  - If there was a wish for a more standardised layout of the file, one
    could think of SPDX tags to declare the preferred inbound/outbound
    license.
  - The whole handling of licenses would not change in the REUSE way.
    Adding or removing licenses would work as before, and it would not
    matter how many licenses the project uses. All the spec and tool may
    have to check is whether the inbound/outbound license does exist as
    license text in LICENSES/.

Cons:
  - There would be another purpose for the LICENSE file apart from the
    usual one. However, since there is no common way how to deal with
    multiple license texts, people already merge multiple license texts
    into this file or add custom text and introductions anyway.
  - This should be supported by source forges and other license
    compliance tools.
  - It's "yet another standard" for how to declare this additional
    information.

Alternative:
  - Do not use the LICENSE file for that but the README file. However,
    since most people care about keeping the LICENSE file, and since
    README is a more fluctuating file, this does not come with many
    benefits against the current state.


## Summary

As you can see, I consider the pro/con to balance in favour of the
repurposed LICENSE file, although it may lead to some more coordination
effort with source forges and other license compliance projects. But
hey, that's why we are here, right? And there are also people who would
rather be in favour of not changing REUSE's handling of LICENSE files at
all.

Please share your opinion on these two options (and the third: do not
change) in reply to this mail. Thank you!

Best,
Max

-- 
Max Mehl - Programme Manager - Free Software Foundation Europe
Contact and information: https://fsfe.org/about/mehl | @mxmehl
Become a supporter of software freedom:  https://fsfe.org/join


More information about the REUSE mailing list