[Bf-committers] extension clause

[Roger Wickes]

sounds like we should make the new Python API LGPL, if it's ok with Campbell 
since he's writing it :) I have in the past and plan on writing proprietary code 
in Python that uses Blender as the render engine. 


 --Roger


Check out my website at www.rogerwickes.com for a good deal on my book and 
training course, as well as information about my latest activities. Use coupon
Papasmurf for $15 off!



----- Original Message ----
From: David Jeske <davidj at gmail.com>
To: bf-blender developers <bf-committers at blender.org>
Sent: Mon, November 15, 2010 4:04:54 PM
Subject: Re: [Bf-committers] extension clause

My large previous post was focused around the reasoning behind my position.
I didn't want my suggestions for how to improve the situation to be lost in
it. Here are a few concrete suggestions. Note that in making these
suggestions, I'm not attempting to judge what would be required to make
these changes, simply suggesting alternatives that I believe would be better
than the current state:

(1) switch Blender entirely to the LGPL

The LGPL license is used for libc, and is written to require source
modifications to the code to remain free and available like the GPL.
However, it allows for "combined works" that link directly into the address
space of the LGPL code, without requiring that code be under any particular
license. This would allow closed-source extensions, as well as allowing
blender to be compiled into closed-source combined works. All improvements
to the blender code would need to be released, but the closed-source pieces
built around or inside blender could remain closed.

This would allow, for example: (a) games written using the blender game
engine to be distributed without releasing the entire source. Any
improvements or modifications to blender or the blender game engine itself
would need to be distributed. (b) extension modules which were build
specifically for blender to be distributed as closed source.

(2) create a section of LGPL code to handle the extension API

This is a compromise intended to acheive the same as (1) without changing
the license of existing code. There are some issues however. Doing this may
violate the GPL, as it is linked with the main blender code and thus should
be under the GPL, not the LGPL. Further, it's hard to imagine how an
extension API could insulate an extension from the details of blender
without encompasing most of RNA and anything related to touching
data-model.

(3) create a special provision for extensions, either as a carve-out
addition to the GPL, or an alternate "Blender-GPL" modified form of the GPL.

While I believe the LGPL was designed for and handles this case very well,
it may be easier for the community to agree on approving a small license
addition carveout for extensions while keeping the GPL in place as-is.

... again, I'm not attempting to start a debate on the viability of making
one of these changes. I'm attempting to discuss and build concensus about
the benefits of doing so.

Because Blender Foundation did not establish a process for copyright
assignment, a change like this would involve auditing copyrightholders and
either obtaining their permission, removing their code, or resigning the
change as unviable. Any discussion about whether or not this is feasible is
simply speculation.
_______________________________________________
Bf-committers mailing list
Bf-committers at blender.org
http://lists.blender.org/mailman/listinfo/bf-committers