[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: anti-tarball clause and GPL



Simon McVittie writes ("Re: anti-tarball clause and GPL"):
> Are you asking this hypothetically, or is there a piece of software that
> someone intends to apply this to?

There are existing packages for which I consider the PFM to include
the git history.  I'm not pressing this point from a legal point of
view because, well, that just generates lots of heat and no light.

I think that we should address this potential problem by arranging to
give to the history to our users and downstreams.  There are lots of
other really good reasons to do this.

(ISTM that whether the PFM needs the upstream vcs history or not is a
question of fact which depends strongly on the context, how the thing
is developed, etc.  I don't think a GPL rider like the one quoted
earlier is definitive either way - it's a statement of the author's
opinion and perhaps implies something about their practices.)

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

This boat already sailed a long time ago.  Via alioth and now salsa,
and via the dgit git server, we are in many cases distributing that
complete history already.

> 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).

Right.  Bundling up git histories in tarballs is not a really sensible
way to carry on (unless trying to make a source CD for offline use or
something).  Better to just have a git server, since then you only
need to keep one copy of the history, and in many cases clients can
only transfer updates.

> 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.

So that interpretation of the PFM is not compatible with upstream's
practices.

Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.


Reply to: