www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <...@envoisolutions.com>
Subject Re: Apache's LGPL Policy
Date Wed, 10 Aug 2005 20:35:34 GMT
Martin Cooper wrote:

> On Wed, 10 Aug 2005, Ralph Goers wrote:
>> Dan Diephouse wrote:
>>> Next question: can I suggest that the policy be such that the ASF 
>>> allow hard LGPL dependencies, but that each project individually 
>>> should consider if its something that they want to do? I.e. HTTPD's 
>>> users and developers may not want to allow a hard dependency on an 
>>> LGPL library because of the above, but other projects such as Roller 
>>> may allow it.
>> I don't agree with this.  I believe Apache should be consistent 
>> across the board and I don't think that hard dependencies on an 
>> LGPL'd component should be allowed.  I hate to harp on this, but as 
>> an example Apache Agila (at least when I looked at it last month) 
>> would not function without Hibernate. Frankly, I think this should 
>> prohibit the project from making it out of incubator.  On the other 
>> hand, providing support for or allowing a framework such as Agila to 
>> be able to use Hibernate is a very good thing as many of its 
>> customers will want that.
> While I think this would be good in theory, I don't believe it's 
> practical or realistic. The problem is that this becomes a significant 
> make-work item for ASF projects. In the particular case of Hibernate, 
> that is well on its way to being a de facto standard for persistence, 
> and businesses are standardising on it. Therefore it makes sense for 
> ASF projects to depend on it. If the policy is that ASF projects 
> cannot do that, then the developers are forced to do perhaps 
> significant extra development just to meet the policy, when the users 
> of the project's software will in large part ignore all that extra 
> work and use Hibernate anyway.
Agreed. Not to mention it pushes good projects away from the ASF.

Like I said in my previous post, if the LGPL dependency really ends up 
being an issue to the vendor, they can help influence the decision to 
use another library. This way the cost of using a different library can 
be weighed against the cost of using the LGPL library.  Prohibiting hard 
dependencies on LGPL libraries is in essence saying that the cost of 
using the LGPL library will always be more than rewriting or using a 
different one is, IMO, not true.
- Dan

Dan Diephouse
Envoi Solutions LLC

DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

View raw message