Re: anti-tarball clause and GPL
On Wed, Jul 24, 2019 at 10:28:19PM +0200, Florian Weimer wrote: > On the other hand, not allowing source distribution as a “flat > tarball” sounds like an additional restriction, which would be > incompatible with the GPL. (Just like parts of glibc used to require > distribution on tapes, only less inconvenient.) I believe that "flat" tarball in Adam's question means tarball stripping out VCS information, not tarball as a format. Also, the clause doesn't disallow the distribution using tarball, but only define what "source code == preferred form for making modification" is. So, "flat tarball" becomes object code license-wise. Yao Wei signature.asc Description: PGP signature
Re: anti-tarball clause and GPL
* Adam Borowski: > 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? The GPL version 2 already requires that you maintain something like a ChangeLog: | 2. You may modify your copy or copies of the Program or any portion | of it, thus forming a work based on the Program, and copy and | distribute such modifications or work under the terms of Section 1 | above, provided that you also meet all of these conditions: | | a) You must cause the modified files to carry prominent notices | stating that you changed the files and the date of any change. On the other hand, not allowing source distribution as a “flat tarball” sounds like an additional restriction, which would be incompatible with the GPL. (Just like parts of glibc used to require distribution on tapes, only less inconvenient.)
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.
Re: anti-tarball clause and GPL
On Wed, 24 Jul 2019 at 02:34:13 +0200, Adam Borowski wrote: > > > ## > > > 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. > > > ## Are you asking this hypothetically, or is there a piece of software that someone intends to apply this to? As always for legal questions on whether something is allowed in Debian, asking -legal will only get you some speculation: the ftp team is the authority on what can and can't be in Debian. However, I think this would be an unwise precedent to set, with undesirable practical implications, and I suspect the ftp team would think the same. Remember that GPL-2 §3c is only allowed for non-commercial redistribution, so commercial redistributors have to use §3a or §3b. This means they have to take steps to redistribute the preferred form for modification themselves (e.g. copy it to *their* network server). In the GPL-3 case, a commercial redistributor could rely on §6d (GPL-3 §6 is the equivalent of GPL-2 §3), but it's unwise to rely on a third party for this without some sort of contractual relationship, because "you remain obligated to ensure that it is available for as long as needed to satisfy these requirements" (so linking to upstream's network server is not enough, because if upstream stop distributing source, you would be in violation of the license unless you immediately stop distributing binaries). Debian and its derivatives are longer-lived than many of the packages we include, so we need to know that we are already distributing source for all our binaries. Redistributing the entire history of a third-party project is practically problematic because it is no longer enough to check that there is nothing you don't want to distribute (e.g. non-free software) in the HEAD commit: you also have to check that there is nothing that you don't want to distribute anywhere in the history. If I remember correctly, this is why the ftp team do not allow "3.0 (git)"-format source packages in the Debian archive: if a git-based source package format is allowed in future, it will have to be "shallow", which makes it functionally equivalent to a tarball plus metadata. For established projects, the complete history is also inconveniently large: my git clone of glib2.0 has a 57M .git, which compares poorly with a 4.5M source tarball (and glib2.0 isn't even particularly big or old by the standards of projects like glibc and the Linux kernel). > 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. We have to draw a line somewhere. You could equally well say the software's bug tracking system and mailing lists, which also store human-readable comments, are part of the preferred form for modification - but those don't normally have any copyright license granted (I certainly didn't put this email under a copyright license!) so they are non-free. > Another piece of [meta]data that a flat tarball lacks is authorship > information. Projects that consider this to be important put copyright notices in source files, lists of authors in source files and/or lists of authors in ./AUTHORS. smcv
Re: anti-tarball clause and GPL
Adam Borowski writes: > Hi! > 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? Not everyone uses version control. Making requirements on how people make modifications would be a significant change. It would definitely be incompatible with the GPL. Cheers, Walter Landry
