Me too, on first read. Well worth the discussion, though.

On Thu, Sep 27, 2012 at 11:44 AM, Ulrich Stärk <[email protected]> wrote:
> 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]
>

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

Reply via email to