(debian-devel following Holger's advice, guessing all authors are subscribed) On Thu, Jul 25, 2019 at 10:43:12PM -0300, Yao Wei (魏銘廷) wrote: > What if, one of the upstream authors consider it violating GPL _without_ the clause? I mean, it could happen. Indeed, and I'd argue this is already the case (implicitly). Consider a security bug reported in Buster, missing from Stretch, that when a fix is found needs to be backported to all upstream supported releases (say, for example, going all the way back to one released just after Stretch). Other than skimming release notes for the affecting change, what would a diligent upstream do to determine which release streams need patching? Would they do a git checkout of each tag, manually testing, but otherwise merely using git as the tarball distribution mechanism? Or would they do a git log on the fixed file to determine when the change was first introduced, then simply git tag --contains? Even better, if the fix is not even known yet, could they `git bisect run foo` to find the breaking commit, then use that knowledge to work out the fix? On Thu, 25 Jul 2019 at 17:40, Adam Borowski <kilobyte@angband.pl> wrote: > On Wed, Jul 24, 2019 at 05:18:28AM +0000, Scott Kitterman wrote: > > On July 24, 2019 12:34:13 AM UTC, Adam Borowski <kilobyte@angband.pl> wrote: > > >By this logic, a pile of .c files with comments removed or preprocessed > > >with cpp would be allowed as well. The VCS is also a means to store > > >human-readable comments. > > I infer from this you think projects without a public VCS (postfix is an example) belong in non-free? > > At this moment, not yet. Obviously, old projects didn't even _have_ a VCS, > and I'm not proposing imposing a VCS workflow on the upstream. I'd like to > consider, at some point in the future, hidden private VCSes where the upstream > occassionally releases a tarball of to be non-free, just like the same PNG Yes, yes, yes - if upstream would prefer to modify their source with the support that their private git repo provides, then publishing just the make dist tarball does not make sense. The repo doesn't have to publicly-writable or accept pull requests, perhaps even doesn't need to have the entire project history (shallow clone since last release?). On Fri, Jul 26, 2019 at 04:00:04AM +0900, Norbert Preining wrote: > On Wed, 24 Jul 2019, Yao Wei wrote: > > I believe that "flat" tarball in Adam's question means tarball stripping > > out VCS information, not tarball as a format. > > Just one hint, if this comes in I will upload texlive with about a > 70Gb tarball as source ... we have 15 years of history of "flat tarball > of 4Gb". > > I don't think that *this* is the preferred form of changes. Then why do *you* use it to make changes? This would also be a good opportunity to improve Debian's 9G+ support (also for game assets). For the record, the texlive .git is 28G and as mentioned, we could consider the replacement for .orig. to be a shallow bare clone since last upload (git-debpush wishlist?).
Attachment:
signature.asc
Description: PGP signature