couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Davies <ja...@jasondavies.com>
Subject Re: Dependencies in SVN
Date Mon, 10 Aug 2009 13:22:32 GMT
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.


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