You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Dmitriy Setrakyan <ds...@apache.org> on 2015/03/28 22:31:24 UTC
[CLOSE] [VOTE] Apache Ignite 1.0.0 release
Understood. Valentin, can you please turn the lgpl flag off by default?
D.
On Sat, Mar 28, 2015 at 12:32 PM, Konstantin Boudnik <co...@apache.org> wrote:
> On Sat, Mar 28, 2015 at 08:23PM, Branko Čibej wrote:
> > On 28.03.2015 15:51, Dmitriy Setrakyan wrote:
> > > On Sat, Mar 28, 2015 at 1:00 AM, Branko Čibej <br...@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.
>
> You right of course - thanks of re-iterating this again: I totally missed
> the
> point of _implicit_ changes in the distribution rights in this case.
> Hence, it
> would be a disservice to the project user if such thing is possible.
>
> Yes - let's deactivate these profiles by default, hence someone will have
> to
> make an effort to turn them during the build.
>
> Cos
>
> > 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
> >
>
Re: [CLOSE] [VOTE] Apache Ignite 1.0.0 release
Posted by Dmitriy Setrakyan <ds...@apache.org>.
Thanks, Valentin. I have made some minor changes to the devnotes. Will send
another release for a vote soon.
D.
On Sat, Mar 28, 2015 at 5:59 PM, Valentin Kulichenko <
valentin.kulichenko@gmail.com> wrote:
> I pushed the fix - now LGPL dependencies are excluded by default. I added
> commands for both build options to DEVNOTES (Dima, please review the text
> and fix if you think it's needed).
>
> --
> Val
>
> On Sat, Mar 28, 2015 at 2:31 PM, Dmitriy Setrakyan <ds...@apache.org>
> wrote:
>
> > Understood. Valentin, can you please turn the lgpl flag off by default?
> >
> > D.
> >
> > On Sat, Mar 28, 2015 at 12:32 PM, Konstantin Boudnik <co...@apache.org>
> > wrote:
> >
> > > On Sat, Mar 28, 2015 at 08:23PM, Branko Čibej wrote:
> > > > On 28.03.2015 15:51, Dmitriy Setrakyan wrote:
> > > > > On Sat, Mar 28, 2015 at 1:00 AM, Branko Čibej <br...@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.
> > >
> > > You right of course - thanks of re-iterating this again: I totally
> missed
> > > the
> > > point of _implicit_ changes in the distribution rights in this case.
> > > Hence, it
> > > would be a disservice to the project user if such thing is possible.
> > >
> > > Yes - let's deactivate these profiles by default, hence someone will
> have
> > > to
> > > make an effort to turn them during the build.
> > >
> > > Cos
> > >
> > > > 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
> > > >
> > >
> >
>
Re: [CLOSE] [VOTE] Apache Ignite 1.0.0 release
Posted by Valentin Kulichenko <va...@gmail.com>.
I pushed the fix - now LGPL dependencies are excluded by default. I added
commands for both build options to DEVNOTES (Dima, please review the text
and fix if you think it's needed).
--
Val
On Sat, Mar 28, 2015 at 2:31 PM, Dmitriy Setrakyan <ds...@apache.org>
wrote:
> Understood. Valentin, can you please turn the lgpl flag off by default?
>
> D.
>
> On Sat, Mar 28, 2015 at 12:32 PM, Konstantin Boudnik <co...@apache.org>
> wrote:
>
> > On Sat, Mar 28, 2015 at 08:23PM, Branko Čibej wrote:
> > > On 28.03.2015 15:51, Dmitriy Setrakyan wrote:
> > > > On Sat, Mar 28, 2015 at 1:00 AM, Branko Čibej <br...@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.
> >
> > You right of course - thanks of re-iterating this again: I totally missed
> > the
> > point of _implicit_ changes in the distribution rights in this case.
> > Hence, it
> > would be a disservice to the project user if such thing is possible.
> >
> > Yes - let's deactivate these profiles by default, hence someone will have
> > to
> > make an effort to turn them during the build.
> >
> > Cos
> >
> > > 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
> > >
> >
>