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.
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.
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.
* 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.
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.
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.
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.
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.
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 DH3.  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.
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.
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.
I thought they provide their own because they don’t want to assume that MSVC is installed too.
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.
> 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?
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.
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.
>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.
Reread the comment, like "I see a far more daunting problem."
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.
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.
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 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.
> 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.
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.
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.
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.
So even with this change, we'd still likely have most of not all of the same overall solutions, derived from other places.
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.
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.
> 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.
> 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.
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.
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!
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.
2. I just entered it into the argument!
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.
And this is about copyright, not patents, right? Oracle has apparently already lost the patent case.
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.
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? 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.
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.
We're talking about copyright, not patents though.
Books, not mouse traps.
This may feel wrong to some, but emulating the API of the famous thing is bread and butter of software interoperability.
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.
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?
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.
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.
On the other hand it's dry, repetitive, and has really poor flow, so I'm struggling to finish it myself.
 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"
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.
> 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.
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.
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.
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.
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.
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.)
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.
This is the only definition of “fair use” that Google will be arguing they comply with.
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.
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.
Art. III, Sec. 2 directly refutes this narrow view of the appellate role of the Supreme Court.
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.
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.)
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.
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.
It's not clear to me why one copyright would be legitimate and the other not.
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.
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.
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
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.
>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.
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.
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.
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.
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.
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.
> 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 :/.
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.
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.
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 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.
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.
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.)
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.
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 more like a set of chapter headings and their descriptions.
It doesn't matter that they are 'not a solution' to anything.
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.
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.
Like in: The implementation are the words and the API is what makes them rhime?
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...
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.
Is this sarcasm? Patents are a mostly stronger form of IP protection, no?
Preventing the reimplementation of APIs is not the way to dethrone Google; this is one instance where we fall on the same side.
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.
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.
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.
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.
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.
"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.
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
Letters are part of a novel, do you think that authors have a copyright to the letters that they use?
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.
> 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.
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 quite fundamentally flawed. In many cases, the APIs are the most important and hardest work, and the implementation is arbitrary.
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.
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..
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?
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.
Why shouldn’t a company be able to copyright the implementation? That’s the work they did.
> 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.
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.
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.