www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@gbiv.com>
Subject Re: Addendum to CCLA of Day Management
Date Sat, 03 Mar 2007 09:27:18 GMT
On Mar 2, 2007, at 8:30 AM, Jim Jagielski wrote:
> On Mar 2, 2007, at 8:11 AM, Roy T. Fielding wrote:
>> Creating a new CCLA each time the contact wants to add an addendum
>> is a very bad idea -- it means we have to have the entire text
>> approved by Day legal, again, and have two officers of the company
>> sign it.  I am sure that other companies have similar restrictions
>> on IP licensing.  That is why the CCLA was designed for addendums
>> to simply be communicated (in any written fashion) to the ASF.
>>
>
> A coupla of things:
>
>   1. I feel that it is inappropriate for any ASF member to
>      recommend a legally appropriate course of action for the
>      ASF when it involves their employer. Are you speaking
>      as a Day employee or as an ASF member in the above?
>      The use of "we" implies as a Day employee. But other
>      statements are being made, imo, as someone who helped
>      craft the CCLA and thus, has the expectation of ASF
>      influence... This conflict confuses the issue.

I am speaking as both!  I am the only person at the ASF who can speak
to the intentions of the CCLA, and the reason I switched the forum to
legal-discuss is so that ASF lawyers can correct me if anyone thinks
there is any real cause for concern.  Receiving contributions quickly
benefits everyone else far more than it benefits Day.

In any case, David already did what you asked before I even entered
the discussion, so I am obviously just trying to make the process
less stupid the next time we or anyone else contribute something.
There is no need for two months of back and forth delays.  Yes,
it has been two months since the internal decision was made to donate
this code, and the only reason it wasn't committed the next day
is because someone added a bunch of process barriers to what
used to be a simple agreement, and each person at the ASF seems to
have their own idea about what is sufficient for a contribution.

Once we have the CLAs in place, there should be no obstacle to a
trusted committer making an addition to an existing project when the
discussion has already taken place on the public dev list.  There is
absolutely no risk to the ASF, so why add yet another paper shuffle?

>   2. Where is it expressly stated that addendums can be
>      communicated "in any written fashion"?

Delaware corporate law.  The same law that made electronic signatures
viable does not require that signatures be anything cryptographically
verifiable -- an X marking the spot is still a legal signature in the
U.S. if it can be ascertained that the person in question made the X.
In this case, responding to the message with the original text
included is more than enough to verify that the person who wrote
the message and typed his name on the bottom is actually reading
and agreeing to the mail that was sent, particularly since David
sent the message to one of the ASF's public dev lists.

>   3. I am having a hard time following the logic that says
>        a. We should not bother with ensuring it is signed
>           because if it's not official, people will catch
>           it and complain. If this is the case, why have
>           anyone sign one in the 1st place?
>        b. That a signed copy of an addendum "means nothing"
>           when we say that a signed copy of the "original"
>           means we trust things forever and henceforth :)

We don't *need* the signatures!  We would have needed them for a
copyright assignment, but the CCLA is only a license.  It is *nice*
to have them because it verifies that everyone is on the same page
for the contribution agreement, but once the original agreement is
signed there should be no need for any additional agreements unless
the terms are in need of change.  This whole notion that we need a
separate software grant for each outside contribution is just
complete crap -- the licenses were designed to be sufficient without
even a single CLA in place, and all a contributor has to do to make
it safe for a contribution is to include the magic words "I consider
this to be a contribution under the terms of the [CCLA | Apache
License 2.0]."  That is all that is *needed* by the ASF (and even
that is more than necessary, since the act of posting to a public
forum is sufficient in itself for everyone except IBM).

The original CCLA (which is signed) identifies a person as
the point of contact so that we don't have to further burden
contributors with meaningless process.  We should only need to
use that contact when it is unclear whether the company is aware
of the contribution that is being made, or when the company wants
to identify additional people that *they* have approved of making
commit decisions on their own behalf.  This is just normal, everyday
written communication between collaborating entities -- there is
no need for additional contracts beyond the living agreement of
the original CCLA.

> Yes, of course, I know that the existence of a CCLA itself
> provides such protection...
>
> In any case, no other entity has had problems with providing
> updates and addendums as signed docs. In fact, it's moot
> since Day itself did so. If entities do have problems,
> then it's something that we should address, but so far no
> one has. It's a simple request and it provides some small level
> of IP tracking protection and no one has raised issues
> with it (it's noteworthy that David raised none at all).

No other entity knows where this process came from.  David is a nice
guy who avoids making waves, whereas I am the guy who has been trying
to keep our procedures safe and sane for the contributors and the ASF.
In my opinion, our procedures have swung too far off the side of
sensibility and we should go back to letting developers write and
contribute their code without second-guessing their intentions.

....Roy

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