Hi Curt,
Thank you for bringing up the issue of third-party licensing. I wrote
the OAuth patch that was recently merged into trunk. After your
various e-mails on the subject, I've spent quite a bit of time
researching how things are handled at the ASF, even to the extent of
thinking we need to request a software grant agreement (SGA) from the
original authors of the third-party libraries that we use, as this is
mentioned in the "IP Clearance" page. This did seem rather ridiculous
as all the third-party libraries that we bundle are ASL-compatible.
For example, consider the jQuery library: do all ASF projects really
need to ask John Resig to personally sign a SGA? What if he is on
holiday?
So I asked for further clarification about this on the legal-discuss@
mailing list. The answer is crystal clear: we do NOT need IP
clearance for unmodified third-party libraries. No vote thread is
needed, no SGAs. We just need an ASL-compatible license (which I had
already checked for) and that is sufficient (and of course, add the
appropriate entries to NOTICE and LICENSE, which we have now done).
I have included the full message below as the legal-discuss archives
haven't updated yet. I hope this clears up the issue for you and
anyone else who was curious about this.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jason Davies wrote:
Hi again,
The first time I read
http://incubator.apache.org/ip-clearance/index.html I got the
impression
that a SGA is required before *any* third-party libraries can be
imported into SVN. However, if the library is simply a dependency and
is copied without changes simply to allow bundling, is a SGA really
required?
For example, I have just realised that we also bundle the jQuery
JavaScript library, which is released under the BSD (modified)
license.
Do we need to ask the author to sign a SGA too? And what if we cannot
contact the author of such a library, does that mean we cannot
import it
into SVN even if it was released under an ASL-compatible license?
IP clearance is for code bases which are being imported into apache for
future development. it's not required for unmodified third party library
dependencies. if you do distribution third party libraries, you do need
to follow http://www.apache.org/legal/src-headers.html.
- - robert
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIcBAEBAgAGBQJKgBadAAoJEHl6NpRAqILLx6QQAJ1sBXB6GgXh/XDu24uMamWt
NVrSiAAd1ebn6p4baqagDR9EQGwIM/0jWCXFZkQyMfoxDme+6ukLd2mvtlya3FYc
cdfTSyoTx/ZYLfxIINWsWnK6JLjiTrh4gjytpl7tYxM9QhdqLw0thK216q4n9qWq
fs+KZuN4Oa76SliSoD8qeMcSRZ66WCuFXkhCqmehQdlzmPT9sn7c/W5VEkgQX4fS
f2+ckYQtsYb589mnkT+BcEYhf0RbR0rFelr02teh6cXAcso/wiHQaJd3mwQ7qIVq
Mcbv3JfyLn5vre+siubgdPGUr81fqNaDP6isZh5xYYw5hLGit2P4rxksj22PA6g3
NnorDHIAjvieGip5kPxXsKTfcFmuhntYs4v0siJuGFj292HWQs3ccupSgdFVr4Sc
d1uPo+JXEYni1astp0T6mIb2Hz+2PhF3YO0mQxZw9kfCl5hKh0I/YIMcjB+E8Tmg
M82u7JAOcVC94LiqxjcLi+GDjwRzyUEed+rTXJJqZPm5JWlj57zF/AGD+9kC9NDO
A4qWB5GNqwHrxdlOgTnBUgZ3oPoWYkyA4EGiVGxPEDgCkRkbhO2pm0Pso9jYGiVS
J5i9AbQF1d+jo8+p1znBVlxtEYn5lFgLp/rgvSYzoyToaksWsqJi5dFiNoKIxkcS
5yhjmjJOlbpi9OagHa5b
=9lY3
-----END PGP SIGNATURE-----
--
Jason Davies
www.jasondavies.com
On 6 Aug 2009, at 05:45, Curt Arnold wrote:
The CouchDB now has at least snapshots of three non-ASL licensed,
non-ASF developed projects in the SVN. The following message
suggests that mochiweb in the CouchDB repo is forked and
incompatible with the main distribution:
http://mail-archives.apache.org/mod_mbox/couchdb-user/200907.mbox/%3c000001ca0dbe$72ac9220$5805b6...@[email protected]%3E
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.
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.
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.
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.
Most of the other dependencies are used in the Futon management
client.
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
Ideally, the interfaces with mochiweb, ibrowse and the like should
be designed so that other providers could be substituted without
huge effort.
I do think the Incubator PMC should review the situation, but it
would be good to understand the issues and discuss a path forward
before asking for review.
