ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@apache.org>
Subject Re: LGPL in 1.4 examples
Date Wed, 30 Sep 2015 08:49:14 GMT
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.

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