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

Re: DRAFT: debian-legal summary of the QPL

Matthew Garrett <mjg59@srcf.ucam.org> writes:

> On Thu, Jul 15, 2004 at 09:42:49AM -0400, Brian Thomas Sniffen wrote:
>> Matthew Garrett <mjg59@srcf.ucam.org> writes:
>> > Right, which indicates that we have nothing in principle against minor 
>> > technical awkwardnesses. If DFSG 4 didn't explicitly allow patch 
>> > clauses, somebody might read it as forbidding them. On the other hand, 
>> > their awkwardness is recognised - we encourage people not to use 
>> > licenses that require this sort of workaround.
>> On the contrary, we do have something in principle against technical
>> awkwardness -- but compromised those principles to accept patch
>> clauses.
> Why did we do that?

That's complicated.  My impression is that it was in the hope of djb
compromising and freeing QMail, but that didn't happen.

>> > Of course distribution is of interest to the original developer. The 
>> > original recipient (who I provided the software to) is making a copy of 
>> > something that I put effort into without necessarily giving me anything 
>> > in return. 
>> And if he has a Free license, then he can do that without the initial
>> developer's interference.
> Your arguments are distressingly circular. You asked me why private 
> modification could be held to different standards when compared to 
> distributed modification. I told you. 

You asserted that they were different.  How is modification less of
interest to the initial developer than distributed modification?  I
can replace "making a copy" with "changing a copy" in your text above
and it makes just as much sense.

> One is outside the developer's field of interest. One
> isn't. Replying to that by saying "But a free license means that it
> isn't of interest to the original developer" doesn't actually say
> anything useful.

Sure it does.  It says that the initial author's copyright gives him
control of modification and distribution.  A free license sacrifices
much of that control.  In particular, it is Free because it allows
others to do what the developer could, and without further permission
from the developer.

>> > In what way does it serve free software to allow people to hoard
>> > modifications rather than allow the community to take advantage of them?
>> Perhaps you weren't paying attention: a restriction on the ways in
>> which a recipient may manipulate a work is Free iff it advances free
>> software.  The converse is not true -- that is, it is not necessary to
>> show that Free Software is served by either decision, just those that
>> on their face restrict freedom.  If we adopt the rule you suggest,
>> we'd never me able to make any decisions but very very clear ones.
> Being forced to provide your modifications to everyone advances free 
> software. How could it not do? It means that more free software is 
> available.

That kind of generality is suspicious.  Whose freedom is advanced?
What disincentives to development are provided?  With the GPL, I can
point at the recipient and say that he has a guarantee of Freedom with
respect to that software.  With a general publication requirement,
whose freedom is increased?

>> In any case, allowing people to decide with whom they associate is a
>> central component of freedom.  A license that compels me to interact
>> with the initial author is, thus, non-free.
> You're arguing by assertion again.

You're just saying that.


Brian Sniffen                                       bts@alum.mit.edu

Reply to: