Re: Ian's DFSG2 would harm Debian and Free Software
On Wed, 2 Dec 1998, Jules Bean wrote:
> --On Wed, Dec 2, 1998 2:07 pm -0500 "Dale Scheetz" <firstname.lastname@example.org>
> > 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).
While I understand you point. I would simply say that the issue can be
resolved technically by simply making CVS archives of such licensed
software always supply first the original, and then the patches. In fact,
it would only require that the first "check out" to create a new archive
must be the original code, and that all succeeding updated only transfer
"the patch" in its current form. This would suit the letter and spirit of
> 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.
As the originally stated license restricts distribution of modifications,
I would be inclined to consider it less free that we would desire.
> 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).
So this license would be considered free under current terms, requiring no
modifications to the DFSG?
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: email@example.com Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-