Re: Oracle vs Google: APIs are copyright; appeal decision ramifications?

[Richard Fontana]

On Fri, May 16, 2014 at 01:17:09PM -0400, Joshua Gay wrote:
> I don't understand how these things work well enough to formulate my
> own opinion, but I've been hearing mixed opinions on precedent. Here
> is Jonathan Band's take on the matter of precedent,
> :
> 
> "1. The Federal Circuit’s decision is not binding precedent in any
> other case in any district court anywhere in the country. Because
> this case arose in the Ninth Circuit, the Federal Circuit was
> required to apply Ninth Circuit precedent. But its interpretation of
> Ninth Circuit precedent is not binding on district courts in the
> Ninth Circuit, or any other circuit. Thus, a district court in San
> Jose or Seattle is free to ignore the Federal Circuit’s
> misinterpretation of Sega v. Accolade and Sony v. Connectix."
> 
> "To be sure, other district courts may find the Federal Circuit’s
> reasoning to be persuasive, but it is not binding. And as these
> district courts dig into the Federal Circuit’s reasoning, they
> quickly will conclude that it is not that persuasive. The Federal
> Circuit certainly undermined its credibility with its assertion that
> Google and its amici believe that software should not be protectable
> under copyright. The Federal Circuit itself flatly contradicts this
> assertion when it observed that"

FWIW I believe what Jonathan says about precedent here is correct. 

 - RF

Re: Oracle vs Google: APIs are copyright; appeal decision ramifications?

[TJ]

On 16/05/14 18:17, Joshua Gay wrote:


I don't understand how these things work well enough to formulate my own
opinion, but I've been hearing mixed opinions on precedent. Here is
Jonathan Band's take on the matter of precedent,
:

"1. The Federal Circuit’s decision is not binding precedent in any other
case in any district court anywhere in the country. Because this case
arose in the Ninth Circuit, the Federal Circuit was required to apply
Ninth Circuit precedent. But its interpretation of Ninth Circuit
precedent is not binding on district courts in the Ninth Circuit, or any
other circuit. Thus, a district court in San Jose or Seattle is free to
ignore the Federal Circuit’s misinterpretation of Sega v. Accolade and
Sony v. Connectix."


Joshua, thank you. If that analysis proves correct it suggests that Google will 
ask for an en-banc hearing which might clarify things.

I'm working on obtaining some expert legal opinion as to the precise situation 
in the E.U./U.K. and I'll keep a close
eye on how things develop in the U.S.A. In the meantime I'm going to suspend my 
project until the legal landscape is clearer.

Re: Oracle vs Google: APIs are copyright; appeal decision ramifications?

[Joshua Gay]

On 05/16/2014 06:32 AM, TJ wrote:


But, unless I have misunderstood the lawyers (such as the EFF) who have
opined on the Oracle vs Google
appeal decision, the finding that the merger doctrine should be applied
to the time of the original creation, not
the time of alleged infringement, resulting in the fact that APIs can be
copyrighted is now precedent - unless overturned by an en-banc hearing
or appeal to the Supreme court.

>
> "Today's decision puts all of that at risk, potentially handing
> Oracle and others veto power over any developer who wants to create a
> compatible program." [0]

I don't understand how these things work well enough to formulate my own 
opinion, but I've been hearing mixed opinions on precedent. Here is 
Jonathan Band's take on the matter of precedent,

:

"1. The Federal Circuit’s decision is not binding precedent in any other 
case in any district court anywhere in the country. Because this case 
arose in the Ninth Circuit, the Federal Circuit was required to apply 
Ninth Circuit precedent. But its interpretation of Ninth Circuit 
precedent is not binding on district courts in the Ninth Circuit, or any 
other circuit. Thus, a district court in San Jose or Seattle is free to 
ignore the Federal Circuit’s misinterpretation of Sega v. Accolade and 
Sony v. Connectix."


"To be sure, other district courts may find the Federal Circuit’s 
reasoning to be persuasive, but it is not binding. And as these district 
courts dig into the Federal Circuit’s reasoning, they quickly will 
conclude that it is not that persuasive. The Federal Circuit certainly 
undermined its credibility with its assertion that Google and its amici 
believe that software should not be protectable under copyright. The 
Federal Circuit itself flatly contradicts this assertion when it 
observed that"

Re: Oracle vs Google: APIs are copyright; appeal decision ramifications?

[TJ]

On 15/05/14 20:58, Bradley M. Kuhn wrote:

[ I attempted to post a message similar to this on May 12th, but it never
   showed up in the archives nor did I get a copy back via the list as
   I usually do for my posts.  I'm posting again, so if the moderators
   just missed my previous email, please just delete that one and mod
   this one through instead.  Thanks! ]

I'd encourage people to not go off too far in speculating about the Oracle
v. Google case, and/or worrying about how it relates to GPL enforcement or
anything like that.  The case is remanded back to the lower court, and until
a new jury considers the fair use defense, there is not that much to say.
(IANAL and TINLA, of course.)


But, unless I have misunderstood the lawyers (such as the EFF) who have opined 
on the Oracle vs Google
appeal decision, the finding that the merger doctrine should be applied to the 
time of the original creation, not
the time of alleged infringement, resulting in the fact that APIs can be 
copyrighted is now precedent - unless overturned by an en-banc hearing or 
appeal to the Supreme court.

"Today's decision puts all of that at risk, potentially handing Oracle and others 
veto power over any developer who wants to create a compatible program." [0]

That's regardless of the outcome of a fair-use trial in the particular case.

I need to make a decision on whether to continue the work I'm currently engaged 
upon reimplementing a proprietary
API and protocol in a GPL v3 project, or to abandon it before I waste a couple 
of years creating something that cannot
be freely distributed.

[0] 
https://www.eff.org/deeplinks/2014/05/dangerous-ruling-oracle-v-google-federal-circuit-reverses-sensible-lower-court

Re: Oracle vs Google: APIs are copyright; appeal decision ramifications?

[Bradley M. Kuhn]

[ I attempted to post a message similar to this on May 12th, but it never
  showed up in the archives nor did I get a copy back via the list as
  I usually do for my posts.  I'm posting again, so if the moderators
  just missed my previous email, please just delete that one and mod
  this one through instead.  Thanks! ]

I'd encourage people to not go off too far in speculating about the Oracle
v. Google case, and/or worrying about how it relates to GPL enforcement or
anything like that.  The case is remanded back to the lower court, and until
a new jury considers the fair use defense, there is not that much to say.
(IANAL and TINLA, of course.)

But, I admit that I did in fact write a blog post and record and audcast
about the topic:
  http://ebb.org/bkuhn/blog/2014/05/10/oracle-google.html
  http://faif.us/cast/2014/may/13/0x44/

.. so maybe there is a *little* something to be said about it. :)

   -- bkuhn

Re: Oracle vs Google: APIs are copyright; appeal decision ramifications?

[TJ]

On 13/05/14 10:47, Neil Brown wrote:


I am afraid that I have not yet had a chance to get to grips with the Oracle v. 
Google case, but you might find the discussion before the High Court, and the 
Court of Appeal, in the SAS v. WPL case in the UK, to be of interest, along 
with the reference for the Court of Justice of the European Union, in 
interpreting the computer programs directive:

High Court: http://www.bailii.org/ew/cases/EWHC/Ch/2013/69.html
CJEU reference: 
http://curia.europa.eu/juris/document/document.jsf?docid=122362&doclang=EN
Court of Appeal:http://www.bailii.org/ew/cases/EWCA/Civ/2013/1482.html


Neil, those links are just what I was hoping for, so thank-you.

I wrote regarding Article 6 2.(c) and reverse-engineering:


In other words I read this as saying it is legal to use reverse-engineered 
interface specifications of a 'server'
in order to create a 'client', but not to create another 'server' 
implementation, nor to publish
documentation of the interface.


The EUCJ deals with this in paragraphs 60 and 61:

"60. As regards that latter condition, Article 6(2)(c) of Directive 91/250 relating to decompilation states that decompilation does not permit the information obtained through its application to be 
used for the development, production or marketing of a computer program substantially similar in its expression, or for any other act which infringes copyright."


61. It must therefore be held that the copyright in a computer program cannot be infringed where, as in the present case, the lawful acquirer of the licence did not have access to the source code of 
the computer program to which that licence relates, but merely studied, observed and tested that program in order to reproduce its functionality in a second program."



So the EUCJ is saying you cannot reverse-engineer a computer program in order to create a functionally compatible alternative, but you can create a functionally compatible alternative by studying the 
program's interaction with other programs, data files, users, other programs and other systems.


THE EUCJ didn't deal explicitly with API interfaces but on my reading it 
addressed it tangentially in its answers to Arnold J's questions 1 to 5 and 8 
to 9.

In the context of format of data files it said:


"43. In that context, it should be made clear that, if a third party were to procure the part of the source code or the object code relating to the programming language or to the format of data files 
used in a computer program, and if that party were to create, with the aid of that code, similar elements in its own computer program, that conduct would be liable to constitute partial reproduction 
within the meaning of Article 4(a) of Directive 91/250."



I take "liable to constitute partial reproduction" to mean, it would infringe.

In the context of discussing the use of the original program's user manual 
being used by the defendant as a specification for writing its alternative 
implementation, the court said:


"70. Consequently, in the light of the foregoing considerations, the answer to Questions 8 and 9 is that Article 2(a) of Directive 2001/29 must be interpreted as meaning that the reproduction, in a 
computer program or a user manual for that program, of certain elements described in the user manual for another computer program protected by copyright is capable of constituting an infringement of 
the copyright in the latter manual if—this being a matter for the national court to ascertain—that reproduction constitutes the expression of the intellectual creation of the author of the user manual 
for the computer program protected by copyright."



I parse that as saying that Program A and User Manual A have copyright protection if they are expressions of Author A's intellectual creation. That being the case, if Author B creates a (functionally 
compatible) Program B and/or a User Manual B based on a reading of User Manual A, then either or both of Program B and User Manual B may infringe on the copyright in User Manual A.


Arnold J interprets the EUCJ in the following terms in paragraph 16:


"In my judgment, the CJEU's answer to Questions 1-5 amounts to an endorsement of Pumfrey J's interpretation of Article 1(2) of the Software Directive. In short, copyright in a computer program does 
not protect either the programming language in which it is written or its interfaces (specifically, its data file formats) or its functionality from being copied. ..."



He goes into more detail in later paragraphs under the heading "SAS data file formats" and much of that is detailing that the plaintiff failed to raise amended issues early enough and therefore cannot 
do it now so avoids any detailed investigation in respect of data file formats.


He concludes that defendants did not infringe on the plaintiff's copyright in 
User Manual A but not for the obvious reason:


"53. I remain of the view that, for the reasons I gave in my first 

Re: Oracle vs Google: APIs are copyright; appeal decision ramifications?

[TJ]

On 14/05/14 04:24, Fernando Cassia wrote:

On Mon, May 12, 2014 at 1:44 PM, TJ  wrote:

It seems to impact reverse engineering too, since most black-box reverse
engineering techniques aim to observe the external interactions of an
executing binary and then write an interface specification (API) from which
a compatible implementation is written in a clean-room environment.


But you forget another way to get interoperability: justice and
regulators. Microsoft for instance was forced by regulators to open up
their networking protocols and APIs, as a result of which SAMBA can
implement compatible versions.


I do not forget - competition law forcing the sharing of otherwise 
(proprietary) copyright-protected information
is only useful where a single organisation has a dominant market position 
(monopoly) in a relevant market.

That is completely orthogonal to my questions about Copyright and doesn't help 
in the majority of instances
where someone would wish to publish an alternative implementation of some API.

It also doesn't help in the U.S.A. where there isn't the same regulatory 
oversight.


The documentation created as part of the EU settlement with Microsoft
helped us to make the Samba 4 Active Directory Compatible domain
controller code robust and reliable when interoperating with Microsoft
AD domain controllers.


That was a welcome outcome, but it took from 1998 to the end of 2007 to obtain the specifications under NDA, cost €1, and required the relentless pursuit of Microsoft by the EU commission through 
massive fines even after judgment and appeals.



Most other open protocols (ie TCPIP) are open by design (from the
start).  Maybe this ruling will have a positive impact: make people
weary of closed protocols and APIs that do not have an open source
implementation.

If this means more use of SIP and less use of Skype, all the better.


Agreed. It also calls to mind Cisco's behaviour over HSRP and VRRP.

The issue I've had in mind in bringing up this subject is how it affects open-source implementations. If it holds that APIs are copyright absent a fair-use judgment, then any existing open-source 
implementation of a (proprietary) copyrighted API could find itself threatened by a litigious API copyright owner, and as copyright terms are so much longer than patent it would effectively destroy 
any realistic prospect of alternative implementations surviving.



Yes, some surely will be hurt, ie WINE and ReactOS... but it's my
belief that they can challenge MSFT to open their APIs on competition
(antitrust) grounds...


I refer back to my earlier comments on the use of competition law.

I have been working on a GPL v3 implementation of a widely used proprietary 
protocol and had worked, until now, on
the assumption that APIs aren't copyrightable but after this appeals decision 
my primary concern has switched from
the technical challenges to the legal. I do not want to get to the end of what is a very time-intensive project which will probably total a couple of man-years only to discover that I am unable to 
legally publish my work.

Re: Oracle vs Google: APIs are copyright; appeal decision ramifications?

[Neil Brown]

On 12 May 2014, at 19:23, TJ  wrote:

>> Hi
>> Short version
>> In EU have already decided that api is not copyrighted. it was a trial a
>> company implement api/function of another program and program languaes. and
>> it is fair use and you have right reimplement.
> 
> My reading of directive 2009/24/EC contradicts your interpretation.
> ...
> 
> This text seems to carefully carve out "ideas and principles" that "underlie 
> its interfaces"
> as not being protected, but it doesn't say interfaces as expressions aren't 
> protected.

I am afraid that I have not yet had a chance to get to grips with the Oracle v. 
Google case, but you might find the discussion before the High Court, and the 
Court of Appeal, in the SAS v. WPL case in the UK, to be of interest, along 
with the reference for the Court of Justice of the European Union, in 
interpreting the computer programs directive:

High Court: http://www.bailii.org/ew/cases/EWHC/Ch/2013/69.html
CJEU reference: 
http://curia.europa.eu/juris/document/document.jsf?docid=122362&doclang=EN
Court of Appeal:http://www.bailii.org/ew/cases/EWCA/Civ/2013/1482.html

There is summary here: 

http://www.scl.org/site.aspx?i=ne34424

but, as with the case itself, “tortuous” is a fair description.



Enjoy :)


Neil

__

Neil Brown
n...@neilzone.co.uk | http://neilzone.co.uk







signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Oracle vs Google: APIs are copyright; appeal decision ramifications?

[TJ]

On 11/05/14 21:36, Magnus Olsen wrote:

Hi
Short version
In EU have already decided that api is not copyrighted. it was a trial a
company implement api/function of another program and program languaes. and
it is fair use and you have right reimplement.


My reading of directive 2009/24/EC contradicts your interpretation.

Article 1 2. says:

"Protection in accordance with this Directive shall apply to
the expression in any form of a computer program. Ideas and
principles which underlie any element of a computer program,
including those which underlie its interfaces, are not protected
by copyright under this Directive."

This text seems to carefully carve out "ideas and principles" that "underlie its 
interfaces"
as not being protected, but it doesn't say interfaces as expressions aren't 
protected.

I've not (yet) looked at the individual member states laws that implement the 
directive
but I doubt the wording will vary significantly from this.

Article 6 2.(c) prevents the use of interoperability interfaces deduced from 
inspecting the operation
of copyrighted works:

"to be used for the development, production or marketing of
a computer program substantially similar in its expression,
or for any other act which infringes copyright."

In other words I read this as saying it is legal to use reverse-engineered 
interface specifications of a 'server'
in order to create a 'client', but not to create another 'server' 
implementation, nor to publish
documentation of the interface.

In the Oracle vs Google situation an analogy would be that it is legal to 
observe the external
interfaces of the Java runtime (RT) library and Java virtual machine to create 
Java applications that
interface with the VM and RT, but not to create another JVM or RT 
implementation.

In the case of Apache Harmony its reimplementation of the Java Class Library 
API was based on the published
Sun SDK Specification and the associated license which permits reimplementation 
that fully reproduces the
specification and passes the TCK.

Google stripped back and modified parts of Harmony, which is the basis upon 
which Oracle's law-suit has succeeded, since without
permission via the SDK license Google had no other license to reimplement a 
reduced or changed API, if APIs are copyrightable as the appeals court has 
found.

In the case of an API that is published, it seems to me that creation of a 
competing implementation may be infringing
if the API documentation license restricts its use for that purpose, or, if the interface 
contains something other than "ideas and principles".

I'm currently working on a GPL v3 project that may be affected by this decision 
and the E.U./U.K. law.

Maybe Neil and Andrew can give their expert view on the current interpretation 
in the E.U./U.K. of this directive as it pertains
to 'interfaces' and pointers to any case law?

Re: Oracle vs Google: APIs are copyright; appeal decision ramifications?

[TJ]

On 11/05/14 17:14, Fernando Cassia wrote:

On Sat, May 10, 2014 at 8:55 AM, TJ  wrote:


>If in creating an interoperable project - let us imagine something akin to
>the Samba developers re-implementing the Microsoft SMB/CIFS and related
>protocols, or the WINE project's reimplementation of the Win32 APIs, or the
>OpenJDK project re-implementing the Java APIs - then the very fact that the
>law assumes that the APIs are copyrighted and a trial on fair-use is the
>only way to determine whether or not there is copyright infringement will
>have the effect of stopping most interoperability projects in their tracks.


When writing about things, it's generally a good idea to first know what
one is talking about.


The key phrase is "...let us imagine something akin to..."; I was giving 
examples of the type of project that (re)implements
a significant de-facto industry standard API to achieve interoperability. The 
same could apply to cloud services APIs being
re-implemented for cross-service portability as in, for example, Eucalyptus, 
OpenStack and CloudStack.

The appeals court decided that the trial court erred in pinpointing the time at 
which the creative expression occurred (the merger doctrine).

Until now it has been generally accepted in the development community that this 
would be the time at which the interoperable
alternative was created and this was the interpretation the trial court adopted.

The appeals court determined that is incorrect; the correct point in time is when the original expression occurred - in this case, when the Java developers at Sun designed the API. The upshot of that 
interpretation means that an interoperability project could not legally create an alternative implementation (in the U.S.A.) on the assumption that the API was not subject to copyright; the only way 
to determine legality would be for a trial and the fair-use defence before a Jury.


"Oracle also argues that the district court erred in invoking interoperability 
in its copyrightability analysis.
Specifically, Oracle argues that Google’s interoperability arguments are only 
relevant, if at all, to fair use
— not to the question of whether the API packages are copyrightable. We agree."

The appeal court further affirmed the trial court's 'scenes a fair' decision in respect of the specific defence Google raised using that doctrine. The EFF (and others) also raised this issue in their 
Amici Curiae briefs to the appeals court.


"On appeal, Google refers to scenes a faire concepts briefly, as do some amici, 
apparently contending that,
because programmers have become accustomed to and comfortable using the 
groupings in the Java API packages,
those groupings are so common place as to be indispensable to the expression of 
an acceptable programming
platform. As such, the argument goes, they are so associated with the “idea” of 
what the packages are
accomplishing that they should be treated as ideas rather than expression. See 
Br. of Amici Curiae Rackspace US, Inc.,
et al. at 19-22."
...
"Finally, Google’s reliance on the doctrine below and the amici reference to it here are premised on a fundamental misunderstanding of the doctrine. Like merger, the focus of the scenes a faire 
doctrine is on the circumstances
presented to the creator, not the copier. See Mitel, 124 F.3d at 1375 (finding error to the extent the trial court discussed “whether external factors such as market forces and efficiency 
considerations justified Iqtel’s copying of the command codes”). The court’s analytical focus must be upon the external factors that dictated Sun’s selection of classes, methods, and code

— not upon what Google encountered at the time it chose to copy those groupings and 
that code."


I see no reason why, on a literal reading of the appeal court's decision, the 
same reasoning will not be
applied to, for example, the command-line arguments of discrete binaries, 
network protocols in respect of the data structure
symbols and ordering, or 'standards' along the lines of POSIX/SUS.

It seems to impact reverse engineering too, since most black-box reverse engineering techniques aim to observe the external interactions of an executing binary and then write an interface 
specification (API) from which a compatible implementation is written in a clean-room environment.


Because copyright terms are so long it seems to me to have the potential to be 
far more disruptive than the U.S.A.'s Software Patent problems.

Even for interoperability developers outside the U.S.A. this has major 
implications if their software is likely to be imported into the U.S.A.; both 
for them and their users.

Re: Oracle vs Google: APIs are copyright; appeal decision ramifications?

[Bradley M. Kuhn]

TJ wrote:
> What are the potential ramifications of the U.S.A. appeals court decision
> in Oracle Vs Google, that APIs are copyrightable and the only question now
> is whether such use is fair-use?

I wrote a blog post on Saturday about this that might be of interest:
  http://ebb.org/bkuhn/blog/2014/05/10/oracle-google.html

> Could the lawyers amongst us provide some guidance especially as the
> decision may affect interpretation of API protection outside of the U.S.A.?

As I noted in my blog post, please note that lawyers don't have magic pixie
dust that they give them in law school to understand things.  The Courts are
discussing a matter of public policy.  I suggest that non-lawyers should have
a say in that too and we should listen to what non-lawyers have to say, too.


However, my TL;DR answer is that there is very little to conclude until
the fair use trial happens.  There are some interesting things in the ruling
to read and think about, but since it remands back to the lower court,
this isn't definitive precedent.

IANAL and TINLA.

   -- bkuhn

Re: Oracle vs Google: APIs are copyright; appeal decision ramifications?

[Fernando Cassia]

On Sat, May 10, 2014 at 8:55 AM, TJ  wrote:

> If in creating an interoperable project - let us imagine something akin to
> the Samba developers re-implementing the Microsoft SMB/CIFS and related
> protocols, or the WINE project's reimplementation of the Win32 APIs, or the
> OpenJDK project re-implementing the Java APIs - then the very fact that the
> law assumes that the APIs are copyrighted and a trial on fair-use is the
> only way to determine whether or not there is copyright infringement will
> have the effect of stopping most interoperability projects in their tracks.


When writing about things, it's generally a good idea to first know what
one is talking about.

OpenJDK is an ORACLE-sponsored project. Other firms contribute to it,
including Twitter, IBM, SAP, Apple, RedHat, and AMD.
In fact, Oracle has made OpenJDK 7 the reference implementation of Java7
and then for Java8 with OpenJDK 8 too. Oracle programmers contribute code
to OpenJDK and OpenJDK is the basis for the commercial and freeware builds
of Oracle JDK.

It's not a re-implementation, it's the official Open Source implementation
of Java.

See this to learn what OpenJDK is about, and the ecosystem around it
(including Oracle)
http://www.redhat.com/summit/2012/pdf/2012-DevDay-OpenJDK-Bhole.pdf‎

IBM Joins OpenJDK
http://www.sutor.com/c/2010/10/ibm-joins-the-openjdk-community/

SAP joins OpenJDK
http://scn.sap.com/community/open-source/blog/2011/07/14/sap-joins-openjdk

AMD and Oracle team up for Java GPU acceleration
http://scn.sap.com/community/open-source/blog/2011/07/14/sap-joins-openjdk

Apple and Oracle announce OpenJDK for Mac OS X
http://www.apple.com/pr/library/2010/11/12Oracle-and-Apple-Announce-OpenJDK
-Project-for-Mac-OS-X.html

Oracle makes OpenJDK the Java7 reference implementaiton
http://www.infoq.com/news/2011/06/openjdk-bylaws

Oracle open sources JavaFX 2.0 as OpenJFX under GPL license
http://openjdk.java.net/projects/openjfx/

Oracle open sources JavaFX 2.0 for iOS and Android
http://www.infoq.com/news/2013/02/javafx-ios-android

Oracle releases Nashorn, the next'generation Javascript engine for the
Java VM in Java8 and OpenJDK 8
http://www.dzone.com/links/all_about_oracle_nashorn_the_nextgeneration_javas.html

So your mixing of WINE (for which your reasoning has a point) with OpenJDK
is misguided and potential FUD...

FC
-- 
During times of Universal Deceit, telling the truth becomes a revolutionary
act
Durante épocas de Engaño Universal, decir la verdad se convierte en un Acto
Revolucionario
- George Orwell