www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: [Jline-users] Windows ANSI colors patch
Date Wed, 08 Jul 2009 07:54:19 GMT

On Jul 7, 2009, at 11:29 PM, Niclas Hedhman wrote:

> On Wed, Jul 8, 2009 at 1:56 PM, Ralph  
> Goers<ralph.goers@dslextreme.com> wrote:
>> https://issues.apache.org/jira/browse/LEGAL-30, which is  
>> unresolved, asks
>> the question about bridge code to prohibited works. Frankly, it  
>> isn't clear
>> to me why that issue is still open and I think the answer you gave  
>> above is
>> wrong.
> Perhaps the "depends on your technical circumstances" disclaimer
> should have been more encompassing, but it still is largely depending
> on the actual case.
>>  https://issues.apache.org/jira/browse/LEGAL-18 discusses a plugin  
>> for
>> JBoss, which is licensed under the LGPL. We said that that was fine  
>> since it
>> is an optional component and the end user has obviously chosen  
>> JBoss (which,
>> of course, is licensed under the LPGL). Note that the referenced  
>> email
>> thread explicitly says the bridge code will reside within ServiceMix.
>> I see very little difference between this and an optional component  
>> that
>> makes use of an LGPL'd library. Just as in the ServiceMix case the  
>> LGPL'd
>> library will be required at compile time. The LPGL'd library cannot  
>> be
>> distributed with the project and must not be required for the  
>> project to run
>> in its default configuration.
> For the case at hand, it is unclear (at least to me) how the LGPL
> dependency comes into play. And I maintain that the ServiceMix case is
> Ok, due to "SMX plugin being a subpart of JBoss" whereas cases of
> JFreeChart "being a subpart of Apache Xyz" isn't Ok, even if that is
> 'optional'. The latter case quickly becomes a slippery slope...

I don't completely agree. In a project like Cocoon, which has many  
components that are mixed and matched, using JFreeChart might be OK  
since the vast majority of users could get by without it. However, in  
a spreadsheet project having JFreeChart as the only option, even if  
isn't enabled by default, most would argue that it is an essential  
part of the project and thus would be a problem. So yes, circumstances  
do come into play, but the policy could be worded to account for that.

>> LEGAL-30 should be resolved to say this and the resolved questions  
>> page
>> should clarify the use of the LGPL by changing the statement  
>> "Therefore,
>> LGPL-licensed works must not be included in Apache products." to an  
>> answer
>> such as "Therefore, Apache project must not distribute LGPL  
>> licensed works
>> or require an LGPL licensed work to perform functions essential to  
>> normal
>> operation. However, projects may use LGPL licensed works in optional
>> features that are not enabled by default".
> I think the real problem is the documentation requirement for said
> "enablement" of an optional feature. Another thing, I think, is that
> it is important that this doesn't become the 'norm' instead of the
> 'exception'. For instance, if a modular project (like ServiceMix) had
> most of its optional 'modules', then something about the Apache
> project is falling apart, isn't it?

Yes, the wording of the documentation is key, but not changing the  
documentation on the resolved page because we can't come up with the  
exact wording leads to the wrong results.

If "most" of the optional components of a project require incompatible  
licenses and the project as a whole I would again question what the  
project is about. But if a project like Maven had its core plugins  
completely under the Apache license but had many optional plugins that  
used other licenses, even if the number of them exceeded the number of  
Apache licensed plugins, I doubt there would be a problem. Yes,  
wording that might be awkward, but I don't think it is undoable.


To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

View raw message