www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: LGPL dependencies for JMeter
Date Fri, 01 Apr 2011 02:54:36 GMT
On 1 April 2011 03:23, Sam Ruby <rubys@intertwingly.net> wrote:
> On Thu, Mar 31, 2011 at 11:16 AM, sebb <sebbaz@gmail.com> wrote:
>> Sorry to bring this up again so soon, but the complicated thread about
>> Lucene/Solr has not dealt with the question we would like answered,
>> There are two proposed patches for JMeter, both of which use LGPL libraries.
>> * One is adding an AMF sampler, which would use Adobe Blaze - LGPL3
>> * Another adds a graphing visualiser using JChart2D - LGPL v2.1
>> Both would be strictly optional.
>> There are lots of samplers other than AMF, and many visualisers.
>> I think this meets the #optional criteria - and we would ensure that
>> JMeter still ran without the libraries present.
>> As far as I can make out, using reflection to link to LGPL is
>> acceptable, even if not exactly encouraged. And this would have no
>> effect on the build process.
>> Q1. Is it OK to provide LGPL glue code (source and binary) using reflection [1]?
>> Now the ASF developers (and particularly the RM) would need to
>> download the LGPL library in order to develop and test the glue code.
>> This suggests an alternative that might be easier to develop and
>> maintain, which is to build the glue code without using reflection.
>> Obviously, we would need to ensure that users could still build from
>> source without downloading the LGPL libraries. This is quite easy in
>> Ant.
>> Seems to me that this scenario is covered by the following section,
>> but I could be wrong:
>> http://www.apache.org/legal/resolved.html#prohibited
>> Q2. Is that an acceptable alternative to using reflection only?
>> [1] Obviously the glue code would not function without the library
>> present, but we would ensure that this only affected the particular
>> sampler or visualiser. This applies whether or not reflection is used.
> I don't see anything here that concerns me.


> First, an analogy.  We have "glue code" in httpd that allows the web
> server to be started and managed as an "NT Service".  This code is
> clearly Windows specific, and makes direct calls to a proprietary API.
>  Such code is not built or used on non-Windows platforms.
> If we are OK with "strictly optional" direct linkage in "glue code" to
> clearly proprietary APIs, I see absolutely no reason to disallow
> linkage to LGPL code.
> I'm taking you at your word that this is "strictly optional", that


> LGPL libraries are  downloaded separately, and most importantly that

Yes, they will be.

> this is "glue code".  One could try to sweep large amounts of
> functionality into the supposed "glue code" or make something that is

I expect that the classes that need to access the libraries will
contain quite a lot of calls to the library, as well as other code
needed by JMeter.

So it sounds as though it would be better to have separate glue
classes that deal purely with each library interface.
This would be a sensible idea anyway, as it should simplify handling
the case where the library is not present.

> "strictly optional" that something one epsilon away from 100% of the
> users of this software treat as essential.


> As long as you don't do anything like this you are fine.  Now, if the
> glue code is large or used by much more than 50% of your user base
> let's talk further.  As JMeter is an established project with existing
> users the latter seems unlikely.
> - Sam Ruby
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org

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

View raw message