https://matija.suklje.name/how-and-why-to-properly-write-copyright-statements-in-your-code TLDR: I think REUSE.software is a bad idea that is worse than what Debian already invented with Machine-readable debian/copyright file. I guess if upstream uses it, there's no reason not to ignore that as a source of copyright assertions. On Wed, Jan 26, 2022 at 12:49:34PM +0100, Stephan Lachnit wrote: > It is straightforward to > implement, add (e.g.) "SPDX-FileCopyrightText: 2019 Jane Doe > <jane@example.com>" and "SPDX-License-Identifier: GPL-3.0-or-later" as > comments to your source file's header and you are done. I *am* a big fan of SPDX-License-Identifier, but the above being straightforward is only true for the most trivial of examples. REUSE advocate for sprinkling .license files around your repo for e.g. logos and other binaries. Same story with multiple authors, they recommend using multiple FileCopyrightText's initially, then split it out to a separate AUTHORS file and use something like "Project X contributors". https://reuse.software/tutorial/#binary-and-uncommentable-files Ultimately, when everything becomes too much, REUSE falls back to recommending Debian's copyright format anyway! So even if upstream sees the value in taking some copyright busywork off our hands, why not suggest they just use it in the first place in e.g. the LICENSE file. https://reuse.software/faq/#bulk-license > My idea is to allow SPDX documents in addition to DEP-5. Firstly, I didn't think it was called DEP-5 anymore - it was accepted into policy in 2012 as "copyright-format" titled "Machine-readable debian/copyright file", so no longer a proposal for enhancement. This would be a minor pedantic point (a colloquialism) except for the fact that REUSE encourages it as part of their interface: `.reuse/dep5`. > Note that I don't want DEP-5 to go away - it is unlikely that every > project will follow the REUSE spec and writing an SPDX document by > hand has no significant advantages over DEP-5. Besides, using the > file-exclusion function in DEP-5 for uscan is quite useful for ds/dfsg > packages (although that could also be moved to an external file). I think this undermines your previous point about it being less prone to failure - if we could trust upstream assertions on copyright, the NEW review wouldn't be a problem in the first place. The point about uscan is interesting, since if upstream does take on the hard work of license verification such that packaging is just checking, then they're unlikely to have any Files-Excluded, so that would have to merged somehow.
Attachment:
signature.asc
Description: PGP signature