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 [email protected]
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.
