On Mon, Jan 18, 2010 at 1:12 PM, Chris Anderson <[email protected]> wrote:
> On Mon, Jan 18, 2010 at 1:23 AM, Jonathan <[email protected]> wrote: > > On Sun, Jan 17, 2010 at 11:31 PM, Dirk-Willem van Gulik < > > [email protected]> 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
