[REUSE] Addressing some papercuts in the specification

[Drew DeVault]

On Wed Dec 22, 2021 at 10:08 AM CET, Max Mehl wrote:
> We would have been able to define a new standard, but always remember
> XKCD #927 [^1] ;)

You already have defined a new standard, in case you hadn't noticed ;)

> 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 introduction of these changes opens the floor for other changes,
too. You should take a more pragmatic approach. This is an opportunity
to improve upon the status quo.

Also, as mentioned before, the REUSE tool allows you to configure these:

https://reuse.readthedocs.io/en/stable/usage.html#addheader

In general, I find that configuration options are harmful as often as
they are helpful. It is essential for the tool to choose strong defaults
so that it does the right thing and provides leadership for the
community on what the best approach is. Often when strong enough
defaults are established, it no longer makes sense to make them
customizable. That we have so many choices suggests that the defaults
are not, in fact, strong enough.

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

Aside: I would be pleased to add first-class REUSE support to SourceHut
if I felt that some of my concerns (some mentioned in this thread, some
not) were addressed.

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

Right, but one thing which is probably consistent among all of your
contributors is a passion for dealing with licenses properly. Most small
projects have a passion for getting their work done and they want little
to nothing to do with licensing.

Ironically, I *do* care quite a lot about licensing, but I am also
fiercely pragmatic about it, which puts me somewhere in the middle.

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

Right, but the question is whether or not the absence of the tool is a
use-case you want to consider, and if REUSE should strive to be
accommodating of users in this bucket.

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

Oh, sure, I'm not suggesting the tool is not useful. I'm suggesting that
a design which requires a tool to be comfortable to use may not be a
good design. Even if the design were improved I'm certain that the tool
would remain very useful. But if you make it easier to meet the spec
without the tool, then the spec will be adopted by more projects.

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

It's already confusing. I don't want to read a bunch of machine headers
in comments at the top of all of my files. It's ugly. License-Id: makes
it read more like natural language while still being useful to machines.
Code is written to be read, and should be as accommodating of human
readers as it is of machine readers. It's important for code to be
beautiful.

It's also not a breaking change, to be clear. You can support both
styles.

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

To be clear, the license headers are a hurdle I'm willing to overcome.
But they are a hurdle, and you should decide which hurdles are important
and which are not, and eliminate the ones that aren't. This one is
important. Others, less so. Every hurdle you add is another developer
who won't be willing jump it. Every hurdle you remove is another
developer who will.

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

REUSE provides a lot of solutions to problems, but it does not eliminate
a lot of problems.

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

Extensive documentation and tooling does NOT make it simpler. It makes
it more work! Now you don't just have to solve the problem, but you also
have to read a bunch of "extensive" docs and learn and evaluate new
tools. If you want it to be simpler, *make it simpler*.

You're leaning too heavily on the mantra of "good licensing discipline"
is important. To most people, it isn't, and honestly, they're right.
FOSS projects below a certain scale have almost always gotten away with
subpar licensing practices, because for the most part, it doesn't really
matter for them. The value-add is not worth the overhead for a lot of
projects. The only way to get them on board is to lower the overhead.

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

I will admit that I'm making somewhat vague, philosophical arguments. I
can make specific suggestions, too, but I expect them to be shot down
much like the license identifier suggestion if we cannot achieve
philosophical alignment first.

Last note: I know this is an annoying thread, but I am appreciative of
your patience with me. You've been very responsive and helpful so far,
even if we haven't found common ground yet.