Igniters,
I just downloaded the ignite 1.4 zip from the website and the example project does not build for me out of the box. The reason is that LGPL dependencies are not included into the POM file. This is a serious usability issue. Am I doing something wrong? D. |
On Wed, Sep 30, 2015 at 4:10 AM, Dmitriy Setrakyan <[hidden email]>
wrote: > Igniters, > > I just downloaded the ignite 1.4 zip from the website and the example > project does not build for me out of the box. > > The reason is that LGPL dependencies are not included into the POM file. > This is a serious usability issue. Am I doing something wrong? > > D. > I confirm that build from fabric binary package is failed: [INFO] ------------------------------------------------------------------------ [INFO] Building ignite-examples 1.4.0 [INFO] ------------------------------------------------------------------------ [WARNING] The POM for org.apache.ignite:ignite-hibernate:jar:1.4.0 is missing, no dependency information available [WARNING] The POM for org.apache.ignite:ignite-schedule:jar:1.4.0 is missing, no dependency information available -- Sergey Kozlov |
I filed the ticket:
Build examples failed from binary fabric package <https://issues.apache.org/jira/browse/IGNITE-1579> On Wed, Sep 30, 2015 at 9:06 AM, Sergey Kozlov <[hidden email]> wrote: > > > On Wed, Sep 30, 2015 at 4:10 AM, Dmitriy Setrakyan <[hidden email]> > wrote: > >> Igniters, >> >> I just downloaded the ignite 1.4 zip from the website and the example >> project does not build for me out of the box. >> >> The reason is that LGPL dependencies are not included into the POM file. >> This is a serious usability issue. Am I doing something wrong? >> >> D. >> > > I confirm that build from fabric binary package is failed: > > [INFO] > ------------------------------------------------------------------------ > [INFO] Building ignite-examples 1.4.0 > [INFO] > ------------------------------------------------------------------------ > [WARNING] The POM for org.apache.ignite:ignite-hibernate:jar:1.4.0 is > missing, no dependency information available > [WARNING] The POM for org.apache.ignite:ignite-schedule:jar:1.4.0 is > missing, no dependency information available > > -- > Sergey Kozlov > > -- Sergey Kozlov GridGain Systems www.gridgain.com |
On Wed, Sep 30, 2015 at 8:25 AM, Sergey Kozlov <[hidden email]> 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? > > > On Wed, Sep 30, 2015 at 9:06 AM, Sergey Kozlov <[hidden email]> > wrote: > > > > > > > On Wed, Sep 30, 2015 at 4:10 AM, Dmitriy Setrakyan < > [hidden email]> > > wrote: > > > >> Igniters, > >> > >> I just downloaded the ignite 1.4 zip from the website and the example > >> project does not build for me out of the box. > >> > >> The reason is that LGPL dependencies are not included into the POM file. > >> This is a serious usability issue. Am I doing something wrong? > >> > >> D. > >> > > > > I confirm that build from fabric binary package is failed: > > > > [INFO] > > ------------------------------------------------------------------------ > > [INFO] Building ignite-examples 1.4.0 > > [INFO] > > ------------------------------------------------------------------------ > > [WARNING] The POM for org.apache.ignite:ignite-hibernate:jar:1.4.0 is > > missing, no dependency information available > > [WARNING] The POM for org.apache.ignite:ignite-schedule:jar:1.4.0 is > > missing, no dependency information available > > > > -- > > Sergey Kozlov > > > > > > > -- > Sergey Kozlov > GridGain Systems > www.gridgain.com > |
We can.
--Yakov 2015-09-30 10:29 GMT+03:00 Dmitriy Setrakyan <[hidden email]>: > On Wed, Sep 30, 2015 at 8:25 AM, Sergey Kozlov <[hidden email]> > 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? > > > > > > > > On Wed, Sep 30, 2015 at 9:06 AM, Sergey Kozlov <[hidden email]> > > wrote: > > > > > > > > > > > On Wed, Sep 30, 2015 at 4:10 AM, Dmitriy Setrakyan < > > [hidden email]> > > > wrote: > > > > > >> Igniters, > > >> > > >> I just downloaded the ignite 1.4 zip from the website and the example > > >> project does not build for me out of the box. > > >> > > >> The reason is that LGPL dependencies are not included into the POM > file. > > >> This is a serious usability issue. Am I doing something wrong? > > >> > > >> D. > > >> > > > > > > I confirm that build from fabric binary package is failed: > > > > > > [INFO] > > > > ------------------------------------------------------------------------ > > > [INFO] Building ignite-examples 1.4.0 > > > [INFO] > > > > ------------------------------------------------------------------------ > > > [WARNING] The POM for org.apache.ignite:ignite-hibernate:jar:1.4.0 is > > > missing, no dependency information available > > > [WARNING] The POM for org.apache.ignite:ignite-schedule:jar:1.4.0 is > > > missing, no dependency information available > > > > > > -- > > > Sergey Kozlov > > > > > > > > > > > > -- > > Sergey Kozlov > > GridGain Systems > > www.gridgain.com > > > |
On Wed, Sep 30, 2015 at 9:34 AM, Yakov Zhdanov <[hidden email]> wrote:
> We can. > I am currently at ApacheCon. Let me ask a few folks. I will respond here soon. > > --Yakov > > 2015-09-30 10:29 GMT+03:00 Dmitriy Setrakyan <[hidden email]>: > > > On Wed, Sep 30, 2015 at 8:25 AM, Sergey Kozlov <[hidden email]> > > 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? > > > > > > > > > > > > > On Wed, Sep 30, 2015 at 9:06 AM, Sergey Kozlov <[hidden email]> > > > wrote: > > > > > > > > > > > > > > > On Wed, Sep 30, 2015 at 4:10 AM, Dmitriy Setrakyan < > > > [hidden email]> > > > > wrote: > > > > > > > >> Igniters, > > > >> > > > >> I just downloaded the ignite 1.4 zip from the website and the > example > > > >> project does not build for me out of the box. > > > >> > > > >> The reason is that LGPL dependencies are not included into the POM > > file. > > > >> This is a serious usability issue. Am I doing something wrong? > > > >> > > > >> D. > > > >> > > > > > > > > I confirm that build from fabric binary package is failed: > > > > > > > > [INFO] > > > > > > ------------------------------------------------------------------------ > > > > [INFO] Building ignite-examples 1.4.0 > > > > [INFO] > > > > > > ------------------------------------------------------------------------ > > > > [WARNING] The POM for org.apache.ignite:ignite-hibernate:jar:1.4.0 is > > > > missing, no dependency information available > > > > [WARNING] The POM for org.apache.ignite:ignite-schedule:jar:1.4.0 is > > > > missing, no dependency information available > > > > > > > > -- > > > > Sergey Kozlov > > > > > > > > > > > > > > > > > -- > > > Sergey Kozlov > > > GridGain Systems > > > www.gridgain.com > > > > > > |
In reply to this post by dsetrakyan
On 30.09.2015 09:29, Dmitriy Setrakyan wrote:
> On Wed, Sep 30, 2015 at 8:25 AM, Sergey Kozlov <[hidden email]> 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. -- Brane |
Could we build these modules during building example project? It seems a
bit excessively from user standpoint. On Wed, Sep 30, 2015 at 10:45 AM, Branko Čibej <[hidden email]> wrote: > On 30.09.2015 09:29, Dmitriy Setrakyan wrote: > > On Wed, Sep 30, 2015 at 8:25 AM, Sergey Kozlov <[hidden email]> > 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. > > -- Brane > > -- Sergey Kozlov |
On 30.09.2015 10:28, Sergey Kozlov wrote:
> Could we build these modules during building example project? It seems a > bit excessively from user standpoint. Why do you think users are dumb and lazy and can't issue two build commands instead of one? > On Wed, Sep 30, 2015 at 10:45 AM, Branko Čibej <[hidden email]> wrote: > >> On 30.09.2015 09:29, Dmitriy Setrakyan wrote: >>> On Wed, Sep 30, 2015 at 8:25 AM, Sergey Kozlov <[hidden email]> >> 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. >> >> -- Brane >> >> > |
In reply to this post by Branko Čibej
On Wed, Sep 30, 2015 at 9:45 AM, Branko Čibej <[hidden email]> wrote:
> On 30.09.2015 09:29, Dmitriy Setrakyan wrote: > > On Wed, Sep 30, 2015 at 8:25 AM, Sergey Kozlov <[hidden email]> > 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. 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. > > -- Brane > > |
In reply to this post by Branko Čibej
On Wed, Sep 30, 2015 at 10:30 AM, Branko Čibej <[hidden email]> wrote:
> On 30.09.2015 10:28, Sergey Kozlov wrote: > > Could we build these modules during building example project? It seems a > > bit excessively from user standpoint. > > Why do you think users are dumb and lazy and can't issue two build > commands instead of one? > Brane, users don't have to issue any build commands right now, they just import the POM file into IDE. I suggested some possible solutions in my other email, let's see what the community will choose. > > > > On Wed, Sep 30, 2015 at 10:45 AM, Branko Čibej <[hidden email]> wrote: > > > >> On 30.09.2015 09:29, Dmitriy Setrakyan wrote: > >>> On Wed, Sep 30, 2015 at 8:25 AM, Sergey Kozlov <[hidden email]> > >> 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. > >> > >> -- Brane > >> > >> > > > > |
On 30.09.2015 10:33, Dmitriy Setrakyan wrote:
> On Wed, Sep 30, 2015 at 10:30 AM, Branko Čibej <[hidden email]> wrote: > >> On 30.09.2015 10:28, Sergey Kozlov wrote: >>> Could we build these modules during building example project? It seems a >>> bit excessively from user standpoint. >> Why do you think users are dumb and lazy and can't issue two build >> commands instead of one? >> > Brane, users don't have to issue any build commands right now, they just > import the POM file into IDE. I suggested some possible solutions in my > other email, let's see what the community will choose. This is not a community decision. This is a legal decision. And it's already been made and is documented in ASF release policy, you've all seen read that page. -- Brane |
In reply to this post by dsetrakyan
On 30.09.2015 10:30, Dmitriy Setrakyan wrote:
> On Wed, Sep 30, 2015 at 9:45 AM, Branko Čibej <[hidden email]> wrote: > >> On 30.09.2015 09:29, Dmitriy Setrakyan wrote: >>> On Wed, Sep 30, 2015 at 8:25 AM, Sergey Kozlov <[hidden email]> >> 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 |
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 <[hidden email]> wrote: > On 30.09.2015 10:30, Dmitriy Setrakyan wrote: > > On Wed, Sep 30, 2015 at 9:45 AM, Branko Čibej <[hidden email]> wrote: > > > >> On 30.09.2015 09:29, Dmitriy Setrakyan wrote: > >>> On Wed, Sep 30, 2015 at 8:25 AM, Sergey Kozlov <[hidden email]> > >> 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 > > |
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 <[hidden email] > 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 <[hidden email]> wrote: > > > On 30.09.2015 10:30, Dmitriy Setrakyan wrote: > > > On Wed, Sep 30, 2015 at 9:45 AM, Branko Čibej <[hidden email]> > wrote: > > > > > >> On 30.09.2015 09:29, Dmitriy Setrakyan wrote: > > >>> On Wed, Sep 30, 2015 at 8:25 AM, Sergey Kozlov <[hidden email] > > > > >> 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 |
In reply to this post by Branko Čibej
On Wed, Sep 30, 2015 at 10:49 AM, Branko Čibej <[hidden email]> wrote:
> On 30.09.2015 10:30, Dmitriy Setrakyan wrote: > > On Wed, Sep 30, 2015 at 9:45 AM, Branko Čibej <[hidden email]> wrote: > > > >> On 30.09.2015 09:29, Dmitriy Setrakyan wrote: > >>> On Wed, Sep 30, 2015 at 8:25 AM, Sergey Kozlov <[hidden email]> > >> 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. > Got it. Thanks for the clarification! > > 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 > > |
In reply to this post by Branko Čibej
On Wed, Sep 30, 2015 at 10:46AM, Branko Čibej wrote:
> On 30.09.2015 10:33, Dmitriy Setrakyan wrote: > > On Wed, Sep 30, 2015 at 10:30 AM, Branko Čibej <[hidden email]> wrote: > > > >> On 30.09.2015 10:28, Sergey Kozlov wrote: > >>> Could we build these modules during building example project? It seems a > >>> bit excessively from user standpoint. > >> Why do you think users are dumb and lazy and can't issue two build > >> commands instead of one? > >> > > Brane, users don't have to issue any build commands right now, they just > > import the POM file into IDE. I suggested some possible solutions in my > > other email, let's see what the community will choose. > > > This is not a community decision. This is a legal decision. And it's > already been made and is documented in ASF release policy, you've all > seen read that page. Yeah, seriously. This comes back like a clock-works.... |
Free forum by Nabble | Edit this page |