usage of logback at Apache, WAS: [ RXTX library and ASL]

[Ceki Gulcu <ce...@qos.ch>]

Hello Emmanuel,

On few occasions we have met some resistance due to logback's LGPL
license. I personally find the terms of the LGPL quite reasonable. (Duck)
However, I should also say that I did not go to great lengths to study
it.

As I understand the LGPL, using logback's API in your code falls under
"work that uses the Library" and not "derivate work."

  5. A program that contains no derivative of any portion of the
  Library, but is designed to work with the Library by being compiled or
  linked with it, is called a "work that uses the Library". Such a work,
  in isolation, is not a derivative work of the Library, and therefore
  falls outside the scope of this License.

  However, linking a "work that uses the Library" with the Library
  creates an executable that is a derivative of the Library (because it
  contains portions of the Library), rather than a "work that uses the
  library". The executable is therefore covered by this License. Section
  6 states terms for distribution of such executables.

In any case, that's how I personally interpret LGPL's terms but I am
not a lawyer nor is English my mother-tongue. Moreover, my stake in
the matter is small compared to that of the ASF.

Note that logback is designed so that client code accesses logback
indirectly through an abstraction layer called SLF4J. SLF4J is
licensed under the MIT license. In other words, your (client) code
never needs to directly import logback classes, only MIT-licensed
SLF4J classes.

Thus, I would go as far as to speculate that there is a non-zero
probability that I/you/we/someone could get permission from ASF legal
to *ship* logback with Apache Directory as long as only the SLF4J
abstraction layer is used within Apache Directory, i.e. client code,
to access logback.

The SLF4J/logback MIT/LGPL combination may deserve special treatment
after all.

To answer your question, I'd first like to explore other approaches
before changing the license from LGPL to good old ASL. Hopefully, there
should be ways for LGPL and ASL code to cohabitate.

Emmanuel Lecharny wrote:
> 
> Incidentally, Ceki, this raise an issue with your new Logback library. 
> Any way for you to switch back to the 'old good' ASL license ?
> 
> Emmanuel

-- 
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch

---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only.  Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF.  See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

Re: usage of logback at Apache, WAS: [ RXTX library and ASL]

[Alex Karasulu <ak...@apache.org>]

The bottom line is we cannot ship logback so long as it is LGPL
even with the compatibility layer afforded with SLF4J.  Users will
have to download logback and integrate it themselves.

Logging should be simple but these issues are complicating things.
Why not just switch the license to ASL?

Alex

On 4/21/07, Ceki Gulcu <ce...@qos.ch> wrote:
>
>
> Hello Emmanuel,
>
> On few occasions we have met some resistance due to logback's LGPL
> license. I personally find the terms of the LGPL quite reasonable. (Duck)
> However, I should also say that I did not go to great lengths to study
> it.
>
> As I understand the LGPL, using logback's API in your code falls under
> "work that uses the Library" and not "derivate work."
>
>   5. A program that contains no derivative of any portion of the
>   Library, but is designed to work with the Library by being compiled or
>   linked with it, is called a "work that uses the Library". Such a work,
>   in isolation, is not a derivative work of the Library, and therefore
>   falls outside the scope of this License.
>
>   However, linking a "work that uses the Library" with the Library
>   creates an executable that is a derivative of the Library (because it
>   contains portions of the Library), rather than a "work that uses the
>   library". The executable is therefore covered by this License. Section
>   6 states terms for distribution of such executables.
>
> In any case, that's how I personally interpret LGPL's terms but I am
> not a lawyer nor is English my mother-tongue. Moreover, my stake in
> the matter is small compared to that of the ASF.
>
> Note that logback is designed so that client code accesses logback
> indirectly through an abstraction layer called SLF4J. SLF4J is
> licensed under the MIT license. In other words, your (client) code
> never needs to directly import logback classes, only MIT-licensed
> SLF4J classes.
>
> Thus, I would go as far as to speculate that there is a non-zero
> probability that I/you/we/someone could get permission from ASF legal
> to *ship* logback with Apache Directory as long as only the SLF4J
> abstraction layer is used within Apache Directory, i.e. client code,
> to access logback.
>
> The SLF4J/logback MIT/LGPL combination may deserve special treatment
> after all.
>
> To answer your question, I'd first like to explore other approaches
> before changing the license from LGPL to good old ASL. Hopefully, there
> should be ways for LGPL and ASL code to cohabitate.
>
> Emmanuel Lecharny wrote:
> >
> > Incidentally, Ceki, this raise an issue with your new Logback library.
> > Any way for you to switch back to the 'old good' ASL license ?
> >
> > Emmanuel
>
> --
> Ceki Gülcü
> Logback: The reliable, generic, fast and flexible logging framework for
> Java.
> http://logback.qos.ch
>
> ---------------------------------------------------------------------
> DISCLAIMER: Discussions on this list are informational and educational
> only.  Statements made on this list are not privileged, do not
> constitute legal advice, and do not necessarily reflect the opinions
> and policies of the ASF.  See <http://www.apache.org/licenses/> for
> official ASF policies and documents.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>