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 Thu, 11 Aug 2005 02:39:32 GMT
Craig McClanahan wrote:

>>I think you're going a little far - having the project ASL'd is still
>>very worthwhile. First, the ASF project can still be repackaged and used
>>commercially. They just can't relicense the LGPL library or sell JUST
>>the LGPL library for profit.  Second, portions of the code in the ASF
>>project might be reused in another proejct.  Third, at some later date
>>it might make sense to rip out the dependency and replace it with
>>another one which is more in line with the ASF line of thinking. That
>>just won't happen until it becomes worth it for the parties involved to
>>do so. Creating a policy which dictates otherwise forces unnecessary
>>cost on the project.
>>W.r.t companies which only allow anything from Apache:
>>1. IMO, they should develop a more comprehensive IP policy stating if
>>the LGPL is allowed
>I know of more than a few companies for which this answer is "no" in
>the general case (although some allow exceptions for certain uses).
I don't see any problem with a few companies saying no. At least there 
is a project or more functionality in an existing project that will 
serve some of the world, instead of no project or no additional 
functionality serving none of the world.

>>2. I don't think its as big of an issue as you make it out to be.
>>Companies are much more familiar and comfortable with open source these
>If a company that is familiar with open source licenses decides to
>take the "no" position on LGPL, what are they to make of an Apache
>project that has a dependency on that package?  From my experience,
>the tendency (especially from the legal staff) will be towards "that's
>more of the same, therefore the answer is no" ... without even trying
>to quibble over whether the dependency is "hard" or "soft".
Even if a project has two seperate distributions? I.e. a core which 
doesn't contain the LGPL jar and a plugin which they have to download 

>We either need to believe that the LPGL is OK and are ready to educate
>the world about that, or we need to believe that the LGPL is not OK
>and are ready to educate the world about that.  Equivocating here
>seems like a very un-Apache thing to do.
I say we educate the world. :-)

>>3. IF an LGPL library is included as a hard dependency we could create a
>>click-through acknowledgement on the download page so people would be
>>aware. In addition there should probably be a FAQ entry describing the
>>extra terms imposed by this library. (I will of course volunteer to help
>>in this area)
>Personally, I cannot *believe* anyone at Apache would ever consider a
>click-through license on our own software.  Kinda defeats the whole
>point of a BSD-ish license, doesn't it?
Agreed. Thats why I said acknowledgement instead of license. Maybe thats 
not the right way to do it, but I was just suggesting a way to make the 
end user *aware* that the distribution contained an LGPL jar as opposed 
to just the standard ASL licensed fare. Obviously we would never want to 
impose a click-through license.

>>>Now, I don't know who gets to vote on this policy change, but I know
>>>if my vote counted I would vote -1 on allowing hard dependencies on
>>>LGPL. I would prefer no LGPL as it is today to that.
>>>As far as the amount of work goes, today LGPL'd software cannot be
>>>used in Apache projects at all. So what I am suggesting is far less
>>>work than is required today.
>>>So while you may not consider it realistic or practical, it is far
>>>better than where we are today and yet continues to maintain how
>>>Apache is viewed by the outside world.  I consider that far more
>>I really don't like outside world benchmarks. If you're so concerned
>>about the outside world, there is a good portion of it that would
>>consider Apache ridiculous because projects can't use Hibernate.
>>Instead, we should go by what we determine to be legally sound and
>>- Dan
>Craig McClanahan
>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

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