Hmm, yes. Makes sense if read that way. I assumed component = tapestry-hibernate

Uli

On 27.09.2012 16:25, Bob Harner wrote:
> My "degree of dependence" phrase is a summarization of the key point
> at the link you cited,
> http://www.apache.org/legal/resolved.html#optional
> 
> Let me paste that text here, with our specific terms inserted [in brackets]:
> 
> --- start of quote ---
> Can Apache projects [e.g. Tapestry Project] rely on components [e.g.
> Hibernate] whose licensing affects the Apache product [e.g. Tapestry]?
> 
> Apache projects [Tapestry Project] cannot distribute any such
> components [Hibernate]. However, if the component [Hibernate] is only
> needed for optional features, a project [Tapestry Project] can provide
> the user with instructions on how to obtain and install the
> non-included work [Hibernate]. Optional means that the component
> [Hibernate] is not required for standard use of the product [Tapestry]
> or for the product [Tapestry] to achieve a desirable level of quality.
> The question to ask yourself in this situation is:
> 
>     "Will the majority of users want to use my product [Tapestry]
> without adding the optional components [Hibernate]?"
> --- end of quote ---
> 
> When I read it that way I don't see any problem. Remember, "component"
> in that text refers to Hibernate, *NOT* Tapestry-hibernate.
> 
> 
> On Thu, Sep 27, 2012 at 8:02 AM, Ulrich Stärk <[email protected]> wrote:
>> On 27.09.2012 12:58, Bob Harner wrote:
>>> I think you might be over-thinking this. By your interpretation, we can't
>>> distribute the tapestry-hibernate module source because of its high degree
>>> of dependence on a 3rd party LGPL-licensed software. But then we *could*
>>> distribute that same code if we moved it into Tapestry-core (because
>>> Tapestry-core *doesn't* have a high degree of dependence on Hibernate. That
>>> strikes me as bizarre.
>>
>> Where did I say anything about "degree of dependence"? The policy is quite 
>> simple: No GPL- and
>> LGPL-depdendent components in your distribution. But if you absolutely want 
>> to have such a
>> component, make it optional and provide the users with instructions on how 
>> to obtain it but don't
>> put it into your distribution.
>>
>>>
>>> I'd bet lots of other Apache projects are distributing such integration
>>> modules and not losing sleep over it.
>>
>> They probably should because they run the risk of having their whole product 
>> infected by the license
>> of the optional component. By factoring out the integration code this risk 
>> is mitigated. And yes,
>> even the LGPL is copyleft in some cases.
>>
>> It's definitely something we should discuss.
>>
>> Uli
>>
>>> On Sep 27, 2012 5:25 AM, Ulrich Stärk <[email protected]> wrote:
>>>
>>>> Folks,
>>>>
>>>> I just reviewed the ASFs policy on including/linkting to software with
>>>> incompatible licenses (e.g. GPL/LGPL) [1]. If my reading is right, we are
>>>> OK to do that as long as the components depending on incompatible stuff
>>>> are not part of our official distribution. So a binary tapestry-hibernate
>>>> jar is OK since the binaries are not part of our official distribution,
>>>> only the source is. This means however, that we are not allowed to include
>>>> sources for modules that depend on software with incompatible licenses in
>>>> our official distribution, which we are currently doing, e.g. with
>>>> tapestry-hibernate.
>>>>
>>>> What we need to do is
>>>>
>>>> 1. check the licenses of all dependencies and see if they are incompatible
>>>> to the ASL
>>>> 2. remove the affected modules from the source distribution and replace
>>>> them with instructions on how to obtain them
>>>>
>>>> Uli
>>>>
>>>> [1] http://www.apache.org/legal/resolved.html#optional
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to