[Bf-committers] extension clause

Ton Roosendaal ton at blender.org
Mon Nov 22 18:05:57 CET 2010


Hi David,

Sorry, my mistake :) LGPL covers both cases I sketched.

For now I'd like to hear first from our key contributors how they feel  
about the general idea. There's no reason to hurry with this, I'll try  
to settle it with final proposal before we move to a final stable 2.6.

-Ton-

------------------------------------------------------------------------
Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands

On 22 Nov, 2010, at 17:02, David Jeske wrote:

> On Sun, Nov 21, 2010 at 3:30 PM, Dan Eicher <dan at trollwerks.org>  
> wrote:
>
>>>
>>> I believe it's important to many users (especially, but not  
>>> limited to
>>> corporate users) to have a secondary 'proprietary plugin market',
>>
>
>
>>> That option has been discussed and all but approved, the only  
>>> hitch is
>> the
>> plugin writers also have to write and maintain the BSD (or  
>> whatever) api
>> shim code.
>>
>
> How is legally viable to make a capable BSD licensed API with the  
> code under
> the GPL? The shim would be dependent on material details of the  
> Blender
> design and internals. It would probably expose many of those details  
> (such
> as UI panels, RNA) As a result, the shim should be under the GPL,  
> and as a
> result, the extensions should be under the GPL.
>
> During this discussion we talked about the license extension  
> exception. This
> applies to Blender embedding Python, effectively making it a 'library
> exception'. Python was a pre-existing library which is not-GPL, and  
> thus is
> covered under the GPL library exception clause. Python does not  
> depend on
> any details of blender. In fact, it's the other way around, Blender  
> depends
> on Python.  If I understand correctly, in order to apply this license
> exception, the authors of all those details (UI, RNA) would need to  
> approve
> the 'exception' of the shim-library, and they would need to depend  
> on it's
> details, not the other way around.
>
> It's interesting to note that if Blender wanted to be non-GPL, and  
> Python
> was GPL, it wouldn't be legal to embed it into Blender. One of the  
> biggest
> benefits of Python is that it can be linked with anything without  
> license
> restriction. It's shown up in all kinda of software, free and  
> commercial,
> and been a stronger open-source project for it.
>
> Ton wrote....
>> Basically there are two cases we can investigate:
>>
>> 1) Allow anyone to extend Blender, linked dynamically with scripts or
>> libraries or plugins
>> 2) Allow anyone to dynamically link in Blender libraries in their own
>> programs
>>
>> The LGPL will only allow the latter. For the first we have to devise
>> an extension clause (if we want to stick to GPL).
>
> The LGPL would allow either. In order for someone to write a non-LGPL
> plugin, their code must depend on details of the LGPL code, and "link
> against" the LGPL code, both of which are allowed by the LGPL.
>
> When you say "extension clause" are you referring to authoring a
> unique-to-Blender extension clause which deviates from the GPL? or  
> using the
> GPL Library Exception provisions?  As I wrote above, in order for the
> library-exception clause to allow closed-source extensions, Blender  
> would
> need to carve bunch of existing code into a "ui and rna" library,  
> which is
> put under a a less restrictive license and is then becomes the library
> exception. This is the route GIMP took. They used the LGPL for that  
> library,
> since the LGPL allows you to link it into closed source without
> contamination. Using a less restrictive license would obviously also  
> work.
>
> I don't see solid comfortable legal ground for claiming that "all  
> 3rd party
> extensions" are "after the fact" library exceptions, using the GPL's  
> library
> exception clause. If this is the route you intend, it would help
> substantially if you could get FSF to publish a specific position on  
> this
> direction.
>
> It's kind of funny how people/companies are willing to contribute  
> code to
>> (and use) Linux more than all the BSD put together yet Linux has a  
>> more
>> restrictive license. You'd think they would all be scared away from  
>> the GPL
>> and go towards a license where they don't have to worry about  
>> having their
>> code 'virally' infected or 'lost' if they (accidently or otherwise)
>> distribute it. But they don't which IMHO says a lot.
>>
>
> Linux can be extended by writing applications. Those applications do  
> not sit
> in the same address-space as the Linux kernel, and they compile  
> against
> glibc and other libraries, not the kernel itself. No GPL  
> contamination.  All
> that is required for the community to adopt a solution is for that  
> solution
> to have critical mass and have a license compatible with them  
> building and
> distributing anything they want, with any license they want. Linux  
> provides
> this. A GPL Blender does not.
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers



More information about the Bf-committers mailing list