Google Answers Logo
View Question
Q: Using LGPL code for commercial application ( Answered 5 out of 5 stars,   0 Comments )
Subject: Using LGPL code for commercial application
Category: Computers > Programming
Asked by: sboisvert-ga
List Price: $20.00
Posted: 06 Dec 2004 18:55 PST
Expires: 05 Jan 2005 18:55 PST
Question ID: 439136
The LGPL ( 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

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.
Subject: Re: Using LGPL code for commercial application
Answered By: maniac-ga on 08 Dec 2004 18:44 PST
Rated:5 out of 5 stars
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).

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

general statements of license and compliant situations.
Q&A with both Richard Stallman (FSF Founder) & Eben Moglen (FSF General Counsel)
Scroll down - commentary about use of a defined API does not
contaminate proprietary modules used in Linux (a GPL system).
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
indicates that you are producing a "derivative work" of the code in
the library. In the United States the US Copyright Office states at
  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:
an article by Lawrence Rosen on derivative works [registration
required] plus a long series of comments by readers.
another long series of comments on the GPL / LGPL, this time in
reference to an article published in the Financial Times earlier this
is a link to the original article.
Eban Moglen's web site at Columbia University. Has a number of
articles you may find interesting.
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.
statement by the FSF on enforcing the GPL.
a good set of links - in particular, see the list of "external links"
that include in part:
an article by Pamela Jones who runs a legal site focusing on open /
free software issue
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

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.

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

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

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.

sboisvert-ga rated this answer:5 out of 5 stars and gave an additional tip of: $2.00
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.

There are no comments at this time.

Important Disclaimer: Answers and comments provided on Google Answers are general information, and are not intended to substitute for informed professional medical, psychiatric, psychological, tax, legal, investment, accounting, or other professional advice. Google does not endorse, and expressly disclaims liability for any product, manufacturer, distributor, service or service provider mentioned or any opinion expressed in answers or comments. Please read carefully the Google Answers Terms of Service.

If you feel that you have found inappropriate content, please let us know by emailing us at with the question ID listed above. Thank you.
Search Google Answers for
Google Answers  

Google Home - Answers FAQ - Terms of Service - Privacy Policy