[REUSE] Addressing some papercuts in the specification

[Max Mehl]

~ Drew DeVault [2021-12-21 16:59 +0100]:
> On Tue Dec 21, 2021 at 4:43 PM CET, Max Mehl wrote:
>> The "SPDX-License-Identifier" is a well-known tag, understood by most if
>> not all compliance tools, and was therefore also a no-brainer for REUSE
>> to adopt. The copyright lines are completely fine, and the
>> SPDX-FileCopyrightText is just an alias. However, we chose to make it
>> the default because it avoid false-positives/negatives. In the tool,
>> that's easy to change [^1].
> 
> "Someone already does it this way, so let's do that" is certainly a good
> way shortcut the bikeshedding phase. However, if it's not a *good* way
> to do something, then it should be changed. For one, just look at the
> inconsistency in the two headers you mentioned as an example:
> License-Identifier is skewer-case and FileCopyrightText is PascalCase.
> The design is noticeably worse even in this small example. I think that
> better headers ought to be chosen and supported, with the existing set
> only used for backwards compatibility.

We would have been able to define a new standard, but always remember
XKCD #927 [^1] ;)

Jokes aside, some historical background: SPDX-License-Identifier is the
first original tag AFAIK. Then, the project decided to change to
CamelCase. I think they dislike this inconsistency as well, but
recognised that changing the former would not make sense.

For REUSE, it's pragmatic to use a widely adopted standard that is used
among communities and industry. Do we like the inconsistency? No. Would
forking the standard because of that make sense? No, too.

The LICENSES folder and .license file on the other hand are pure REUSE
inventions. Existing practices did not make sense or were to complicated
for developers from our PoV, so we had to fill in the gap. That's
pragmatic.

> The perspective of the REUSE developers is likely biased towards the
> needs of large projects or large businesses, many with hundreds of
> developers, and an existing culture of using tooling and automation to
> maintain their software. The values of this culture are not shared with
> small- to medium-sized projects.

Absolutely not. I dare to say that we provide the best practices that a)
fit 99% of the edge cases and b) are still reasonably easy to understand
and implement for developers. We've also received positive feedback from
smaller projects in the scope of the NGI project [^2]. The critique we
received was rarely on inconsistencies but on other factors (like that
GitHub and GitLab to this day do not "understand" REUSE's LICENSES
folder, but that's another story).

That we always have a developer without any legal background or a lot of
time in mind when working on the spec and tool should become obvious
when having a look at the tutorial and FAQ [^3].

> For instance, REUSE wants me to install a CLI tool. The answer is "no".
> I intend to maintain these files by hand, so they need to be pleasant to
> read or write by hand. The introduction of a new tool into my workflow
> or dependency graph requires a large value-add and is subject to a lot
> of scrutiny, and the reuse tool does not pass. An annoying specification
> which is made easier to use thanks to a robot is still an annoying
> specification.

Hey, one neither forces you to adopt REUSE nor to install the tool.
It's a suggestion, a best practice you can choose to either use or
disregard.

In the early days there was no tool, and we received the feedback that
adding a linter and further commands to add headers (and more) would
increase adoption. I'd say that was a good decision as keeping an
overview manually over *all* files in a large repo and their different
ways to label them via REUSE is almost impossible.

If you want to make this manually, go ahead. If you would like to
confirm whether you made it right but not use the tool, feel free to use
the API.

> Perhaps it comes down to taste. If so, know that many developers are
> already bending over backwards to fight their distaste at the behaviors
> encouraged by this specification. A whole lot of developers hate the
> idea of filling their source files with huge license headers, taking on
> the bigger maintenance burden to keep copyright lines up to date,
> getting annoying emails from distributions who want them to change their
> software to suit a slightly different convention*, and so on. If the
> headers are more pleasant to use, then that's one less thing causing
> friction for maintainers.

I am still not completely certain what you would want REUSE to change.
Instead of "SPDX-License-Identifier" you would like to do "License-Id".
We'll stick with the former because it's the de facto standard, and I
cannot recognise any "bending over backwards" because of using this
string and not the other. If we'd introduce aliases and breaking
changes, that would confuse our core audience: developers.

Ad "huge license headers": two lines really are not "huge", compared
with the license notices other best practices demand (often two
paragraphs or more).

Ad "maintaining copyright lines", please see this FAQ item [^4].

Again, I know that making a project REUSE compliant is extra work which
we intend to make as simple as possible with extensive documentation and
tooling. Our experience is that once this is achieved, it's relatively
easy to maintain. But no one forces a project to do this, but they
should know that the alternative is licensing and copyright uncertainty,
perhaps incompatibilities or unknown proprietary components.

> You might think that I'm just being difficult, and maybe I am. But I am
> squarely in the target demographic of REUSE, and if you want me to
> overcome all of these papercuts to adopt it for my projects, then I
> expect an equal measure of good-will from REUSE to make these papercuts
> as few in number as possible. Does that make sense?

To make it short: please sum up your concrete suggestions for REUSE spec
changes? Here's what I got: changing the license identifier tag is not
feasible as explained above. Using "traditional" copyright lines is
already today supported. Using the tool is not mandatory as per the
spec, just a strong recommendation.


Best,
Max


[^1]: https://xkcd.com/927/

[^2]: https://fsfe.org/news/2021/news-20210504-01.html

[^3]: https://reuse.software/tutorial/ & https://reuse.software/faq/

[^4]: https://reuse.software/faq/#many-copyright-statements

-- 
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