ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: LGPL in 1.4 examples
Date Wed, 30 Sep 2015 12:14:21 GMT
On Wed, Sep 30, 2015 at 10:49 AM, Branko ─îibej <brane@apache.org> wrote:

> On 30.09.2015 10:30, Dmitriy Setrakyan wrote:
> > On Wed, Sep 30, 2015 at 9:45 AM, Branko ─îibej <brane@apache.org> wrote:
> >
> >> On 30.09.2015 09:29, Dmitriy Setrakyan wrote:
> >>> On Wed, Sep 30, 2015 at 8:25 AM, Sergey Kozlov <skozlov@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.
>

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message