couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: Uneasiness with use of github for experimentation
Date Fri, 07 Aug 2009 04:55:27 GMT
In retrospec, I should not write on a complicated topic while groggy  
and then head off to my day job.   Standard disclaimer that I am not a  
lawyer.

There are at least two issues, neither of them is specific to using  
git vs svn, but related to substantial or collaborative development  
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  
that a contribution is intended as a contribution.  That is intended  
as a reinforcement (or an explicit refutation) of the implied license  
for things posted on the mailing lists or in Bugzilla (which lacks the  
checkbox).  The implied license for contributions comes from item 5 in  
the ASL.


    5. Submission of Contributions. Unless You explicitly state  
otherwise,
       any Contribution intentionally submitted for inclusion in the  
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  
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  
is a quote.

Contributor License Agreements
The ASF desires that all contributors of ideas, code, or documentation  
to the Apache projects complete, sign, and submit (via postal mail,  
fax or email) an Individual Contributor License Agreement (CLA) [PDF  
form]. The purpose of this agreement is to clearly define the terms  
under which intellectual property has been contributed to the ASF and  
thereby allow us to defend the project should there be a legal dispute  
regarding the software at some future time. A signed CLA is required  
to be on file before an individual is given commit rights to an ASF  
project.

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

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

       An individual contribution committed into the SVN under the  
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  
tracker, the PMC may think it is warranted to have a signed CLA on  
file before incorporating the code.  That is a judgement call left up  
to the PMC, but as with anything can be overriden by the board.

The mailing lists are archived, the bug trackers are logged and  
archived.  If there is ever a challenge the ASF should be able to  
trace any piece of code back to  a particular email or bug tracker or  
SVN user who represented that the code was their original creation  
which they intended and had the right to license under the ASL.

The ASF license allows forking and commercialized or internal  
variants.  Unlike the GPL, however it does not require that forkers  
donate their code back to the ASF.  I'm fully within my legal limits  
to create "Curt's Relaxing Database" from the Apache CouchDB code and  
make it available under the ASL or under a more restrictive license as  
long as I comply with the ASF terms on the code that I incorporated  
from the ASF.  If I set up CRDb as independent project under a  
different license and I accepted contributions from others, I may not  
have the rights to relicense their contributions back the the ASF if I  
ever decided to merge CRDb.  Also, those contributions would not be  
documented in the ASF infrastructure as would contributions that had  
gone into CouchDB.  Because of that, any  convergence would need to go  
through the Incubator to make sure that every contribution is  
documented.

While not intentional doing collaborative development outside of the  
ASF infrastructure has a lot of similarities to an intentional  
forking.  For a small window of time, a developer is offering a code  
base under the ASL may be incorporating contributions from others  
where the ASL has no record of either the transaction or the possible  
separate license agreement that was executed between the forker and  
the contributor.



The second issue is open, collaborative development:

 From http://www.apache.org/foundation/how-it-works.html#what

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

Using github is definitely more open than doing a whole lot of work  
off on your private machine or code repository and then contributing a  
big pile of work that the rest of the community now has to accept as a  
done deal.  However, I requires that I notice that your message about  
your work on Github, that that I actively follow it independent of  
tracking the existing development that is being done in the Apache  
SVN.  If experimental development is done under http://svn.apache.org/repos/asf/couchdb/sandbox/whatever

, then anyone who is interested enough to subscribe to commits@couchdb.apache.org 
  will also see the commits that occur on sandbox/whatever.

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

The threshold to granting access rights could be a lot lower in the  
sandbox.  Obviously, my Erlang and CouchDB foo isn't sufficient to  
even think about touching the trunk, but I might have an idea that  
would benefit from being fleshed out in the sandbox.  Current  
committers should feel free to create branches in the sandbox if they  
need room to explore something.  Being the Apache SVN, any committer  
needs a signed CLA and an @apache.org account already, but if there  
was some experiment that came from outside the not-already-committer  
world, then a committer could act as a code secretary and incorporate  
patches submitted through the mailing list or JIRA.

A really big danger of large development being done off-list and off- 
SVN, particularly when done by major contributors, is that it can  
leave the rest of the community feeling powerless.  If I'm building  
some major app or my business around CouchDB and have some interest in  
a topic and some particular needs, if I see the development occurring,  
I have the opportunity to influence the direction while the code is  
evolving.  If development is done out-of-sight (or at least not in the  
expected place) and dropped in fully-formed without my critical  
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  
those things, just wanting to point out some potential dangers.  I  
would recommend that any of the committers try to do their CouchDB  
related work in the SVN.  If someone has a great idea that might  
warrant playing in the sandbox, ask on the list and see if anyone else  
wants to play.

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


Mime
View raw message