[PD] pd-extended license WAS: Keyboard shortcuts for "nudge", "done editing"

[Hans-Christoph Steiner]

On Oct 12, 2011, at 5:42 PM, Jonathan Wilkes wrote:

> ----- Original Message -----
>
>> From: Hans-Christoph Steiner <hans at at.or.at>
>> To: Mathieu Bouchard <matju at artengine.ca>
>> Cc: Pd List <pd-list at iem.kug.ac.at>
>> Sent: Wednesday, October 12, 2011 4:00 PM
>> Subject: Re: [PD] pd-extended license WAS: Keyboard shortcuts for  
>> "nudge", "done editing"
>>
>>
>> On Oct 6, 2011, at 5:58 PM, Mathieu Bouchard wrote:
>>
>>> Le 2011-09-28 à 10:35:00, Hans-Christoph Steiner a écrit :
>>>
>>>> In the case of a GPL project including a BSD code, there is not a
>> separate license.  Only the copyright holder can change the  
>> license. It is just
>> that the BSD license allows you to add additional restrictions.   
>> The GPL adds
>> one restriction: whenever you give someone the software, you have  
>> to also give
>> them the source code.
>>>
>>> GPL also adds the restriction of not adding any additional  
>>> restrictions,
>> and that's a restriction by itself (I'm not saying that it's good or
>> bad).
>>>
>>> It can also be counted as several additional restrictions,  
>>> depending on the
>> way one reads it.
>>>
>>>> So if you were going to include Pd-extended in your OS as a  
>>>> whole, you
>> have to treat all the code as GPLv3.  list-abs is a library  
>> included in
>> Pd-extended.  It is released under a BSD license.  If you download  
>> list-abs by
>> itself and package that, then it is not Pd-extended.  So its BSD.
>>>
>>> If someone includes Pd-extended as a whole in their OS, and modify  
>>> BSD
>> externals, while keeping them bundled with the rest of Pd-extended,  
>> they
>> don't have to distribute the source to those modifications, despite  
>> your
>> claim that Pd-extended has a license « as a whole ». That person  
>> doesn't
>> have to take anything apart (debundle) or whatever.
>>>
>>> The « as a whole » concept has a more limited applicability than  
>>> what you
>> seem to be claiming.
>>
>>
>> There are many examples of software that includes code that has  
>> many different
>> licenese.  ffmpeg/libav is an example.  It not only gives you ./ 
>> configure flags
>> to support different licenses, but also includes non-free code,  
>> that when linked
>> together into a binary is not legal to distribute.
>>
>> Perhaps in theory this is bad.  Then there is theory and there is  
>> practice.
>> I'll bet there are many people who are glad to be able to compile  
>> this
>> non-free ffmpeg, because once they have the binary it will be able  
>> to do things
>> that the free ffmpeg cannot.
>
> Wait a second-- didn't you decide not to include some external that  
> Yves authored
> which had a clause that made it nonfree?  If so, then why are you  
> arguing from the
> practicality angle for another software package?
>
> But those two questions are for curiosity's sake-- they are  
> irrelevant to the discussion
> at hand because all the licenses we're talking about are free  
> software licenses.  It's
> simply a matter of whether one ought to say GPLv3 as a whole or that  
> the core of
> Pd-extended is GPL3, and that there are various free licenses for  
> the external libraries.
>
> (Well, there's also the issue of GPLv2 or later vs GPLv2 only, but  
> we've completed
> the discussion for that one.)


Building ffmpeg as non-free means the binaries cannot be  
redistributed.  The vast majority of Pd users want to download  
binaries, not build their own.  They are free to download pidip and  
use it with Pd-extended under the terms of the pidip license.

If someone wants to maintain some kind of configuration that deals  
with pidip's restrictive license, they are free to do so, like they  
did with ffmpeg.  I have zero interest in spending my time doing that.

.hc



----------------------------------------------------------------------------

                             kill your television