|
|
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 (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. |
|
Subject:
Re: Using LGPL code for commercial application
Answered By: maniac-ga on 08 Dec 2004 18:44 PST Rated: |
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 | |
| |
|
sboisvert-ga
rated this answer:
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. |
If you feel that you have found inappropriate content, please let us know by emailing us at answers-support@google.com with the question ID listed above. Thank you. |
Search Google Answers for |
Google Home - Answers FAQ - Terms of Service - Privacy Policy |