incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Re: Adopting non-ASF AL projects (was Re: [DISCUSS] Kudu incubator proposal)
Date Sun, 29 Nov 2015 02:58:34 GMT
On Fri, Nov 27, 2015 at 11:16 AM, Alex Harui <> wrote:

> On 11/27/15, 7:34 AM, "Marvin Humphrey" <> wrote:
>>On Fri, Nov 27, 2015 at 7:28 AM, Alex Harui <> wrote:
>>> Since you are VP-Legal, I a willing to abide by your answer.  If the
>>> answer is a flat "No", then fine, we can continue working with it as 3rd
>>> party, but if the answer is "Yes, but understand the risks" as Ted said,
>>> then the PMC is empowered to make the risk/reward trade-off.
>> Please make a concrete proposal rather than justify such a course of
>> action on the basis of the VP Legal's participation in hypothetical
>> discussion.
> OK, sounds like PMCs are not empowered to make a judgement call here.

Thanks for providing details.

When we assume control over a project, the common case is that we have the
consent of all contributors.  That's covered by our SGA procedures, with or
without incubation.

Having a TLP take over a codebase *without* the explicit consent of all
contributors isn't a common case, and there are both legal and social risks.
I don't think we need a general solution for that problem, other than "Don't
do this without consulting the Board first."  The Board might choose to
involve the Incubator or it might not.  (I'd rather the Incubator be left out
of it unless full incubation was prescribed, but that's a side issue.) It
might choose to delegate to VP Legal or it might not.  But the informal
discussion we're having now shouldn't be taken as setting general policy.

Your points about not having all code associated with an SGA/ICLA are salient.
Ideally, we would like to trace back every line of code to either an SGA or an
ICLA, and we try hard to make that happen, both when a codebase is taken in
and during ongoing development.

However, even if we achieve that ideal, having someone to blame is not an
impregnable legal defense in the event that a bad contribution sneaks in.
(For instance, if a deep-pocketed corporation gets sued for redistributing an
ASF product that infringes on someone's copyright, they might try to recover
damages from the ASF itself, the committer, the committer's employer or
whoever else they can throw lawyers at, but there might not be enough money
there to cover everything.)  We strive for high standards, but must reconcile
ourselves to imperfection.

And so, when there is an ALv2 codebase for which it isn't feasible to track
down every last copyright holder, some judgment calls are in order.  The
situation with Groovy's SGA was heavily discussed; the Incubator specializes
in such matters, multiple Board members participated in the thread, and how we
resolved the situation wound up in our April 2015 report.  It is arguable that
we have somewhat weaker guarantees with commits in Groovy's history than we do
for other projects because we did not chase down every last contributor.
However, our best defense at the ASF is vigilance by dedicated PMC members --
and in that regard, Groovy's core contributors impressed as few others have.
I think the Incubator made a reasonable call.

Marvin Humphrey

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message