[REUSE] Addressing some papercuts in the specification

[Drew DeVault]

On Tue Dec 21, 2021 at 4:43 PM CET, Max Mehl wrote:
> Well, you can do that, and it would fit the purpose of being
> human-readable, but for machines it's only partly, and it would simply
> not be fully compatible with REUSE.
>
> 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.

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.

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.

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.

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?

* Fun fact, this is why I'm here in the first place.