2009/10/29 Alexei Fedotov <alexei.fedo...@gmail.com>: > How does LGPL place restrictions on larger works?
The main issue is section 6 in LGPL, namely we would have to ensure that downstream users are allowed to reverse engineer the "derived works". So what does that really mean? LGPL defines linking to it with dynamic languages as "derived work", so IF you 'depend' on the LGPL library your work is "a derivative work" of that library. Therefor, the library owner places restrictions on how this combination may or may not be used. A typical scenario, 1. Apache Foo depends on LGPL library Bar. 2. Company XYZ creates a variant of Foo, licenses it commercially, still depending on Bar. 3. Company XYZ MUST now allow their product to be reverse engineered, to resolve issues of upgrading of Bar by XYZ's customers. 4. Hence we must place the same Section 6 restriction on Foo, which is against our policy. Many (not all) commercial licenses prohibits reverse engineering of the code, and Apache is all about allowing commercialization of our codebases. HTH And the reason we basically allow optional dependencies on LGPL work is because XYZ would then both have a choice. Such "optionality" also has a tendency to make the Foo codebase modular, allowing XYZ to make its own implementation of the troubled code. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
