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 Tue, 08 Apr 2014 14:52:11 GMT

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