On 7/23/19 6:49 PM, Adam Borowski wrote: > In the light of the currently discussed GR proposal, I wonder if the > following license clause would be considered DFSG-free and GPL-compatible: > > ################## > I do not consider a flat tarball to be a preferred form for modification. > Thus, like any non-source form, it must be accompanied by a way to obtain > the actual form for modification. There are many such ways -- unless you > distribute the software in highly unusual circumstances, a link to a > network server suffices; see the text of the GPL for further details. > ################## > > I believe such a statement would be GPL-compatible; rationale: > * by the 2011 Red Hat kernel sources outcry, it is obvious such a tarball > is long obsolete > * a flat tarball deprives the recipient of features of modern VCSes > * comments giving rationale for a change tend to be written as VCS commit > messages > * future forms are not banned: it is conceivable that next week someone > invents a revolutionary new form that wins over git > > Thoughts?
Flat tarballs are not the preferred form for the modification of anything; they are a popular method for storing directory hierarchies, which can then be distributed in many ways. Modern VCSes provide other methods for distributing directory hierarchies, some of which are becoming quite popular in their own right (i.e. "git clone"). So, to my reading, upstream is merely adding restrictions to the way some project's source code may be distributed, which looks to me like an additional restriction that makes it GPL-incompatible. Imagine forking something like gcc, and then requiring that anyone distributing your fork must distribute the result using git. Can you imagine the FSF being on board with that? (Actually, to make it more clear, imagine forking gcc, and then requiring distribution via CVS. I think a few more people would object than just the FSF, and on more than just principled grounds. But it also illustrates why this kind of restriction is against the spirit of free software.) If the intent is to not strip out the usual VCS metadata, then why not just say that? "We consider VCS metadata to be essential to proper modification of our project, and thus stripping out such metadata is tantamount to making the result a non-preferred form for modification of the work." Does it really matter that your .git directory was created directly with the git tool, as opposed to being unpacked via tar? The git tool itself doesn't seem to care. Personally, I wouldn't take this latter approach, because I don't trust that VCS tools treat their metadata with enough care to make a VCS checkout operation reproducible. And that doesn't even consider how VCS metadata tends to explode in size over time. But, to each their own.