couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: Dependencies in SVN
Date Thu, 06 Aug 2009 05:04:40 GMT
Hey,

On Wed, Aug 05, 2009 at 11:45:52PM -0500, Curt Arnold wrote:
> Having an external code base in the SVN is an invitation to fork which results
> in the ASF effectively publishing software under a license other the the ASL
> v2. That is a whole different animal than having a dependency on an non-ASL'd
> licensed piece of software.

Thank you for taking the time to review the project! Your commentary has been
very helpful in clearing up a few misunderstandings I had about the ASF, and the
way that code needs to be cleared before being added to a project.

> erlang-oauth was introduced into the SVN yesterday to support the
> couch_http_oauth authentication handler.  It is optional, the recently
> added oauth authentication handler would fail to load without it but
> that should be all.  There was no mention that the patch included
> third-party developed software, no dev list discussion or vote or
> Incubator PMC clearance.  I have requested that it be removed from the
> SVN pending review.

Ideally, we should try to import this, and fail if unavailable. Any
customisation or patching that we have done to make this CouchDB compatible
should be aggressively pushed upstream.

> ibrowse was added initially added to the SVN in January and is an HTTP
> client used in replication.  I was unable to find any mailing list
> discussion or Incubator review on the addition of this code base.

Likewise.

> mochiweb was added in March 2008 and provides the http server included
> in CouchDB.  The Incubator PMC was aware of this dependency based on the
> April 2008 Incubator PMC board report.  In addition to the http server,
> CouchDB also uses mochiweb routines for parsing query strings, url
> encoding, etc.

Likewise.

> Most of the other dependencies are used in the Futon management client.

These are small JavaScript libraries, and where I see that individual Erlang
libraries should be satisfied externally to CouchDB, I do not think that the
same should apply to JavaScript. This is no way of "importing" a library, and no
standard way of packaging shared libraries that I am aware of.

> To minimize the amount of effort that a user has to perform to satisfy
> their license issues, I think we should consider modularizing couchdb so
> that a user who isn't interested in OAuth does not have to research its
> license, etc.
>
> I'd see the parts as:
>
> core: The database and non-network core of CouchDB.  I would hope this
> code have no dependencies other than OTP.
>
> http: The http server dependent on MochiWeb's http services and core.
>
> replicator: dependent on core and ibrowse
>
> futon: HTTP admin console
>
> oauth: OAuth authenticator, dependent on erlang-oauth

Moving our Erlang dependencies out from the source is one thing, but splitting
CouchDB into multiple components is entirely another. It makes little sense to
modularise the code when each of the modules would be functionally useless in
isolation. But moreover, this is orthogonal to the licensing issue. By all
means, some degree of modularisation and abstraction of interface might be a
good direction for the project to take, but please, let's discuss that as an
architectural issue separate to this one. I think we would do well to
concentrate on removing the 3rd party Erlang code, or discussing the most
palatable way forward, and leave it at that, for the time being.

Best,

-- 
Noah Slater, http://tumbolia.org/nslater

Mime
View raw message