ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@apache.org>
Subject Re: [VOTE] Apache Ignite 1.0.0 release
Date Sat, 28 Mar 2015 19:23:06 GMT
On 28.03.2015 15:51, Dmitriy Setrakyan wrote:
> On Sat, Mar 28, 2015 at 1:00 AM, Branko ─îibej <brane@apache.org> wrote:
>> On 28.03.2015 06:41, Konstantin Boudnik wrote:
>>> On Fri, Mar 27, 2015 at 08:32PM, Dmitriy Setrakyan wrote:
>>>> (restarting a new vote for 1.0.0 after having fixed the LGPL issue that
>> was
>>>> raised during the previous vote today)
>>>> I have uploaded the new 1.0.0 release candidate to:
>>>>   http://people.apache.org/~dsetrakyan/incubator-ignite-1.0.0/
>>>> The following changes were made based on all the feedback I got for RC3:
>>>> 1. Added the ability to build a binary ZIP file without LGPL
>> dependencies.
>>>> 2. Fixed jdk8.backport wrong license issue.
>>>> 3. Fixed NOTICE.txt according to comments from IPMC.
>>>> 4. Fixed LICENSE.txt according to comments from IPMC.
>>>> To build a binary release from source run:
>>>>     # With LGPL dependencies
>>>>     mvn clean package -DskipTests
>>>>     # Without LGPL dependencies
>>>>     mvn clean package -DskipTests -P-lgpl,-examples
>>> Would it make sense to turn off 'lgpl' by default? Perhaps doesn't have
>> to be
>>> addressed until next release, unless a re-spin will happen.
>> These dependencies /have/ to be turned off by default, because otherwise
>> it's too easy to build binaries that are not ALv2. Especially if that
>> -P-lgpl is not documented anywhere.
> To my knowledge, the reason why LGPL is not allowed is because of its
> redistribution conflicts with ALv2. If users download the source code
> without LGPL in it, and then download the binaries for LGPL dependencies
> themselves during the build, then there is no redistribution of LGPL
> occurring and we should be OK. That's why the flag is turned on for the
> users by default.

But that's not the point. If someone builds a product using code
licensed under ALv2, they're allowed to distribute just the binary of
that product to users. If the product also contains LGPL components,
that's no longer true; they have to also make available the source code
for those components. Depending on the exact version of LGPL (there are
at least two of them in common use), there may be other constraints. So
including LGPL libraries in the binary build does indeed change the
distribution rights for those binaries in non-trivial ways.

Open-source licensing is an extremely complex area and I don't pretend
to know everything about it, but I do know it's a bad idea to try
second-guessing recommendations from people who have spent many years
working in the area.

> The flag to turn LGPL off is *only* for us, so we can build our own
> convenience binary which will be downloadable from the website. This binary
> cannot and will not have LGPL because of redistribution issues.

This assumption is incorrect, as per my comment above. By the principle
of least surprise, the default build should create a binary package that
can be distributed under the terms of the ALv2.

> Having said that, I simply wanted to explain our reasoning here. If you
> feel strongly about this issue and want us to resubmit the release for a
> vote with LGPL turned off by default, we can do that too.

It's not about my feeling strongly about anything; it's about an ASF
project not misleading our users.

-- Brane

View raw message