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 <[email protected]> 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 >
