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

[Ben Gertzfield <che debian org>]

(This document is available at http://csl.cse.ucsc.edu/~ben/ibm-open-source )

THE TEN-LINE WEAKNESS OF THE LGPL,
or, How the Corporation Got Its Source

Ben Gertzfield <che@debian.org>

Today (8 July 1999) I attended a meeting at IBM Almaden regarding
open-source licenses and how software using those licenses can be (and
is being) used at IBM.  Several interesting issues were brought up by
both the speaker and the audience, both from a legal standpoint and a
programmer's standpoint.

Before I begin, let me say that I in no way speak officially for IBM;
this is simply my interpretation of a discussion about open-source
licenses.  Personally, we use and develop open-source software in many
places at my research job at IBM, and I am merely concerned about some
of the issues brought up at the meeting.

The talk mainly concerned the GNU General Public License (GPL) and
Lesser (formerly Library) General Public License (LGPL), and the issue
of intellectual property explicitly or implicitly licensed under those
licenses.  A quick overview of the GPL was given, prompting a number
of questions from both people new to the GPL and programmers who were
already familiar with it.

The issue of using GPLed header files was discussed; it was noted
that, under a strict interpretation of the GPL, any source that
includes header files of a GPLed work in order to interface with that
program must be licensed under the GPL (or a less restrictive license,
of course).  

However, Linus Torvalds disagrees with this interpretation, and has
publically stated that binary modules compiled against Linux kernel
headers are not confined to GPL or less restrictive licensing.  So the
current state of things isn't quite clear, and won't be, until the GPL
is challenged in a court of law.

The header file problems with the GPL are well-known, which led the
speaker to the LGPL, including a section I had not previously known
about regarding including header files of LGPLed works. The LGPL
states (in Section 5) that:

"When a "work that uses the Library" uses material from a header file
that is part of the Library, the object code for the work may be a
derivative work of the Library even though the source code is not. ...

If such an object file uses only numerical parameters, data structure
layouts and accessors, and small macros and small inline functions
(ten lines or less in length), then the use of the object file is
unrestricted, regardless of whether it is legally a derivative work."

The official (extremely conservative) interpretation at IBM of this
last paragraph is currently that the header file itself must be ten
lines or less in length -- otherwise a work using the header file must
be licensed under the GPL.  

The programmers in the room vehemently disagreed with this statement;
most were quite familiar with the fact that most header files are much
longer than ten lines in length, and both the speaker and the audience
agreed that the ten lines restriction referred to the 'small' of
'small macros and small inline functions'.

However, this is a perfect example of the vagueness still present in
the GPL and LGPL licenses.  Who defines the length of a line?  Why is
ten lines the limit for an inlined function or macro, instead of
twenty or thirty?  Does 'ten lines' here refer to the *total* length
of any and all inlined functions or macros in a header file, or does
it mean ten lines for each inline?

The above section is a most unsatisfactory clause in the LGPL, as now
anyone who wishes to link their program with an LGPLed library must go
through, by hand, each header file they include, and make sure no
inlined functions or macros are over ten lines in length.

For instance, the GLib C library, the close counterpart of GTK+, the
graphical library used for the GNOME project, is licensed under the
LGPL.  However, in the 'glib.h' header file the following macro is
defined:

#define g_return_if_fail(expr)          G_STMT_START{                   \
     if (!(expr))                                                       \
       {                                                                \
         g_log (G_LOG_DOMAIN,                                           \
                G_LOG_LEVEL_CRITICAL,                                   \
                "file %s: line %d (%s): assertion `%s' failed.",        \
                __FILE__,                                               \
                __LINE__,                                               \
                __PRETTY_FUNCTION__,                                    \
                #expr);                                                 \
         return;                                                        \
       };                               }G_STMT_END

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.

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.

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.

-- 
Brought to you by the letters X and N and the number 19.
"A baloo is a bear."
Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/