www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Ruby <ru...@intertwingly.net>
Subject Re: LGPL dependencies for JMeter
Date Fri, 01 Apr 2011 02:23:44 GMT
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
this is "glue code".  One could try to sweep large amounts of
functionality into the supposed "glue code" or make something that is
"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


Mime
View raw message