decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.


Contact PJ

Click here to email PJ. You won't find me on Facebook Donate Paypal


User Functions

Username:

Password:

Don't have an account yet? Sign up as a New User

No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
Newspicks | 287 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
App Developers File Amicus Brief in Support of Google ~pj
Authored by: Anonymous on Tuesday, June 04 2013 @ 11:52 PM EDT
amicus briefpdf is missing

[ Reply to This | # ]

Corrections
Authored by: Kilz on Tuesday, June 04 2013 @ 11:59 PM EDT
Please list the mistake in the title of your post.

[ Reply to This | # ]

Off Topic
Authored by: Kilz on Wednesday, June 05 2013 @ 12:00 AM EDT
For all posts that are not on topic. Please make links
clickable with HTML.

[ Reply to This | # ]

Newspicks
Authored by: Kilz on Wednesday, June 05 2013 @ 12:02 AM EDT
Please mention the name of the news story in the title of the
top post. A link to the story is also helpful so others can
read the story when the link falls off the home page.

[ Reply to This | # ]

Comes
Authored by: Kilz on Wednesday, June 05 2013 @ 12:03 AM EDT
Please leave all transcriptions of Comes exhibits here for
PJ. Please post the html in Plain Old Text mode so she can
easily copy it.

[ Reply to This | # ]

Trying to explain APIs to non-geeks
Authored by: PolR on Wednesday, June 05 2013 @ 12:28 AM EDT
There is something more than compatibility involved. There is also reuse of
code.

Let's take the C standard library for example. The whole point of the library is
to implement frequently used functionality once so programmers don't have to
write the print function from scratch every time they want to print for example.
There is one standard print function, written once for all in a library, and
everyone uses that.

You can reuse code in all sorts of settings. You don't need to target an
operating system. Any functionality you want to reuse across multiple programs
may go in a library. You may have a library for file compression and
decompression. You may have another library for telephony over the Internet. You
may have a library to access a database. You may put anything you want in a
library as long as it makes sense to reuse the code.

In this setup there are two pieces of code that need to communicate. There is
the code I write, and there is the library I use. The APIs is how we get them to
talk together. Without the APIs I can't reuse the code in the library. This is
where the Logo analogy comes into play. The libraries are a bit like the Logo
bricks that may be reused and assembled. The APIs plays the role of the bumps
and holes that makes everything fit together.

Compatibility is needed when we want many libraries to be interchangeable. If
they all have the same APIs then the libraries may be swapped without rewriting
the existing programs. There are good reasons for doing that. Someone may
discover a better faster or less buggy algorithm. Then a new improved library
with the same APIs will be compatible with all the existing programs. Or the
license may not be GPL compatible so a new library may be written under a
different license.

Then there is the question of how much must be reused. If the Java libraries are
bloated with more functionality than what is needed, then another smaller more
efficient library maybe written. And if some functionality is missing in Java,
the new libraries may implement it. This new library is not compatible in the
sense that the unneeded functionality of Java is missing and new functions are
not in Java. But the functionality that is available on both libraries is
compatible. The advantage is for the programmers. They don't have to learn a new
series of APIs. And some of their code that use the common APIs can use both
libraries. I didn't check but I think the Android vs Java compatibility issues
are of that kind.

A copyright on APIs is a monopoly on the communication and on the knowledge. You
can't swap the libraries because you can't write an alternative library that
uses the same APIs without permission of the monopolist. If someone proposes an
alternative with different APIs, the coders must learn another set of APIs and
then rewrite all the code using the old APIs. This is a big burden. Then the
monopolists can control the advances in technology because no compatible
advances will occur unless they give permission. Anyone using a proprietary API
becomes locked-in.

I think this is what these lawsuits are about, getting control over the
technology. Oracle says "Android is not compatible" but this is an
excuse to get the court to give them the control they want.

[ Reply to This | # ]

Graphics Artists and APIs?
Authored by: Anonymous on Wednesday, June 05 2013 @ 01:47 AM EDT
What exactly is their stake in this game? Can someone please explain?

[ Reply to This | # ]

Why do the amici briefs focus so much on business models?
Authored by: Anonymous on Wednesday, June 05 2013 @ 05:21 AM EDT
Not coming from a common-law jurisdiction, I have some problems understanding
the focus of the amici briefs:
All the amici briefs published here include very detailed descriptions on how a
decision in favour of Oracle would affect the software industry as a whole and
some business models in particular.
But isn't this something important only during legislation?
Court decisions on the other hand shouldn't be concerned with how they affect
certain business models.
Given the importance of precedents in common-law jurisdictions I've expected to
see many court decisions supporting Oracle's or Google's case. But so far I
failed to see any decision, that hasn't been cited before.
What am I missing here?

[ Reply to This | # ]

App Developers File Amicus Brief in Support of Google ~pj
Authored by: JamesK on Wednesday, June 05 2013 @ 08:22 AM EDT
{
And here is the brief, as text:
}

Why are briefs so long? ;-)


---
The following program contains immature subject matter.
Viewer discretion is advised.

[ Reply to This | # ]

Lego bricks
Authored by: Anonymous on Wednesday, June 05 2013 @ 09:01 AM EDT
Isn't that a worryingly terrible analogy?

The bumps and holes of the lego brick, their sizes and spacing and depth,
_were_ protected by copyright, surely?

[ Reply to This | # ]

Our Voices: A Power
Authored by: Anonymous on Wednesday, June 05 2013 @ 01:07 PM EDT

We're (most of us I think) laymen as far as the Law is concerned.

Early in the discussion on software patents, I think Lawyers like Gene Quinn were actually laughing at us. I can just imagine them having done so.

The legal voices have been influencing Patent Law for a long time. The legal discussions with the USPTO members. The legal arguments presented to the Federal Circuit. The legal voices have been quite a strong power in molding Patent Law below the Supremes.

And then along come us mathematicians, software developers, philosophers.....

... and we start speaking of why software shouldn't be patented.

Initially we (the general we of course, not any specific individual) spoke from emotion. And they laughed at us because they knew they had the power and thought our voices weak.

And we learned.... P.J. taught us about the Law. And they still laughed at us because they believed that we wouldn't be heard unless we, ourselves, became Lawyers.

And while we learned, our emotions cooled and our logic took over. And we started painting pictures which mapped how we viewed the situation over how the Law viewed the situation. Merging them into a clear picture. And they still laughed.

All the while, the pro-patent-everything (even patent math) lawyers kept coming here to hone their arguments to take to the Federal Circuit... and to the eventual goal: convince The Supremes! Laughing.

And they failed to see that we were honing our arguments all the while as well. That while their greatest tool was to increase complexity and obfuscation of the situation ("look at the flowchart, there must be something patentable there") - our greatest weapon was to simplify. And they still laughed.

And then They came. When They began to come is unknown. How often They came is unknown. How frequently They still come is unknown.

But They started speaking. They spoke in Their authorings and Their authorings started quoting the information found in blogs.

And then the lawyers started to understand:

    Our voices are being heard by the Supremes!
And now they are no longer honing their argument skills against so much as they are trying to convince us that patenting our work - even software, even math - is in our best interest. And they must be frustrated because we refuse to give in to what we view as their faulty reasoning.

Now the lawyers speak from emotion while we speak from logic. We quote from the Supremes authorings while they attempt to argue around those same authorings. Our opinions as to how existing Law applies to our field of expertise are based on citations while their opinions are becoming less and less backed.

The lawyers are no longer laughing.

And worse - they are recognizing that not only could they lose the patent wars.... they could also lose the copyright wars due to a simple factor:

    Functionality!

I wonder if in 20/50/100 years, history will paint the picture outlined above :)

RAS

[ Reply to This | # ]

Microsoft Antitrus does not help
Authored by: argee on Wednesday, June 05 2013 @ 09:26 PM EDT
In the US vs Microsoft, they were ordered to open up their
API's. This was because MS is a monopoly.

It stands to reason that in the absence of a Monopoly
question, or ordered to do so, they would *not* have to
open up their API's.

Oracle is not a monopoly, and they have not been ordered
to open their API's; ergo, by implication, the US vs MS
decision not only does not hinder Oracle, it seems to
support their version.

You could argue (1) Oracle is a monopoly. I doubt this
would fly, but in any case it is not the case at bar;
and (2) They had already released the API's, where in the
case of MS the API's were secret, and the matter was not
a case of Copyright but of releasing them to the public.


---
--
argee

[ Reply to This | # ]

Functionalities
Authored by: Anonymous on Wednesday, June 05 2013 @ 11:58 PM EDT

Functionalities

APIs are functionalities
They're simple functionalities
Forget about your lawsuit and your fight
You know they're functionalities
They're just a bunch of recipes
APIs are free from copyright

Look at the functionality
The basic functionality
Forget about your lawsuit and your strife
Please Oracle eschew the sleaze
You'll save yourself a ton in fees
You've used others' APIs all your life

(With absolutely no apologies to Disney or anyone else who clings to 45 year old copyrights like the great worm Smaug atop his golden hoard. My deepest apologizes to anyone who tries to make it scan or, Heaven forbid, tries to sing it.)

[ Reply to This | # ]

App developers, precision, APIs, blueprints, and non-lawyer amicus briefs
Authored by: bugstomper on Thursday, June 06 2013 @ 08:47 PM EDT
I have been starting typing this comment since the article that mentioned Eugene
Spafford's amicus brief, but it keeps getting too long and I have to put it
aside. So now I will go just for a summary of points and let this lay unnoticed
at the bottom of 256 other comments, probably moments before PJ posts a new
article and nobody will ever see this :)

1. I noticed that the amicus brief from the app developers had some very precise
language that is a better way of expressing things than what led to the
back-and-forth when PJ referred to "SDK" as opposed to
"API". The app developers were very careful to talk about the
"declaring code" of the APIs as opposed to the implementing code. That
is absolutely the correct terminology to include what in C and C++ you find in
headers, and what in Java is extracted from the full source files to generate
the JavaDoc that is used to document the API. We should adopt that language and
say that the argument with Oracle is whether the declaring code of APIs is
copyrightable.

2. Eugene Spafford et al bases much of his argument on a conflation between the
declaring code of an API and the rest of it. Not all of his arguments disappear
if you replace the term "API" with "declaring code of the
API", but I leave it as an exercise for the reader to go through his amicus
brief making that substitution to see where he is really arguing for the
copyrightability of the implementing code.

3. The most fascinating thing I encountered with the Spafford amicus was when I
realized that my argument with his analogy of API as blueprint was based on
deficiencies with the analogy, but there is something much deeper. To clarify,
my initial reaction was along the lines of

"Blueprints have to specify every detail to allow one to build the plans in
a way that satisfy the building codes and the engineering calculations.
Blueprints tell you what material to use with what precise dimensions, and how
they are attached. An API just tells you that you can find the storeroom by
taking a left down that hallway and then three doors to the right, not how to
build the hallway. APIs are not blueprints!"

Then I realized that not being a lawyer I don't know anything about blueprints
and copyrights. Maybe Spafford doesn't know either. So I googled for the
information. I am still not a lawyer, and so still don't know anything, but here
are some interesting details that I found. For the sake of brevity I will not
include links, but all I had to do was a Google search for

is a blueprint protected by copyright?

It turns out that until a law was passed in 1990 expressly to provide better
protection for architectural design, not much about a blueprint was protected by
US copyright law other than the actual drawing on a piece of paper.

From wikipedia:
"As a result, under the 1976 Act, most courts held that even this grant of
coverage to an architect's plans and drawings did not protect an architect's
right to build structures depicted in the drawings. Courts generally held that
both the utilitarian doctrine prohibiting copyright in useful articles and the
idea-expression dichotomy prohibiting copyright in ideas barred protection of
buildings designed from architectural plans."

The extra protections added to architecture under the 1990 law are limited in
certain ways. Again from Wikipedia, talking about the current state of the law
since 1990:

"In order to obtain protection as an 'architectural work' under 17 U.S.C. §
102(a)(8), as opposed to a 'pictorial, graphic, or sculptural work' under 17
U.S.C. § 102(a)(5), the work must include a design of a building. 'Buildings'
are defined in the Copyright Office as 'humanly habitable structures that are
intended to be both permanent and stationary, such as houses and office
buildings, and other permanent and stationary structures designed for human
occupancy, including but not limited to churches, museums, gazebos, and garden
pavilions'. Specifically prohibited from protection are 'structures other than
buildings, such as bridges, cloverleafs, dams, walkways, tents, recreational
vehicles, mobile homes, and boats'."

There's a lot more detail in other links amongst the first page of Google search
results. But you can see that even if the Spafford, et al amicus brief is
correct that APIs are like blueprints, given that an API does not describe a
"humanly habitable structure" which comes under the special provision
of the 1990 act, that analogy does not help Oracle's claim that the declaring
code of an API is or even should be copyrightable.

[ Reply to This | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )