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