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: Move log4cplus' license to ASL 2.0.
Date Tue, 11 Aug 2009 01:29:09 GMT

On Aug 10, 2009, at 9:30 AM, Ceki Gulcu wrote:

> Ralph Goers wrote:
>> On Aug 10, 2009, at 7:36 AM, Ceki Gulcu wrote:
>>> The only question is then about clients who repackage and republish
>>> Apache licensed software which happens to contain an LGPLed
>>> library. Why should the ASF protect clients who choose to *publish*
>>> their work under a closed license?
>> You've been a member here for years and you don't know the answer  
>> to that?
> I have to admit that I actually don't know the answer. Do you?

To start with,  http://www.apache.org/foundation/how-it-works.html#management 
  in the heading under "Philosophy". Of course, the second bullet  
point is embodied in http://www.apache.org/licenses/LICENSE-2.0.  
Allowing the LGPL as a requirement essentially negates the Apache  
license by placing restrictions on the use of our software that by  
itself wouldn't be there.

Is this really important?
See http://www.openhandsetalliance.com/android_faq.html and http://news.cnet.com/8301-13505_3-10229817-16.html

And in case you haven't attended an ApacheCon presentation on the  
subject take a look at http://docs.huihoo.com/apache/apachecon/us2007/apachecon2007us-asf-intro-paper.pdf

  and read the section on "Licensing Philosophy".  I'm sure there are  
many more presentations that say the same thing.

>>> I understand that the ASF does not wish to prevent software  
>>> companies
>>> from building commercial and closed-source products on top of Apache
>>> licensed software.  However, if an Apache project, say P, decides to
>>> rely on LGPLed software, say L, and if some software company, say C,
>>> decides to build a product on top of P, then that's C's problem not
>>> P's. Project P should be free to use L. Project P should only be
>>> required to clearly state that they use LGPLed software but that
>>> should be it. If company C still wishes to build a product on top of
>>> P, then that's C's problem not P's.
>> That would be a fundamental change in direction for the ASF. The  
>> position has always been that anyone can take an Apache project and  
>> do what they want with it without any real restrictions. Depending  
>> on the LGPL adds restrictions that violate that. See my other email  
>> for the specifics.
> Indeed. My understanding was that essentially the ASF was about
> meritocracy and collaborative development. Protecting (in contrast to
> allowing) closed-source development on top of our software is not a
> goal of the foundation, at least not as far as I know.

Again, see the Philosophy section. Apache is very much in favor of  
Apache software being used in embedded products or having IBM rename  
Geronimo as "Websphere Express" (or something like that), or having  
SpringSource sell its tc Server (Tomcat + Hyperic) or Day software  
sell CRX and on and on.  This freedom of use is largely what has made  
Apache software so successful in Enterprise organizations.

> > I do find it ironic that you are posting these questions here since
> > I've had this same discussion with you to get you to change the
> > license for Logback to something besides the LGPL. I am having to
> > sandbox the Appenders I am writing for Logback to insure they will
> > never be distributed outside my employer's doors.
> By licensing code under LGPL, my intention is not to force users to
> change their license of their software which uses LGPLed software.
> The LGPL requires the user to permit the reverse-engineering of
> portions of the LGPLed library. Depending on your interpretation, this
> requirement is limited to the usage of the library *or* to the whole
> of the combined work. If the former interpretation is retained, then
> it's an nop requirement. If you "just" use the library, you do not
> have to change your license or do anything specific in relation with
> LGPL. Note that this a very reasonable reading of the LGPL.
> The ASF chose a conservative reading of the reverse-engineering
> requirement. Even if that reading is correct and we will probably
> never know, ASF bending backward to accommodate and protect
> closed-source applications, is not necessarily the only path the
> foundation could have chosen as there are other reasonable paths
> available.
Ceki, Suppose a company uses SLF4J/Logback as their logging framework.  
As part of this lets suppose they develop a specialized logger based  
on LoggerWrapper that includes some proprietary objects. These then  
get passed through Logback to Appenders. First, any Appenders are  
derivative works so have to be LGPL (which is a problem). Second,  
presume that someone else comes along and wants to modify Logback in  
such a way that for some reason these LoggerWrappers no longer  
function properly. Under the LGPL they are entitled to go and inspect  
what these LoggerWrappers are doing (even though they are licensed  
under MIT) as well as the proprietary objects so that they can debug  
why their modifications don't work properly.

This is not just fantasy - it is actually a fairly common scenario. So  
we are not being extremists in taking this position.  It is why I've  
lobbied you so hard about changing the license for Logback. If you  
created your own license based on the LGPL without the debugging  
restrictions it would be a lot more acceptable.  However, I think  
using the LGPL as a "protection" to make sure contributions come back  
isn't based on reality. How many forks of Log4j were ever successful?


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

View raw message