Niclas Hedhman wrote: > On Friday 01 September 2006 15:47, Nektarios K. Papadopoulos wrote: >>> Since FSF is still considering Java to trigger the viral behavior of LGPL >>> when you have a dependency through an import statement, ASF plays safe >>> and do not allow projects to have a direct binary dependency. >> IANAL, but according to http://www.gnu.org/licenses/lgpl-java.html it is >> safe to have a dependency through an import statement. The problem would >> be to link to GPL, *not* LGPL. >> Nevertheless, indeed ASF do not allow this, with the exceptions >> described in the link provided by Upayavira > > Mr Turner's statement is of course both accurate and misleading. > > Though the derived work may not be required to be LGPL'd, the LGPL requires > concession's in the downstream licenses that are not acceptable by the ASF, > i.e. someone making a commercial version of Felix and its constituents must > not be required to allow reverse-engineering of the codebase, which LGPL > require us to enforce on our downstream users. Hence the virality... > Therefor LGPL is listed as Excluded Licenses. > > <quote source="Cliff Schmidt" > > Inclusion within the product > YOU MUST NOT include any portion of a prohibited work within the Apache > product, whether or not that work is considered required or optional. > > YOU MAY include code within the Apache product necessary to achieve > compatibility with a prohibited work through the use of API calls, "bridge > code", or protocols, provided that the compatibility code was contributed > under a CLA. However, any such code used for compatibility with a > third-party work that is licensed under terms that violate criterion #2 > ("must not place restrictions on the distribution of independent works that > simply use or contain the covered work."), such as the GPL, requires review > and explicit approval of both the PMC chair and the Legal Affairs officer. > This review will ensure that the Apache product takes only the necessary > steps to achieve compatibility. > > YOU MAY ALSO include a feature within an Apache product that allows the > user to explicitly choose to download an optional third-party add-on, as > long as that feature also alerts the user of the associated license. > </quote> > > I interpret this as; > If JMood (I haven't checked) uses LGPL code that part shall not be part of > the > Felix project, irregardless if it is optional or not. And to be safe, the > Facade API reside in Felix (without the linking prohibited code) and the > implementation of that Facade resides elsewhere, e.g. SF. > > Any other use, I guess Cliff wants a say about it...
I don't see it /quite/ so strongly as that. If this charting component is optional (either the charting, or the entire Felix component), and the user has to consciously acknowledge its license before proceeding, that would be accepable, IMO. More acceptable would be using a charting component that doesn't add restrictions above and beyond those of the Apache License, if finding such a library was possible. As Niclas is trying to make clear above, it is worth noting that these restrictions are not about Apache just being difficult (although it sometimes seems like that) - it is about respecting and protecting our users and their freedom to use the code that we produce. I wonder if it is this thoroughness around licensing that has been largely responsible for the strength of the Apache brand. Regards, Upayavira
