On Sat, Mar 21, 2015 at 10:01 PM, Branko Čibej <br...@apache.org> wrote:
> http://www.apache.org/legal/resolved.html says, on the topic of GPL and > similar: > > Apache projects cannot distribute any such components. However, if > the component is only needed for optional features, a project can > provide the user with instructions on how to obtain and install the > non-included work. Optional means that the component is not required > for standard use of the product or for the product to achieve a > desirable level of quality. > > Given the above, why are we still discussing this? After further research, here's where I stand: * I'm not going to vote on Ignite's release candidates based on this issue. * I agree that that passage appears to grant permission for Apache products to offer non-core features implemented against GPL-only interfaces. * I question whether that interpretation was intended. LGPL libraries yes, GPL libraries no. (FWIW, we haven't even confirmed that Ignite implements against any GPL-only interfaces.) LEGAL-54, the issue where that language was formulated, discusses LGPL libraries and GPL build tools, but not GPL libraries. https://issues.apache.org/jira/browse/LEGAL-54 See also this message from Sam Ruby (Legal VP at the time) which differentiates between LGPL and GPL libraries: http://markmail.org/message/r4wbsivdlvwtoc5u Another issue discusses "optional" components including GPL libraries behind a generic interface: https://issues.apache.org/jira/browse/LEGAL-63 > When Subversion was incubating, 5 or so years ago, we went through the > same discussion regarding our dependency on Neon, even though it was > optional and Subversion works fine without any DAV plugin at all. > Subversion graduated while still having this (optional) dependency. All the discussion that I was able to find (the most important stuff was on private lists over a decade ago) talks about Neon as *LGPL*. > If you want to question Ignite's optional dependency on GPL code, you > should start by changing the published policy and making all TLPs throw > out such dependencies. > > Not gonna happen, right? I'm not going to go to the wall over this; I'm content to raise the point so that an interpretation I think may be faulty does not establish unchallenged precedent. The risks are low, I'm not an lawyer, and the case law on whether API usage even creates a derivative work is in flux -- see Google vs. Oracle and appeals. Please carry on. Marvin Humphrey --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
