~ 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