couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan <jdkne...@gmail.com>
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 <jchris@apache.org> wrote:

> On Mon, Jan 18, 2010 at 1:23 AM, Jonathan <jdknezek@gmail.com> wrote:
> > On Sun, Jan 17, 2010 at 11:31 PM, Dirk-Willem van Gulik <
> > Dirk-Willem.van.Gulik@bbc.co.uk> 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 :[


Jonathan

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