[Bf-committers] extension clause

[David Jeske]

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 <blenderwell at 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*.