LLGPL Clarification

[Marc Santoro]

John Foderaro <jkf@franz.com> said:

> 
>     When a "work that uses the Library" uses material from a header file
>     that is part of the Library, 
>

Notice the use of "When" instead of "If and only if". When you murder 
someone, you go to jail. When you use macros, you create a derivative work. 
How you murder someone, or how you got those macros, doesn't really matter -
- this is more of an example of specific applicability. Note the end of the 
paragraph: 

    The threshhold for this to be true is not precisely defined by law.

In essence and in practice, macros and data structures can come from 
anywhere. If they could only come from header files, defeating this even 
with a language as limitde as C would be trivial.

> 
> So again this paragraph is trying to establish rules to handle
> people making use of very fancy header files to create
> their own library which they want to consider as an independent
> work yet in reality it's simply derived from the 
> work done to write the existing library.
> 

Not really -- the paragraph is trying to establish rules for complex header 
files, macros, and data structures -- not necessarily in unison with 
eachother -- which are used as part of a library as to how the resulting 
object code -- which is a derivative of the Library (I do not see you 
disagreeing with this, so I assume you agree) -- should be licensed. Note 
that section 6 does not say it must be licensed under the LGPL, instead 
that the license must give the user rights to modify or reverse-engineer 
the object code, primarily for the purpose of debugging interactions 
between the derived code and the original Library. The LGPL does not want 
to take away your rights, but I'm afraid that the LLGPL inadvertently does.

> There is simply no parallel in the Lisp world.  

In the Lisp world, all programs could be considered libraries, especially 
programs developed using bottom-up programming. Even more so, the 
distinction (especially with regards to reflection) of higher order 
languages between functions and data begins to fade away. See section 2 -- 
legally, dynamically and statically linked works are considered derivatives 
of the Library. The LGPL is completely inadequate in describing this 
situation in terms of Lisp and higher-order functions. This is not about 
header files -- they are too specific a case, and seem to provide nothing 
but a useful example for a subset of programming languages.

> Also all section 5 of the LGPL does is say that sometimes 
> things fall under section 6.  But our preamble to the LGPL 
> says that
> 
>     Because of this declaration, section 6 of LGPL is not 
>     applicable to the Library.
> 
> so this wipes out section 6.

.. as I pointed out before you state it is not applicable to the Library, 
however, it would be applicable to the work that uses the Library.

> We tried to be as clear as possible that a Lisp Library is 
> a collection of functions (and macros are just source transformation
> functions) and data.   Even if you load a Lisp Library
> into your code and use those functions and macros
> you haven't made a work derived from that Library.
> 
> It's just that simple.

How so? Macros are macros, regardless of how powerful they are (or aren't). 
I am arguing that the offending object code constitutes a derivative 
because the object code will necessarily be based in part on source code 
licensed under the LLGPL/LGPL. This is inherent in the definition of a 
derivative. You are saying this is not the case, because such functionality 
is integral to Lisp. However, that statement does not invalidate my 
argument, and merely supports that the LLGPL is ambiguous and needs 
clarification as well as correct terminology.

> LGPL, since it has many C language things in it, isn't 
> the perfect open source license for Lisp.  I'll admit that.
> We considered making yet another open source license but
> found that people were happier to with an existing license 
> whose intent they understood.  

How is the intent any easier understood, than stating in the preamble 
something along the lines of "The intent of this license is to be similar 
to that of the LGPL"? That would be just as effective.

> The intent of the LGPL (and LLGPL) isn't to trick you into forcing you
> to make your code open source.   Its intent is to ensure
> that modification to the library itself are shared yet
> people can write applications using the library and
> have the choice as to whether to open source their applications.
> 

Agreed.

> Ultimately whether the LLGPL does what it's supposed to
> will be up to a judge.  I sure hope it never comes to that.
> 

Nor do I. However, as it stands, the LLGPL is awfully ambiguous. Maybe it's 
time for a serious revision.




--