couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Uneasiness with use of github for experimentation
Date Fri, 07 Aug 2009 06:23:43 GMT
A few shapeless and incomplete thoughts leap to mind:

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

As I read this, anyone that submits a patch to me on github has
granted ASF license to that contribution unless they specifically
state that their contribution was not intended for inclusion. Its
still my ass on the line as a committer if I put something in SVN that
violates this agreement. The radio button on JIRA is not an absolute
requirement for inclusion.

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

I read the rest as "The ASF wants to cover its ass". This is a good
thing. It protects not only the ASF but all downstream users. By
exerting a bit of foresight we promote the integrity and reliability
of the ASF as a whole.

That said, using "Apache SVN" in an argument about providing that
paper trail prevents me from considering the issue seriously. I'm a
hacker. I hack. I judge my tools and I have judged SVN to be lacking.
I would very be very excited to see hosted git repositories for ASF
contributors and would use them exclusively to all other git hosting
for my ASF development. If there were a recommendation to stop using
Github as a host for development, I would just stop pushing code
public. SVN sucks that bad.

Don't get me started on JIRA.

HTH,
Paul Davis

Mime
View raw message