Alex <[email protected]> writes: > So I think we're agreeing on many points, Russ, but talking past each > other in some aspects. REUSE-compliant projects go to great lengths > maintaining detailed, machine- and human-readable information about the > copyright of directories, files and even snippets in files in their > project.
I have mixed feelings about the usefulness of that effort but I'm never going to tell people not to spend time on something that matters to them and I'm very glad that better ways of tagging licenses is coming out of that project. That information in the sort of granular format that has been described in this bug does not, in the general case, belong in debian/copyright. That's where we're disagreeing. debian/copyright is intended to be a primarily *human-readable* summary of the licensing of the *installed package* (secondarily the source package as well, but primarily the *installed package*) for the *users of Debian*, not for machines. Putting all of this detailed information in debian/copyright in the way that's been described on this thread runs the high risk of making the file unusable for its intended purpose. It's turning it into a detailed license attribution database in a complicated, verbose, and redundant format that's annoying for humans to understand. The main purpose of the debian/copyright file is to communicate to *other humans* what the license of the source and binaries of that package is, ideally without them having to pour over a complex quasi-database and perform mental license set mathematics. Therefore, replicating this sort of detailed machine-readable information into debian/copyright at this level of granularity is, IMO, a bug in the Debian package. It may not be a very severe one depending on how much overhead and obfuscation this generates, but I'm certainly not going to recommend that anyone use debian/copyright in that fashion, nor am I going to support any changes to Debian Policy to encourage that. The copyright-format standard is an attempt at a compromise between machine readability and human readability, and I think that compromise is best suited by having an opening Files: * stanza that specifies the main license that the user cares about for the package, and then, if necessary, a list of specific exceptions, with as much coalescing of copyright statements and licenses as possible without misrepresenting the package. > They are very different from projects which ship a single LICENSE file. > **Not** taking that effort seriously, would be a lapse on Debian's part, > IMO. I have no objections to someone looking at ways to generate complex machine-readable copyright information in Debian, although I would question how much effort people put into source licensing when *binary* licensing matters as much or more to most of our users and is a more complex problem with more real-world risk than the nitpicky details of specific source files. But again, I am certainly not going to tell people not to work on things that interest them. However, I do object to overloading debian/copyright with individual listings of every file or separate stanzas for every copyright holder. This is poor packaging, IMO, because it's poor communication to the user. We have already strayed a little too far towards machine readability at the cost of human readability, in my opinion, and going farther is not good for the distribution. If you want to publish detailed machine-parsable information, I think it would be better to come up with a new file for that purpose and keep debian/copyright as succinct and to the point as possible, conveying the information that our users care about (and the information we're legally required to convey by the licenses). > Now, to tie this back to the original problem of the bug and away from > the spdx2debian tool: REUSE requires projects to put all LICENSES it > uses into a LICENSES/ directory at the root project level (see e.g. [the > reuse tool itself][1]). And just like the case Ben encountered, there is > no really accurate way to cover this directory in d/copyright properly: > - While we can explicitly say that Files: * does not apply to > LICENSES, this discussion shows that one can easily be lead think it > does. I'm not really convinced by this, since I think explaining this explicitly in Debian Policy is sufficient to handle this fairly minor issue. But I can see the argument for specifying this in debian/copyright *succinctly*. It only adds a bit more noise. I am much more alarmed by the descriptions of the debian/copyright files that some folks seem to want to generate that have turned up in this bug. > - Silencing Lintian to stop complaining about uncovered LICENSE files, > or as I pointed out, other copyright information conveying files, on a > per-project basis is also an inelegant way forward. I suspect that you are getting Lintian complaints only because you refuse to use Files: * and Lintian therefore is complaining about uncovered files. You can file a bug against Lintian to carve out an exception for LICENSES/*, and I think that's reasonable, but the real solution for the Lintian diagnostic is that you should use Files: * with a set of exceptions because it's a better way of communicating license information to *humans*. > Which is why I still think that introducing a fourth type of stanza into > d/copyright, which allows making explicit which files d/copyright is > **not** making a copyright claim about, would be a workable solution. I don't have a strong objection to this, although I don't like that it's being used to support a pattern that I think is introducing communication bugs into Debian, so I'm not super-excited about it either. I am also dubious, as previously stated, that it belongs in debian/copyright. I can see the argument, but remember that copyright-format is *optional*, and many packages in Debian still use a free-form copyright-format file but may still be interested in the Lintian configuration aspect of the problem. To me, that argues for using a separate file in debian/source, but this isn't a strongly-held opinion. -- Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
