Re: anti-tarball clause and GPL
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.
Reply to: