LGPL clarification

[Bryan George]

Greetings,

I've been lurking on the list for a bit, haven't seen this come up, and
am unaware of a FAQ or list archive, so I'm going to go ahead and fire
off a few questions related to the LGPL and the possible development of
an LGPL-derived license - my apologies if it's an old topic.

MITRE (and similar organizations) regularly develop infrastructure
libraries that we would like to see used in both non-commercial and
commercial contexts, and that we would like to be considered standards,
de facto or otherwise.  For these reasons, I have taken a very keen
interest in OSS licensing in general, and the LGPL in particular.

At first glance, the LGPL appears to be exactly what an organization
such as ours requires.  It provides protection against fragmentation of
the infrastructure itself through closed development, and provides a
mechanism whereby free software developers (including ourselves) can
contribute to and evolve the infrastructure without concern that their
good work will "go private".

At the same time, the LGPL appears to make provisions for the
infrastructure to be used in reasonable ways by profit-making
enterprises, without strings attached to the source code making use of
the infrastructure or executables thus derived.  Without such
provisions, companies would simply ignore our work, develop their own
in-house code, and nothing would be accomplished at all.

As I said, that is how the LGPL _appears_.  However, a close reading of
the license text reveals what again appears to be a poison pill where
commercial interests are concerned.  Sections 5 and 6, in particular,
seem in fact to put strings on executables that a company might want to
sell.  Section 5 states:

"... linking a "work that uses the Library" with the Library creates an
executable that is a derivative of the Library (because it contains
portions of the Library), rather than a "work that uses the library".
The executable is therefore covered by this License. Section 6 states
terms for distribution of such executables."

And Section 6 states:

"... As an exception to the Sections above, you may also combine or link
a "work that uses the Library" with the Library to produce a work
containing portions of the Library, and distribute that work under terms
of your choice, provided that the terms permit modification of the work
for the customer's own use and reverse engineering for debugging such
modifications."

These statements are very unfortunate, because they cross the boundary
that the LGPL intends to establish between the OSS and commercial
worlds, and dictate terms on the distribution of executable programs
using LGPL-covered libraries.

I have seen some discussion of these issues in other lists, and the
responses to such objections are along the lines of "Well, modification
and reverse-engineering happen anyway, and it's been determined to be
legal in some European countries and probably will be here soon as well,
so it doesn't really matter."

But it _does_ matter.  As I said before, one of our goals in covering
code under the LGPL is to get companies to adopt the libraries instead
of developing the infrastructure in-house.  If there are any, and I do
mean _any_, restrictions added to the sale and distribution of a
company's executable product, the desired adoption will happen rarely,
and certainly not by any large corporations with the means to develop
in-house code.

To put it another way: I guarantee that, as soon as a corporate lawyer
gets a sniff of either of these provisions, whether they "don't matter"
or not, that lawyer will immediately turn to the company's technical
staff and say "Thou shalt not use library x for any product development
purposes whatsoever."

So, with that background, here are my questions:

- Am I interpreting the aforementioned sections of the LGPL correctly? 
I am not a lawyer, so if there is a reasonable interpretation of the
license that renders the objections I've raised moot, please enlighten
me.

- Assuming I'm interpreting the LGPL text correctly, are there any
reasonable circumstances under which a company might be able to develop
and deploy a binary executable without being subject to the stated
conditions?

- Assuming there are no such circumstances, are there any GPL-compatible
licenses that behave similarly to the LGPL, but without the "obnoxious
modification and reverse engineering clause"?

- Assuming there is no such single license, is there a multi-license
approach that might accomplish what I'm after?

- If not, would it be difficult to surgically alter the LGPL to remove
the OMAREC and maintain GPL compatibility?

- If a "text-snipping" approach is inappropriate, can anyone give me an
idea of where the "third rail" is with respect to modifying the LGPL to
create a license that maintains anti-forking, remove all strings from
the distribution of executable (but not library) products using the
library, and preserves GPL compatibility?

- If it is intractable to modify the LGPL, would it be more reasonable
to modify another OSS license to be more LGPL-like in the ways I've
described?

- Or should we just say to hell with it and develop our source under an
X11 license? :)

Thanks very much in advance for your feedback.

Regards,

Bryan

-- 
Dr. Bryan George                     Phone: +1 (703) 883-5458
Lead Signal Processing Engineer      FAX:   +1 (703) 883-6708
The MITRE Corporation                Email: bgeorge at mitre.org
1820 Dolley Madison Blvd., M/S W622  Internet: http://www.mitre.org
McLean, VA 22102-3481 USA

Disclaimer: I speak for absolutely no one besides myself.