On 2026-02-09, Ludovic Courtès wrote: > Gabriel Wicki <[email protected]> skribis: >> We should consider cleaning up our codebase somewhat—at least to the >> extent where it becomes clear (or can be clarified) for new contributors >> where which part of code belongs. Our package modules seem (in some >> places) especially unordered. Ordering them is not such a big issue, >> but cleaning up the modules and retaining correct copyright lines is, >> indeed. Since I couldn't find it documented and could not find a >> satisfying answer through web searches I ask here: are these by-author >> copyright lines really needed? For what jurisdiction and what are the >> rules to include them? Should we delete them, when for example all >> changes by a contributor C are overwritten over time by other >> contributions and none of the original committer C are still in place? >> >> Are really the mentioned people the legal copyright holders? And is >> writing these lines really the only and best way to ensure their rights? > > The people mentioned are supposed to be copyright holders, yes, though > that’s not something we verify (and it would be hard to do); we rely on > authors.
I am glad to see the subject under discussion. :) > The goal was to keep a good record of copyright holders, like most free > software projects would traditionally do (a notable exception being > Linux, which probably made the SCO attack easier). > > However, I’ve come to think that this has questionable utility, > particularity for gnu/packages/*.scm, most of which is essentially a > database comprised of things barely “legally significant” (in the sense > that there’s little or no creativity, which is what determines whether > something is copyrightable). It most certainly is not copyrightable to bump the version and a hash, but many people do add Copyright to their patches for such things. I have taken pause when reviewing a few requests that meet that and similar totally-not-copyrightable updates. I have always gone along with it in the end as that seems to be the norm, but ... I will admit to rarely adding Copyright lines for my own contributions in guix lately; perhaps too much, but I feel most of my contributions are not creative works (e.g. copyrightable) but more mechanistic changes (e.g. non-copyrightable). It gets a bit blurrier when you take into consideration comments, and of course custom phases and such... a definition of what is creative is a non-trivial problem! Most guidelines I have seen leave me with more doubts than confidence. :) > In Guix-Science, we recently removed those long copyright headers with a > single SPDX license line: > > https://codeberg.org/guix-science/guix-science/issues/196 > > I would personally be in favor of doing something similar at least for > gnu/packages/*.scm. On a wholly different perspective, having reviewed a fair number of packages with Debian's much-more-meticulous-and-tedious-to-the-point-of-comedy-at-times copyright and licensing documentation... The sheer number of files I have seen in the wild that have the copyright holders removed from the individual files, with a reference to a missing AUTHORS file (or even LICENSE file, gasp!) presumably where someone copied a file or a significant portion of the file into another project, and poof ... no legit licensing and copyright information ... I shed a few tears here and there ... so it gives me pause to consider removing too much! Though package definitions are probably not going to make much sense outside of guix, so at least being a bit more flexible there makes some sense... Other parts of guix certainly might have other utility outside of guix... Documenting the copyright years is arguably not needed in (many? most?) jurisdictions... with my reproducible builds hat on, the fewer timestamps the better. Thankfully the Guix community has been wise enough to not auto-generate a copyright year at build time ... this is practically a definition of non copyrightable works! So, mixed feelings all around. :) live well, vagrant
signature.asc
Description: PGP signature
