Re: [logback-user] Why LGPL instead of Apache License?
Ceki, What is the legal implication of using Logback through slf4j? Does this limit our obligations to slf4j's MIT license or does any aspect of logback's LGPL license pass through? Thank you, Gili Ceki Gulcu-2 wrote:
Hello Bruce,
The LGPL was chosen for a number of reasons. First, it is a relatively permissive license for those wishing to use logback as a logging library. Second, those who wish to extend logback can do so as long as they publish the results under the LGPL, a condition which I find quite reasonable. Third, the LGPL help to differentiate between log4j and logback as projects.
Moreover, given that logback is intended to be used behind the SLF4J API, client code does not come in direct contact with logback code. SLF4J is licensed under and MIT/X11 type of license. Thus, even organizations such the ASF which do not permit the use of LGPL licensed libraries, can use logback through SLF4J.
I hope this answers the question,
At 02:16 AM 12/27/2006, you wrote:
Log4J employs the Apache License and wound up being the inspiration for
the
entire Logging Project at the ASF, why was the LGPL chosen as the license to employ for Logback? --
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
-- View this message in context: http://www.nabble.com/Why-LGPL-instead-of-Apache-License--tp8058617p19112373... Sent from the Logback User mailing list archive at Nabble.com.
cowwoc wrote:
Ceki,
What is the legal implication of using Logback through slf4j? Does this limit our obligations to slf4j's MIT license or does any aspect of logback's LGPL license pass through?
Thank you, Gili
Pass through to what? Any application that uses SLF4J is not a derivative of Logback and isn't impacted by Logback's use of LGPL. OTOH, if you write your own Logback components those would be derivative works and would be impacted. Ralph
If my application is written against slf4j but I plug in logback at runtime as the logging implementation doesn't this somehow imply that my application is linking against logback and as such the LGPL applies? Gili Ralph Goers wrote:
cowwoc wrote:
Ceki,
What is the legal implication of using Logback through slf4j? Does this limit our obligations to slf4j's MIT license or does any aspect of logback's LGPL license pass through?
Thank you, Gili
Pass through to what? Any application that uses SLF4J is not a derivative of Logback and isn't impacted by Logback's use of LGPL. OTOH, if you write your own Logback components those would be derivative works and would be impacted.
Ralph _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
-- View this message in context: http://www.nabble.com/Why-LGPL-instead-of-Apache-License--tp8058617p19119217... Sent from the Logback User mailing list archive at Nabble.com.
If you are just using logback, then I don't think you have any obligations to begin with. The question is then distinguishing between "just using" from "extending". If you are accessing logback as a runtime implementation of SLF4J, then even under a conservative interpretation of LGPL, you are not linking with logback but with SLF4J. It follows that your "work in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License [LGPL]." As I see it, it is pretty clear that you are only "just using" logback and not extending it. Thus, accessing logback via SLF4J limits LGPL's protective (or viral depending on your point of view) properties so that it does not propagate to your application. I hope this answers your question, cowwoc wrote:
If my application is written against slf4j but I plug in logback at runtime as the logging implementation doesn't this somehow imply that my application is linking against logback and as such the LGPL applies?
Gili
-- Ceki Gülcü
Thanks for the clarification :) Gili Ceki Gulcu wrote:
If you are just using logback, then I don't think you have any obligations to begin with. The question is then distinguishing between "just using" from "extending". If you are accessing logback as a runtime implementation of SLF4J, then even under a conservative interpretation of LGPL, you are not linking with logback but with SLF4J. It follows that your "work in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License [LGPL]."
As I see it, it is pretty clear that you are only "just using" logback and not extending it. Thus, accessing logback via SLF4J limits LGPL's protective (or viral depending on your point of view) properties so that it does not propagate to your application.
I hope this answers your question,
cowwoc wrote:
If my application is written against slf4j but I plug in logback at runtime as the logging implementation doesn't this somehow imply that my application is linking against logback and as such the LGPL applies?
Gili
-- Ceki Gülcü _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
-- View this message in context: http://www.nabble.com/Why-LGPL-instead-of-Apache-License--tp8058617p19123387... Sent from the Logback User mailing list archive at Nabble.com.
participants (3)
-
Ceki Gulcu -
cowwoc -
Ralph Goers