www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell" <bay...@apache.org>
Subject Re: GPL licensing question ...
Date Sun, 27 Jul 2008 06:33:10 GMT
On Sat, Jul 26, 2008 at 11:32 PM, Henri Yandell <bayard@apache.org> wrote:
> On Sat, Jul 26, 2008 at 1:47 PM, Ralph Goers <Ralph.Goers@dslextreme.com> wrote:
>>
>>
>> Henri Yandell wrote:
>>>
>>> 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.
>>>
>>
>> My understanding is the FSF's position is that you can take something under
>> the Apache license and use it from a GPL'd work with no problems (at least
>> with GPL3) but the whole work will be under the GPL. OTOH, if you take
>> something under the Apache license and provide some kind of glue to the
>> GPL'd work, then the GPL "infects" the Apache licensed work because it is a
>> derivative work and requires the distribution as a whole to be GPL'd. The
>> code under the Apache license remains only under the Apache license.
>> However, if the Apache licensed code can't easily be separated from the
>> GPL'd code then it might as well be under the GPL.
>
> Exactly.
>
> Our source code remains AL 2.0, but when we distributed it for use
> with a GPL product, it is inside a GPL package (though I don't
> understand if that means the code is now dual-licensed, or whether the
> source is AL 2.0 but there is some vague and translucent GPL ether
> surrounding it).
>
> There is a good reason for doing this. It allows someone (imo) to
> take, say a Mysql JDBC driver, and create a Derby JDBC driver from it
> without affecting the licensing of the new Derby driver. If we simply
> applied GPL to it all, then we would have to treat that authored code
> as a risky source.
>
> So... I'm somewhat tempted by the idea of our still writing source
> under a GPL compatible license, and then having some level of GPL
> apply to the release.
>
> We're getting quite far down the hypothetical path though - time to
> wait for a real use case I think.

Before I start a 'wtf' thread there, I'm supposing we wrote the Mysql
JDBC driver. I don't mean any existing driver.

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


Mime
View raw message