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

Gear

Groklaw Gear

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


You won't find me on Facebook


Donate

Donate Paypal


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
Oracle v. Google - Further Questions from the Bench on Interoperability | 214 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Oracle v. Google - Further Questions from the Bench on Interoperability
Authored by: Anonymous on Monday, May 21 2012 @ 10:01 PM EDT
I doubt if there is a "program" that you ever want to try to
get to work in both environments. To be honest, the
semantics related to the operating environment (eg UI,
foreground work, background services, threads etc) differ
enough that you'd want to write a program from near scratch.

But what any programmer wants to do is to write a program
(or a library) efficiently and with high quality.

From a programmer perspective, this means having a
recognizable development environment - with the tools and
APIs you are already comfortable with, and access to the
same 3rd party libraries - preferably without having to go
through recoding, which is bound to introduce new bugs.

From an ongoing maintenance perspective, you want to keep
*one* working source. Once you have to branch the source to
create a version that would work in Android, you are forever
consigned to having to copy bugfixes and improvements
between the two versions. In this sense, "write once, test
once, maintain once" is an important concept.

[ Reply to This | Parent | # ]

Oracle v. Google - Further Questions from the Bench on Interoperability
Authored by: Anonymous on Monday, May 21 2012 @ 11:14 PM EDT
> Programmers can always learn a new vocabulary.

But a language is not just vocabulary, it is also semantics.

There is a reason that the airline industry uses English. It is for
interoperability of the people. Saying that an English pilot who wants to fly to
Rumania "can always learn a new vocabulary" would miss the point.

Java is what they want to use and this includes java.math.float.

In any case most Java programmers will have their collection of useful class
libraries for utilitarian and business logic use and they will want to reuse
these (which they can if the underlying API is there) without having to re
implement them.

[ Reply to This | Parent | # ]

Oracle v. Google - Further Questions from the Bench on Interoperability
Authored by: indyandy on Tuesday, May 22 2012 @ 02:17 AM EDT
Java:
static double atan2(double y, double x)
Returns the angle theta from the conversion of rectangular coordinates
(x, y) to polar coordinates (r, theta).

Hypothetical language:
static double atan2(double x, double y)
Returns the angle theta from the conversion of rectangular coordinates
(x, y) to polar coordinates (r, theta).

Did you spot the difference?
Given another 20 similar differences wouldn't an experienced Java programmer
explicitly avoid learning 'Hypothetical language' as the subtle API differences
would be too confusing and have potentially catastrophic consequences?

[ Reply to This | Parent | # ]

This is the core here
Authored by: xtifr on Tuesday, May 22 2012 @ 05:40 AM EDT

Programmers can always learn a new vocabulary.
Sure, Google could have written a completely new language from scratch. But then they'd have to persuade programmers to learn that new language. With many languages, including Java, C++, Python, Perl, and Lua, learning the standard libraries is the biggest part of learning the language, and nobody who isn't familiar with at least the core of the standard libraries can honestly claim to be fluent in the language. The standard libraries are generally considered part of the language!
They can always run scripts to rename methods in old programs.
Maybe, in theory, though in some cases, it may require hard AI to proved the proper conversion, but the point is that they could do the same thing with the language itself. There's nothing special about an API--it's just more vocabulary in the language.

Google chose Java because they wanted programmers to be able to use a language they know, and the API in question--the Java standard library--is, for all intents and purposes, part of the language. If they'd had to write their own APIs, they might as well have written their own language to go along with it, because 90% of the benefit of using Java would be gone.

(In Tcl, the syntax is such that parts of add-on libraries are often moved to become part of the core language itself, with no change to the way they're used, except that commands to load the library become redundant. Just to emphasise how much an API is like an extension to a language.)

We agree that APIs are functional, though. And that is another reason they're not copyrightable. But specifically, they're a means for expression, not an expression themselves. They're vocabulary, not prose. And vocabulary isn't copyrightable.

---
Do not meddle in the affairs of Wizards, for it makes them soggy and hard to light.

[ Reply to This | Parent | # ]

Replying to all of the above posters...
Authored by: PolR on Tuesday, May 22 2012 @ 10:04 AM EDT
I agree with you. Changing the API is as problematic to the programmers as you
say.

Does copyright law care?

If the programs stop interoperating then we have proof that the API are
functional. Copyright law cares about that. Functional elements are not
copyrightable. But where is the case law that says the impact on the programmers
means the APIs are not copyrightable?

Here I try to find what it is that the judge care about when he asks his
questions. This is not the same as what the programmers care about.

[ Reply to This | Parent | # ]

Oracle v. Google - Further Questions from the Bench on Interoperability
Authored by: Wol on Tuesday, May 22 2012 @ 02:50 PM EDT
The problem with running a script is that the new program is a derivative of the
old.

In other words, as far as copyright is concerned, NOTHING HAS CHANGED.

Cheers,
Wol

[ Reply to This | Parent | # ]

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 )