You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by "Noel J. Bergman" <no...@devtech.com> on 2006/10/03 21:33:50 UTC

FW: LGPL and compile dummies?

Forwarded from late moderation.

-----Original Message-----
From: Roland Weber [mailto:http-async@dubioso.net]
Sent: Monday, September 25, 2006 13:48
To: legal-discuss@apache.org
Subject: LGPL and compile dummies?


Hi all,

I'm a committer on the Jakarta project and spend my time with
HttpClient and HttpComponents. We have some NTLMv1 authentication
code in our code base we'd like to get rid of. The preferred
replacement would be jCIFS, as the Samba guys are probably deepest
into that protocol family. jCIFS is licensed under the LGPL.
I've checked these two wiki pages:

http://people.apache.org/~cliffs/3party.html
http://wiki.apache.org/jakarta/Using_LGPL'd_code

and some stuff in the archives of the legal-discuss list.
The rules set in the Using_LGPL'd_code wiki page basically
mean we'd have to disable jCIFS/NTLM support in the binaries we
distribute. That may not seem much of a problem if you're used
to compile code day in, day out. But I also have some corporate
background, and there the difference between "download and
install library X" and "download sources, recompile them with
special flags, then install the result" can be very significant.
One might be considered an installation/administration task,
while the other one is a development task. Completely different
corporate processes can kick in. That's why I would be reluctant
to drop the current out-of-the-box NTLMv1 support, while I also
don't like the alternative of keeping the NTLM authentication
code in the code base. We're HTTP experts, not cryptographers.

The main problem with the LGPL seems to be the question whether
an import statement in the Java source, and the consequence of
compiling against the LGPL library, is an act of linking against
the LGPL library. Since we'd only need maybe one or two classes
with a handful of methods from jCIFS, it would be a viable option
for us to create a compile dummy for that part of the jCIFS API.
That can be easily done from non-code documentation (JavaDocs).
The compile dummy would fall under the Apache license, and
compiling the rest of the code against the dummy should not
cause any licensing troubles - or so I think.
Then set the default configuration so that the code depending
on jCIFS is not executed, and you have a package that does not
depend on the LGPL library. On the other hand, enabling that
support is as simple as putting the jCIFS library into the
classpath and changing a configuration property - no need to
recompile anything.

What are your views on this idea?

cheers,
  Roland (rolandw -at- apache)



---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only.  Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF.  See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org