www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gulcu <c...@qos.ch>
Subject Re: LGPL software behind an isolation layer
Date Wed, 16 Sep 2009 20:46:16 GMT
Hello Luigi,

Thank you for your post. If I may selectively quote you and freely
edit:

-- 
Given:

1) A java library called logback licensed under LGPL 2.1.

2) Logback implementing an interface called SLF4J, licensed under the
MIT license. Logback being implementation among many others of the
SLF4J API.

3) Let FooCorp be a company and Frobber be some software developed by
FooCorp. Frobber codes against the SLF4J API without ever directly
referencing logback.

My Question: Should Frobber be considered as derivate work (of
logback)?

Your Answer: If (logback) is not required for Frobber to operate as
expected (i.e., Frobber will work without (logback), or with an
equivalent different implementation of the MIT SLF4J), then it seems
reasonable that this is sufficiently arms-length, and a case could
probably be made that providing the source code for the SLF4J
implementation would satisfy the requirement.

--

I hope my editing was faithful to the original and corresponds to your
intent.

Your answer is interesting because although not from an official
representative of the FSF, it originates from a person close to that
organization, and also because it answers my original question about
whether Frobber is derivative work or not.

If Frobber is not derivative work, then LGPL requirements do not apply
to Frobber (as long as it remains non-derivative).

Best regards,

Luigi Bai wrote:
> Group,
> 
> My name is Luigi Bai; I'm a volunteer on the licensing@fsf.org mailing list. I 
> recently answered a query from Mr. Ceki Gülkü posing a hypothetical 
> situation, which I have attached to this email. He asked me for permission to 
> cross post the response to this list; I offered to do that myself so I'd be 
> available to answer any questions which arose.
> 
> After making that offer, I perused the list archives, and decided this thread 
> was the most likely reason for the question posed to us. If that's true, I'm 
> not sure my message below will be of much use; it's clear the participants 
> here are very familiar with the licenses involved and how they may or may not 
> interact. My interpretation below may or may not be consistent with the 
> consensus here. Keep in mind I can't speak officially for the FSF, only for 
> myself as a volunteer.
> 
> If my analysis is correct, Mr. Gülkü is attempting to convince the ASF or an 
> ASF project to include and propagate a library which is released in this case 
> under the LGPLv2.1.
> 
> First, the ASF might choose to include his (firm's) library in its project(s). 
> If I analyze the situation correctly, this is less of a license issue and 
> more of a philosophical issue. I will not argue the point either way. It's my 
> impression that ASF has rejected this option.
> 
> Second, Mr Gülkü and/or his firm can release the code under a dual license or 
> some more permissive license compatible with the goals and philosophy of the 
> ASF. They may or may not have considered the option; if they have, they may 
> have reasons why they've not chosen this route.
> 
> Third, because the library in question is an implementation of an API layer, 
> the project might choose to include by default a "stub" implementation of the 
> logging library, which, upon first execution, perhaps prompts the user to 
> download a "full" implementation, and perhaps present choices with license 
> terms and URLs. This is uncomfortably close to the Microsoft browser proposal 
> to the European Union, where users are prompted to download a browser when 
> they first install their operating system, so I hesitate to advance this, but 
> perhaps it's a workable compromise solution.
> 
> I'm happy to discuss my opinions on the effect of including this LGPLv2.1 
> library in various distributed applications. I'm not here to advocate a 
> particular position or course of action, just to provide information, if 
> that's valuable.
> 
> Thanks;
> Luigi Bai
> 
> --- Original Message ---
> Ceki,
> 
> As you know, we are a volunteer organization, and sometimes take a while to 
> respond to emails. My apologies for your wait on this question.
> 
> My first question would be: why is your company releasing (logback) under 
> LGPLv2.1 (is all the work copyrighted by your company)? What rights does this 
> license grant to users that your company finds important, and what 
> responsibilities do you expect your users to respect? Perhaps this might 
> provide guidance on how you interact with FooCorp.
> 
> In general, the LGPLv2.1 requires a "work that uses the Library" to
> allow reverse engineering to the extent necessary to debug the work's
> use of a modified Library. If (logback) is not required for Frobber to
> operate as expected (i.e., Frobber will work without (logback), or with an 
> equivalent different implementation of the MIT SLF4J), then it seems 
> reasonable that this is sufficiently arms-length, and a case could probably 
> be made that providing the source code for the SLF4J implementation would 
> satisfy the requirement. If on the other hand Frobber does not perform its 
> expected function without (logback) specifically, in other words if it relies 
> on a particular way that (logback) implements SLF4J, then it would more
> likely be considered a derivative work rather than a "work that uses the
> Library".
> 
> As an example, consider: A logging framework is expected to manage information 
> and error messages. The application generally should not care what happens to 
> those messages once they're emitted; whether they're discarded, sent to a 
> file, communicated via pager, etc., the program continues without change.
> 
> However, the logging framework /could/ perform a specific function such as 
> send a message over a bus (TCP, UDP, SMS, etc) or expect a response to 
> a "logging message". Some implementations (or only logback) of SLF4J may 
> include that capability. If Frobber depends on one or more of those specific 
> capabilities then it can more reasonably considered a derivative work of 
> (logback). It in effect "reaches over" the SLF4J API to require additional 
> specific capabilities from (logback).
> 
> These observations (and the explanatory terms) are my personal opinion as 
> guidelines to understanding the LGPLv2.1 and the rights and responsibilities 
> of individuals and companies who ship works incorporating Libraries released 
> under that license. This is not legal advice, and cannot substitute for a 
> lawyer analyzing the specific facts of your case in the appropriate 
> jurisdiction(s).
> 
>> [ceki@qos.ch - Thu Aug 27 06:55:02 2009]:
>>
>> Hello,
>>
>> I have previously asked a related question to the present
>> one. However, this one is significantly different. By the way, thank
>> you very much for your answer to my previous question.
>>
>> My company develops a java library called logback [1] which is
>> licensed under LGPL 2.1. Logback implements an interface called SLF4J
>> [2] which is licensed under the MIT license. Logback is merely one
>> implementation among many others of the SLF4J API.
>>
>> Let FooCorp be a company and Frobber be some software developed by
>> FooCorp. Frobber codes against the SLF4J API without ever
>> directly referencing logback. Can FooCorp distribute Frobber with an
>> unmodified version of logback (our LGPLed library). Does the LGPL
>> require FooCorp to allow users to reverse engineer Frobber for their
>> own use? Allow me to insist on the fact that usage of logback in
>> Frobber is isolated behind the SLF4J API.
>>
>> My question is then whether Frobber should or can be considered as
>> derivate work (of logback).
>>
>> Many thanks in advance for your response,
>>
>> [1] http://logback.qos.ch/
>> [2] http://www.slf4j.org/
>>
>>
>>
> --- Original Message ---
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
> 
> 

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

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


Mime
View raw message