[Artoolkit] Can I Use LGPL code for commercial application

这是一个比较普遍但又容易被忽略的问题。

From: http://answers.google.com/answers/threadview/id/439136.html

 

假设背景：

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

 

我的疑问：

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

 

---

 

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

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

 

结论就是“可以”，只是稍微需要点"技巧"。