couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <>
Subject Re: Dependencies in SVN
Date Thu, 06 Aug 2009 11:54:49 GMT

On Aug 6, 2009, at 12:04 AM, Noah Slater wrote:

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

I have no first hand experience with CEAN, but it appears that both  
mochiweb and ibrowse are available through that package manager.

Another complication with having their source in our SVN is that  
mailing list and JIRA submitted patches are implicitly ASL licensed  
via paragraph 5 of the ASL or explicitly via a CLA for a contributor.   
However, that does not give any party the right to include that patch  
in a non-ASL licensed work with an license grant from the original  
author of the patch.  We can ask the patch author to push something  
upstream, but the project can't do it for them.

>> ibrowse was added initially added to the SVN in January and is an  
>> 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.

My thoughts too, thanks for elaborating.

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

It has helpful conceptually for me to say that, but that comes from a  
Java/C++ background where compiling against a dependency results in a  
binary that is then a derivative of the whatever it was compiled  
against.  In that world, if you were linking against an LGPL library  
to provide some functionality to an ASF framework, you'd do the plugin  
outside of ASF and license it as LGPL.

My understanding of erlc is that the .beam file includes only the  
import directives, does not need to library present and the resulting  
file is not a derivative  work.

View raw message