Comments

• NotZed

  2014-05-11 01:31:18

  So I read through the google/oracle decision and I see nothing in there that would affect free software developers.
  
  In this specific case all the code in question is available under GNU GPL (version 2 + classpath exception), meaning that at least in part this is a GNU GPL violation by google - which oracle is defending. i.e. if google used the GNU GNPLv2+classpath exception version of the openjdk, Oracle could not sue them.
  
  Secondly the interface was simply copied - akin to taking a good chunk of the header files in /usr/include and stripping out the comments and license headers (and if you don't think that is copyrighted material, why do they all have copyright headers?). This was not a clean-room re-implementation.
  
  And lastly although the question of fair use was not decided it was discussed. The defence of using it for interoperability has some pretty glaring problems as google clearly did not create an interoperable implementation - and have said as much. The intention was instead to to leverage the language's familiarity with external developers for the commercial benefit of google. Basically google pulled an embrace/extend/extinguish move, and somehow gets lauded for it by those who should be most aware of them.
  
  But the most alarming revelation comes in the last 3 pages. Google was apparently arguing that copyrights shouldn't even apply to computer software and it should only be covered by patents. Quite rightly the court rejected this wholesale but this line of thinking is about as 'evil' as you can imagine. It would essentially end all commercial software development by individuals and SMBs too small to employ eye-pee lawyers, and greatly affect non-commercial software development - free software or otherwise.
  
  I recommend reading it, it's not that long and much of it is well written and shows a good understanding of the technical issues involved and explains each decision clearly and succinctly.
  
  The basic gist seems to be that google could have created another programming language runtime (possibly with the same language syntax) to perform the same function, but instead intentionally created a direct copy of an existing one. This is the source of the copyright infringement.
  
  It also seems to hint that the fair use defence of 'interoperability' should fall flat because google explicitly stated android was intended not to be java. They were simply utilising it's popularity and familiarity and the existing tools in order to accelerate their own commercial interests.

• Dr. Roy Schestowitz

  2014-05-11 05:36:34

  I don't share these views and in a post later today I will explain why. For now, here's another interpretation:
  
  

  Appeals Court Doesn't Understand The Difference Between Software And An API; Declares APIs Copyrightable

  
  
  [...]
  
  We sort of expected this to happen after the appeals court for the Federal Circuit (CAFC) held its oral arguments back in December, but CAFC has now spit at basic common sense and has declared that you can copyright an API. As we noted, back when Judge William Alsup (who learned to code Java to better understand the issues in the case) ruled that APIs were not subject to copyright protection, his ruling was somewhat unique in that it was clearly directed as much at an appeals court panel who would be hearing the appeal as it was at the parties. Alsup rightly suspected that the judges on the appeal wouldn't actually understand the issues as well as he did, and tried to break it down clearly for them. Unfortunately, the three judge CAFC panel did not pay attention. The ruling is so bad that legal scholars are suggesting that it may be as bad as the horrific ruling in the Garcia case.
  
  [...]
  
  As for the ruling itself... well... it's bad. The court seems to not understand what an API is, confusing it with software functionality. It also appears to misread Judge Alsup's ruling, thinking that he's mistakenly using a fair use analysis to determine whether or not something is copyrightable. But that was not the basis of Judge Alsup's ruling. He very specifically noted that the "command structure is a system or method of operation under Section 102(b) of the Copyright Act and, therefore, cannot be copyrighted." The CAFC panel doesn't seem to understand this at all.
  
  [...]
  
  It seems fairly clear that the CAFC judges don't understand the difference between an API and software. And thus they make a decision that makes no sense. There is no distinction recognized when it comes to the functionality of an API and how it's entirely different than the purpose of the software itself. This is especially clear towards the end, in which the CAFC ruling misrepresents some discussions on whether certain functionality is best protected by patents or copyright. But the problem is that they misinterpret statements people are making about APIs, thinking that those statements were made about software as a whole. This is just a flat-out fundamental misunderstanding of what an API is, assuming that it's just software.
  
  [...]
  
  Note that "[software]" thrown in before interfaces? Google is talking about whether APIs -- "application programming interfaces" -- are copyrightable. Not whether or not software is copyrightable. And yet the CAFC doesn't even seem to realize this. Ridiculously, CAFC then uses its own misunderstanding and misquote, and points to some of the (many) arguments where people argue that patents are inappropriate for software to dismiss Google's argument about APIs. It honestly doesn't realize that it's comparing two totally different things. What lots of people agree on: software shouldn't be patentable and APIs shouldn't be copyrightable, but software can be copyrightable and API functionality may be patentable. But by confusing APIs and software, CAFC totally misreads both arguments.