On Wed, Nov 17, 2010 at 2:24 PM, Dan Eicher <[email protected]> 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). _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
