On Sunday 14 Aug 2005 03:25, Anders Johansson wrote:

On Saturday 13 August 2005 22:20, François Pinard wrote:

...

The essence is, you may not be attached by someone through GPL'ed software, and you may not use GPL'ed software to attach clients.

This I didn't understand.

I think François meant "attached" in the support/maintenance/upgrade sense - the GPL effectively makes it impossible for an application or OS vendor to "lock you in" to their system. Having the source means you can choose as any time to ask another third party to take on development or maintenance. With closed source you are reliant on the vendor (or their vendors up the line or ....) to fix bugs and develop functionality.

What you cannot do is use GPL libraries in a non-GPL binary, or vice versa, the 'linking' clause of the GPL forbids it. This is why they wrote the LGPL

Which way does the LGPL work? Is it that closed source binaries can link against LGPL libraries, or that LGPL binaries can link to GPL libraries? Dylan -- "The man who strikes first admits that his ideas have given out." (Chinese Proverb)

Anders Johansson wrote:

On Sunday 14 August 2005 04:36, Dylan wrote:

...

I think François meant "attached" in the support/maintenance/upgrade sense - the GPL effectively makes it impossible for an application or OS vendor to "lock you in" to their system. Having the source means you

Ah, yes, that's true.

It also means to attach in the legal sense, ie. to place a legal restriction on something.

The main purpose of the LGPL is to allow non-GPL applications to use free libraries, such as glibc. When a library is licensed under the LGPL, anything can link to it, whether GPL, BSD or MSEULA (at least as far as the library license is concerned. The binary license may have other restrictions)

The LGPL says: "*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." Now, I am not a lawyer, but to me this means, so long as the compiled program is not linked to a LGPL library (whether compiled with it or not), it is not a derivative work, but as soon as it is so linked, whether statically or dynamically, it becomes a derivative work. Section 6 of the LGPL then requires the work to be open source. If Mozilla uses only ANSI C function calls but I compile with and link it to glibc, does that make it a derivative work? I don't think so, even though it will contain portions of the glibc code. A web browser is hardly substantially the same as a compiler library, but that is one of the prime legal requirements for something to be a derivative of something else. The LGPL would have us believe that the substantial additional functionality of Mozilla is insufficient to release it from the burden of being "derived from" glibc, that linking with glibc in and of itself suffices to make it so. That is patently ludicrous, even if Mozilla uses functions which exist nowhere outside glibc. The only relevant legal precedent I know of, from the Supreme Court of Canada, has held the opposite, that something cannot be a derivative work of something else unless the two are first and foremost "substantially the same" and that they cannot be substantially the same unless (amongst other things) they have the same or similar functionality and purpose. In short, you cannot force any licencing provisions on me simply because I use (or might use) your compiler and libraries to compile my source, even if I use function calls which exist nowhere outside your libraries (otherwise, <that company in Redmond> would be equally within its rights to say I may **not** open-source my code if it is possible to compile and link it with their compiler and libraries). I don't know about the rest of the WTO block, but AFAIK, Canadian copyright law is as close to the Berne Convention as you are liable to find. I believe US copyright law contains some pretty funky departures from the Berne Convention, and US courts have on occasion stepped even further away from that treaty, but I doubt relevant copyright law within the EU could be interpreted any differently from that in Canada. Vast tracts of real estate within the LGPL are seemingly on very shaky legal ground, and I would hesitate to suggest that anyone rely on the LGPL Section 5 for any purpose whatsoever, unless and until a few courts do a rather abrupt about-face. In their wisdom (I think), the authors of the LGPL have included paragraph 3 to section 5, which states: "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." Or, in other words, "what we just said in the previous paragraphs is what we want this thing to say, but we do not have a clue if we are even allowed to say it." Even more to the point, "we really do not have the slightest idea if the previous 2 paragraphs hold any legal water or not." Castrol would have a much better chance of telling me that I may not use their motor oil in a Ford.

Anders Johansson wrote:

On Monday 15 August 2005 07:11, Darryl Gregorash wrote:

...

Now, I am not a lawyer, but to me this means, so long as the compiled program is not linked to a LGPL library (whether compiled with it or not), it is not a derivative work, but as soon as it is so linked, whether statically or dynamically, it becomes a derivative work. Section 6 of the LGPL then requires the work to be open source.

Did you actually read section 6? It's long, but worth the read, and it does not require the full work to be open source

6. 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. The operative phrase here is "modification of the work" which means your stuff, not the LGPL library. OK, so you have a bit of an out here -- instead of having to produce the original source, you -may- instead simply give away the object code and all the necessary debug info so the customer can reverse engineer it. Sub-section a) in fact repeats the same statement in more precise language.

In their wisdom (I think), the authors of the LGPL have included paragraph 3 to section 5, which states: <snip>

No, that's not how I read it. You snipped a bit too early.

"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.)"

I read it as "even though it may be a derivative work under the legal definition, we are absolving you from any requirements you would have had under the full GPL" In fact, the LGPL does no such thing. Look again at what you quoted. Such a restricted use of the LGPL library makes the object file only unrestricted, but section 6 still applies to the linked executables, and

Legally, that seems still to fit the definition of "open source". that essentially requires I give away the ability to reverse engineer them, which again is still effectively and essentially (in law) the same thing as open source. Think on it, if what I say were not true, there would be no need for that escape clause in section 5, which merely states "this whole thing might not in fact be at all legal". If has, in fact, about as much legal validity as <that company in Redmond> trying to tell me I may not open source anything linked against their libraries (and if they tried that, you know you would hear the whole open source community crying "foul", or worse).