uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Klügl <pklu...@uni-wuerzburg.de>
Subject Re: [VOTE] Release Apache UIMA Ruta 2.2.0 RC5
Date Wed, 09 Apr 2014 07:33:57 GMT
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 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
>>>>>
>>


Mime
View raw message