On 2024-04-06 16:30:44 +0100 (+0100), Simon McVittie wrote: [...] > Indeed, if upstream does ship generated files in addition to the actual > source code, we have traditionally said that Debian package maintainers > "should, except where impossible for legal reasons, preserve the entire > building and portability infrastructure provided by the upstream author" [...] > Another question about the source code is whether it is sufficient to take > a snapshot of the current state of the git tree (again, tree as jargon term) > and say that it is the preferred form for modification, or whether complete > corresponding source code should be understood to mean its complete git > history going back to the beginning of the project (in git jargon, a series > of commits going back to one without a parent, rather than a tree). > > I think that Guillem, and maybe Adrian too, whether rightly or wrongly, > understood you to be claiming that a single snapshot (git tree or `git > archive` output) is not enough, and the history is also required - and > it's that assertion, which you might not have intended to be making, > that they are pushing back most strongly against? (Or perhaps I'm > misunderstanding.) > > If that's what is happening, then I agree with them. > > Demanding that we ship the full history is clearly not what was meant by > the authors of the GPL. That surely can't be what the GPL was intended > to mean, because at the time it was written, public VCSs were rare, and > the GNU system was developed via a "cathedral" approach with a small > number of authors writing software privately and releasing it to the > world as a series of tarballs. It seems obvious to me that they wouldn't > have written the license to require more a comprehensive version of > "what is source?" than what they themselves were releasing. > > Demanding the fully history is also not really practical for a Free > Software distribution, because a non-trivial project's history is > inconveniently large, and over a long enough timescale it's relatively > likely that someone has committed (and perhaps subsequently deleted) > something that does not qualify as Free Software - either accidentally, or > because they were assuming that it's OK to include non-Free documentation, > artwork, test data or whatever, as long as it isn't executable code > (which, rightly or wrongly, is not the position taken by Debian). [...] A related place where this becomes fuzzy is when projects extract metadata from revision control or otherwise assemble real files based on relationships between commits. Projects I work on set version information from Git tags, by parsing footers from commit messages, and counting commits in what is basically their `make dist` process. They may also build ChangeLog files from commit messages, assemble AUTHORS files referred to in their copyright license from commit data, build release notes by associating the introduction of independent stub files with specific commits appearing in different branches and tags, and so on. Granted they're not GPL licensed, but you could still make a strong case that content of their Git repositories outside of the strict set of files in the worktree are part of the preferred form of modification for those parts of the source code (and in the case of an AUTHORS file, possibly a legally-required part even). For those projects, we upstream maintainers understand that downstream distributions want to include source code and can't necessarily include full copies of our Git repositories, so we create and cryptographically sign source code tarballs with all that extracted/assembled metadata in the form of "generated" files, and present those as our primary source distributions. -- Jeremy Stanley
Attachment:
signature.asc
Description: PGP signature