couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan <>
Subject Re: Making CouchDB crypto dependency optional
Date Mon, 18 Jan 2010 19:24:10 GMT
On Mon, Jan 18, 2010 at 1:12 PM, Chris Anderson <> wrote:

> On Mon, Jan 18, 2010 at 1:23 AM, Jonathan <> wrote:
> > On Sun, Jan 17, 2010 at 11:31 PM, Dirk-Willem van Gulik <
> >> wrote:
> >
> >> Sorry - that is the algorithm - not the *implementation*.
> > Excellent, thanks very much for the clarification - I'm thoroughly
> > inexperienced when it comes to licensing.  My code was based off of
> > pseudocode listed on Wikipedia and so (I believe) would fall under the
> > CC-BY-SA license - I've updated the Jira issue as appropriate.  Thank you
> > for catching this early.
> Thanks for taking this so seriously. I think it would really help
> CouchDB a lot to have the option to fall back to native crypto in
> environments that don't have the dependencies.

At Dw's clarification, if creating a concrete implementation of the
pseudo-code description of an algorithm counts as a derivative work of that
pseudo-code, the SHA code I've ported falls under CC-By-SA license and so
would be unusable with the Apache license.

That aside, it's quite slow... a better option would be to implement the SHA
portions (from spec alone) in C/++ and access them using Erlang ports.  I
will gladly work on this, but is any code I spit out tainted as CC-By-SA by
the fact I've looked at the imperative pseudo-code? :P

Is there anything sane we can do to add entropy to the random seed --
> anyone have any options on how much more likely this could make uuid
> collisions?

Out of my league, sorry :[


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