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 > >
