This stack overflow answer suggests that this is not CC-By-SA: http://stackoverflow.com/questions/244898/wikipedia-pseudocode-and-ip
On Mon, Jan 18, 2010 at 1:24 PM, Jonathan <[email protected]> wrote: > 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 >
