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

Re: LGPL Library concerns...



Bruce Wampler wrote:
> 
> Brian Macy wrote:
> >
> > I didn't notice any posts on this in the archive... does V have an
> > exception to the LGPL license with regards to a 10-line in-line function
> > header limit? The 10 line limit is impossible to abide by with regards
> > to templates and if anyone exceeds it then any code linking your library
> > in would have to be GPL'd.
> 
> I've never heard this issue before, and don't understand what you mean
> here. I want to keep V completely Open Source, and in the Gnu camp.

Ahhh... blissful ignorance :) I used to think the LGPL/GPL were good
things until I read them. This is the most problematic clause (though 6
doesn't help any).

Basically if I create a product (let's say a Windows DLL) that links or
compiles with an LGPL'd library, there are no restrictions on my
product. If this product is then linked in to create another product
(say a Windows EXE) then that new product (the EXE itself) falls under
the LGPL.

The third paragraph is the nasty one... basically making, under certain
circumstances, applications that simply use the library LGPL'd just
because the headers don't fall under the exceptions in the fourth
paragraph (notice the 10line limit is one of the exceptions).

Anyways the LGPL/GPL are a mess... they contaminate everything and most
people don't actually know what they say. I can't believe they were ever
considered "Open Source". There is only one way I know of to make the
LGPL palatable and it violates the LGPL (expections to the LGPL can only
be because of geographical requirements -- ie your country don't allow
something)... make 2 exceptions:

-1 In no circumstance shall any product that links, compiles, or
otherwise uses binary forms of this product fall under this license
(wxWindows makes this basic exception to get around the 10line inline
function problems)
-2 This product can link, compile with, or use any other product that
doesn't restrict it's use and distribution in the many used (basically
so you can use a BSD, Public Domain, or other open souce product in your
product without have to make the product you use LGPL'd)

"5. A program that contains no derivative of any portion of the Library,
but is designed to work with the Library by being compiled or linked
with it, is called a "work that uses the Library". Such a
work, in isolation, is not a derivative work of the Library, and
therefore falls outside the scope of this License. 

However, 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. 

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. Whether this is true is especially significant if the work can be
linked without the Library, or if the work is itself a library. The
threshold for this to be true is not precisely defined by law. 

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.
(Executables containing this object code plus portions of the Library
will still fall under Section 6.) 

Otherwise, if the work is a derivative of the Library, you may
distribute the object code for the work under the terms of Section 6.
Any executables containing that work also fall under Section 6,
whether or not they are linked directly with the Library itself. "

> The only problem I've ever seen in LGPL is the requirement that you
> allow different versions of the library to be linked to your app.
> I've also understood that DLLs or shared libs cover this clause.
> Since V will work with DLLs and shared libraries, this requirement
> can be met by any application. I'm afraid I don't understand
> what in-lines have to do with anything.

Actually I think you have to make the object files (DLLs would work too)
available... I don't believe there is any requirement that if they
attempt to relink that it is successful or will even function. Basically
a worthless requirement.

> If you are this desparate, I'd suggest you talk with me directly. If you
> have the energy to put in to customizing wxWindows, I'd much
> rather you direct that energy to V. I'd be more than
> happy to work with you to add whatever features you need to V, so
> your energy could help everyone.

I'll get back to you privately on that... if I can find a GUI framework
that I can "use" with practically no restrictions (commercial,
non-commercial), is reasonably organized (I got write access to CVS for
wxWindows about the instant I subscribed to the list... I couldn't
believe it... very bad), works under Linux (gtk, motify, whatever...
don't care which) and satisfies the fairly minimal needs I have I'd be
happy to put my effort into helping develop it.

Brian Macy


Reply to: