From dev-return-5685-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Mon Aug 10 13:23:01 2009 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 4507 invoked from network); 10 Aug 2009 13:23:01 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 10 Aug 2009 13:23:01 -0000 Received: (qmail 59724 invoked by uid 500); 10 Aug 2009 13:23:08 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 59644 invoked by uid 500); 10 Aug 2009 13:23:07 -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 59630 invoked by uid 99); 10 Aug 2009 13:23:07 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Aug 2009 13:23:07 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jason@jasondavies.com designates 89.145.97.179 as permitted sender) Received: from [89.145.97.179] (HELO www1.netspade.com) (89.145.97.179) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Aug 2009 13:22:55 +0000 Received: from jddavies.gotadsl.co.uk ([82.133.112.184] helo=[10.0.1.2]) by www1.netspade.com with esmtpa (Exim 4.69) (envelope-from ) id 1MaUwn-00080X-I7; Mon, 10 Aug 2009 13:29:59 +0000 Cc: Curt Arnold Message-Id: From: Jason Davies To: dev@couchdb.apache.org In-Reply-To: <29420CCA-62BF-424E-A03D-6B376A0D91FF@apache.org> Content-Type: multipart/alternative; boundary=Apple-Mail-21-1020412643 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 10 Aug 2009 14:22:32 +0100 References: <29420CCA-62BF-424E-A03D-6B376A0D91FF@apache.org> X-Mailer: Apple Mail (2.936) X-SA-Exim-Connect-IP: 82.133.112.184 X-SA-Exim-Mail-From: jason@jasondavies.com X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on www1.netspade.com X-Spam-Level: Subject: Re: Dependencies in SVN X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000) X-SA-Exim-Scanned: Yes (on www1.netspade.com) X-Virus-Checked: Checked by ClamAV on apache.org X-Old-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, HTML_MESSAGE autolearn=ham version=3.2.5 --Apple-Mail-21-1020412643 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit 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$5805b660$@grice@logosworld.com%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. --Apple-Mail-21-1020412643--