Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: legal-discuss@apache.org
Received-SPF: pass (athena.apache.org: domain of hyandell@gmail.com designates
 209.85.198.226 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references:x-google-sender-auth;
        b=IMEu8jJciCLgKdMP2gkdpGogxzEh8eijmf1ajJjs+uRArrsUjkYA66eQhbLo2XUjrn
         PPWJa0TwEwNPXv0ZVAoT0Liih6rx6tmw4oYQNaFeSghR+pJfT5+Fp5Dw4cqJX5vSJxab
         W7BfepLZ/huca1qCzoTeYtdkPTIZu2wyBD8Es=
Message-ID: <2d12b2f00807261002m41c80714q88d8fac3df0c103c@mail.gmail.com>
Date: Sat, 26 Jul 2008 10:02:00 -0700
From: "Henri Yandell" <bayard@apache.org>
Sender: hyandell@gmail.com
To: legal-discuss@apache.org, rgoers@apache.org
Subject: Re: GPL licensing question ...
In-Reply-To: <488AE506.3060606@dslextreme.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <3d4032300807191203v257e530enb5261e92fe9f978a@mail.gmail.com>
	 <NBBBJGEAGJAKLIDBKJOPIEGDFNAD.noel@devtech.com>
	 <2d12b2f00807241939s4482e9a2nf6d425cd8791afcb@mail.gmail.com>
	 <48893F24.3080000@rowe-clan.net>
	 <2d12b2f00807250016u69f717fap3f6b615f6e10cfe9@mail.gmail.com>
	 <488AE506.3060606@dslextreme.com>

On Sat, Jul 26, 2008 at 1:49 AM, Ralph Goers <Ralph.Goers@dslextreme.com> wrote:
>
>
> Henri Yandell wrote:
>>
>> So, wrt my reply:
>>
>> 1) We judge if that bridging/plugin API is sufficient (ie: no binding
>> occurs).
>> 2) We decide if we're happy to host the bridge to the GPL work, which
>> we decide if we want to release under AL 2.0 or GPL.
>>
>
> This makes no sense to me.  Forget for a moment that many think the FSF's
> position on derivative works is total nonsense. Going by their position the
> bridge code must be licensed under the GPL and can't be Apache licensed
> since it is a derivative work of the project being bridged.

Here's my reasoning here.

If I take a GPL project, and add a new feature by inlining a piece of
existing Apache code, I don't magically affect the original licensing
of that existing Apache code, only the fact that it is now in or with
a larger piece of GPL'd work. Similarly, we should be able to consider
any changes we make as AL 2.0, or any new code as AL 2.0 in a bridge
library and then consider GPL as a larger licensing affecting it when
that new code is used. Or we dual license it under GPL/AL 2.0. Or BSD
if we decide we're concerned about the GPLv2 compatibility bit and
we're talking GPLv2.

I think that's all quite complex though and it's probably easier to
say "Keep the bridge library small" and "use GPL".

> Getting even more paranoid, I'd argue that simply creating a bridge
> interface doesn't really help if the only thing around to implement it is
> under the GPL (i.e. the bridge to the "real" thing) . If push came to shove
> I'd imagine someone who liked to pay lawyers would argue that was just some
> fancy way to dance around the problem and the work using the bridge API was
> still a derivative. However, with multiple implementations I'd find it hard
> to believe anyone would go along with that.

I think we would mandate as policy that there must be alternatives. So
if you wanted to use gnu-regexp, you would have to do so through a
commons-regexp facade that let you talk to ORO as well. In the Lokahi
example, the plugin interface would have to be used for other
applications too. You couldn't hardware permissive things in and then
have a 'GPL licensed plugin'.

> Of course, maybe the FSF has relaxed their position on what a derivative
> work is since the last time I checked.  I'm well aware that many folks using
> the GPL don't even seem to agree with them.

No clue :) I like to take a pessimistic view; am just thinking out loud above.

Hen

---------------------------------------------------------------------
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