Re: why LGPL 2.0?

[Douglas Ian Linder <linderdi cs curtin edu au>]

> Part of this is caused by the fact that GTK++ comes with LGPL version 
> 2, from June 1991.  This has some very confusing wording in section 
> 5, where the first paragraph says that a program that links with the 
> library is not a derivative work, and the second paragraph says that 
> a program that links with the library IS a derivative work.

This is a slightly long reply, but it covers what you're talking about...

Mmm.... if you read the license very carefully, section 5 is not what
you have to worry about, it's section 6...

(From 2.1)

  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.

[ Note: Such a work, IN ISOLATION, is not a derivative work... ]

  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.

[ Note: creates an executable THAT IS A DERIVATIVE of the Library... ]

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

[ Ie. If you use only the api calls, structures, macros and inline
  functions, the use of object code is unrestricted. ]

  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.

[ Note: IF the work is a derivative... ]

So, what does that come down to?

(A) - A work that is designed to work the Library (say GTK) is, in
      isolation, independent of this license. From the later paragraphs
      we note that this includes works that use the API, structures,
      macros, etc. of the library in question.

      The work, pre-compile, is totally independent of this license.

(B) - If the object code contains a significant portion of a header
      file from a library, the object code becomes a derivative of
      the library. If the executable is linked with the library, it
      becomes a derivative of the library.

      So...? Basically, under section (5) you're screwed. If you link
      with the GTK stuff, you form a derivative of the library and must
      release the source code, EVEN THOUGH the source code itself is
      not, when independent of the library, covered by the license.

  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.

[ "provided that the terms permit modification of the work for a 
  customer's own use and reverse engineering for debugging such
  modification." Note this. ]

[ Blah.. just note the last sentence of the next paragraph:
  "Also, you must do ONE of these things:" (Emphasis mine) ]

    a) Accompany the work with the complete corresponding
    machine-readable source code for the Library including whatever
    changes were used in the work (which must be distributed under
    Sections 1 and 2 above); and, if the work is an executable linked
    with the Library, with the complete machine-readable "work that
    uses the Library", as object code and/or source code, so that the
    user can modify the Library and then relink to produce a modified
    executable containing the modified Library.  (It is understood
    that the user who changes the contents of definitions files in the
    Library will not necessarily be able to recompile the application
    to use the modified definitions.)

[ This is a bit scary: A work as we've thought up before, which is
  only a derivative of the library as an executable, must be distributed
  along with the source for the library.
 
  However, "if the work is an executable linked with the Library,
  with the complete machine-readable "work that uses the Library",
  as object code and/or source source..." ]

    b) Use a suitable shared library mechanism for linking with the
    Library.  A suitable mechanism is one that (1) uses at run time a
    copy of the library already present on the user's computer system,
    rather than copying library functions into the executable, and (2)
    will operate properly with a modified version of the library, if
    the user installs one, as long as the modified version is
    interface-compatible with the version that the work was made with.

[ So... a shared library mechanism which satisfies (1) and (2). Not
  too hard. No requirement to distribute the object or source code
  of our work. ]

    c) Accompany the work with a written offer, valid for at
    least three years, to give the same user the materials
    specified in Subsection 6a, above, for a charge no more
    than the cost of performing this distribution.

    d) If distribution of the work is made by offering access to copy
    from a designated place, offer equivalent access to copy the above
    specified materials from the same place.

    e) Verify that the user has already received a copy of these
    materials or that you have already sent this user a copy.

[ Variations on a ]

  For an executable, the required form of the "work that uses the
Library" must include any data and utility programs needed for
reproducing the executable from it.  However, as a special exception,
the materials to be distributed need not include anything that is
normally distributed (in either source or binary form) with the major
components (compiler, kernel, and so on) of the operating system on
which the executable runs, unless that component itself accompanies
the executable.

[ This, is the annoying bit, but read it carefully. "anything this is
  normally distributed (in either source OR BINARY FORM) with the 
  major components (COMPILER, kernel, and so on) of the operating 
  system... "]

It comes down to this: if you have a work that uses the GTK library say,
the source code is not a derivative work, but the executable IS. So,
you have to distribute the executable with that in mind.

If you take option (B) from the list, you can happily just link to
what ever library the user happens to have installed given you satisfy
the requires of the shared library ((1) and (2)).

You simply have to distribute your program under the conditions: 
"the terms permit modification of the work for the customer's own
use and reverse engineering for debugging such modification."

Ie. None of this "You agree not to reverse engineer... " license
agreement stuff.

So, is there anything wrong? It all comes down to the last point. You MUST 
distribute the work in a form that includes the tools required to 
reproduce the executable, UNLESS those components come standard as 
distribution for the OS the program will run on. Not quite. Unless those
components come standard with -any of the major components of the OS-,
like the compiler.

For linux, unix, etc. this is fine, the OS comes with the compiler.
For windows, just think "Visual C". That is not a component of OS,
and yet, neither is the GCC, which goes with linux, but that counts.
"Visual C" is considered "the compiler" by the OS developer, and 
fully has a capability to reproduce the executable.

At least, this is the argument. Taking it to task opens doors as to
way GCC counts as part of the OS but visual C does not (sure, it's
-generally- distributed with the OS, but it is not an intrinsic 
part).

So all in all, if you use a shared library that already exists on 
the users computer (or distribute a copy of that library, make them
install that, then use it as such) your application can pretty much
ignore the terms of LGPL (like free distribution) with a mild
limitation.

BUT, most specifically, if you generate an executable which contains
the object code directly (static link), the whole thing will fall
under LGPL, no question. You don't want to do that.

> Also, if our attorney needs a written statement of approval from 
> someone clarifying that our intended use of GTK++ does not constitute 
> a derivative work, whom would we talk to about that?

Good luck...! Hope this (slightly long) post helped. To be honest
I doubt most people ever bother to read the license that well: it
just happens that you can follow the rule: "use shared libraries and 
we're fine", with no problem.

ciao!
Doug.