Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-Id: <13B4F2C2-C0DE-4C9F-BEFF-DB8ABBE301B0@apache.org>
From: Curt Arnold <carnold@apache.org>
To: dev@couchdb.apache.org
In-Reply-To: <20090806220550.GA25455@tumbolia.org>
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: Uneasiness with use of github for experimentation
Date: Thu, 6 Aug 2009 23:55:27 -0500
References: <399A2534-FBBB-4D0E-A7C9-A04AB0E175BA@apache.org>
 <96A8267B-72C4-473F-A78A-B8C665805D4A@gmail.com>
 <e2111bbb0908061145p59ca6925ka8ab506780d84198@mail.gmail.com>
 <20090806220550.GA25455@tumbolia.org>

In retrospec, I should not write on a complicated topic while groggy =20
and then head off to my day job.   Standard disclaimer that I am not a =20=

lawyer.

There are at least two issues, neither of them is specific to using =20
git vs svn, but related to substantial or collaborative development =20
occurring outside of the ASF infrastructure.

The first is code provenance (ownership, license, etc):

As previously mentioned, the JIRA does have an checkbox to indicate =20
that a contribution is intended as a contribution.  That is intended =20
as a reinforcement (or an explicit refutation) of the implied license =20=

for things posted on the mailing lists or in Bugzilla (which lacks the =20=

checkbox).  The implied license for contributions comes from item 5 in =20=

the ASL.


    5. Submission of Contributions. Unless You explicitly state =20
otherwise,
       any Contribution intentionally submitted for inclusion in the =20
Work
       by You to the Licensor shall be under the terms and conditions of
       this License, without any additional terms or conditions.
       Notwithstanding the above, nothing herein shall supersede or =20
modify
       the terms of any separate license agreement you may have executed
       with Licensor regarding such Contributions.

CLA's are described on http://www.apache.org/licenses/.  The following =20=

is a quote.

Contributor License Agreements
The ASF desires that all contributors of ideas, code, or documentation =20=

to the Apache projects complete, sign, and submit (via postal mail, =20
fax or email) an Individual Contributor License Agreement (CLA) [PDF =20
form]. The purpose of this agreement is to clearly define the terms =20
under which intellectual property has been contributed to the ASF and =20=

thereby allow us to defend the project should there be a legal dispute =20=

regarding the software at some future time. A signed CLA is required =20
to be on file before an individual is given commit rights to an ASF =20
project.

Code should only get into an Apache project in one of the following =20
ways:

       A contribution submitted on the mailing list or bug tracker =20
that is either implicitly licensed under the ASF via item 5 or =20
explicitly under a CLA.

       An individual contribution committed into the SVN under the =20
terms of a signed CLA on file.

       An external contribution cleared through the incubator.

In the case of a substantial contribution on the mailing list or bug =20
tracker, the PMC may think it is warranted to have a signed CLA on =20
file before incorporating the code.  That is a judgement call left up =20=

to the PMC, but as with anything can be overriden by the board.

The mailing lists are archived, the bug trackers are logged and =20
archived.  If there is ever a challenge the ASF should be able to =20
trace any piece of code back to  a particular email or bug tracker or =20=

SVN user who represented that the code was their original creation =20
which they intended and had the right to license under the ASL.

The ASF license allows forking and commercialized or internal =20
variants.  Unlike the GPL, however it does not require that forkers =20
donate their code back to the ASF.  I'm fully within my legal limits =20
to create "Curt's Relaxing Database" from the Apache CouchDB code and =20=

make it available under the ASL or under a more restrictive license as =20=

long as I comply with the ASF terms on the code that I incorporated =20
from the ASF.  If I set up CRDb as independent project under a =20
different license and I accepted contributions from others, I may not =20=

have the rights to relicense their contributions back the the ASF if I =20=

ever decided to merge CRDb.  Also, those contributions would not be =20
documented in the ASF infrastructure as would contributions that had =20
gone into CouchDB.  Because of that, any  convergence would need to go =20=

through the Incubator to make sure that every contribution is =20
documented.

While not intentional doing collaborative development outside of the =20
ASF infrastructure has a lot of similarities to an intentional =20
forking.  For a small window of time, a developer is offering a code =20
base under the ASL may be incorporating contributions from others =20
where the ASL has no record of either the transaction or the possible =20=

separate license agreement that was executed between the forker and =20
the contributor.


The second issue is open, collaborative development:

 =46rom http://www.apache.org/foundation/how-it-works.html#what

> The Apache Software Foundation (ASF) is a 501(c)3 non-profit =20
> organization incorporated in the United States of America and was =20
> formed primarily to:
>
> 	=95 provide a foundation for open, collaborative software =
development =20
> projects by supplying hardware, communication, and business =20
> infrastructure
>         ...
>
> We endeavour to conduct as much discussion in public as possible. =20
> This encourages openness, provides a public record, and stimulates =20
> the broader community.
>
>

Using github is definitely more open than doing a whole lot of work =20
off on your private machine or code repository and then contributing a =20=

big pile of work that the rest of the community now has to accept as a =20=

done deal.  However, I requires that I notice that your message about =20=

your work on Github, that that I actively follow it independent of =20
tracking the existing development that is being done in the Apache =20
SVN.  If experimental development is done under =
http://svn.apache.org/repos/asf/couchdb/sandbox/whatever=20
, then anyone who is interested enough to subscribe to =
commits@couchdb.apache.org=20
  will also see the commits that occur on sandbox/whatever.

I could see work on authentication and authorization warranting a =20
branch in the sandbox, maybe more than one if there are multiple =20
competing ideas.

The threshold to granting access rights could be a lot lower in the =20
sandbox.  Obviously, my Erlang and CouchDB foo isn't sufficient to =20
even think about touching the trunk, but I might have an idea that =20
would benefit from being fleshed out in the sandbox.  Current =20
committers should feel free to create branches in the sandbox if they =20=

need room to explore something.  Being the Apache SVN, any committer =20
needs a signed CLA and an @apache.org account already, but if there =20
was some experiment that came from outside the not-already-committer =20
world, then a committer could act as a code secretary and incorporate =20=

patches submitted through the mailing list or JIRA.

A really big danger of large development being done off-list and off-=20
SVN, particularly when done by major contributors, is that it can =20
leave the rest of the community feeling powerless.  If I'm building =20
some major app or my business around CouchDB and have some interest in =20=

a topic and some particular needs, if I see the development occurring, =20=

I have the opportunity to influence the direction while the code is =20
evolving.  If development is done out-of-sight (or at least not in the =20=

expected place) and dropped in fully-formed without my critical =20
feature, it could be a lot harder to get my critical feature in.

End of soap box tonight.  Not saying that CouchDB is doing any of =20
those things, just wanting to point out some potential dangers.  I =20
would recommend that any of the committers try to do their CouchDB =20
related work in the SVN.  If someone has a great idea that might =20
warrant playing in the sandbox, ask on the list and see if anyone else =20=

wants to play.

p.s. I had mentioned Apache Labs (http://labs.apache.org), but =20
intended it to be an inadequate options since it would lack the =20
visibility of a sandbox, though it would address the licensing issues.