Although it's definitely difficult to understand, it says "You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications", which sounds to me like you have to let users swap the library out, and you accept that they may reverse engineer to allow them to do so.
Section 4 d) (in the LGPL3 <https://www.gnu.org/licenses/lgpl.html>) also says that, assuming you don't want to distribute any source (option 0) then you must use a dynamic linking mechanism which uses a library already present on the user's system (option 1) which rules out a Java app shipping a library as a jar file with the main application. Either way, the fine detail is fairly moot since the uncertainty alone is enough to make most corporations (especially in the US) unwilling to risk it. If I were running a US corp I'd need to be really, really sure that I needed that library and that there were no viable alternatives and that I couldn't reimplement in order to risk it. In my last company no LGPL library ever made that cut. On 14 November 2013 16:46, John Gabriele <jmg3...@gmail.com> wrote: > On Wednesday, November 13, 2013 6:06:02 PM UTC-5, Colin Fleming wrote: > > > > I don't see why a company would have any problem at all with *using* > > > LGPL'd software, even in a product. However, I can see the possible > > > complaints if they wanted to *modify* it and then distribute their > modified > > > version (since that would then require distributing the modified source > > > along with it). > > At least one company (mine at the time) had a problem with using LGPL >> software because of the clause where you explicitly allow reverse >> engineering of your product in order to use a different version of the LGPL >> library. {snip} >> > > For what it's worth, I find that passage of the LGPL ("4. Combined Works") > somewhat difficult to understand. It *seems* to me that it's saying: > although your combined work may be non-free, > > * you can't restrict modification of the LGPL library contained therein, > and > * you can't restrict users from reverse engineering any modifications > you've made to the LGPL library contained therein. > > Where that 2nd point seems redundant to me, since, if you're distributing > a modified version of an LGPL'd lib, you're already required to also > distribute the modified source of it as well. > > -- John > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
