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@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 implementation.
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. Ralph