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
Reply to: