www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Ruby" <ru...@intertwingly.net>
Subject Re: Licenses are not always what they seem [was: RE: GPL licensing question ...]
Date Mon, 28 Jul 2008 20:12:37 GMT
On Mon, Jul 28, 2008 at 2:46 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
> On Jul 28, 2008, at 3:04 AM, Sam Ruby wrote:
>>
>> It makes exactly the same amount of sense as us treating a checkbox in
>> JIRA as sufficient permission for simple three line bug patch, but we
>> demand multiple ICLAs and generally a CCLA or two when the incubator
>> accepts an entire codebase which was previously released under a
>> different license.
>
> We don't need the checkbox at all.  And what we "demand" of new submissions
> to incubator is that the original authors want to maintain it at the ASF
> (or let others maintain it at the ASF) and give us the ability to relicense
> in accordance with our nonprofit purpose.  How that ended up being a demand
> for signed iCLAs is anyone's guess.  IMO, the incubator has an obscene
> inclination towards paperwork for the same reason that any large institution
> needs forms in triplicate -- because they prefer to simplify their own
> process and documented requirements rather than simplify the task of
> the volunteers bringing in new code.

<chuckle>

While the incubator is responsible for the execution, I see
requirements for a clear audit trail as being derived from this
committee's predecessors.  If this group were to say that we no longer
saw this as necessary, I am sure that the incubator would be quick to
comply.

That being said, the notion of an ASF product with a dependency on
GPL'ed code is something I, for one, would like to move very slowly
and carefully on; and in the process make sure that there is as little
room as possible for misunderstandings.  Which means that I am for a
clear audit trail, complete with i's dotted and t's crossed.  Not to
simply my own workload.  And, as you correctly point out, in a desire
to simply the task of volunteers bringing in new code.  But rather to
satisfy my own desire to make sure that we have every right to make
available our product under only the terms of the Apache Software
License, Version 2.0.

>> If the authors of a given bit of code wishes to dual license their
>> code, they should do so.  But for someone to make the claim that a GPL
>> license gives the ASF permission to redistribute code that depends on
>> it under the Apache License is a bit of a stretch.
>
> I don't think anyone claimed that.  Note, however, that a dual license
> happens whenever the owner says "yes, you can do that".  It does not
> need to be in the form of a new LICENSE text document inserted in the
> package bundle and then formally released.
>
> Keep in mind that copyright defines the exclusive rights of the owner.
> It is always the owner's statements that matter first, even if they
> don't correlate with other licenses the owner has granted.

Agreed.  Just so that we are clear, and using Xen as a example.  Xen
has a hypercall interface[1].  If an ASF project wishes to make use of
this interface, the statement currently appearing on the Xen wiki[2]
is not sufficient.

However, if we were to get explicit permissions the owner, that would
be sufficient.  I would be more comfortable if that were in writing,
but we will worry about that when we get there.

If there is a single owner (by virtue of copyright assignment),
obtaining permission may be simple.  If copyright assignment was not
done, then permissions from each owner may be necessary.  And given
the nature of the GPL license, that may involve obtaining explicit
permissions from other works from which Xen was derived.

> ....Roy

- Sam Ruby

[1] http://www.cl.cam.ac.uk/research/srg/netos/xen/readmes/interface/interface.html#SECTION00610000000000000000

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