Hacker News new | past | comments | ask | show | jobs | submit login
Google vs. Oracle: The Supreme Court will decide software development’s future? (zdnet.com)
107 points by tosh 5 days ago | hide | past | web | favorite | 161 comments





Here's the SCOTUSblog page for the case. It's got all the related Amicus briefs, and oral will be posted there once it happens (usually a day or two after) that will include a transcript and audio. Doesn't look like a date has been set yet, as far as I can tell. Oyez also usually does an awesome mashup with the transcript and audio from oral argument. I encourage everyone to check out that page. A favorite of mine is below.

https://www.scotusblog.com/case-files/cases/google-llc-v-ora...

https://www.oyez.org/cases/2013/13-132


I really hope they invite plenty of industry leaders to speak. Especially relevant ones like Guido who made Python and his languages API is reused. Theres gotta be others where the API was copied verbatum and the original devs dont mind. Hell OpenJDK was made cause Sun didnt care about API copyright when the GNU peeps made their own libre JDK.

I don't think oral arguments at SCOTUS or other high courts ever work like that. Guido et al can submit an amicus curae brief. Many have for this particular case (EFF, Mozilla, Mapbox, Medium, Patreon, Etsy, and Wikimedia e.g.)

Oral arguments in front of SCOTUS are surprisingly quick and short. I was able to go and sit in the "audience" one day back in 2013, and it took only about an hour for each case (got to see 2 of them).

The point of the oral arguments (at least for the cases I saw) was for the justices to essentially ask clarifying questions to help make up their minds. They had already thoroughly reviewed the case documents, amicus curae briefs, etc.


How do one become an audience of a Supreme Court (or federal courts) trial in the U.S?

Stand in line.

Oral arguements are open to the public, and available on a first come first serve basis.

Generally speaking, court proceeding in the US are open to the public unless the proceeding has been specifically closed to the public.


Get up early and get in line at the court early. The calendar is available https://www.supremecourt.gov/

As others have said, you'll need to stand in line. I recommend going in a warmer month if you can. When I was there, it was March 2013, and it snowed/sleeted the morning of. Luckily, at one point they handed out paper tickets designating your place in line and at that point you could go to the closest cafe to warm up.

Also, at the time, they only allowed the first 50 people in line to be able to sit in the audience to view the entirety of the oral arguments. No idea if it's still the same 6 years later or not. If you were in spot 51+, you had the opportunity to join a rotating group of audience members who would get to enter the court room and view about 10-15 minutes of arguments, before being escorted back out and replaced with another group.


In addition to standing in line, you need to get up really early. IIRC, you probably want to arrive before 5 AM.

If someone makes a good argument in public, lawyers can absolutely reference it in argument. That said, an amicus brief is the best way to bolster a friendly case.

I am somewhat ignorant, so I would love it if someone could fill me in on what I'm missing.

* APIs are just as novel as implementations. API design is hard, and interesting, and it's code just as much as a library is code.

* While in this case it would be nice for Google to win because it's a case of a Proprietary software being used for Open Source, I see a far more daunting problem. I see massive companies like AWS reimplementing open source projects' APIs with proprietary solutions, and I'm not sure if copyleft licensing would be able to protect them if Google wins. That sounds far more dangerous to me than a company being able to copyright its API.

* People say this would be a disaster. Is it not the case that, if this happened, that new and novel APIs could be copyrighted? Why is that bad? The difference between a free/proprietary API is that you can't use a drop-in replacement, but we already avoid proprietary software, or overly restrictive software, all the time. So wouldn't we just continue doing so?

edit: From another of my posts, to put it this way:

To me, if I write a program under license X, it is strange to me that someone can reimplement my program's API under an incompatible license Y. To me, that violates my license, and software licenses are enforced via copyright protection.


APIs are interfaces. If an interface is truly innovative in some important way, the proper way to protect it is with a patent, not with copyright. Of course, then you'll have to actually prove that it's sufficiently innovative - and, conversely, somebody could challenge your patent and strike it down by e.g. providing examples of prior art.

If all APIs are copyrighted, then interoperability goes out of the window. How far do you think would F/OSS have gone if it couldn't re-implement Unix enough to be reasonably compatible? The story of Linux vs Hurd tells volumes right there.


Books are protected even if they are not innovative, programs are protected even if they are not innovative. Why should interfaces not be?

Referring to the article in [0], facts are not copyrightable.

If you're going to write some code, then you usually choose to base your work on a particular language, which means you copy a lot of the design decisions and original work that went into it, and that is hopefully what everyone wanted ITFP. You (or O'Reilly) copyright a thorough description of the language's syntax, not the syntax itself. An API's function signatures are a more specific and elaborate kind of syntax, but all are just facts about the world now that someone published the thing. edit: I mean that the uncopyrightable fact is that "if you are going to use this thing, here is exactly the way it must be done".

This goes much further than 'imitation is the sincerest form of flattery'. The reason e.g. Microsoft published the reference for MFC is because they wanted people to be able to use it, and actually use it. My shallow opinion is that interfaces are like that. You want people to build on top of it rather than making up a new and utterly foreign thing every time, so you want people to copy the exact things about it that make this possible, correctly.

You could argue that Oracle didn't own any of the code that different bits of Android were interfacing with, so they didn't have any incentive there. But that only means Oracle forgot or doesn't care about that thing called 'mindshare'. People learning and using identical interfaces "should" have been something that Oracle wanted.

(I don't mean to imply any notable similarity in the two cases, but people knowing when and where the trains were running-- so they could use those and keep on deciding to use those-- "should" be something that MTA wanted.)

On the side, obsessing over protection is precisely what I've said is distasteful about the GPL.

$0.02

[0] https://news.ycombinator.com/item?id=22002272


You Seem to Assume that the language in question and the API’s must have identical license requirements. Sure, if someone write a novel in English they can get a copyright on the book but not the language. But If I invent a different language and publish it in a book, why should I lose the rights to it simply because of what the language is or how people would use it. You can’t copyright the European history because it’s facts, but you definitely can hold a copyright to the Written. history of Westeros.

Also, just to note. Even authors of completely proprietary languages want people to use them. Only they also want to make money when people use term. The intention that people should use your product does not give anyone rights to copy outside of license allowances or to break copyright where that applies.


> You Seem to Assume that the language in question and the API’s must have identical license requirements.

Maybe. I seem to be saying that with both languages and APIs, licensing-related restrictions are worse than useless. Anyone can go write a compiler that translates a pre-existing language into object code, right? If you can insist on being the only one who can compile your language, good luck getting people to write in it.

> But If I invent a different language and publish it in a book, why should I lose the rights to it simply because of what the language is or how people would use it.

Which rights? Isn't that the original question, the one of what rights are implied as 'granted' when you publish a thing, such as 'the right to read and understand it'? (No I didn't purchase your book, I found it at a library.) You don't "lose the rights" to it, that sounds a bit like false dichotomy. You merely would not have had all the rights you had hoped, from the beginning.

---

I can almost see it Oracle's way: they own all the results of a great deal of work that Sun('s employees) did, and later on Google managed to avoid a chunk of that work and so help their own bottom line. Google also takes advantage of the industry's pre-existing familiarity with it. I still think Oracle is on the wrong side of common sense because Google was also helping Oracle's thing stay popular by increasing the motivation for anyone to gain familiarity with it, and I would call it a fair trade. But that's me, and my business sense is rather like a phantom limb.


"If you're going to write some code, then you usually choose to base your work on a particular language, which means you copy a lot of the design decisions and original work that went into it, and that is hopefully what everyone wanted ITFP. You (or O'Reilly) copyright a thorough description of the language's syntax, not the syntax itself."

Yes, exactly like APIs.

"An API's function signatures are a more specific and elaborate kind of syntax, but all are just facts about the world now that someone published the thing. "

This is just plainly not true.

Nobody on this thread has given a reasonable argument as to why APIs are not more or less like code.

In fact, almost everyone's attempt to demonstrated that 'API s are different that code' have done the opposite, and highlighted how similar they are.

I believe HNers just don't like copyright, and don't like Oracle.


> This is just plainly not true.

This is DH3. [0] I need some more red meat. :)

> Nobody on this thread has given a reasonable argument as to why APIs are not more or less like code.

I think they did, though. An API is designed and written, and then it is "a design". (OK "an interface" but that's jargon, the design and formal requirements and patterns are what matters) Code is designed and written, then it is "an implementation". If there's anything special about your design so that you want to control how and whether people are legally allowed to implement it, you get a patent, not a copyright. Then (IINM which seems probable because IANAL) the separate (perhaps royalty-paying) patent licensee can still copyright their own implementation. Don't get me wrong-- I don't want even more patents around software, I just hope people will call things what they are. I have to admit that I could merely be mincing words, if only because that's what I want to accuse someone else of doing. I don't envy the court.

[0] http://www.paulgraham.com/disagree.html


Yes, that's actually a good attempt at making the case, along the lines of some some of the amicus brief filings. (Most of the arguments on this thread are missing the point).

So here is where people are crossing streams I think:

'The interface' to something is not copyrightable as the law says today - fair enough.

But the description of said interfaces may in fact be.

In many cases, probably most, the API is literally part of the code - which is copyrighted already.

So it might be possible that the articulation of an interface is a creative work like anything else, but the implementation is not.

So you can release an implementation of some copyrighted platform - that does the exact same thing with the exact same interface, but the description of said interface in some descriptive language is copyrighted.

The paradox of the fact that the API is often part of the copyrighted code ... is hard to get past.


This part is pretty settled, I think - an .h file is copyrightable, for example, because it is code (that happens to define an API). That's fine, well-established, and people have worked around it for a long time now - e.g. MinGW uses their own <windows.h> for this exact reason, even though it describes the same API as the one that comes with MSVC.

The question at stake is whether the API itself is copyrightable, and that workaround is therefore not sufficient.

It has been conflated in this particular case, because IIRC there were some infringement claims around the literal contents of the .java files, and others over the "structure, sequence, and organization" (i.e. the API proper). But then for that first part, Google pointed out that in Java, there is usually only one way to describe one particular API; and if you use the standard coding style, then even independent definitions will end up looking the same verbatim.


> MinGW uses their own <windows.h> for this exact reason, even though it describes the same API as the one that comes with MSVC.

I thought they provide their own because they don’t want to assume that MSVC is installed too.


If it weren't copyrighted, they could have just copied it as is, instead of rewriting it from scratch.

The file may be copyrighted, but the discussion here is whether the API is or not.

In this subthread, we were discussing "the interface something is not copyrightable as the law says today, but the description of said interfaces may in fact be". The header file was an example of how this is already generally assumed to be the status quo - the API is not copyrighted, but the particular description of that API, in form of <windows.h> that ships with MSVC, is copyrighted. So MinGW could do this for Win32 API, so long as they rolled their own header.

Yes, thanks. As I see it, that 'conflation' to me is a not just some odd mangling of issues, it's a material to the nature of what's being created.

> ou want people to build on top of it rather than making up a new and utterly foreign thing every time, so you want people to copy the exact things about it that make this possible, correctly.

As the copyright holder you are free to grant that right to anyone. In fact, if Google wins, you just won't have a choice in the matter. If Oracle wins it's far more inline with how licensing currently works - the developer chooses who and how their code is used.

Ironically enough, Oracle winning gives developers more power over their code. Google winning will allow any large company to replace open source software with proprietary software with no ability for devs to protect themselves.


> if Google wins, you just won't have a choice in the matter.

> Google winning will allow any large company to replace open source software with proprietary software with no ability for devs to protect themselves.

Can you back this up? What should I be reading if I wanted to convince myself that this is true? What if I'm not releasing a FOSS library (and necessarily publishing the API) which I hope people will use if only to justify the time I spent designing and implementing it?


> Can you back this up?

This is just the way licensing works today. So just take the existing rules for a software license and apply them to an API.

> What if I'm not releasing a FOSS library (and necessarily publishing the API) which I hope people will use if only to justify the time I spent designing and implementing it?

If Oracle wins you are the copyright holder of that code, including the API. So feel free to let anyone use it if you would like.

Oracle winning means you get more control over your code. Google winning means you have no control over the API.


> This is just the way licensing works today.

I remain unconvinced.

> If Oracle wins you are the copyright holder of that code, including the API.

I said "what if I'm NOT", as in, "how will this ruin everything for me in the most common case, that of being only a user?"

But I am planning a library and it is meant to be free-as-in-sunlight if it ever gets there. I'm not worried, I just find it easier to agree with those who are saying the opposite. They seem to think Oracle winning will be precedent for an incredible amount of control to be exercised by software publishers, especially regarding operating systems... this would basically throw a bucket of sand into the proverbial gearbox, for everyone, down to the last user.

Not everyone wants more control. On the flip side, not everyone wants more users just for the sake of proving they made a more useful thing.

IIUC Google winning means I have to be mentally prepared for someone to someday take advantage of my work, which is what I wanted from the very beginning. Whether or not that feels "fair" depends entirely on my definition of "fair", not the court's. Anyone who decides to do that will have paid me a compliment, unless of course someone reuses my work to do something specific that I happen to really dislike. But people are very different from me, so that's almost inevitable, and I might not even learn about any of it, and anyway I accept the possibility.


If Google wins it basically re-establishes the status quo. Unless you think things are a disaster now I don't really understand your conclusion.

>The difference between a free/proprietary API is that you can't use a drop-in replacement, but we already avoid proprietary software, or overly restrictive software, all the time. So wouldn't we just continue doing so?

Right now we can drop in implementations as we see fit. Oracle's win would mean all proprietary APIs become vendor lock in. This would be a massive sea change that would shake the industry (possibly many industries?) to its foundation.

>it's code just as much as a library is code

APIs enforce a representation. We are free to re implement the functionality of other software without copying it verbatim. Any implementation of an API will produce an exact copy of code at the API boundary. This is inescapable and we should not treat this as copyright infringement.


> Unless you think things are a disaster now

Reread the comment, like "I see a far more daunting problem."


A good analogy might be the special provisions in copyright law for the design of typefaces.

In the US, as I understand it, copyright does not apply to those designs, although it can apply to a specific description of the design such as a font file on a computer.

This is not because typeface design isn’t a creative activity; clearly it is, and as such the usual arguments for the copyright incentive would apply. However, that must be balanced against the public benefit of being able to communicate unfettered. In the case of typeface designs, the view was taken that the public benefit was more important.

It seems to me that a directly analogous argument can be made for APIs in software. While making a good API is certainly skilled creative work, allowing the API to be restricted by copyright would be a huge barrier to interoperability and competition.


It goes both ways. WINE is a free implementation of windows apis. After an oracle win, widows could sue to stop development of wine.

But it has always gone both ways with software licensing.

Copyrighting API means there no longer is operability allowed, not only between proprietary and open source software, but also between incompatible open source software. For example ruling in Oracle's favor means no ZFS on Linux.

Your concern about Amazon implementing proprietary solutions using open source API I believe is not an issue. I actually can't see it being one. It's like a proprietary service using TCP/IP. I don't think it would be easier to write an open source client, if there was a proprietary stack that copyright would prevent you from implementing anything compatible with it.


> also between incompatible open source software. For example ruling in Oracle's favor means no ZFS on Linux.

Can you please elaborate here? I don't understand what you mean.

It is already the case that you can not relicense software under and incompatible license.

> I actually can't see it being one.

Let's say I write an amazing database. It's open source, and my license dictates that any modifications to the source code get contributed back.

Someone else clones the repo, guys everything except the APIs, and reimplements what's inside. They then release this under an incompatible, proprietary license.

Why is that ok? It seems like a clear violation of the intent of my copyright. And it's already what we see AWS doing, so this is obviously a lever that large companies are willing to pull.


> Why is that ok? It seems like a clear violation of the intent of my copyright. And it's already what we see AWS doing, so this is obviously a lever that large companies are willing to pull.

Why does it seem this way?

> Someone else clones the repo, guys everything except the APIs, and reimplements what's inside. They then release this under an incompatible, proprietary license.

So you mean, they don't even use your source code? For all you know they used 0% of your source code (for example the source of your amazing database was in C++, and they implemented theirs in Rust). Why should Amazon's completely different amazing database that shares zero implementation details of yours be contributed back?

Another bad side effect of things like this is that potentially things like `Shape` and `sort` become copyrightable APIs. If oracle has copyright on Java APIs, that prevents other people from implementing better/other versions of the Java sort function (maybe it's faster, but unstable), you can't implement that.


Why does it seem what way? Like a violation? For the same reason that it would be a violation of my license if they copy/pasted the code and just made some modifications to the implementation, then released it under a proprietary license.

> So you mean, they don't even use your source code?

They delete the implementation but keep the API. But sure, let's say they deleted 100% of the code just for argument's sake.

> that shares zero implementation details of yours be contributed back?

My opinion is that APIs are implementation details. I completely fail to see why some people are insisting that APIs are not code.

> Another bad side effect of things like this is that potentially things like `Shape` and `sort` become copyrightable APIs.

Doubtful. For one thing, they exist across tons of languages - you can't copyright the work of others.

> If oracle has copyright on Java APIs, that prevents other people from implementing better/other versions of the Java sort function (maybe it's faster, but unstable), you can't implement that.

Not true. Oracle's copyright would not extend outside of their enterprise / separately licensed APIs. If people choose to use those APIs they are accepting Oracle's copyright, which is an obvious mistake that they should avoid.

Copyright is not there to protect you from making a bad technical decision If Java's APIs were all copyrighted the obvious choice would be to not use Java.

Same reason why companies ban using libraries that are AGPL3.


> Why does it seem what way? Like a violation? For the same reason that it would be a violation of my license if they copy/pasted the code and just made some modifications to the implementation, then released it under a proprietary license.

Copyright, historically has only extended to the concrete work in question. Other protections, like patents or trademarks are for concepts. Steamboat Willie is protected by copyright, but generic depictions of Mickey Mouse are trademark protected.

If as you claim, someone can delete all the code but still maintain copyright, that's a fundamental change to how copyright works: it now extends to ideas and concepts, not just things. This has deep impacts due to how copyright works vs. those other things.

Let's talk about some of the weird outcomes:

> I completely fail to see why some people are insisting that APIs are not code.

Well, in Haskell, APIs are built from fundamental mathematical properties. Is `sort :: [a] -> [a]` copyrightable? We don't consider mathematical constructs to be covered by patent, so while a specific sorting algorithm might be patentable, the API wouldn't be. But now the API is copyrightable. So the mathematical construct can be copyright protected. That's weird.

> Doubtful. For one thing, they exist across tons of languages - you can't copyright the work of others.

This fails the Rule Utilitarian test: If we rewound time to the mid 1950s, and set intellectual property law to what you're proposing, someone could have copyrighted `sort`, and `sprintf`, and `malloc` and `cat`. GNU could never have appeared because the APIs that GNU copied would have been copyright protected by the Unix authors.

So that's a big issue. What else?

> If Java's APIs were all copyrighted the obvious choice would be to not use Java.

This is easier said that done, I believe your proposal actually breaks the GPL, because I can fork and add a new API surface to a GPL-licensed piece of software, and then use API-copyright to prevent others from making further changes. So currently GPL software would need to be relicensed under a hypothetical GPLv4 that fixes this loophole.


> Copyright, historically has only extended to the concrete work in question.

APIs are concrete work.

> it now extends to ideas and concepts, not just things.

APIs are things as much as code is.

> Well, in Haskell, APIs are built from fundamental mathematical properties. Is `sort :: [a] -> [a]` copyrightable?

No. sort as an API is both fundamental and preexisting.

> If we rewound time to the mid 1950s, and set intellectual property law to what you're proposing, someone could have copyrighted `sort`, and `sprintf`, and `malloc` and `cat`.

Maybe. But that's fine. Someone would have just written their own APIs and licensed in a way that allowed others to use them - the way all software development has gone for decades.

I'm sure there were many proprietary 'malloc' APIs that ended up going nowhere, and one one cares today. The ability for developers to license the code was in fact a major deciding factor in APIs surviving - I'm sure we'd see many APIs today, given copyrightable APIs.

> GNU could never have appeared because the APIs that GNU copied would have been copyright protected by the Unix authors.

The Unix authors could have granted permission (not saying they would). Just because someone holds the copyright doesn't mean they restrict usage - hence the entire open source ecosystem having developers own their copyright, and how the vast majority release that copyright under a liberal license.

Or, as stated above, someone would have released their own APIs and granted their copyright via the license they chose, and those APIs would be what we have today

> This is easier said that done,

We do it all the time. Companies largely ban some licenses, such as AGPLv3. The same exact thing will happen with proprietary or overly restrictive licenses on APIs.

The fundamental question here is who owns the code. IF Oracle wins, the developer owns the code - this is much closer to how code copyright already exists, but extended to APIs. IF Google wins no one can own that code, developers lose control over their own work.

> because I can fork and add a new API surface to a GPL-licensed piece of software, and then use API-copyright to prevent others from making further changes.

I'm not sure that that's true, but even if it were that doesn't "violate" the GPL, it acts in accordance with the license.

The question here is if licenses we apply to our code should extend to our APIs. Again, developers have more power in a world where Oracle wins, and less power in a world where Google wins.

Further, I feel that things have changed quite a lot. Everyone has been burned by poorly licensed code that has gone stale, and can no longer be modified. Open source has won this fight already.

I am far more concerned about the future, as tech companies grow massive, and consolidate. We already see AWS implementing open source APIs with drop-in replacements. If Google wins you kill any ability for developers to protect themselves against that. If ORacle wins you give open source developers back their greatest weapon (Software licensing), and they can create licenses that restrict the ability for massive companies to reimplement their open source code as a proprietary service.


> APIs are concrete work.

So in the case of an API re-implemented without copying any code, what concrete work is taken? If not the code, then what thing?

> APIs are things as much as code is.

I can print out code and read it. I can't print out an API and read it. (I can print out documentation of an API, which is copyrightable, but I cannot print out the API itself).

> No. sort as an API is both fundamental and preexisting.

What makes sort fundamental but other things...not fundamental? Historically copyright has been pretty straightforward: if there's a physical thing (like a written work, in the case of code) you can copyright it. Now you're adding weird rules like "well some apis are obvious and fundamental but others aren't". Who dictates that?

> Maybe. But that's fine. Someone would have just written their own APIs and licensed in a way that allowed others to use them - the way all software development has gone for decades.

The problem here is that it means that people can, for example, api-squat. Which is terrible. Imagine the ML craze of recent years, but with Google or Facebook or whomever copyrighting the tensorflow API so that other libraries couldn't be tensorflow compatible without licensing to Google. Sure, companies could just not use Tensorflow, but it was like a half a decade ahead of the competition, and had the backing of basically the largest Machine Learning practitioner in the world. An Open Source version could maybe compete, but probably not.

> Again, developers have more power in a world where Oracle wins, and less power in a world where Google wins.

Some individual developers have more power, but the development community has less freedom.

> The fundamental question here is who owns the code.

No, the fundamental question here is if an API is copyrightable. Oracle very clearly owns the code. The question is if the concept of how to do something is a copyrightable work in the same way that actually doing a thing is. A map is not the same as a taxi, and you're saying that the protections we give taxis should also extend to maps all of a sudden.

> I am far more concerned about the future, as tech companies grow massive, and consolidate. We already see AWS implementing open source APIs with drop-in replacements.

But you don't seem to consider that Amazon probably already has an answer to API-licensing.

> they can create licenses that restrict the ability for massive companies to reimplement their open source code as a proprietary service.

No, what you're saying is that companies can restrict the ability for competitors in the same space by building arbitrary lock-in. Companies can already use licensing to prevent competitors from stealing their work, but what you're suggesting is that a competitor can prevent others from entering the space. Consider the opposite situation: Spanner and CockroachDB. If Google decided to license its API, cockroachDB couldn't exist, or at least couldn't compete. Your ideas cut both ways, they don't magically fix things for the little guy.


We wouldn't have Linux, BSDs, or MacOS, or any of our modern web infrastructure, if AT&T had been able to maintain a monopoly on the UNIX API design.

Those came out to scratch an itch. If AT&T had maintained a monopoly on UNIX API, someone else would have scratched the itch. Maybe someone would have designed an interface and explicitly granted public reproduction rights, as many products have done before UNIX and after.

So even with this change, we'd still likely have most of not all of the same overall solutions, derived from other places.


> Can you please elaborate here? I don't understand what you mean. It is already the case that you can not relicense software under and incompatible license.

According to some groups (Canonical, Nvidia, VMware etc.) you can use proprietary/incompatible licenses with (not in) the Linux kernel by using a shim. This shim construction or other compatibility layers relies on the argument that you don't have to relicense at all, but that just using/implementing the API is fine.

The Oracle case has the possibility of changing this logic completely, making all shims/compatibility layers illegal and possibly making all software GPL.


Because the API is not code. It's that simple

It is implemented through code, but it isn't.

> Let's say I write an amazing database. It's open source... Someone else clones the repo, guys everything except the APIs, and reimplements what's inside

It's fine to copy the essential parts to maintain interoperability, so that's fine. But then again, API is not code so "guts everything besides the API" is almost moot.


You can say an API isn't code but it doesn't make it true. Even if it somehow were true, code is hardly the only thing copyrightable, even in software.

> Can you please elaborate here? I don't understand what you mean.

> It is already the case that you can not relicense software under and incompatible license.

Yes you can't, but currently in case for example Linux and ZFS and even BSD and ZFS. Programmers were able to use ZFS (note, it is Open Source but under CDDL) by implementing so called shim, that was providing API that ZFS was expecting. Ruling in favor of Oracle will make this illegal.

Even within Open Source it could became a problem, for example FreeBSD implements Linux ABI (it's binary version of API) which allows it to run Linux binaries natively. Depending if the other side is hostile, this might no longer be allowed. Same thing with Wine. The law would prevent interoperability between all kinds of software, that's bad thing for all users, it's already difficult.

> Let's say I write an amazing database. It's open source, and my license dictates that any modifications to the source code get contributed back.

> Someone else clones the repo, guys everything except the APIs, and reimplements what's inside. They then release this under an incompatible, proprietary license.

> Why is that ok? It seems like a clear violation of the intent of my copyright. And it's already what we see AWS doing, so this is obviously a lever that large companies are willing to pull.

First of all, creating a good API is not trivial, but it is nothing compared to developing the actual product. If someone went the effort and create their own database from scratch that someone (especially if it is Amazon) would provide their own API, even today when it is legal to use someone else's.

They would be concerned that having to follow other API would limit them, also it would make it easy to replace their product with Open Source alternative.

You're saying that Amazon is already doing, I'm guessing you mean Aurora PostgreSQL and MySQL. In those instances they are using existing Open Source products and just replaced the storage layer with their proprietary. They can do this, because license permits them already. PostgreSQL license allows for commercial use without sharing code, MySQL is GPL but most likely they paid Oracle for the proprietary license. Ruling in Oracle's favor won't change anything there.


> Depending if the other side is hostile, this might no longer be allowed

It seems like it would be license compatible.

> The law would prevent interoperability between all kinds of software, that's bad thing for all users,

Only between incompatibly licensed interfaces.

> First of all, creating a good API is not trivial, but it is nothing compared to developing the actual product.

It could be, depending on the implementation.

I don't know what your next few sentences are saying.

> I'm guessing you mean Aurora PostgreSQL and MySQL

No. I mean their proprietary reimplementation of Rabbit, Cassandra, and MongoDB.


If your code is floss then amazon or whoever could just fork the code and just use it in their backend. If that is okay with you then why is complete reimplementing it not okay? In both cases customers are directed away from your wallet.

Let’s not go all draconian here. Copyrighting APIs just means you need approval from the original owning entity to do interoperability. Which again comes down to licensing. Why should the creator not own what they create and why should others not be forced to seek approval or license to use it? You might say “but the purpose of APIs is integration! How can they sue people for using it for integration?” But it seems obvious that they would be able to sue people using Oracle DB without license even if they are using it for its intended purpose.

> API design is hard, and interesting,

OK, fair enough.

But plenty of difficult and interesting things are not patentable.

> and it's code just as much as a library is code.

It doesn't execute, so it's not code!


Java code doesn't execute either. It is compiled to a different representation, and then interpreted or compiled again by a different program. And that binary representation has a translation for `void foo(int a)` just as much as it does for `x = new Object()`.

Even if there were any technical merit to this idea that API definitions are not code, I still don't think it would mean anything. Copyright law applies to human expression, not to code specifcally.


If it's text it's code. The fact that it doesn't do anything doesn't enter the argument.

1. By that logic this post is code;

2. I just entered it into the argument!


All text is copyrightable including source code and the comment you just typed. In fact when you look at TOS for websites you'll notice that you give an indefinite copyright to works by yourself on their platform including images, posts, comments etc etc etc.

The fact that the code is never executed doesn't enter into the argument.

The argument is whether a clean room reimplementation violates their IP rights.


Libraries don't execute either, unless someone wraps them in an implemented program.

And this is about copyright, not patents, right? Oracle has apparently already lost the patent case.


Isn’t that a bit like saying cars don’t drive unless a driver gets in them?

I don't know, is it? I don't like analogies.

This comes down to what is and is not copyrightable. 'Code', whatever that is, very obviously is copyrightable - hence licensing. 'APIs' are now being separated from code by Google to support their claim that they did not violate Oracle's copyright.

To me, if I write a program under license X, it is strange to me that someone can reimplement my program's API under an incompatible license Y. To me, that violates my license, and software licenses are enforced via copyright protection.


How can you own the interface to an implementation? Can someone copyright toString() or appendToKeyValueDataStore() in a given language?

Honestly, given that I literally write Java code for a living and think this case is mega confusing (granted, I've spent roughly 6 minutes reading about it), I am skeptical about the SC's ability to render a sensible verdict. But, meh, maybe it really can be abstracted out a legal principle.


> How can you own the interface to an implementation? Can someone copyright toString() or appendToKeyValueDataStore() in a given language?

How? The same exact way I own copyright to all of the code I write. It's the same exact system.

Yes, someone could copyright those if they weren't fundamental, obvious, and preexisting. The same way that if I write a novel new implementation of a String it is copyrighted under whatever license I choose. The same way that a new codec is copyrighted, etc.


I'm not a legal guy, so I don't know.

It just seems a bit funny that the example you give to point out how obvious this standard must be is an implementation, not an interface. It would be weird to me that if I created a different String implementation with the same interfaces as your, that is prohibited.

I guess that with Java it's a little bit more straightforward, because the interface is a file that you must have created. But what if I create EvenBetterInterface and convince people to swap it out in their dependency injection and use my implementation, which otherwise has the same interfaces as yours? I feel that the interfaces they are talking about are supposed to be more that classical type of interface (a definition/promise with NO implementation details but assurance of functionality), and not the straight up Java (jesus christ, im sorry) "implementation" of an interface.


> But plenty of difficult and interesting things are not patentable.

We're talking about copyright, not patents though.

Books, not mouse traps.


Plenty of difficult and interesting things are not copyrightable, too.

> I see massive companies like AWS reimplementing open source projects' APIs with proprietary solutions

This may feel wrong to some, but emulating the API of the famous thing is bread and butter of software interoperability.


Funnily enough, music of all industries is having their own similar "come to Jesus" moment with copyright along the same lines of the Oracle v. Google case.

All code (and music) is math, at it's core. It's a pipeline of transformation functions that end up getting a particular system to do a particular thing (or assortment of alternating musical notes and silence that make up an experience).

The problem comes in that when everyone converges to the same tools and ways of doing things, you end up running into copyright induced paralysis innovationwise. Over time, there is a trend toward "nothing new under the Sun". Once this point is reached, copyright poisons landscape for everyone. No one is free to innovate, because that innovation is dependent on some schmuck who won't just let their copyright die.

The entire bloody concept of copyright is one of the most intellectually destructive forces on the planet. The fact we've entertained this farce this long is testament to humankind's love of the long-period, delayed-activation foot-gun.

Also, to respond even more to your point, API's are meaningless in the end. The Binary is what runs, and all it takes is a pass by a code mangler to fundamentally change the character of code to make it a derivative work.

Will it be as warm, comfy, and human readable necessarily as the original? No. Will the binary generated from it run exactly the same? Yepper. You bet it will. It's part of what makes copyrighting any particular program on a Turing Machine farcical. You don't want me using yours? Fine. Give me a bit to rejigger and reimplement with a slightly different naming convention or approach to optimization.

Boom. Equivalent functionality, completely different source code. Almost as if computer code were some sort of mathematical construct.

We cannot afford to maintain this litigious stature when the means of production and innovation exist in everyone's hands. It's not a case of one company trying to get one over on another. It's a case of a handful of people stomping their feet and saying "How dare you put in the work to make me irrelevant! Someone force them to pay me!"

We need to cut the time of copyright, and leave enforcement of it alone, or we need to seriously weaken the enforcement severity if we're looking at fundamental technological building blocks getting locked away behind the threat of an angry legal department.

And no, in case anyone is wondering, anything I write for myself, I pretty much just implicitly release to the public domain. I don't want to have to solve the same problems over and over again, just slightly different and for a different boss this time; nor do I want anyone else to have to.


> The entire bloody concept of copyright is one of the most intellectually destructive forces on the planet.

What if somebody accidentally leaves their personal diary on a park bench. A finder quickly locates the author and returns the diary, but not before they make a copy, which they're about to publish to the world. Is that okay? Should the author not even have a right to control public disclosure--that is, a right of first publication?


Don't go leaving personal diaries on park benches. Especially when legal action has non-trivial chance of exposing the contents as a matter of public record anyway.

And regardless, that is a substantively far cry from how Oracle is trying to employ copyright. The Java API's are no mere diary left on a bench that the evil Google has taken to publish and profit from.

Think of the precedent this would set. You'd open the door to never being able to right the Pair<K.V> API in any form. Oracle owns it. Sorry. You weren't the first to write it.

You'd open up a gold rush scenario. Imagine someone writing a generator, or going and publishing micro-API's doing nothing but squatting on the most logical or attractive signatures, structures, and ergonomics that everyone would converge toward or independently rederive. It'd be like domain squatting, but absolute leagues worse. You'dactively degrade the ability to innovate and write easily readable code all because you wanted to treat an interface as something you should be allowed to lock the rest of the world out of.

That's insane, pure and simple, and makes a mockery of what copyright was intended to actually do.

To go back to your journal on a bench example; I'd be willing to accept a right to protest over the unintended publishing of a creative given the caveat that it not in any way be extended to anything that has to with source material for executable code, or anything that is broadly reducible to math. I even grant this reluctantly, because you're still enshrining the same artistic time bomb if you don't enforce strict, and shorter time limits to the copyright term, or the specific aspects protected by it.

Copyright was intended to incentivize creative work (I.e. the process of doing the creative work) not to create a framework whereby upon compiling a large enough basis of creative works as intellectual property an entity with a sufficiently funded legal department can shut down or render perilous the landscape of creative endeavor simply by virtue of everything having been seen/done in one shape or another before. The legal system, and corporate portfolio's in particular have created a situation where entire generations of people can come and go without being able to reintegrate and iterate on older experiences.

We communicate and perpetuate our understandings, mores, and common experiences in our time on earth through these activities; the risk and cost of freezing out our descendants ability to practice by stripping them of the very giant's shoulders on which we were ourselves placed upon our arrival into the world is real, and even today is fundamentally changing the shape of the field as we are now more than ever concerned with trying to wring as much as possible out of the smallest crumb of similarity.

I'm probably edging into rant territory at this point, but while I recognize valid interest in enforceable copyright your example represents, I cannot accept Oracle's assertion that their Ali's would constitute the same phenomena in kind, or that it is right to have any creative work locked away for a lifetime. The experience, takings away, and derivations of the audiences it influences should hold the same level of sanctity as the original work. Especially if redone independently or utilized in a novel way.


EU courts got it right, and declared APIs non copyrightable already. Time for US Supreme Court to do the same, and fix the mess lower courts created.

I hope the supreme court understands the significance of this. This decision will change the direct history of the world.

Congress could change the law if it doesn't like how the ruling goes.

As they should. Software IP needs a new domain of IP protection outside copyright/patent/trademark law.

This is the domain of the legislature, not the courts. We shouldn't shoehorn in an interpretation we like or don't like because of the failure of the law to adapt to new kinds of content and culture towards it.


> This is the domain of the legislature, not the courts. We shouldn't shoehorn in an interpretation we like or don't like because of the failure of the law to adapt to new kinds of content and culture towards it.

The courts are the fallback when legislation comes into question. It's not a perfect system but it attempts to balance itself out. For example, laws that violate your constitutional rights can be challenged in court, as they should.


For anyone who is curious about this line of thinking, I'd recommend reading a little bit of Neil Gorsuch's "A Republic, If You Can Keep It." The book covers these ideas very well.

On the other hand it's dry, repetitive, and has really poor flow, so I'm struggling to finish it myself.


Throughout history, Congress has leaned heavily on the side of rights holders. I would love it if this would be a wake up call for Congress that overzealous copyright protection has stifled innovation and contributed to the current rent-seeking business models in entertainment.

Rent seeking is everywhere these days. Not just entertainment. Sure major studios have realized they can actually collect more revenue by sharing their entire libraries (opposed to selling single dvds) but so have developers who favor building and renting luxury apartments over single family starter homes. Or the monthly subscription box craze. Or Amazon scheduled deliveries.

The Supreme Court makes tons of decisions that change the direct history of the world. The Court has decided many cases FAR more important than this one.

While I’m really hoping that Google wins this, I also hope that the Supreme Court applies the law as they see it, without any consideration at all for the social impact. If you want a law change, you should be hoping to see that come out of the legislature, not a branch of government that specifically does not have legislating powers.

Something to consider in the case of copyright law is that the copyright is explicitly justified in the Constitution by the potential benefit to society[1]. A large part of this case comes down to the meaning of fair use and whether ownership of API is justified according to the cost/benefit that it presents to society.

[1] US Constitution: "To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries"


The supreme court did relative recently a decision on a constitutional challenge in regard to copyright when people argued that the Copyright Term Extension Act was unconstitutional. The general rule that came out of the judgement is that copyright law is constitutional as long as it observes the distinction between expression and idea, which the Supreme Court said is the constitutional guarantee, provided that fair use rights are adequately maintained.

For most people it would seem obvious that a 95 years in additional to the life time of the author is counter productive if the goal is to promote the progress of Science and useful Arts, and the limited time part lose its meaning when it keep getting extended, but that is the situation we are in. The meta interpretation I heard after that decision is that the supreme court do not want challenge Congress on the topic of copyright law.


Copyright is not a constitutional right, which you’d see if you hadn’t trimmed the opening phrase of that section out of your quote

> Clause 8. The Congress shall have Power * * * To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries.

https://law.justia.com/constitution/us/article-1/50-copyrigh...

All this does is allow for Congress to pass copyright legislation, without violating the 1st amendment, which it otherwise would.


> All this does is allow for Congress to pass copyright legislation, without violating the 1st amendment, which it otherwise would.

The First Amendment wasn't even drafted, let alone ratified, before the US Constitution and its Copyright Clause came into effect.

The Copyright Clause exists because the Federal government's expansive Commerce Clause powers wouldn't exist for at least another 100 years. Without an express grant, the Federal government wouldn't have had any power to grant and regulate copyrights.

Under modern jurisprudence, the Copyright Clause is unnecessary to grant the Federal government jurisdiction as copyrights are an archetype of a national commercial domain; even the most conservative rollback of Commerce Clause jurisprudence would be unlikely to change this. Instead, many legal scholars, including several justices in uncontended dicta, have opined that the clause effectively limits the Federal government's powers by restricting the scope of Federal copyrights (copyrightable subject matter, defenses to infringement, etc) to what was cognizable under the Common Law in 1789. (Indeed, the majority said exactly that regarding time limits, though AFAIK it's only in dicta have they said the clause implicitly limits copyright powers more generally.)

So, for example, Congress could never completely legislate away a Fair Use defense. Likewise for doctrines like the Idea-Expression dichotomy, which Google heavily relied upon in their first trial (less so in their second trial because of appeal court decisions) to argue that APIs weren't copyrightable in the first place.

It's true that the First Amendment is used--and used more often--to restrain the reach of copyright. But that's mostly because the First Amendment has undergone an expansive reinterpretation similar to the evolution of the Commerce Clause. The drafters would have perceived little, if any, tension, between the Copyright Clause and the First Amendment--mostly because of how they understood terms of art like free speech, but also because times were simpler then and the flaws and ambiguity in their legal concepts hadn't yet been revealed by 100+ years of litigation.


Laws can't be interpreted in a vacuum, and the Supreme Court has recognized that multiple times.

Programmers like to think of laws like they are code, and you just need a computer to compute the results. This isn't how the law works, nor could it ever.

There is always ambiguity in the law, and the supreme court's job is to use their knowledge of the law, combined with their understanding of the world as it exists, and come up with the best decision that aligns with the law and the current state of the world.


Any particular law does not exist in a vacuum. It exists within the context of firstly the constitution, and secondly all other statutes and previous court decisions.

Supreme Court justices have the authority to determine the constitutionality of a law, and they have the authority to determine how a law should be interpreted in a given case (with essentially unlimited discretion for applying their own judicial ideology).

However, they have no authority whatsoever to determine the social merit of a law. The legislature has the sole authority to legislate, and the constitution prohibits either of the other branches from usurping that power. It is far beyond the jurisdiction of the Supreme Court to determine the merit of a law in any way other than its constitutionality.

Anybody who expects the Supreme Court to act as a safe guard against otherwise constitutional law, that they simply don’t like, is undermining the separation of powers detailed in the constitution, and will be sorely surprised when they find out that’s not what the Supreme Court does.


> and come up with the best decision that aligns with the law and the current state of the world.

No, the current state is in constant flux. The only ambiguity the court should be resolving is the intent of the law. Not whether or not it “makes sense given the current politics of the day”. If the law no longer makes sense in the current state of the world, a new one should be passed by legislation.


> While I’m really hoping that Google wins this, I also hope that the Supreme Court applies the law as they see it, without any consideration at all for the social impact

On the fair use, if not the copyrightability, issue, social impact is an express consideration of the law. (Though given that the copyright power is expressly contingent on a particular social purpose, it arguably is on copyrightability even if the statute doesn't invoke it.)


> social impact is an express consideration of the law

It is, but in a very narrow sense. The fair use test is a part of the law, some of the factors it considers relate to social impact (for example allowance made for education), but it has no general ‘social impact’ criteria.

https://www.law.cornell.edu/uscode/text/17/107

This is the only definition of “fair use” that Google will be arguing they comply with.


There are different philosophies here. I'm mostly with you. I too believe the court should apply the law, not invent the law. On the other hand, there are people who believe the court should just make the "right" decision, take history to the "right" path.

However, I do have problem with your statement "without any consideration at all for the social impact". I fear this statement goes to an extreme which would never be hold by any judge in real life.

By the way, it's not only the judges and the law make the case, lawyers of both sides are also important in the process.


> However, I do have problem with your statement "without any consideration at all for the social impact". I fear this statement goes to an extreme which would never be hold by any judge in real life.

A lower court judge?

Absolutely not. They have huge amounts of discretion in making their judgements.

The Supreme Court justice?

Absolutely yes. In cases where the Supreme Court is exercising it’s appellate jurisdiction, the only authority it has it to determine constitutionality, and interpret existing legislation. If the legislature passes bad legislation, as long as it doesn’t violate the constitution, then the Supreme Court has no authority to over turn it. This isn’t an extreme position, it’s the constitutionally prescribed role of the Supreme Court.


> In cases where the Supreme Court is exercising it’s appellate jurisdiction, the only authority it has it to determine constitutionality, and interpret existing legislation.

Art. III, Sec. 2 directly refutes this narrow view of the appellate role of the Supreme Court.


Article III grants the Supreme Court judicial power, it does not grant the Supreme Court any legislative power at all. It directly affirms what I said.

Nothing I’ve said is even remotely controversial. No Supreme Court justice has ever claimed to have legislative power. It’s honestly quite shocking that people are willing to dispute the most basic concepts in civics.


> Article III grants the Supreme Court judicial power

And, contrary to your description, that power is expressly not a power limiting it only to “determine constitutionality, and interpret existing legislation” whereas trial judges have “huge amounts of discretion in making their judgements” that the Supreme Court lacks (in fact, as the Supreme Court has, but rarely exercises, appellate power over fact decisions as well as law, its domain is broader, in jury trials, than that of the trial judge, who is the original trier of law but not fact.)


Lower courts have original jurisdiction over nearly all legal actions commenced in the United States. You absolutely do expect trial court judges to exercise a much greater level of discretion than appellate judges, regardless of whether it pertains to matters of law or fact.

However, none of that is to distract from the fact that, contrary to your misinterpretation of Article III, judicial powers do not bestow any legislative powers whatsoever.


We always see the anti-Oracle/FreeAPI’s regards this story, but I’m curious who out there is on Oracles side in this? Are there any other major players or even small ones that people know of that would like to see Oracle win this case ?

I'm on Google's side professionally because it affects my livelihood directly.

I'm on Oracle's side dogmatically because I think there's nothing in the law that says they can't copyright an API.

I'm on neither side personally because I think this whole case is a massive failing by the law to adapt to new use cases.


Copyright is a grant, not a natural right, which generally means you can only copyright what the legislature says you can.

Sure. But if I can copyright a screenplay, what's to say I can't copyright an API?

It's not clear to me why one copyright would be legitimate and the other not.


>there's nothing in the law that says they can't copyright an API.

Well this is copyright law and not patent law but my understanding is in patent law they've already established things like obvious plug designs cannot be patented. If we assume the same is to be said for code you easily argue that to keep compatibility for any given method signature, the reimplementation method signature is obvious.


Copying anything is “obvious” given the source material. Your arguing against all forms of copyright not just Software interfaces.

You can often reimplement a function body in a way that happens to be the exact way another person implimented the method. There's only so many ways to count the size of an array. That does not mean you're committing copyright infringement.

Google has shown that they did not copy the bodies verbatim so its down to the API. There happens to only be a single way to write the method signatures of a compatible method.


> There happens to only be a single way to write the method signatures of a compatible method.

That's not actually true. For example, all of the following method headers are compatible:

    void foo(int a) throws Exception 
    void foo(int x) throws IOException
    void foo(int index) throws RuntimeException

Sure, this is a technicality, but it is not completely irrelevant.

However, the whole discussion is moot, because Google had no intention of being compatible with anything, as shown by the fact that there is no real-world Java program that runs as-is on Android.

Also, copyright only applies to actual copies of the original work. Google could have done a clean-room redesign of the Java API starting from Java programs, they could have arrived at the same API that they have today, and could not have been successfully accused of copying.


Many of the method parameter names are indeed changed in this situation. Changing the thrown exception is an incompatible change in Java.

>However, the whole discussion is moot, because Google had no intention of being compatible with anything, as shown by the fact that there is no real-world Java program that runs as-is on Android.

The vast majority of Java code runs on perfectly well in Android. APKs are packaged differently than JARs but that's a different discussion.

>Also, copyright only applies to actual copies of the original work. Google could have done a clean-room redesign of the Java API starting from Java programs, they could have arrived at the same API that they have today, and could not have been successfully accused of copying.

This is what they did. Oracle's argument is that a clean room implementation of the Java API is also copyright infringement.


> Changing the thrown exception is an incompatible change in Java.

Not if you're throwing a more specific exception. So the second and third methods are compatible with the first one, but not the other way around.

> The vast majority of Java code runs on perfectly well in Android.

The vast majority of Java applications use features not available on Dalvik, ever-changing though the vast majority of their code would indeed run.

> This is what they did. Oracle's argument is that a clean room implementation of the Java API is also copyright infringement.

They did a clean-room implementation by looking at the specification of the Java API. They did not reverse-engineer the API from working programs or from decompiled binaries, and are not claiming that they did. If they had, you would have probably seen minor differences in parameter names, thrown exceptions and a few other places.


>Not if you're throwing a more specific exception. So the second and third methods are compatible with the first one, but not the other way around.

These are public classes and third party code will have overridden the original exception and not your subtype. This would break compatibility. You cannot change the types of these signatures in either direction.


Yeah... a big part of my feelings on this case come down to an idea that "the law is broken and needs to be fixed, and applications of the law to this that try to be consistent yield nonsensical results that no one really likes"; so I guess part of me kind of hopes Oracle wins because then it might feel like a set of broken laws is being more consistently applied and thereby maybe someone will finally bother to actually fix it? Copyright as an entire concept is just so arbitrary and broken when you really get into the weeds, and I find it almost impossible to draw any bright lines from first principles :(.

I mean, Google clearly wanted to build something similar in many ways to Java and, honestly, did _not_ do so for trivial "interoperability" purposes (which is the most common defense of what Google did, as "interoperability" has often been used as a successful defense of fair use and even has many explicit carve outs and exemptions in the DMCA) as existing Java software did not work on their implementation and they didn't _really_ care (and in fact benefited); the best part of the lawsuit to me was when Google's lawyers failed to find even a single Java program that could run on Android when challenged by Oracle.

> District Court noted that Oracle in essence was arguing that Google’s interoperability argument would have been stronger if Google copied more--the structure of all 166 Java API packages--rather than just 37.

https://www.law.berkeley.edu/wp-content/uploads/2015/09/Jona...

I mean, this is just "good TV", and doesn't lead to a situation to me where anyone is "obviously correct" to me given either the law or the current precedent. At the end of that PDF, the case of Lotus v. Borland is brought up, where Borland had a menu variant compatible with Lotus 1-2-3 for their Quattro Pro. Is the API of a programming environment more like this kind of user interface (which was left without a national precedent as it _split evenly_ at the Supreme Court level: four to four with one recusal) or more like the API of the IBM BIOS that had to be replicated by Compaq (which _was_ considered to be copyrightable)?

I really feel like most people are largely on Google's side for, as you state, "professional" reasons, as it causes all of us issues if it turns out that Google wasn't allowed to do this, as we all _like_ being able to build something "kind of similar to what this other person built but not compatible enough so that our use is neutral". Imagine if this got applied to protocols... what kind of effect would that have on the web? Oracle has also been so classically evil--and there's still this residual delusion that Google isn't--that I think we all have blinders on with respect to whether they might be right.


In 2008, no smartphone could really handle the full Java API. Java failed on mobile precisely because Desktop Java was a pig, and the mobile variants were either pigs too, or so non-featured, that they represented no market parity.

Does anyone really thing Swing, or PersonalJava, or MIDP on phones, or even JavaFX, was going to compete with iOS?

The whole write-once-run-anywhere promise of Java is a sham. Any non-trivial professional Java app, used some non-portable APIs. Take the popular ones like Limewire, or IntelliJ, and they end up on each platform, hooking into MacOS, Windows, et al, specific APIs that require JNI code.

" Imagine if this got applied to protocols"

That's exactly what happened since the 80s. Do you know how many versions of IMAP there are if you count the extensions? Or Jabber? The internet was built on "rough consensus and running code". People shared code and ideas freely. That's what built the net.

Copyrighting APIs with 100+ year time spans is INSANE.


> " Imagine if this got applied to protocols"

> That's exactly what happened since the 80s.

You managed to invert my paragraph somehow :/. Imagine if [this: the idea that APIs are copyrightable] got applied to protocols... that would be horrible, and would have had massive (negative) impacts on the web; this categorically did not happen "since the 80s".

Therefore, paying no attention to the law or the precedent or even the facts of the case, we all have this visceral reaction to the idea behind this lawsuit and want it to be decided in a way that feels like it works for us... but maybe the issue is that the law is broken.

> Copyrighting APIs with 100+ year time spans is INSANE.

I would argue copyrighting anything with 100+ year time spans is INSANE. The idea that developing and distributing techniques that even merely help people copy things is illegal (a la Section 1201(b))... the issue is that this entire area of law is INSANE :/.


Personally, although I generally despise their practices, I think that Oracle is fully in the right here. APIs are obviously the result of human creativity and they do deserve protection. Google only chose to copy the Java API for their new platform because they liked it aesthetically and didn't want to invest into creating a new API to use for their platform (a decision I'm sure they are regretting).

What I think would make most sense is to allow APIs to be copyrighted, but to enshrine a specific fair-use exception for interoperability. If that were granted, WINE and other emulators would be allowed to copy Windows' API under that fair-use exception, whereas Google would still not be allowed to do what they did.


The concept is tempting. However in most cases the implementation is only partial. As in Wine and Samba, etc do not implement the full extent of the API. Just the part that's practical for their purposes.

And that's essentially what Google did - made a partial implementation of the API. I don't see a good way to rule that Google use was protected but other not 100% complete implementations are.


> Are there any other major players or even small ones that people know of that would like to see Oracle win this case ?

The Trump Administration. (They've filed, AFAIK, the only amicus brief supporting Oracle in the case. I would think they count as a major player.)


I'm on Oracle's side because I think APIs are essentially the same as code and should be protected similarly.

I don't believe that this will be massively disruptive to the industry.

I think it's unfair that Google or anyone should have to pay anyone for doing something that was no clearly unlawful and the gov. should also step in and clear up the legality of these things. Clarity on these matters will help everyone, everywhere, except lawyers.

I do not believe that the adversarial justice system is remotely the right place to be making these decisions.


One more reason the rest of the world has to up their game so that a bad decision by a U.S. mega corp or U.S. court don’t leave all of us with no alternatives.

Unfortunately, almost the entire world signed on to the Berne Convention [0], and it's basically impossible to change it anymore. It predates the internet too, so it has silly things like "minimum copyright term must be 50 years after the death of the author" and makes no allowances for the copyright of technological content.

The entire world has already handcuffed itself to the bad decision of having incredibly restrictive copyright laws, so we already are in a pretty bad spot there.

[0]: https://en.wikipedia.org/wiki/Berne_Convention


I wonder who has copyright over the file API (e.g. open(), close(), etc.). Since filesystems are written by implementing this common API, I guess they'd all be infringing someone's copyright. Also language interpreters and standard libraries that wrap those OS facilities to make them available in their language. Linux PAM modules are built by implementing an API defined by PAM. Language wrappers which allow us to use libraries written in different languages would all be violating copyright too, I guess. No more using GTK in a language different from C, for example. How far does this go?

i think Oracle has a very weak case, because i think it and especially its predecessor have always presented java as an open software, even going so far as to standardize it so that others could easily implement, resulting in the many implementations of the java platform we have today. claiming copyright after all that should never hold up in front of a judge.

Java has always been copyrighted, and Sun has already used that copyright against to shut down an implementation that was not conforming before - see Microsoft Java (later kept alive for a while as J#).

Sun used the Java trademark against Microsoft. The case was settled out of court.

If Google wins, does that mean that anyone can make third-party compatible software without permission from the owner? That third-party Teddy Ruxpin tapes, for example, which were sued out of existence, would be protected?

http://docs.law.gwu.edu/facweb/claw/ch5b.htm


Remember: Congress always has the ability to change the law.

While fuck Oracle and all that of course, I actually must admit I disagree that interfaces are trivial and, especially, not creative and thus worthy of copyright.

I think interfaces are super creative, way more distilled ideation than implementations which are often bogged down with mundane details. I and work try to write programs very compositionally, and good interfaces are the keystone that makes this possible and productive. Put in a slogan, I must rather be forced to replace and rewrite my favorite implementations than replace and rewrite my favorite interfaces.

Perhaps think a better argument in a better world is a symmetrical fair use one where if you invite people to consume (re provide) and interface, you must also allow people to provide (re consume) it. Unlike e.g. a flu vaccine, the market isn't preexisting but built around the interface. I dunno, I'm still thinking it over.

Of course, given that's copywrite is insane, it might be prudent to pretend otherwise!

(lastly a fun fact: harmony alone isn't copywritable while melody alone is.)


The reason I dislike API protection is that an API is a description of a problem, not a solution to the problem. It may be a useful, well thought out description, but that’s all. It’s the plot, not the story and plots aren’t protected by copyright.

In principle the plot is simply a byproduct of writing the story. Yes authors often plan out the plot first, but they don’t have to. If you just write a story as it comes to you, it will still have a plot. Likewise with an API.


A novel API can totally be a solution to a problem, though. Hence API design being an area that we all spend lots of time thinking and learning about.

Sure, but equally prospective authors spend a huge amount of work creating great plots, and a terrible plot can wreck an extremely well written story. They still can't copyright or otherwise protect them though, for good reasons.

Protecting plots would have terrible negative consequences for creative arts, just as protecting APIs would have terrible consequences for the software industry. It's not 100% directly comparable, APIs are often more explicitly stated than plots, but I think the analogy is close enough to be useful.


An API is not a 'plot' - it's a very specific articulation of information.

An API is more like a set of chapter headings and their descriptions.

It doesn't matter that they are 'not a solution' to anything.


Could you please provide an example of an API that is a solution and not a description of how to access the solution? I am completely unconvinced by your assertion.


> API is a description of a problem, not a solution to the problem.

No, it's a description of functionality.

> plots aren't protected by copyright

You cannot copy another story if there is "substantial similarity." This would included having a point-by-point identical plot and characters.

https://writing.stackexchange.com/a/3930


Yes I agree in that there is a non-trivial intellectual effort to create an interface and that there are many things that are copyrightable which takes less effort. I think you create something tangible when you create an interface, perhaps comparable with a poem.

I can certainly see it is "better for the world" if the court rules in Google's favour, but I will not be the least surprised if it does not.


> perhaps comparable with a poem.

Like in: The implementation are the words and the API is what makes them rhime?


> Put in a slogan, I must rather be forced to replace and rewrite my favorite implementations than replace and rewrite my favorite interfaces.

Then you'd better hope that your favorite interfaces aren't going to get copyrighted (by other people / companies who had the same idea). Otherwise you're going to have to replace your interfaces...


> I actually must admit I disagree that interfaces are trivial

No one is arguing that they are trivial (or "not creative" as this argument has also been posed).

There are many non-trivial (and creative) things that aren't copyrightable...for instance everything covered by patents.


Or data, you can copyright presentation but not facts. Those facts can take a lot of effort to calculate, etc. - but ultimately they are not a creative work.

> ...for instance everything covered by patents

Is this sarcasm? Patents are a mostly stronger form of IP protection, no?


For once rooting for Oracle. They may be slimy but Google needs to be dethroned for the tech world to progress.

If it's Oracle vs. Google, Oracle is the slime king.

Preventing the reimplementation of APIs is not the way to dethrone Google; this is one instance where we fall on the same side.


Dethroning google by catastrophically harming everyone seems like a fairly bad outcome.

Mostly it will impact small projects - an open source implementation of an API would constitute a copyright violation, an open source reader of game data (eg all those game implementation that depend on the game data of a legitimate copy) would also be potentially subject to the same copyright violations.

In fact it would be very difficult for any open source project to read any proprietary format, without being subject to copyright violation suits.


Why shouldn't it? If I spent 10 months coming up with non trivial interface and 10 years marketing and popularizing it, you cant come in one day and steal the thunder

If we want the tech world to consistently advance, companies need to succeed by providing products and services people want, rather than collecting rent indefinitely off of a good idea they once had. Their thunder should get stolen if they can't do a better job than their competitors.

If it's an idea that does something functional, then it belongs in the domain of patent law: you register it, prove its unique, and then it's yours for 10 years.

What it definitely shouldn't be is copyrighted, the class of IP that's made for stuff like novels and paintings, where the protection is automatic and lasts until 90 years after your death.

It helps nobody to have to wait until 2150 to write an interface for Java.


"If it's an idea that does something functional, then it belongs in the domain of patent law: you register it, prove its unique, and then it's yours for 10 years."

APIs are nearly identical to code in terms of what they are, it's very reasonable to apply the same copyright rules.


> APIs are nearly identical to code in terms of what they are, it's very reasonable to apply the same copyright rules.

I don't really agree, except to say that, sure, there's a good argument that code is purely functional (in the sense of “providing function”, not the programming paradigm), too. But copyrightability of code isn't the issue in this case.


No they're not. API's don't have comments, they don't have expressiveness, and by their nature there is almost no choice on the part of the designer, they're just a list of names attached to functions (but not the functions themselves). There's only so many synonyms for "print".

Oracle is trying to claim that they own the idea of a toolbox with a tool called a "screwdriver", a tool called a "hammer", and a tool called "wire cutters", and nobody is allowed to make their own toolbox using the same list of names of tools.


" API's don't have comments, they don't have expressiveness, and by their nature there is almost no choice on the part of the designer, they're just a list of names attached to functions"

I don't know how anyone who's written code could even say this.

APIs have comments, they are expressive, there is considerable choice in design and they are a 'list of names' the same as the list of names attached to variables.


APIs are not code. They are functional interfaces that code interacts with. The decision to have a function called `sqrt` and put it in a module called `math` is not creative, and it is definitely not artistic.

"APIs are not code" - most APIs are literally part of the code.

"The decision to have a function called `sqrt` and put it in a module called `math` is not creative, and it is definitely not artistic."

Yes, it absolutely is, in the sense that literally any arbitrary sentence or gibberish that I write is creative and copyrightable.

I can copyright: "Blahdy Blady Blady Blah" right now.

API design is as creative as any other part of the code.


You can’t copyright that - precisely because it is not a significant creative work.

The question is an API a significantly creative work, vs the implementation.

Historically - because the entire modern world depends on it - APIs were not considered copyrightable, largely because the creativity is embodied by the implementation.

You clearly disagree, I am curious if you believe being able to have competing software was detrimental - for example say MS claimed copyright over the XMLHttpRequest API? Or google over search engine query API, etc


And colors are part of a painting. Do you believe that colors are copyrightable?

Letters are part of a novel, do you think that authors have a copyright to the letters that they use?


the philips screw head was patented.

By all accounts thats an “interface” for a screw to be driven in by a screw driver.

However i hope the court doesnt rule in Oracles favor.

https://en.wikipedia.org/wiki/Henry_F._Phillips


> the philips screw head was patented.

> By all accounts thats an “interface” for a screw to be driven in by a screw driver.

As a functional component, to the extent novel and otherwise eligible for patent, patent protection for APIs makes perfect sense; patents also have an extremely short duration compared to essentially-eternal copyrights.

API copyrightability is, aside from being inconsistent (IMO) with both the letter and intent of the law, an absolutely nightmare in practical terms because it has neither the novelty requirements nor the short term associated with patents.


And it would be ok if oracle patented it, but they claim copyright. Patent doesnt last nearly as long as copyright.

The interface of the Phillips screwdriver had some inherent value (i.e self centering property) so it makes sense to protect it.

With software the interface is a trivial detail that anyone could come up with. One interface is as good as any other. It seems disingenuous if the owner of one interface that suddenly became popular tries to claim copyright after everyone starts using it.


This would hurt the rest of the tech world way more than it would hurt Google.

No matter what, one thing this surely will not do is "dethrone google". At worst a loss here will sting the investors for a while. But the possibility has likely been priced in already. Oracle request 9B in damages so supposing they get everything they asked for it's about 1Q of profits for big G.

"While valuable, there's nothing creative about an API."

This quite fundamentally flawed. In many cases, the APIs are the most important and hardest work, and the implementation is arbitrary.


> In many cases, the APIs are the most important and hardest work

Importance and hard work aren't the issue. The particular sense of expressive creativity protected by copyright, distinct from the kind of functional invention protected, if at all, by patents, is the issue. APIs are (often not particularly novel, but sometimes quite nov) functional inventions, not works of authorship. Yes, API design is critically important to the functionality, sometimes.the most important and hardest work in building the functional software. That is not an argument for copyrightability, however. It's more of an argument against it.


I get that 'hard/creative/important work' isn't the core of the legal issue, I was referring to the statement in the text, which I think is quite wrong.

But APIs are, I think, 'works of authorship'. It seems rational to me that APIs should have the same copyright protections as code, poetry, music, etc..


I can’t understand the practical effect of a copywriting an API.

Why would a company publish an API if they didn’t want people to use it? Paid APIs exist as well.

Why does copyright stop the example of sharing photos between different services? What’s stopping Google from rejecting photos from nonGoogle devices right now?


AFAIK the issue is not using the API, it's reimplementing it verbatim.

For example, AWS has done this a lot - many of AWS's services are 'drop in' for open source projects, making it easy to migrate off of, say, RabbitMQ, or Cassandra, or Mongo, and over to SQS or one of their databases.

If Google loses those open source projects could protect themselves against this by copyrighting their APIs.


Now I’m even more confused. That sounds completely different from copyrighting an API.

Why shouldn’t a company be able to copyright the implementation? That’s the work they did.


Well perhaps I'm the one that's confused then.

> Why shouldn’t a company be able to copyright the implementation?

This is what a software license is - software licenses are, to my knowledge, just a form of copyright.

The question here is if the API is copyrightable, not just the implementation. In my opinion it is, the API is, as you say, part of the work they did.

Honestly I feel like I have to be missing something. Articles like this exclaim that there is a consensus among programmers that I'm wrong, so I feel like I've got to have misunderstood.


Many reasons, e.g. You want people to use your API, but not reimplement it. Or you want to allow people to use your API for specific use cases without paying, but want money for others.

Sun wanted the second one, Google thought they could get away with ignoring that and now someone has to sort out the fallout and make a decision.


The only reason why it's gotten this far, instead of being settled, is because the two parties are at an impasse. And the conflicting views resulting in the impasse have been established by their respective boards, as argued by the law teams.

These two companies failed to voluntarily agree to a compromise. No one made them get to this point. They fundamentally disagree with each other. Either they both think they're in the right. Or one side is bluffing, and willing to take a gambit, hoping the Court will go along with it.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: