Ansgar 🙀 <[email protected]> writes: > Hi, > >> I think we should be clear that this wasn't a decision that the >> tag2upload Delegates took. It was taken by the FTP team, when >> dgit-repos was first started. We explicitly got them to okay storing >> potentially non-free stuff in git histories there. > > There is a difference between some parts of Debian distributing non- > free artifacts and making non-free artifacts parts of what Debian > considers source.
+1 > The Dgit folks want to make the complete Git repository, including the > non-free artifacts, the "source", thus disregarding the social contract > in its current form. And it is not possible to clean this up even with > rewriting commit history as that would require resetting branch > history[1]. > > They go so far as to claim that including, for example, the Dgit > software within the Debian archive as-is would actually be a license > violation as it does not include the Git history (but if development > history data is such an inherent part of the "preferred form of > modification", then I wonder whether issue tracker data and mailing > list data should also be considered part of the complete "preferred > form of modification"). I think that is a fairly opinionated and non-mainstream interpretation of what the preferred form of modication means. It isn't unreasonable, but it leads to some interesting consequences (see below). > The "outdated" source model allows excluding artifacts as it doesn't > require shipping (incomplete) historic baggage associated with the > development which might contain non-free artifacts. Indeed. That's actually a quite powerful and nice property of our tarball-centric approach. However, I think there is some potential to find a middle ground here. Debian already distribute non-free artifacts in main from snapshot.debian.org, for DFSG violations we weren't aware of but has since fixed (or where things are "work in progress" and we look at it with a blind eye). Distributing non-DFSG content in the historic part of a git repository for a package in main could equally be seen as the same practice. I think there is no clear right obvious simple interpretation here, and this is a space that is evolving and has legal/social aspects. Compare what the Linux-libre folks consider: they rewrite Linux kernel git history so that non-free blobs were never introduced into the git history. That is the only reasonable approach if you consider the entire git history the "preferred form of making modifications" and care about license hygiene. I think we will see more of the git history rewrite approach: if indeed the entire git repository is considered a "preferred form of modification", there is no longer anything immutable about it. Just rewrite it when you want to make a change for something in the past which were a mistake. Either something is up for modification, or it isn't. You can't reasonably claim that an entire git repository is the preferred form of making modifications to and say that modifications of it is not permitted. That would be contrary to GPL intentions. If only the latest git HEAD is the "preferred form of modication", then only that counts for license review (and thus MUST be DFSG acceptable), and older content can be considered similar to snapshot.debian.org preserving factual history. The transition to Git SHA256 may make git history rewrites more socially common than it is now. I don't think there is anything inherently problematic with git history rewrites as long as there is some PGP/SSH/etc signature on resulting work. People's notion that Git history is immutable is as false as trusting SHA1 for integrity protection, and the notions are somewhat linked. Git history rewrites may also improve security by re-signing old commits using current-maintainer's private keys. /Simon
signature.asc
Description: PGP signature
