
Oracle's history highlights a possible downside to its stance on API copyrights - Bella-Xiang
https://arstechnica.com/tech-policy/2020/03/before-it-sued-google-for-copying-from-java-oracle-got-rich-copying-ibms-sql/
======
emilecantin
I think if Oracle wins, the best thing that could happen is IBM immediately
suing for infringment on SQL. And since Oracle built their whole business on
the SQL standard, IBM should ask for an amount high enough that it's sure to
bankrupt Oracle.

I believe that's a fair price to pay for breaking the software industry.

~~~
speedplane
> I believe that's a fair price to pay for breaking the software industry.

There is a theoretical legal question of whether APIs should be copyrightable,
and then there are the practical issues.

As a purely legal matter, there is a strong (but not slam-dunk) case that an
API is copyrightable. As a practical matter however, everyone in the software
industry has been operating as if APIs were free to copy for decades, and
enforcing such a copyright would break a ton of things.

Practical effects of a legal ruling are generally not "officially" considered
by the judge, but more-often-than-not, they're operating behind the scenes and
judges craft their opinions to support an established status-quo.

~~~
m463
There's an interesting analogy with microprocessor architecture..

I believe the Z80 was a copy of the 8080 architecture - it used the same
binary opcodes but it used an assembly language with different words.

So an API is at source level, so it uses words which seem more aligned with
copyright of text. I wonder what would happen if the api had the text "oracle"
in the function names?

p.s. and amusingly when intel did the 8086, it was source level compatible
with the 8080, but not binary.

~~~
martinmunk
This reminds me of the gameboy copy protection. The device looked for the
Nintendo bitmap in the cartridge boot screen before it continued execution.
That way you couldn't make third party cartridges without stepping on their
trademark. (On mobile so can't find video source)

~~~
tomxor
Interesting, that's pretty cunning... Not indefeatable i wonder? The
interesting thing about cartridges is their potential to house more than just
a ROM, there have been a few HN posts about such games - in one of them it
effectively worked around the physical memory address limitations by switching
blocks based on the contents of a small area of memory.

In this case perhaps a gameboy cartridge could differentiate the sequence of
reads for nintendo bitmap detection (which could be argued as API) and reads
for the actual boot display and present different data... that's assuming they
are separate reads, if the gameboy handles boot display all by itself and
checks in the same step then i guess it's indefeatable.

~~~
thristian
A real Game Boy reads the logo data once to copy it into video RAM, then a
second time to validate it, so a cart with clever hardware can make the boot-
up logo display whatever they want:

[https://dhole.github.io/post/gameboy_custom_logo/](https://dhole.github.io/post/gameboy_custom_logo/)

Of course, you still have to include a copy of the Nintendo logo to get past
the BIOS check, even if it's not displayed, which I think is supposed to be
the trademark infringement.

~~~
tomxor
cool

> Of course, you still have to include a copy of the Nintendo logo to get past
> the BIOS check, even if it's not displayed, which I think is supposed to be
> the trademark infringement.

Yeah i think this is the bit that a brave publisher could have argued in
court, I think for it to be a trademark violation it would have to be visible
somewhere beyond the raw content of the ROM. That's why i'd argue it's
essentially being used as an API token, and trademark definitely doesn't cover
that.

------
0xcde4c3db
I'm not sure I'll ever properly get my head around this case. On one hand,
it's certainly possible to make an intellectually sound argument that APIs are
eligible for copyright. On the other hand, such an argument seems to imply
that IBM PC clones, MS-DOS, and Linux have all been infringing from the start
and it's just that everybody has been too timid to actually enforce their API
copyrights over the course of decades where there were plenty of affiliated
deep pockets to raid. And that seems _really_ hard to swallow.

~~~
wtallis
The idea that so much existing infrastructure would infringe on this new kind
of copyright is tough to accept, but at least it's very straightforward in a
way, with brutal direct consequences.

What I have more of a problem with is that we have no clear precedents for how
API copyright will work in practice if it is suddenly foisted upon the real
world. What does it mean for an API to be licensed under the GPLv2, or any
other copyright license that was written with source code and object code in
mind but not APIs? How will we determine which license agreements executed
long ago should be retroactively considered to include or exclude the APIs?
How many industry standards will have to be assessed for whether the relevant
APIs are available under FRAND licensing terms as the relevant patents usually
are? Is there a distinction between providing vs using an API, for the
purposes of determining copyright infringement?

~~~
speedplane
> The idea that so much existing infrastructure would infringe on this new
> kind of copyright is tough to accept, but at least it's very straightforward
> in a way, with brutal direct consequences.

I don't anticipate a doom-and-gloom scenario if APIs were all-of-a-sudden
copyrightable. Today, open source software is backed by powerful companies,
and there is far less lock-in to any particular set of software functionality.
The likely outcome is that big tech companies would just cross-license their
basic APIs like Win32, SQL, NTFS, POSIX-like functionality, and other basic
interface layers.

Today in 2020, the value is not in the interface, but data. Facebook probably
wouldn't care if you created a clone that used the same API structure. But if
you started imported their user data, you could expect a lawsuit.

~~~
wtallis
Your best case scenario is that hardly anyone attempts to follow in the
footsteps of a resounding Oracle success, and that everyone in the industry is
saddled with huge potential liabilities until a massive multi-year relicensing
project can be completed to confirm who is committed to never trying Oracle's
tactics when they fall on hard times. That _is_ a doom and gloom scenario for
anyone who takes legal threats seriously and doesn't have an IBM-class
mutually assured destruction IP portfolio. It's postulating a series of events
that leaves us with most of the software industry intact, but for the most
part would still be a scenario where the only true winners are the lawyers.

~~~
speedplane
> everyone in the industry is saddled with huge potential liabilities until a
> massive multi-year relicensing project can be completed to confirm who is
> committed to never trying Oracle's tactics when they fall on hard times.
> That is a doom and gloom scenario for anyone who takes legal threats
> seriously and doesn't have an IBM-class mutually assured destruction IP
> portfolio.

This multi-year cross licensing project wouldn't be a big impediment. It
happens all the time in standards setting organizations, and wouldn't slow
down progress significantly.

The worst case scenario would be trolls somehow obtaining the copyright to a
foundational API and collecting money from everyone. That would be a pretty
big annoyance, but that too would't be a doomsday scenario. Patent trolls have
been active for decades and have had minimal impact on overall progress.

~~~
emiliobumachar
"Patent trolls have been active for decades and have had minimal impact on
overall progress."

Where did you get this from? It's mighty hard to quantify what might have
been. Patent trolls disproportionately affect small organizations that are not
on anyone's radar unless and until they deliver. They die with not a roar but
a whisper.

------
wyqydsyq
Man I would absolutely LOVE to see IBM suing the pants off of Oracle and
sending those muppets into insolvency. I don't think there is a single company
in the software industry more widely hated than Oracle today, it seems to me
they have devolved into mere patent trolls because they couldn't figure out a
way to adapt their business model.

~~~
dralley
Time to send in the Nazgûl

[https://lotrgames.fandom.com/wiki/Nazgul#Behind_the_Scenes](https://lotrgames.fandom.com/wiki/Nazgul#Behind_the_Scenes)

~~~
saagarjha
> The term Nazgûl has been used to refer to IBM's cadre of lawyers, with whom
> it has been said that IBM can blacken the sky - particularly with reference
> to the SCO v. IBM lawsuit because they supposedly never sleep, are utterly
> ruthless, and are completely loyal servants to their master.

I thought it was SCO who were the bad guys in that one?

~~~
kick
There were no good guys in that one. There was a bad guy who was wrong, and a
bad guy who was initially right but then tried playing the exact same game on
the other guy.

------
jiggawatts
Whenever I hear Oracle mentioned it reminds me that it's once again time to
re-watch the "Never make the mistake of anthropomorphising Larry Ellison"
rant.

[https://youtu.be/-zRN7XLCRhc?t=2085](https://youtu.be/-zRN7XLCRhc?t=2085)

~~~
sork_hn
Wow that was enjoyable. I had never seen that before.

------
pron
There are some very basic elements of this case that this article (and most
others) miss, which makes me wonder if they'd read the relevant court
documents at all. That Oracle is "trying to copyright APIs" is a popular (and
biased) framing of the case, but this is not at all what they're actually
saying. As I understand the filings, they're saying that _if there is some
already-copyrighted work and you copy substantial portions of it_ , those
portions aren't _exempt_ from copyright if they're "declaration code"
(although the copying, as always, could _potentially_ be fair use). In other
words, it's not a new kind of copyright, but about exemption from established
copyright. So regardless of whether SQL is an API, unless anyone copied
substantial portions of copyrighted code from IBM, this case -- as it actually
is, not as it's presented by some media outlets -- is irrelevant.

It is hard to find any popular blog post that faithfully represents the sides'
claims, so it's best to read what they actually are in one of these locations:

* [https://www.supremecourt.gov/search.aspx?filename=/docket/do...](https://www.supremecourt.gov/search.aspx?filename=/docket/docketfiles/html/public/18-956.html)

* [https://www.scotusblog.com/case-files/cases/google-llc-v-ora...](https://www.scotusblog.com/case-files/cases/google-llc-v-oracle-america-inc/)

~~~
Natsu
Yeah, but Google copied only "declaration code" (i.e. the class structure of
Java to make it compatible). There are a few other lines, yes, but those came
about due to being utterly trivial code that looks more like two people
choosing the same trivial implementation randomly from what I recall.

Also, regardless of intent, this would have the effect of making APIs
copyrightable. That would be _terrible_ for compatibility and would destroy
the viability of a lot of work for no good reason at all, unleashing a lot of
copyright parasites to go around suing for trivial nonsense.

I'm sorry, but this is basically a phone book that can be used by machines of
where to find the code that does X. It shouldn't be copyrightable any more
than the actual phone book and the structure was copied only to make it
compatible.

It'd be like suing everyone for making similar electrical plugs, ignoring how
they have to meet certain requirements to actually fit in the socket.

~~~
namdnay
I was wondering about physical equivalents. Does anyone know if the Torx
system was copyrighted/patented? Not a trademark on the name Torx, a real
protection on that design of screw head/driver

~~~
wtallis
Screw drives are patent territory. Just about every one you've used except the
simple flat head driver for slotted screws was patented at some point.

------
neilparikh
I have a question that's slightly off on a tangent.

The project for some compilers courses is implementing a compiler for a subset
for Java. Would the current ruling mean that doing the project is copyright
infringement?

~~~
speedplane
> The project for some compilers courses is implementing a compiler for a
> subset for Java. Would the current ruling mean that doing the project is
> copyright infringement?

Fair use would probably protect you because you're doing it for non-commercial
educational purposes. But further, this lawsuit is not over the Java language,
but it's libraries.

------
cmiles74
I fully expect the Supreme Court to rule as narrowly as they can on this case.
As others have pointed out, to rule otherwise could potentially disrupt the
entire software industry.

"Alternatively, the Supreme Court could hold that software interfaces are
sometimes eligible for copyrights but that Google's copying falls under the
fair use doctrine. This would save Google from writing Oracle a 10-figure
check, but it could still drag the software industry into a legal quagmire."

~~~
gpm
I'm hoping for a ruling that can be basically summed up as "The merger
doctrine is evaluated at the time the copying takes place, therefore we
reverse the federal circuit and don't have to decide the rest of this
nonsense".

Explanation: The merger doctrine is the doctrine that if there is only one way
to write something it isn't copyrightable/copyright infringement. Alsup (the
original judge) interpreted this as being interpreted at the time Google
copied the API, at which point in time there was only one way to write an API
compatible with existing java programs, thereby killing Oracle's case. The
federal circuit reversed based on the idea that it should be interpreted at
the time of the creation of the copyrighted work, at which time there was no
reason to favor calling something "java.lang.String" instead of
"java.std.String" and so on.

Fair use is _a lot_ more complicated to deal with than the merger doctrine.
Ruling based on it will almost certainly result in a lot more pointless court
cases as people debate whether or not _this_ instance is fair use.

------
kiadimoondi
I think there's a case to be made that there's nothing novel in an API itself
(emphasis on the interface). The novelty comes from the implementation,
whereby competition actually kicks in (novel algorithms, data structures,
storage techniques, etc.). But maybe I'm missing something? I come from a
distributed systems background, so my bias is likely titled.

~~~
rk06
yep, APIs are a work of art. the API you chose would vary a lot by the
individual who designed (and Acceptance tests they were required to pass) as
such, there is a novelty in them. whether it is worth patenting or
copyrighting is separate matter.

~~~
kiadimoondi
I agree there's nuance to the issue, and thst's where the argument is to be
made. But I think it'd be a bad faith application of copyright or patent law,
as your competitive edge largely doesn't come from API design but the product
being interfaced with.

------
deanCommie
I'm split.

IBM wanted companies to embrace SQL - because then people implement
applications already compatible with their database product, and conceptually
could migrate without rewriting their applications.

Amazon wanted companies to embrace S3 - for the same reason. Or maybe they
didn't, but they decided that the API was the least significant compelling
part of their product - that people would still choose S3 regardless of
whether other storage offerings had the same API - for the cost, and
durability.

Sun wanted Google to use Java. Because more developers using the language,
regardless of the underlying implementation is better for the entire
ecosystem.

Oracle doesn't.

So to some degree i do feel like consent matters here. It doesn't matter if
Oracle copied Amazon's S3 API illegally if Amazon doesn't care enough to
pursue it.

Finally, I hate arguments that say "It's just the API". We all know a good API
makes or breaks developer tools.

Ultimately, I feel like it goes without question that a decision in Oracle's
favour will cause irrevocable damage to the industry and permit all sorts of
bad actors to start looking to purchase ownership to APIs just so they could
sue those they consider infringers.

But I can't help but feel that ultimately Oracle has a point :(

~~~
virgilp
> Sun wanted Google to use Java. [...] Oracle doesn't.

By your reasoning, IBM could spin-off a division with intellectual property
rights to SQL, sell it to Google for 10B, who could then claim "we never
agreed SQL should be free!" and sue Oracle into bankruptcy

~~~
cmiles74
Isn't that how the whole SCO vs. Linux lawsuits worked?

[https://en.wikipedia.org/wiki/SCO%E2%80%93Linux_disputes](https://en.wikipedia.org/wiki/SCO%E2%80%93Linux_disputes)

------
slowhand09
Oracle implemented similar technology at a time when organic growth was good
for both companies. More technologist adopting SQL meant more sales for both
companies. Oracle implementations on IBM hardware were and still are pretty
common. I think IBM had no good reason to shoot a competitor that likely was
helping their bottom line via adoption and popularization of database
technology. The industry and the technology were evolving. Squashing it would
have been a bad move for them at the time.

------
enitihas
Oracle seems to have partnered with, surprise, Breitbart, to present their
side on this case.

Source:
[https://twitter.com/joshbloch/status/1237518298922745861](https://twitter.com/joshbloch/status/1237518298922745861)

~~~
jshevek
Breitbart's coverage does not appear severely biased, in this case:
[https://www.breitbart.com/tech/2020/02/21/report-trump-
backs...](https://www.breitbart.com/tech/2020/02/21/report-trump-backs-oracle-
in-legal-battle-with-google/)

(I suppose just saying "Trump backs.." can be a signal indicating what the
Trump supporting readers ought to think. OTOH, the same language on CNN has a
similar effect in the opposite direction.)

------
mqus
If Google wins, will that weaken the AGPL? Doesn't the AGPL pretty much
copyright APIs?

~~~
cyphar
No, the GNU AGPL doesn't have anything to do with copyright of APIs question
(at least, no more than any other copyright license given these court
decisions). After all, the GNU AGPL was published in 2007 -- long before this
whole legal battle started and even before Android itself was released.

The GNU AGPL has additional restrictions that require redistribution of the
source code under the GNU AGPL to users which access the software _over a
computer network_ (AFAIK those particular restrictions have not yet been
tested in court, so it's entirely possible that they're unenforceable).

------
ggm
two things

1) the comparison may be inapplicable. The case in hand does not rise or fall
on hypocrisy. I am a bad actor does not forbid me pursuing a law case based on
the law I break myself in another matter.

2) IBM has at least three strategies

a) leave alone: let sleeping dogs lie b) pursue oracle but settle for cash or
in-kind or IPR swap or RAND, or some outcome which advantages them (Redhat?)
but nobody else c) be an advocate for a movement and take a posture in the
wider interest.

What do you think is more likely?

------
hyperpallium
Copying a functional spec - like for SQL - is fine. But copying implementation
code is not (unless that's the only way it can be implemented).

Unethicalprotip: publish proprietary source to bait copying. Then sue.

~~~
speedplane
> Copying a functional spec - like for SQL - is fine. But copying
> implementation code is not (unless that's the only way it can be
> implemented).

Why are specs fundamentally different than implementations?

~~~
wtallis
I think by "Copying a functional spec" he meant to say _implementing_ someone
else's functional spec, rather than just _re-publishing_ it. So that what's
being copied is not the copyrightable text of the spec, but the non-
copyrightable abstract ideas described by the spec.

~~~
speedplane
> I think by "Copying a functional spec" he meant to say implementing someone
> else's functional spec, rather than just re-publishing it. So that what's
> being copied is not the copyrightable text of the spec, but the non-
> copyrightable abstract ideas described by the spec.

Implementing an API spec is not just using the "abstract ideas" in the spec.
It requires copying the specific text of the API: a function named DoSomething
will incompatible with one named do_something.

I don't think that's a valid way to distinguish copying APIs and
implementation.

On a purely theoretical basis, I do think APIs could be copyrightable, I don't
think there is a valid way to distinguish them from implementation. The main
argument against copyrighting APIs is practical: everyone has been doing it
for decades, and changing the status-quo will be disruptive.

Another practical reason is that copyrighting APIs will decrease competition
by impeding companies from creating better drop-in competitor products to
established players. But this is really an argument against all software
copyright, not just API copyrights.

