uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: [VOTE] Release Apache UIMA Ruta 2.2.0 RC5
Date Wed, 09 Apr 2014 19:05:24 GMT

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 :-)

> 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
>>>> 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

View raw message