Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: legal-discuss@apache.org
Received-SPF: pass (nike.apache.org: domain of ralph.goers@dslextreme.com
 designates 209.85.214.178 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: Building ASL code requiring LGPL 3rd party
From: Ralph Goers <ralph.goers@dslextreme.com>
In-Reply-To: <AB1B9109-9CA7-46DC-AC70-13A85D74FFAE@jpl.nasa.gov>
Date: Wed, 30 Mar 2011 23:36:26 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <526128E8-7972-4A02-88C0-62685E5376E4@dslextreme.com>
References: 
 <C9B912DD.780A%dsmiley@mitre.org>,<86D14AFB-F632-4177-9886-67F66C1C7F06@jpl.nasa.gov>
 <CA4A5C993E465A4292E14C850B2BBD2607244F084F@IMCMBX1.MITRE.ORG>
 <BBEA75BF-7114-47B7-B691-AF8AF2652B42@jpl.nasa.gov>
 <8CD4BAB3-E1E2-47D2-8C45-FFF4659C34D1@dslextreme.com>
 <AB1B9109-9CA7-46DC-AC70-13A85D74FFAE@jpl.nasa.gov>
To: legal-discuss@apache.org


On Mar 30, 2011, at 10:16 PM, Mattmann, Chris A (388J) wrote:

> Hi Ralph,
>=20
>>> No you haven't. You said it's optional. That's not strictly true =
since the LGPL infected code that's part of your patch would be part of =
the tarball that the Lucene project has distributed in the past (and =
will distribute) aka its contrib as part of its source.
>>=20
>> Technically that statement is not correct. The LGPL allows clients to =
reference the interfaces without the code itself having to be licensed =
under the LGPL, so there is no "infection" in this particular case.
>=20
> Ehhh, what's an "interface" though? That's a sticky point.=20

I answered Greg with the same comment. In Java, it doesn't really =
matter.  If you don't have the classes your Java class will have =
references to the other class but nothing more. The code, static fields, =
etc. is part of the target class and simply isn't present until the =
target class is available on the class path. So for the purposes of the =
LGPL it is equivalent to a header file.

>=20
> It seems from his patch that there are concrete classes from JTS being =
used, and *not* interfaces, no? Thanks for the clarification regardless.

Again, don't take that so literally.

FWIW, I'm not advocating that Lucene should accept the patch and =
certainly not as is.   The fundamental question that is pointed out in =
resolved.html is "Will the majority of users want to use my product =
without adding the optional components?".  You should infer from this =
that the dependency should be optional both in the build and at runtime. =
If that is not desirable then a solution with a more appropriate license =
should be used.

Ralph=

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