[Bf-committers] extension clause

[David Jeske]

On Wed, Nov 17, 2010 at 2:24 PM, Dan Eicher <dan at trollwerks.org> wrote:

> > This contradicts the information I see in the industry, and both the
> legal
> > and my laymen's understanding of the GPL.  Is there some company that
> could
> > publish a case study about how they feel it safe to build closed-source
> > extensions to GPL code?
> >
> > Seems like y'all are talking about two different things (again).


> They aren't making 'extensions' to GPL code but merely linking *to* the
> GPL'd code from their 'closed domain'. They would also (presumably) take
> into account this *linking* when distributing their code to 'contracting
> shops and other third parties'.
>

I don't see two different things, perhaps I can clarify and you can explain
why you believe this to be the case...

When I write "extension", I mean: "an add-on which is compiled against and
dynamic loaded into the address space of another program, but normally
distributed separately."

To write a "closed source extension add-on" you have to "link to GPL code
from a closed source domain (the add-on extension)", you have to "depend on
details of the GPL code specifically in closed-source", and you have to "run
closed-source code (which is not a system library) in the same process as
the GPL code".  -- All of which are prohibited by the GPL as far as I can
see.

Any code which links to (in process) and depends specifically on details of
GPL code must be under the GPL. Even if it's a DLL/dso, it still needs to be
under the GPL. That's the purpose of the license. This is the reason glibc
is under the LGPL, because if every program that linked to glibc had to be
under the GPL, closed-source programs could not be built with glibc.

I think this interpretation of the GPL is fairly accepted. If you don't
think this is the case, I encourage you to work with the FSF to see if they
will release a position statement explaining how closed-source DLL/dynamic
modules may be built to run in-process and be dependent on details of a GPL
codebase. I don't think they believe this to be valid, but if they do,
writing a position statement should clear it up.

I've heard a few people mention this loophole related to the definition of
'distribution', where if a binary is distributed only within an
organization, then that's not really 'distribution' and so the closed-source
code does not need to be moved to the GPL and released in source form. I've
explained why this loophole is not practically useful, both because it's not
universally accepted, and because companies must often distribute the
binaries outside their organization to get work done.

Which part of Blender will an extension use?


It seems like today's extensions use the UI, operator stack, and RNA/mesh
data. This is probably the minimum set.


> If it just has access to an API which provides user data (mesh data,

materials and such) and a way to return some processed data to Blender so

this extension is independent work.

If it doesnot use some or Blenders internal libs (render calls, modifier

code, ...) it depends of the data and not Blender itself.

And the data is not GPL... so where is the problem?


The problem is that according to the GPL, if you do that in the same address
space, your code has to be GPL as well. Doing this legally as closed-source
either requires building an out-of-process network based API (as Campbell
mentioned), or building an LGPL API shim in the middle (as GIMP did).