The LGPL (http://www.gnu.org/copyleft/lesser.html) document is, at
best, confusing, hard to understand, and purposely obfuscated. It
doesn't provide a clear description of what's allowed and not allowed,
the specific requirements, or clear definitions of 'work that uses the
Library' and 'derivative of the Library' (2nd paragraph of section 5
of LGPL). Seems no one can afford a lawyer to decipher the text, and
the lack of any clear explanation/FAQ on the internet suggests the
license text is too generic to answer any of the specific FAQs that come up in
discussions.

So, I would like a clear, authoritative answer, and not simply
someone's "interpretation" of the license text, for the following
specific context:

Given the following...

- want to write a commercial (shareware) application; this is a mix of
Objective-C and C code
- want to use a library released under the LGPL; do not own the
library code, and will not modify the library code; will only use its
API and functions; assume a c, obj-c or c++ coded library
- want to keep commercial application closed-source (at least as much as possible)

...would like to know the following:

- can the LGPL library be used in a commercial application in the
context described above
- what are the implications of 
	a) statically linking the library to the application
	b) dynamically linking the library with the application
     with regards to distribution of the completed code
- how can the completed application/code be distributed (with or without the
library when linked dynamically? ie what's allowed/needed)
- what are the complete requirements to using the LGPL'ed library when
distributing the application (eg. attribution in documentation,
availability of original library source code, etc... what else?)

Extra points if you provide on/off-line (online preferred) references
that support the information provided in your answer and/or that
provide insights on the concerns listed above, and more if you can
provide a clear, easy to understand explanation of sections 5 & 6 of
the LGPL document (keeping in mind the above context), which seem to
simply contradict themselves.

Hello Sboisvert,

Let's go through your situation and describe the bounds by which you
can / cannot use an LGPL library to produce a commercial application.
If you have any further questions or need further clarification -
please indicate the LGPL library (libraries) you intend to use so I
can get a more definitive answer for that (those) specific product(s).

Situation:
Your own C / C++ source code using an unmodified LGPL library to
produce a commercial product (with closed source code) that you can
distribute to customers (for a fee).

Questions and Answers:
Q1: Can the LGPL library be used in that situation?
A1: Yes, if you comply with the license requirements. Note that much
of the license compliance is not in the building (or your use) of the
application but in the distribution [LGPL 9] of the LGPL library
[primarily] and your application [secondarily].

References:
  http://encyclopedia.thefreedictionary.com/Library+General+Public+License
  http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License
  http://c2.com/cgi/wiki?GnuLesserGeneralPublicLicense
general statements of license and compliant situations.
  http://www.spinics.net/lists/xf/msg02311.html
Q&A with both Richard Stallman (FSF Founder) & Eben Moglen (FSF General Counsel)
  http://www.linuxdevices.com/articles/AT2899063844.html
Scroll down - commentary about use of a defined API does not
contaminate proprietary modules used in Linux (a GPL system).
  http://www.rollerweblogger.org/page/roller/20030220#java_lgpl_clarification
Similar statement by Eban Moglen, this time for Java / jar files.

Q2a: What is the implication of static linking?
A2a: You need to comply with the license requirements. Eban Moglen in
  http://www.spinics.net/lists/xf/msg02311.html
indicates that you are producing a "derivative work" of the code in
the library. In the United States the US Copyright Office states at
  http://www.copyright.gov/circs/circ14.html
  A ?derivative work,? that is, a work that is based on (or derived
  from) one or more already existing works ... [copyright statements].
Both of those statements are pretty clear so section 6 of the LGPL
applies. Note that you can distribute (6a)
  ... [your work] 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
You can thus distribute object files (and protect your source code)
and still comply with the requirements of the LGPL.

However, others (in particular, Richard Stallman) does not necessarily
interpret the LGPL in this way. I strongly recommend you contact the
copyright holder prior to building a statically linked application for
distribution as a commercial product.

Q2b: What is the implication of dynamic linking?
A2b: That is pretty much up to you. You can decide to...
  - build the application (with your copies of the library),
distribute that application without the library and expect to have
users provide their own copy of the library. In this case - YOU are
not distributing the LGPL library and thus are not bound by the
distribution terms of the LGPL license.
  - build the application (with your copies of the library), and
distribute [or make available] two separate packages
    o your application (binaries only)
    o the matching LGPL library (binaries and source code)
In this case, I strongly suggest you clearly document what you did to
produce the LGPL library so [you and] others can reproduce it to
confirm your compliance with the LGPL terms. I also suggest you
distribute the two items separately so it is clear you are not
producing a "derived work" of the library.

If you are targeting for a specific system configuration (e.g., Fedora
Core 3), I suggest an approach like the first one since it is much
less likely to cause any possible problems with compliance. The second
one is more appropriate if you want to support a range of
configurations (and perhaps want to reduce support problems due to
"almost compatible" libraries).

Q3: How can the completed application be distributed?
A3: The answers to 2a and 2b should already answer this question. I
suggest a brief review of section 1 in the LGPL which allows you to
charge a fee for the physical act of making copies (of your
application and the LGPL library [if you choose to distribute it]).

Q4: What are the complete requirements when distributing the
application that uses the LGPL library?
A4: That depends on the way you build and distribute the application.
At a minimum I suggest:
 - disclose your use of the library and its license terms [LGPL 6]
 - IF you display a copyright notice for your code, include the
library copyright notice [LGPL 6]
 - choose one or more of the methods in LGPL 6 [a through e] 
 - do the steps I described in the answers to 2a or 2b to build /
distribute your application

If you expect to expend a considerable amount of work or funds in
producing such a proprietary product, I also recommend you get your
own lawyer to help interpret the language of the LGPL. You may find
the money well spent.

You may also consider writing your application to use a non LGPL
library (in addition to the LGPL library) to ensure compatibility with
the interface and is more clearly NOT a derived work of the library.

Other references you may find interesting:
  http://www.linuxjournal.com/article/6366
an article by Lawrence Rosen on derivative works [registration
required] plus a long series of comments by readers.
  http://lwn.net/Articles/108568/
another long series of comments on the GPL / LGPL, this time in
reference to an article published in the Financial Times earlier this
year.
  http://news.ft.com/cms/s/78d9812a-2386-11d9-aee5-00000e2511c8.html
is a link to the original article.
  http://emoglen.law.columbia.edu/
Eban Moglen's web site at Columbia University. Has a number of
articles you may find interesting.
  http://www.fsf.org/licenses/NYC_Seminars_Jan2004.html
the FSF has previously provided 2 day seminars on the GPL, LGPL, and
related topics. The last one was in August 2004 but I don't see any
currently planned.
  http://www.gnu.org/philosophy/enforcing-gpl.html
statement by the FSF on enforcing the GPL.
  http://www.thebestlinks.com/GNU_General_Public_License.html
a good set of links - in particular, see the list of "external links"
that include in part:
  http://www.groklaw.net/article.php?story=20031214210634851
an article by Pamela Jones who runs a legal site focusing on open /
free software issue
AND
  http://www.groklaw.net/article.php?story=20040725150736471
a translation (from German) of a court case enforcing the GPL and
establishing an injuction on the company infringing the license.

Search phrases to find more references:
  lgpl linking
  lgpl moglen linking
  lgpl linking proprietary
  copyright derivative work
  lgpl site:emoglen.law.columbia.edu

I realize you may have additional questions or need some points
clarified. I would be glad to respond to any clarification requests
you make on this issue.

Good luck with your product.
  --Maniac

---

Request for Answer Clarification by sboisvert-ga on 10 Dec 2004 19:12 PST

I would wish to distribute everything so as to not have to make
assumptions of what the user has installed or require the user to
install additional files seperately (ie. want to provide 'the whole
package')

I've just re-read section 7 of the LGPL and am wondering this:

Could I create my own library, which would be a derivative of the LGPL
library, designed to be a 'proxy' (or 'wrapper library') for access to
functions of the LGPL library, but this wrapper library would have its
own APIs which would be called from my application. I could then
release/distribute the wrapper library under an acceptable license,
while keeping the rest of the application closed.

Would that prevent me from having to release object code files for the
application, and only have to provide the sources for the wrapper
library, or would I be stuck in a recursive situation where my wrapper
library would have to be L/GPL and linked with my application,
returning me back to square one (ie. the 'viral' effect)?

---

Clarification of Answer by maniac-ga on 12 Dec 2004 20:02 PST

Hello Sboisvert,

The new library:
 - LGPL software
 - your API
would be considered a "derivative work" and the new library would then
be subject to the same compliance terms as the original software. That
does not mean the "new library" must be all LGPL software, just that
you comply with the LGPL license terms (to be able to distribute the
LGPL software in the new library). In particular, you either provide
all the source code or your object files and the LGPL source code.

I do not see how that particularly improves your situation with
respect to the main application. You could not do a static link to the
combined library (unless done by your customer from object files as
part of an automated install process) and the effort of a dynamic link
would be basically the same. The addition of your custom API does not
change much other than ruling out use of unmodified libraries already
installed on your customer's system. It may reduce [or increase?] some
follow up support calls, but I am not sure the effect would be
significant.

I don't see section 7 as providing any relief to the general
requirements in the preceeding license sections. Plus it adds some
additional requirements for compliance.

  --Maniac

Good explanations and excellent effort of answering an obviously
difficult answer. Provided good resources, though a lot were specific
to the GPL while the question was about the LGPL.