On Mon, Nov 15, 2010 at 5:59 PM, Campbell Barton <ideasma...@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. _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers