www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Building ASL code requiring LGPL 3rd party
Date Wed, 30 Mar 2011 13:36:00 GMT
On 30 March 2011 14:28, Ralph Goers <ralph.goers@dslextreme.com> wrote:
> I'm not sure I'd know how to make it optional at build time by checking if the library
isn't present, although it may be possible. I was thinking in terms of requiring a Maven profile
to activate the portion of the build that includes the optional dependency.

This is getting OT, but in Ant one can check if a particular class is
present on the class path.
If Maven supports such a check then it could probably be used to
auto-activate the profile.

> Ralph
>
> On Mar 30, 2011, at 5:09 AM, sebb wrote:
>
>> Can you make the library optional at build-time? I.e. if the library
>> is not present, then don't build that part of the code.
>> That would allow users who don't want to download the dependency to
>> build from source.
>>
>> But that still leaves the issue of whether ASF releases can include
>> the compiled glue code in binary release artifacts, since that would
>> presumably require the developer to download the library.
>>
>> Seems this area does need some clarification, because it's difficult
>> to see how one can implement the #optional dependency, apart from
>> dependencies such as JDBC implementations which use an API that does
>> not have the restriction.
>>
>> On 30 March 2011 08:18, Ralph Goers <ralph.goers@dslextreme.com> wrote:
>>> Right.  I saw the optional at runtime but missed the required at build.  Indeed,
that is not specifically covered.  I have mixed feelings about this, and while I wouldn't
go so far as to say it is verboten I would say that a) it is highly discouraged and b) it
probably could be refactored so that the build dependency could be eliminated as well - which
probably has the same effect as saying it isn't allowed.
>>>
>>>
>>> On Mar 29, 2011, at 8:01 PM, Greg Stein wrote:
>>>
>>>> "JTS becomes required to build & test Lucene/Solr"
>>>>
>>>> I don't see how that fits under the "optional" terms. My read is that
>>>> a *required* LGPL library is verboten.
>>>>
>>>> On Tue, Mar 29, 2011 at 22:23, Ralph Goers <ralph.goers@dslextreme.com>
wrote:
>>>>> What you are describing sounds exactly like what http://www.apache.org/legal/resolved.html#optional
was intended to answer.  You timing is pretty good since that issue was resolved and added
to the page roughly a week ago.
>>>>>
>>>>> Ralph
>>>>>
>>>>>
>>>>> On Mar 29, 2011, at 10:36 AM, Smiley, David W. wrote:
>>>>>
>>>>>> Hello.
>>>>>>
>>>>>> I've been involved with Lucene & Solr for some time.  I'm working
on enhancing its support for geospatial search. I have java code in a patch in JIRA SOLR-2155
but I'm seeking that it get committed.  The patch uses the LGPL licensed Java Topology Suite
(JTS) library for part of its functionality.  That part is segmented in the code such that
if JTS is not included with Lucene/Solr at runtime then Lucene/Solr will still work, and even
the rest of my patch that doesn't use it.  I modified Lucene/Solr's ant based build script
to automatically downloads the JTS jar so that Lucene/Solr with my patch will compile and
tests will run.  This is triggered by default in the build  -- i.e. JTS becomes required
to build & test Lucene/Solr.  The patch *does not* cause JTS to be included in any packaged
deliverable of Lucene/Solr.
>>>>>>
>>>>>> Will the inclusion of my patch as I described in Lucene/Solr violate
the terms of applicable licensed software, namely Apache & LGPL?  This is the key question
I wish to get adjudicated by authorities at the ASF.  I've read these sources already, carefully:
>>>>>>       http://www.apache.org/legal/resolved.html
>>>>>>       http://www.apache.org/legal/3party.html#transition-examples-lgpl
>>>>>>       http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200801.mbox/%3C768dcb2e0801240130v604f0088w5781db2d889f5581@mail.gmail.com%3E
>>>>>>
>>>>>> These references are not 100% clear on this matter, but in my opinion
I get the sense that my approach is satisfactory.  But IANAL (I'm sure that comes up often
on this list!), and uncertainly amongst at least two others on the Lucene/Solr list remains.
 I wish to get this settled.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> ~ David Smiley
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>

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


Mime
View raw message