I think this mechanism Alex brought up is an important one to consider. In addition I've referenced some additional FSF documentation about GPL vs LGPL.
On Tue, Nov 16, 2010 at 2:22 AM, Alex Combas <blenderw...@gmail.com> wrote: > > 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. > > It does not say that. I think you are bringing in your own interpretation. > > The way the document describes it there are only two classes of libraries: > system, and non-system. > > You indicate that you think that certain libraries would automatically > be disqualified by the FSF depending upon their date of authorship or their > purpose or utility. > That's not the source of my interpretation. The GPL refers to a "system or non-system library" which implies it exists and can be named. If the library does not exist at the time of the exception, how can it be named? In my view, we're not proposing to name an exception "library" but a "class of libraries". I see no provision in the GPL for a "class of libraries" or a "set of libraries conforming to an API". Further, some might also argue that the accepted computer science definition of "library" (system or non-system), implies that it is developed and compiled independently. If are to consider an addon a reasonable case of 'library', that code still must be compiled/linked independently, and so any headers it's compiled/linked with would need to be at least LGPL to prevent GPL contamination. I do think this "library exception" may be the opening that allows the GPLed GIMP code to make exception for the LGPL gimp extension library. Without this exception, it might be a violation of the GPL for gimp to link with the LGPL extension library. ----- This rider at the bottom of the GPL seems to pretty clearly advocate an LGPL path for code which intends to allow incorporating (linking) propritary code. The GNU General Public License does not permit incorporating your program > into proprietary programs. If your program is a subroutine library, you may > consider it more useful to permit linking proprietary applications with the > library. If this is what you want to do, use the GNU Lesser General Public > License instead of this License. But first, please read < > http://www.gnu.org/philosophy/why-not-lgpl.html>. ..and further, on the linked philosophy about gpl vs lgpl... Using the ordinary GPL is not advantageous for every library. There are > reasons that can make it better to use the Lesser GPL in certain cases. The > most common case is when a free library's features are readily available for > proprietary software through other alternative libraries. In that case, the > library cannot give free software any particular advantage, so it is better > to use the Lesser GPL for that library. Even though a 3d modeler is an "application" the way it is commonly used it is also a "library" because extensions and modules are built and linked with it. This is why we used the Lesser GPL for the GNU C library. After all, there > are plenty of other C libraries; using the GPL for ours would have driven > proprietary software developers to use another—no problem for them, only for > us. ..which seems analagous to our situation. There are plenty of other 3d modelers which allow extensions. Using the GPL drives propritary software developers to use another -- *which is no problem for them, only for us*. I understand that some may be sympathetic with the other messages in that lgpl vs gpl philosophy. Namely ... We free software developers should support one another. By releasing > libraries that are limited to free software only, we can help each other's > free software packages outdo the proprietary alternatives. The whole free > software movement will have more popularity, because free software as a > whole will stack up better against the competition. I am not oblivious to this argument. To reuse the rationale made in that document...At least one piece of extension code will probably be released in the GPL that would not have been if Blender remains fully GPL. However, I believe the entirely free-and-open-source code of Blender will stack up better against the competitors if proprietary software developers (and companies) can use it as a replacement for those products. A situation which is very analagous to libc. Being fully GPL, removing Blender as an option for companies, really *is not a problem for them, only for us*. _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers