Mailing-List: contact community-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: community@apache.org
Message-ID: 
 <3927.172.27.64.4.1044973965.squirrel@webserver.intranet.hisitech.com>
Date: Tue, 11 Feb 2003 15:32:45 +0100 (CET)
Subject: Re: Classpath Licensing
From: "Santiago Gala" <sgala@hisitech.com>
To: <community@apache.org>
In-Reply-To: <89EE28AE-3D67-11D7-B26F-000393753936@apache.org>
References: <NBBBJGEAGJAKLIDBKJOPKECDAAAB.noel@devtech.com>
        <89EE28AE-3D67-11D7-B26F-000393753936@apache.org>
Importance: Normal
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit


> On Thursday, February 6, 2003, at 12:30  PM, Noel J. Bergman wrote:
>>> I believe Classpath has a special exception for distribution, but,
>>> AIUI, that isn't typical of FSF packages.
>>
>> I agree.  The only issue for me is whether or not the Classpath
>> packages are
>> a suitable special case that we can use.
>
> The answer is no.  Look, this should be clear from the license text. The
> exception refers to the effect of linking done by the Classpath code,
> which is a neutral third-party.  The exception is to allow the neutral
> third-party (GPL code) to cause other object code to be
> combined without altering the license of that object code.  It does not
> make an exception to any direct use of the GPL code itself,
> such as if some part of our code did an import of one of the classes
> within the GPL library.
>
>> As to the rest, you have a valid point that the FSF holds a copyright
>> on the
>> code.  However, Nic is entitled to multi-license his own code (not all
>>  of
>> Classpath, but I was specifically thinking of his implementation of
>> JavaMail
>> and Chris' implementations of JavaMail handlers), and thus it seems
>> that
>> their representation would have effect.
>
> Nic just repeated what the license says.  It has no relevance to a
> situation where one java app/library imports from an LGPL class.
>
>> Personally, I'd prefer for them to license their source under the ASF
>> license, but as long as we can use their binaries, that suffices.
>
> We can *use* their binaries.  We cannot introduce features that depend
> only on their binaries (or their source code, for that matter).  Doing
> so restricts the distribution of our entire product to LGPL or GPL,
> which is why it is forbidden within the ASF.
>
> If the developer dual-licenses the code in a form that is non-viral,
> such as the Apache or MPL 1.1 licenses, then we can depend on it.
>

I see perfectly the point. One of the distinguishing ("positioning")
features of the ASF is that it allows us (at least me, I suspect many of
us) to work with clients using the Apache code base, without forcing
them to free our modifications to the source code.

While I try to encourage contributing back from my customers, I'm
not always able to get the message through. Some times it is due to the
changes revealing Business processes that they don't want to show.
Most of the times it is because they (mistakenly) believe that "their"
modifications give them a competitive advantage.
I make my life, at least bug are found and they always allow me
to contribute back small patches in "core" tools.

I would not be able to use GPL code
in such contexts, or it would be far more difficult, if I arrived with
code that forced restrictions upon them.

Given that the position of knowledgeable people seems to be that LGPL +
original interfaces = derivative work (which I half agree), I understand
and support the ASF policies regarding the subject.

My small +1 ;-)

Regards,
     Santiago

> ....Roy


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