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