couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Dependencies in SVN
Date Thu, 06 Aug 2009 14:44:05 GMT

On 6 Aug 2009, at 13:54, Curt Arnold wrote:

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

FWIW, in my two years with Erlang, I've never came across CEAN in any  
practical setting. I know it exists, but for all I know, nobody uses  
it. There are also the Faxien and Sinian[sp?] distribution tools, but  
they are not widespread either. For all I know, the Erlang community  
is longing for a release management system.

Cheers
Jan
--


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


Mime
View raw message