I think we can follow current logic of splitting on java/java8/scala examples and new profile 'LGPL' where new module will be activated
On Wed, Sep 30, 2015 at 12:30 PM, Anton Vinogradov <avinogra...@gridgain.com > wrote: > I offer to split examples to 2 modules: > 'examples' and 'lgpl-examples'. > Ignite convenience binaries will contain only 'examples' project, but user > will have opportunity to download sources and using lgpl profile build > 'lgpl-examples'. > > On Wed, Sep 30, 2015 at 11:49 AM, Branko Čibej <br...@apache.org> wrote: > > > On 30.09.2015 10:30, Dmitriy Setrakyan wrote: > > > On Wed, Sep 30, 2015 at 9:45 AM, Branko Čibej <br...@apache.org> > wrote: > > > > > >> On 30.09.2015 09:29, Dmitriy Setrakyan wrote: > > >>> On Wed, Sep 30, 2015 at 8:25 AM, Sergey Kozlov <skoz...@gridgain.com > > > > >> wrote: > > >>>> I filed the ticket: > > >>>> Build examples failed from binary fabric package > > >>>> <https://issues.apache.org/jira/browse/IGNITE-1579> > > >>>> > > >>> I think the reason is that we do not upload Ignite LGPL integrations, > > >> e.g. > > >>> ignite-hiberbnate artifact to maven central. I don't see why we do > not, > > >>> because even though they depend on some LGPL-based code, the ignite > > >> module > > >>> itself is licensed under ASL. > > >>> > > >>> Can we upload these artifacts manually? > > >> We've been through this any number of times, yes? We cannot distribute > > >> (L)GPL dependencies. If you can't run a reasonable grid that doesn't > > >> depend on LGPL-licensed modules, then those modules are not "optional" > > >> by any reasonable definition. > > >> > > >> It's quite all right to have examples that require those modules; just > > >> tell users that if they want to run those examples, they'll have to > > >> build Ignite (or at least the LGPL dependencies) themselves. > > >> > > > > > > Hm... I thought that ignite-hibernate module could still be published > to > > > Maven because the module itself is licensed under ASL2.0 license. > > > > People keep misunderstanding the LGPL. You really should read it. The > > "module itself" cannot be licensed under ALv2. For example, this is > > LGPL2.1 section 5 paragraph 2: > > > > However, linking a "work that uses the Library" with the Library > > creates an executable that is a derivative of the Library (because > > it contains portions of the Library), rather than a "work that uses > > the library". The executable is therefore covered by this License. > > Section 6 states terms for distribution of such executables. > > > > > > In other words, as soon as you *build* something that is linked with > > LGPL, it's covered by the LGPL. The sources of the module can be ALv2, > > but the built module isn't. > > > > This is why ASF policy forbids mandatory (L)GPL dependencies and > > absolutely forbids releases containing (L)GPL code. And whilst the > > binaries we put on Maven aren't "releases", they must follow these > > policies. > > > > > If not, then we should not include these modules into the main set of > > > examples, primarily because there is no way for a user to build them > out > > of > > > the box. > > > > > > I see 2 solutions: > > > > > > 1. Remove modules that depend on LGPL from the examples altogether. > > > 2. Add a separate LGPL folder in examples, which will not be included > > into > > > the POM file with a special README explaining how to build them. > > > > > > Option 2 is acceptable. > > > > -- Brane > > > > > -- Sergey Kozlov
