[logback-user] Minimal library dependency for logback implementation of RequestLogImpl

Ralph Goers rgoers at apache.org
Wed Jan 28 07:15:20 CET 2009

On Jan 27, 2009, at 11:43 AM, Russell E Glaue wrote:

> Ceki Gulcu wrote:
>> Ralph Goers wrote:
>>> While Geronimo can use the SLF4J api, due to its licensing Logback  
>>> can
>>> only be an optional component for any Apache project. So you can
>>> expect that the default implementation used would be log4j.
>> Hello Ralph,
>> You are right. At present time the ASF considers LGPL to be in  
>> category
>> C (excluded licenses).
>> However, I think one could argue that as long as some Apache  
>> software,
>> say Geronimo, uses logback-classic via SLF4J, without ever linking
>> against logback-classic, LGPL restrictions on distribution do not  
>> apply.
>> I hope to eventually present this argument to legal at apache.
> I support this.
> I really think the line between APL and LGPL needs to be clean.
> Currently Apache just says No to LGPL.

This is not at all true. I have been following the legal-discuss list  
for years.  Apache projects may take advantage of LGPL'd components -  
such as Hibernate or Logback - as optional dependencies. Since SLF4J's  
license is completely compatible with the Apache license it is fairly  
easy to incorporate Logback with projects that choose to use SLF4J.  
However, a project such as Geronimo would need to ship with a  
different logging framework, such as JUL or Log4j as its default  
> But I am not seeing how including LGPL libraries in a distribution,  
> which only
> provides additional options, can be a problem. Especially as Ceki  
> says Logback
> code is actually implementing an interface with an APL license.
> The only thing to be careful of is that if there are any derived  
> works from the
> LGPL libraries, that the code is probably contributed to the LGPL  
> licensed work
> instead of the APL licensed work.

This isn't really correct. The LGPL isn't really viral like the GPL  
is. The only requirement is that any enhancements, improvements, etc.  
to the library must also be licensed under the LGPL. One additional  
restriction that isn't in the Apache license is that those  
enhancements, etc must also be available so that anyone using the  
modified version of the library can
> So if I want to contribute some code to Geronimo which the code  
> actually is a
> derived work of Logback libraries, I should contribute it to Logback  
> and then
> put in a request to upgrade the Logback libraries in Geronimo so  
> that support
> exists there.

Yes, if it is an enhancement to Logback it should reside with Logback,  
not in the ASF. To me, that makes sense regardless of the license.
> And this answer a previous question of where to commit the GBean  
> implementation
> of the Logback Jetty RequestLogImpl for Geronimo. We should  
> contribute it to
> Logback for inclusion in release X, then lobby Geronimo to support  
> release X of
> Logback.

If GBean's are a Geronimo construct (I am unfamiliar with Geronimo)  
and the GBean in question just allows Logback's configuration to be  
dynamically updated I see no reason why this can't reside with  
Geronimo, unless it needs to modify existing Logback classes.


More information about the Logback-user mailing list