> The problem I described influences not only binary tar ball, but also > binaries which is deployed on maven. We need to check them.
I checked GPL sentences to check whether we need eliminate LGPL files: http://www.gnu.org/licenses/gpl-faq.en.html#GPLCompatInstaller Quoting from the sentence: > I would like to bundle GPLed software with some sort of installation > software. Does that installer need to have a GPL-compatible license? > (#GPLCompatInstaller) > No. The installer and the files it installs are separate works. As a result, > the terms of the GPL do not apply to the installation software. I think the binary tar ball and maven is just a box and installer. Fortunately, the source code itself seems to be Apache License and Apache compatible licenses. It's strongly depend on what "Apache Products" means[2], but we can interpret that we don't need to eliminate LGPL files from tar ball and maven installer. I think we should we have a talk with legal team. I'll contact them. > [2] http://www.apache.org/legal/resolved.html#category-x >> WHICH LICENSES MAY NOT BE INCLUDED WITHIN APACHE PRODUCTS? >> * GNU LGPL 2, 2.1, 3 Thanks, - Tsuyoshi On Thu, May 19, 2016 at 5:39 PM, Tsuyoshi Ozawa <oz...@apache.org> wrote: >> so I'm thinking this is not a problem. We need to update the patch to > address the above comments. Especially, we need to investigate what > dependency is in binary tarball or not. > > The problem I described influences not only binary tar ball, but also > binaries which is deployed on maven. We need to check them. > > Thanks, > - Tsuyoshi > > On Thu, May 19, 2016 at 5:36 PM, Tsuyoshi Ozawa <oz...@apache.org> wrote: >> Quoting from offline discussion by Akira's comment: >> >> In HADOOP-12893, the LGPL2.1 dependencies are as follows: >> >>> Logback Core Module >>> jdiff >>> Javaassist >> They are not included in binary tarball. >> >>> FindBugs-jsr305 >> jsr305-3.0.0.jar is included in binary tarball. This is actually New >> BSD license. >> https://github.com/findbugsproject/findbugs/blob/3.0.0/findbugs/licenses/LICENSE-jsr305.txt >> >>> Data Mapper for Jackson >>> Xml Compatibility extensions for Jackson >> They are dual-licensed (ASLv2 and LGPL2.1) and users can use either of >> this. We are using ASLv2 by setting "jackson-core-asl" in pom.xml. >> >> so I'm thinking this is not a problem. We need to update the patch to >> address the above comments. Especially, we need to investigate what >> dependency is in binary tarball or not. >> >> Best, >> Akira >> >> On Thu, May 19, 2016 at 5:34 PM, Tsuyoshi Ozawa <oz...@apache.org> wrote: >>>> We used to say "the src tarball is the only official release artifact, the >>>> bin tarball and jars are only provided as a convenience", but I don't think >>>> we're actually allowed to do that. >>> >>> Yes, I know it's not useful for end users. I'd like to clarify the >>> problems we're facing here. >>> >>> Currently, our binary tar ball cannot be delivered under the Apache >>> License since it includes LGPL binary. Hence, IIUC, the binary >>> contains mixed license - LGPL and Apache Software License v2. >>> This mean, we may be hosting software which is NOT under the apache >>> license. It seems to be forbidden[1][2] for us. Apache Ignite solves >>> the problems well by providing Docker script and binary tar balls >>> without LGPL files. >>> >>> If we choose to release next version of Hadoop with the binary >>> release, we should fix HADOOP-12893 at the first. >>> >>> Yes, I'll review the patch. >>> >>> [1] http://www.apache.org/legal/resolved.html#licenses >>>> CAN ASF PMCS HOST PROJECTS THAT ARE NOT UNDER THE APACHE LICENSE? >>>> No. See the Apache Software Foundation licenses page for more details, and >>>> the Apache Software Foundation page for additional background. >>> >>> [2] http://www.apache.org/legal/resolved.html#category-x >>>> WHICH LICENSES MAY NOT BE INCLUDED WITHIN APACHE PRODUCTS? >>>> * GNU LGPL 2, 2.1, 3 >>> >>> [3] https://ignite.apache.org/download.html >>> >>> Best, >>> - Tsuyoshi >>> >>> On Wed, May 18, 2016 at 5:45 AM, Andrew Wang <andrew.w...@cloudera.com> >>> wrote: >>>> Re: src-only release >>>> >>>> The primary way people consume our artifacts is the binary tarball and more >>>> importantly the Maven artifacts. Our downstreams aren't going to integrate >>>> and test without Maven artifacts. Thus (unfortunately) I don't see a >>>> src-only release being very useful. >>>> >>>> We used to say "the src tarball is the only official release artifact, the >>>> bin tarball and jars are only provided as a convenience", but I don't think >>>> we're actually allowed to do that. >>>> >>>> On Tue, May 17, 2016 at 1:56 AM, Steve Loughran <ste...@hortonworks.com> >>>> wrote: >>>> >>>>> >>>>> > On 16 May 2016, at 02:43, Andrew Wang <andrew.w...@cloudera.com> wrote: >>>>> > >>>>> > Hi common-dev, >>>>> > >>>>> > We have a first cut of the L&N files on HADOOP-12893. Many thanks to >>>>> > Xiao >>>>> > Chen and Akira Ajisaka for doing the brunt of this work. However, full >>>>> ASF >>>>> > compliance will require a lot more Maven work. In the meanwhile, our >>>>> > releases are blocked. >>>>> > >>>>> > We're thinking about a "fix-and-iterate" approach, just to get the >>>>> > currently ongoing releases out the door. The intent is not to keep >>>>> kicking >>>>> > the can down the road. >>>>> > >>>>> > Since releases require a majority PMC vote, if a PMC member would -1 a >>>>> > release on these grounds, please speak up. Additional review help & >>>>> > particularly Maven wizardry is also always appreciated. >>>>> > >>>>> > Best, >>>>> > Andrew >>>>> >>>>> >>>>> >>>>> HADOOP-13154 covers a license-ish issue: a bit of S3AFilesystem is clearly >>>>> a cut and paste of the Amazon SDK. There's nothing directly wrong with >>>>> that, the SDK is ASF-licensed, we just need to call it out. In >>>>> HADOOP-13130 >>>>> I've cut the code out. >>>>> >>>>> >>>>> >>>>> BTW: does anyone know why the default reply is to sender and not list >>>>> anymore? That's really annoying. >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org >>>>> For additional commands, e-mail: common-dev-h...@hadoop.apache.org >>>>> >>>>> --------------------------------------------------------------------- To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
