From dev-return-5592-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Thu Aug 06 14:44:32 2009
Return-Path:
Delivered-To: apmail-couchdb-dev-archive@www.apache.org
Received: (qmail 12735 invoked from network); 6 Aug 2009 14:44:32 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
by minotaur.apache.org with SMTP; 6 Aug 2009 14:44:32 -0000
Received: (qmail 21596 invoked by uid 500); 6 Aug 2009 14:44:39 -0000
Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org
Received: (qmail 21516 invoked by uid 500); 6 Aug 2009 14:44:39 -0000
Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: dev@couchdb.apache.org
Delivered-To: mailing list dev@couchdb.apache.org
Received: (qmail 21504 invoked by uid 99); 6 Aug 2009 14:44:39 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Aug 2009 14:44:39 +0000
X-ASF-Spam-Status: No, hits=1.2 required=10.0
tests=SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Received: from [83.97.50.139] (HELO jan.prima.de) (83.97.50.139)
by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Aug 2009 14:44:29 +0000
Received: from [192.168.1.14] (f053012224.adsl.alicedsl.de [::ffff:78.53.12.224])
(AUTH: LOGIN jan, TLS: TLSv1/SSLv3,128bits,AES128-SHA)
by jan.prima.de with esmtp; Thu, 06 Aug 2009 14:44:06 +0000
Message-Id: <621A0BE0-6458-48F0-80AC-8D701F5375D9@apache.org>
From: Jan Lehnardt
To: dev@couchdb.apache.org
In-Reply-To: <6AD2E30B-3CBF-419E-9EE9-8F73160C8D91@apache.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: Dependencies in SVN
Date: Thu, 6 Aug 2009 16:44:05 +0200
References: <29420CCA-62BF-424E-A03D-6B376A0D91FF@apache.org> <20090806050440.GA21830@tumbolia.org> <6AD2E30B-3CBF-419E-9EE9-8F73160C8D91@apache.org>
X-Mailer: Apple Mail (2.935.3)
X-Virus-Checked: Checked by ClamAV on apache.org
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.
>