[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: The Ten-Line Weakness of the LGPL and the effects on GTK+/GLib



On 8 Jul 1999, Ben Gertzfield wrote:

> This is twelve lines in length. Obviously it does not have to be
> twelve lines in length (and is so only for readability), but under the
> strict guidelines of the LGPL, every single program that links with
> GLib must be licensed under the GPL or a less restrictive license, or
> it is in conflict with the LGPL.

this is not true. Reread the LGPL. Specifically, read section 6 on what is
required of a "work that uses the Library". Notably, the work does *not*
have to be licensed under the GPL or less restrictive. Subsection 6b
allows that if the executable is dynamically linked, it fulfills the
requirements, since the user can replace the library with a modified
version.

> Obviously this can happen again and again with any LGPLed library; how
> many people have actually combed through the header files of the GNU C
> library to make sure there are no inlines of ten lines or greater?
> The idea of the LGPL is not inherently flawed, but this 'feature' does
> not guarantee the freeness (whatever your definition of 'free' happens
> to be) of software in any way -- it merely hampers real life people
> in their everyday jobs from using LGPLed software in the manner it
> was meant to be used.

Reread section 5. If the application can be compiled without the library,
it is not a derivative work. If your code can compile with another C
library than the GNU C Library, it needn't be free software - but it does
need to dynamically link (rather than statically link) to the C Library.

> Is this what the intent of the LGPL is really about?  How can we
> repair this situation -- as it stands, I'm sure many people are
> unintentionally violating the LGPL with GLib by linking a proprietary
> program to it.  But who has the time to go through every header file
> of every LGPLed library on their system and count the lines of every
> macro and inlined function?  This weakness in the LGPL needs to be
> addressed quickly by the FSF, and I hope that this matter will be
> fixed soon.

The intent of the LGPL is laid out in the preamble:

<QUOTE>
  For example, on rare occasions, there may be a special need to
encourage the widest possible use of a certain library, so that it becomes
a de-facto standard.  To achieve this, non-free programs must be
allowed to use the library.  A more frequent case is that a free
library does the same job as widely used non-free libraries.  In this
case, there is little to gain by limiting the free library to free
software only, so we use the Lesser General Public License.

  In other cases, permission to use a particular library in non-free
programs enables a greater number of people to use a large body of
free software.  For example, permission to use the GNU C Library in
non-free programs enables many more people to use the whole GNU
operating system, as well as its variant, the GNU/Linux operating
system.
</QUOTE>

Nutshell: sometimes it makes sense to allow non-free software to use free
software. In these cases, a license is needed that permits this while
protecting the sanctity of the free software - this license is the Lesser
General Public License. It may not be as desirable as a world that is
wholly free software, but is seen as a necessary evil/inconveniance.

P.S. No flamewars on GPL vs. LGPL vs. BSD vs. AL vs. MPL vs. whatever,
definitions of free, how free various licenses are, captialism vs.
communism, gun control, or anything else, please. And of course, IMHO,
IANAL, AFAIK, HAND.

-- 
Jakob 'sparky' Kaivo - jkaivo@ndn.net - http://www.ndn.net/
"As time goes on, my signature gets shorter and shorter..." - me



Reply to: