[Bf-committers] extension clause

[David Jeske]

On Mon, Nov 15, 2010 at 5:59 PM, Campbell Barton <ideasman42 at gmail.com>wrote:

> @David Jeske, at least twice you point to The GIMP, as an example of
> software that is limited by the GPL.
> This in-fact is incorrect. The GIMP has already resolved this by
> providing a LGPL libgimp which closed source plug-ins my link to.
> Incidentally, does anyone know if this has helped the GIMP?, or know
> of any commercial plug-ins on the market for the GIMP?.
>

I wasn't aware of this license split in GIMP. At face value it looks like
exactly the sort of "LGPL api" that has been brought up by myself and some
others. I found a decent overview of the gimp components and
licenses<http://gimp-plug-ins.sourceforge.net/gimp2/doc_components.html>.
 I will do some research and see if I can learn anything about commercial
comfort with this license situation. Unfortunatly, gimp may not tell us much
about the viability of this scenerio, because as I understand it there are
many other factors that make gimp a challenging tool to adopt vs photoshop.

* As for a GPL exception, I'm not against this but expect its
> difficult to do this. Id also be fine with a LGPL python api but this
> uses internal blender libraries which I think will complicate things.
>

Looking at the gimp lgpl vs gpl diagram, there are substantial portions of
gimp which seem to be lgpl to enable this type of split. To mirror this
structure, I suspect RNA would need to be part of this LGPL'ed layer.


> * Along similar lines to Matt, I'm more interested in blender linking
> with closed modules, this would allow us to have a FBX importer (like
> Wings3D can do because they are BSD), it would also allow integration
> with commercial rendering plugins without having to mess with external
> processes.
>

I'm with you on this goal.

@Alex Combas - That certainly is a creative interpretation of the system
library and library-permissions clause. The spirit of that clause is very
different than the manner in which you are attempting to apply it. The
intention is to allow for the base-case that GPLed software written for a
commercial operating system (such as windows), is obviously going to link in
a bunch of non-GPL system-library code, and if the GPL attempted to assert
GPL requirements on that system-library we'd all probably consider the GPL
flawed at a fundamental level and reject it.

The wording here, even in the case of a manual exception, refers to the
non-GPL code as a "library" and implies it's existance before the authoring
of the program. Something which was authored before the GPL program
shouldn't have any dependencies of the program in it, making this entire
concept redundant with the "indepdenent and separable" test. An
addon-library which is authored after the GPLed program, and which is
obviously dependent on an API established by the GPLed program seems like a
different beast entirely and not at all synonous with the concept of a
'system library'. Further, the exception would need to not be for a specific
library, but an entire class of library (any addon).

We'd need a lawyer to render an opinion, and even moreso, only time would
tell whether that interpretion would be reasonable. It's unclear if this
would provide enough comfort, until the situation was tested by a court or
disagreement. That said, it is a very creative suggestion, and we should
consider this as it might be a decent route for the idea of carving out an
addon-exception.