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

Re: Ian's DFSG2 would harm Debian and Free Software

--On Wed, Dec 2, 1998 2:07 pm -0500 "Dale Scheetz" <dwarf@polaris.net>

> Technically, this doesn't effect Debian, as our source format already
> provides the upstream source against a Debian diff. The reported
> difficulty with CVS is a straw man as best I can tell. If this is a
> version management system, the CVS archive should be able to serve the
> original unmodified source or the current version, or any version
> inbetween. That is what version management systems are supposed to provide
> and I find it hard to believe that CVS is not up to the task.

I have seen lots of people on this list who apparently don't understand
Ian's point on CVS, so I'll outline it, as I see it.

It is certainly true that CVS is very good at understanding the difference
between modified versions and original versions.  Using a CVS set-up with a
so-called 'vendor branch' is a good way of tracking a Qt-like situation
(i.e. repeated releases from an authoritative source, couple with local

However, that doesn't change the fact that CVS will violate the letter (if
not the spirit) of a license with an 'unmodified source + patches' clause
such as the Qt one.

Suppose I download Qt for a personal project, under the *original* draft of
the QPL.  I now put it under CVS.  I make a few local changes (be they bug
fixes, or minor enhancements, or major changes).  I now say to my
co-developers, that they can access my patched version of Qt (so they can
collaborate with me on some project I'm working on which uses my patched Qt)
via CVS over TCP (the pserver method, say).

They then download from me a modified version of Qt.  So, I have broken the
law.  I have distributed (to my fellow developers) a modified version of Qt,
not in the form of unmodified source plus patches.

The same problem affects anonymous CVS.

Now, of course, CVS *does* clearly separate unmodified source from patches. 
In fact, if my developers choose to first check-out the vendor branch, and
then update to the 'trunk', they will not be in violation of the licenses -
since in this case they have in fact downloaded unmodified source, followed
by patches. (CVS distributes changes as patches, normally, depending on the
size of the patch file).

The point here is a technical one.  Clearly the use I am proposing above
does not violate Troll's stated goals for the QPL.  (For information on
those, read the archive of debian-legal, where Joseph Carter explains it
very nicely).  However, it does violate the letter of the first draft.

AFAIK, *this* is what is meant when people say that the first draft of the
QPL doesn't allow CVS.  If you like it's a 'technicality', but it does
suggest that that restriction is a little harsh.  Consult Joseph's current
draft modified version for a more gentle solution, which simply stipulates
that the recipient of the code must be able to see which bits are original
(which is certainly true of the CVS method).


|  Jelibean aka  | jules@jellybean.co.uk         |  6 Evelyn Rd        |
|  Jules aka     | jules@debian.org              |  Richmond, Surrey   |
|  Julian Bean   | jmlb2@hermes.cam.ac.uk        |  TW9 2TF *UK*       |
|  War doesn't demonstrate who's right... just who's left.             |
|  When privacy is outlawed... only the outlaws have privacy.          |

Reply to: