incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <>
Subject Re: Third-party dependencies in CouchDB
Date Sun, 09 Aug 2009 10:54:58 GMT
Two things come to my mind immediately, and this is without reading your
references (might do that when I'm back at a computer).

1. CouchDb graduated long ago, and is no longer the concern of the Incubator
in particular. If you have legal concerns that the CouchDb doesn't want to
address, I suggest you seek further info from legal-discuss, and if it isn't
of legal nature, go to the Board or Membership with the concerns...

2. Speaking from a legal perspective, there is nothing "at Apache" that
prevents people for doing source code copy, in small or large (a.k.a forks),
PROVIDED that the license allows it. I saw you mentioning BSD (modified I
hope) and MIT X, and those licenses require attribution and few other
things, so if that is done, there is no legal contention here. Now you said
that Apache doesn't fork... well the reason behind that (I think) is that we
are all lazy, it takes a lot of energy to maintain forks. And we don't do it
to compete with the original project, out of courtesy... is that your

I appreciate your concerns, just target the right audience and preferably
with the invitation of the CouchDb PMC...

-- Niclas

On Aug 9, 2009 5:48 PM, "Curt Arnold" <> wrote:

I've been using CouchDB in my personal development and have recently started
trying to get up to speed with the project itself.  I've brought up a few
issues on where I encountered things that were a bit
unsettling.  There has been follow up discussion, but no resolution and no
one who can speak authoritatively on where the line is on certain issues.

A recent patch introduced the source code of a BSD-licensed project
(erlang_oauth) into the CouchDB SVN.  There was no mention of the addition
of the dependency in the patch and the license file for the project was not
included (which required including the license and disclaimers).  Digging a
little more, I found that another non-ASL code base (ibrowse) was added to
the SVN in January, again with missing license, no notice in the submission,
traffic in the mailing list.  There is a third code base (mochiweb) that was
in the source during incubation which was noted in the April 2008 board

On Apr 14, 2008, at 11:07 AM, Noel J. Bergman wrote:

> === CouchDB ===
> CouchDB is a distributed document-oriented database system written in
> Erlang. The project entered incubation on February 12th, 2008.
> The infrastructure (SVN, JIRA, mailing lists, and web-site) has been set
> up,
> and the team has moved source, documentation, and bug reports from their
> former homes to the ASF.
> Work has continued on removing code forked from other projects from the
> CouchDB codebase. This includes Mozilla !SpiderMonkey, the code for which
> was previously included with CouchDB in slightly modified form. Instead, it
> is now treated as an external compile-time dependency via a custom C
> wrapper
> using the !SpiderMonkey API. Also, work is currently in progress on
> replacing the dependency on a forked version of `inets`, which is part of
> the Erlang standard library (EPL), with the MIT-licensed !MochiWeb library.
> For the time being, the !MochiWeb code is included in the CouchDB codebase,
> mostly because there has been no official release of that library yet.
That point indicated that the direction was to remove external codebases
from the CouchDB source tree.  The mochiweb and ibrowse have slightly
diverged from the base project, so in essence (but not likely in intent)
CouchDB has forked those projects.

I requested that the erlang_oauth commit be reverted until we had a
clarification, but no action has been taken.

The second issue is that there seemed to be a recurring pattern of
significant contributors using Github for feature branches.  This raised the
possibility of the resulting patch not being the work of a single individual
and also removed the development history from the archives.

I reported these issues in the following threads:

The current question is:
On Aug 8, 2009, at 1:39 PM, Paul Davis wrote:


> Maybe its just me but I haven't the slightest what problem this thread
> is trying to solve. Why would we even think about removing our runtime
> dependencies from SVN? I know someone suggested it in thread this
> conversation forked from but I never read discussion about why this
> would be good or necessary.
I'm having problems pointing to a definitive statement that says that these
are things that an Apache project doesn't do, but am struggling to come up
with anything definitive.

I would appreciate review of these threads and appropriate participation
from the Incubator PMC.

To unsubscribe, e-mail:
For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message