On 4/9/2014 3:33 AM, Peter Klügl wrote: > Thanks, Marhsall. Overall, it is obious to me, but I probably got just a > bit upset yesterday that we did not get it right in the first place.
I think the license stuff is hard, and projects gradually figure out (climb learning curves) how to do this part better and better. I also think that part of the value of Apache projects is a certain high level confidence users feel in having the licensing / notices things well looked after :-) -Marshall > > I will create a new RC and take also a look again at the other jars if > there is something in their license files. > > Peter > > Am 08.04.2014 16:52, schrieb Marshall Schor: >> On 4/8/2014 3:40 AM, Peter Klügl wrote: >>> Am 07.04.2014 15:26, schrieb Marshall Schor: >>>> On 4/7/2014 8:29 AM, Peter Klügl wrote: >>>>> ... >>>>> Advice would be greatly appreciated. >>>> I looked at the license file in that jar and it seems to have a lot of >>>> additional licenses. So, one thing to do is to copy those licenses into >>>> the top >>>> level license file for your distribution. >>> That would be the engine plugin artifact. >>> >>>> Another thing to possibly do is to "filter" the Jar to remove the parts >>>> you're >>>> not using, and drop the notices/licenses for those parts (since the jar >>>> you'll >>>> be distributing won't have those). >>>> >>>> There are tools out there for figuring out what can be dropped, and doing >>>> the >>>> filtering - I don't have a link at this moment, but I remember coming >>>> across >>>> them when looking at Android packaging tooling. >>> I'd rather remove the complete dependency. It is only used in the addons >>> plugin in one view of the cde framework, but we actually have been >>> thinking about using more functionality in the future. This would cause >>> us to do the filtering each time. >>> >>> So, I will cancel the RC and create a new one with an extended LICENSE >>> file, right? >>> >>> Just to mention a reason why this did not happen before: >>> https://www.apache.org/dev/licensing-howto.html#alv2-dep >>> >>> <quote> >>> Bundling an Apache-2.0-licensed Dependency >>> Assuming once again that that the dependency subtree contains no bundled >>> subcomponents under other licenses and thus the ALv2 applies uniformly >>> to all files, there is no need to modify LICENSE. >> But this doesn't seem to be the case here. The dependency subtree (the Jar) >> presumably has something licensed under those other licenses (not Apache-2.0) >> included in their Jar? >>> If the dependency supplies a NOTICE file, its contents must be analyzed >>> and the relevant portions bubbled up into the top-level NOTICE file. >>> </quote> >>> >>> Reading this with the fact in mind that the dependency is a library >>> developed and released by ASF, one can easily think that the license >>> file does not need to be changed. Isn't there only one license for a >>> released artifact at ASF? >> Anytime we prepare convenience packaging that mixes work we do at the ASF >> (which >> is licensed under the Apache v2 license) and other artifacts licensed under >> other licenses (icons, etc.), we are releasing an artifact which has more >> than >> just the Apache v2 license. If others then incorporate our artifact, they >> have >> to deal with those other licenses and notices, too. >> >> This is something we need to consider when building artifacts. Sometimes, it >> not so great a concern if we bundle lots of other things having separate >> notice/files (although it makes it a bit more difficult for end-users to >> understand their obligations), but other times, for instance, if we expect >> other >> developers to take our work and build other products of their own, then it >> becomes more of a concern, because those other developers will be >> redistributing >> their works, and they have to then do a careful analysis of all the licenses >> and >> notices (much as we're having to do now ...). >> >> -Marshall >>> Peter >>> >>>> -Marshall >>>>> Best, >>>>> >>>>> Peter >>>>> >>>>>> -Marshall >>>>>> > >
