Groklaw has the goods on Oracle v. Google

I’m expecting you already know about the important Oracle v. Google court case over Android’s use of Java APIs, including both copyright and patent claims. But it would be hard to find a more detailed and direct account than Groklaw’s series of notes from the courtroom like this one from the copyright phase, ultimately subtitled Partial Verdict; Oracle Wins Nothing That Matters.  For the entire ongoing catalog, try this rabbit hole.

Having read direct courtroom reporting and the Court’s own documents, the headlines in some mainstream news outlets declaring Oracle the “winner” and Google “guilty” will start to look awfully remote and more than a little bizarre.  Google has moved for a new case since this jury was unable to determine whether their code constitutes a “fair use” of the Java API, so we might get to see the whole thing play out again.

More likely, the Court itself could deliver definitive resolution to the question whether APIs are copyrightable, particularly if the Court’s opinion converges its EU counterpart in a very recent case (Ars Technica via Google Cache, since the original is 404-ing for some reason).  One can hope.  The EU ruling was particularly bold because it protects reimplementation to the extent of voiding any agreements (read: EULAs) inhibiting that right.  That is a smart extra step in order to make the rights not immediately click-through disposable.

For more, follow along during the trial’s current patent phase at Groklaw.

Posted in News | Comments Off on Groklaw has the goods on Oracle v. Google

National Library of Sweden Rejects OCLC Record-sharing Terms

In as direct and unflinching an account as you are likely to see from a library, Sweden’s LIBRIS nationella bibliotekssystem explains 3 reasons why OCLC WorldCat terms don’t really work for them:
http://librisbloggen.kb.se/2012/04/19/clarification-regarding-worldcat-membership-2/

Tip o’ the hat to the cluegiver Magnus Elder, who asks of Norway’s BIBSYS whether their assessment is based on the same constraints or not.

Rails exploit compromises GitHub, many sites vulnerable

I know patching massive and longstanding security holes doesn’t contribute to “developer fun”, but neither does living in a world where GitHub (and by extension every project that uses it) are vulnerable to direct exploitation:

http://arstechnica.com/business/news/2012/03/hacker-commandeers-github-to-prove-vuln-in-ruby.ars

One Russian coder (Egor Homakov), one well-known exploit, and one high-visibility repo host later… Homakov has made his point, and the fun and games are over.  It would also be high time to review any Rails code you have in production to see if you aren’t subject to the same vulnerability.

It is interesting to see that the Rails community’s initial response was to shift the blame to individual developers.  Basically WONTFIX. But with a massively public exploit in their own back yard, namely a site most of us use daily for development infrastructure, I suspect they are going to find themselves in possession of a newfound energy to establish a secure-by-default fix.

Kudos to github for patching their vulnerability rather quickly, and for reinstating Homakov’s account.