Google and Oracle's decade-long copyright battle reaches Supreme Court
npr.org
npr.org
To point back to the substance of the thread and Oracle's claims...
Google didn't copy any of Oracle/Sun's Java source code base into Android Java. Oracle lawyers acknowledge this.
Instead, Google copied the API of function name spellings and also the hierarchy of organization (tree of namespaces) of those API methods. I asked about this in a previous comment and some folks more familiar with the case replied with citations of court opinions: https://news.ycombinator.com/item?id=7852100
So to give a flippant summary of the current situation: you _can_ copy some exact spellings of API function names (e.g. other browsers Chrome/Firefox/Safari can copy Microsoft IE XMLHttpRequest() exactly without renaming it to RetrieveHttpXtensibleMarkupLang()) -- as long as you don't copy too much of the API surface area. The threshold of "too much" and getting in legal trouble is yet to be determined by The US Supreme Court.
If Oracle ultimately wins, it seems like millions of programmers will have to reach for a thesaurus to find synonyms to name functions. We'll have to waste brain cycles coming up and alternative spellings of methods to stay away from copyright infringement.
I have never been involved in a US Supreme Court case but back in 1999 or so I was asked to prep a barrister in the UK on the guts of TCP/IP. I literally jumped in a black cab at short notice with 6 or 7 volumes of W. Richard Stevens and spent an afternoon showing him and a few others from his chambers packet dumps and TCP state diagrams and drawing some diagrams of my own showing what a webserver, browser does, how caching works, etc. The next day using my information synthesized with some really archaic law about what is and isn't a document he issued his opinion about where particular actions occur (and therefore what legal jurisdictions apply) when someone does something on a website. It was extremely thoughtful and nuanced and literally a day earlier he didn't even know what a webpage was.
In reality, technology (and technology companies) mirror their predecessors in other industries. And often abuses of copyright or antitrust by tech companies really isn't much different than the actions of companies decades ago, just obscured by a layer of technology magic.
The one I helped write an expert witness report for a technology-related case, there was quite a bit of technical detail in it (although it was written so as to be intelligible to a non-specialist).
This isn't how copyright works though. It's neither necessary or sufficient. If you copy an API but change the words using a thesaurus you are still copying it so it would still be infringement. If by happenstance you come up with the same wording in your API, then that would not be copyright infringement because you didn't copy anything.
From the previous thread I referred to, a commenter cited an excerpt from a circuit court opinion about alternative naming :
[...] Using the district court's "java.lang.Math.max" example, Oracle explains that the developers could have called it any number of things, including "Math.maximum" or "Arith.larger." This was not a situation where Oracle was selecting among preordained names and phrases to create its packages. As the district court recognized, moreover, "the Android method and class names could have been different from the names of their counterparts in Java and still have worked." Copyrightability Decision, 872 F. Supp. 2d at 976. [...]
[1] don't know where the canonical source is so I provide a Google search link: https://www.google.com/search?q=Using+the+district+court%27s...
Producing a new work that happens to be similar to, or even word for word identical to an existing work, if you truly created it yourself from scratch without taking anything from the existing work, would not be copying.
As a practical matter, unless you had extraordinary proof that you really had never read Harry Potter books, watched the movies, read the plot summaries on Wikipedia, attended a party shortly after one of the books came out where everyone was talking about it, you would lose in a copyright infringement lawsuit. If you work is very similar to Harry Potter and you had access to Harry Potter, that's sufficient for the plaintiff to make their case, switching the burden to you to prove that you did not copy it.
There is no plot in an API, no main characters, etc. It communicates matters of technical nature, and there aren't five different way of writing 'sqrt()' or whatever. It is more appropriately compares to architechtural blueprints and other technical documents.
Which is amusing, because Sun almost certainly chose "max" in part for "compatibility" with the C standard library.
That also isn't how copyright works.
You're essentially asserting copyright over the semantics of an API.
The semantics of an API may (although I would argue otherwise) be protected, but if they are it would have to be either as a design patent, or as trade dress, not as copyright.
That said, even if the un-synonymized API is protected by copyright (and I would generally argue otherwise), reimplementing it must be seen as fair use, all the more so an API with renamed functions.
For a more recent example: Amazon's DocumentDB reimplements the MongoDB API. This should be allowed, even though we could wish Amazon had acted otherwise.
Here is the crux of the matter: unless there is some sort of no-man's-land between the various intellectual property regimes for software, no interoperability will be allowed except that which a vendor explicitly opts into. If copyrights, trademarks, and patents overlap sufficiently, even clean-room reimplementations will be forbidden.
We can argue about which aspects of software should be protected, for how long, and by what means, but at the end of the day there must be an unprotectable area of some kind, or we're all going to be doomed to either working entirely within vendors' vertically integrated stacks, or else implementing NSidedWheelAPIFactoryFactory() all the way down to bare metal for the foreseeable future.
Wouldn't semantics be functional and thus require a utility patent, rather than a design patent or trade dress?
The argument being made by Google (and stipulated by Oracle) is that the reason Google copied the API was for its familiarity to developers, rather than any inherent quality or functionality.
This is, essentially, a "look-and-feel" lawsuit, only applied to code, rather than UI.
If you use the API surface area for your own software because you like the design, copying it is easier than coming up with something new, or you want to provide a familiar programming environment to developers then you're looking at infringing.
But wasn't that one of Google's original goals for Android? Making porting existing Java apps easy?
Why do you presuppose to know the legal rule that the Supreme Court will articulate in its decision? I mean, you seem to presuppose that the Court will uphold the Federal Circuit on all contested questions of law and only reconsider whether the decision on the facts is reasonable, which is...mighty presumptuous.
It's quite conceivable that Google could win on a more fundamental ground, since the question of whether the API is even protected by copyright or unprotected as a functional element (which also does not turn on Google’s intent) is a love issue in the appeal. They win on that, and the Court doesn't have to touch anything else.
Even if they do need to address the fair use question because Google loses on copyright ability, the Court a lot will turn on the standard of review and the Seventh Amendment as to whether the Court is really probing Google's intent (de novo review) or merely probing whether any reasonable jury could have concluded that the use was fair, as the actual trial jury did here, preserving the right to jury trial. I would expect the latter, the Federal Circuit seems to have gone completely off the rails invoking de novo review to overturn the jury verdict.
Google did that: for compatibility with existing Java tooling, which is software.
Sure, Java apps aren't, unmodified, compatible with Android, but the compatibility makes tooling and intermediate libraries compatible, which is a functional, interoperability concern.
In other words, Google won on most or all of its arguments at the jury trial level, and CAFC kept overturning all of its arguments. The sentiment I'm getting from the oral arguments is that SCOTUS is leaning much more towards "CAFC is off its rocker" here.
You can find the replay here: https://www.c-span.org/video/?469263-1/google-v-oracle-ameri...
Don't need oral arguments for the results of the first trial and the arguments filed in the appeal of that first trial.
Here's the final judgement from the first trial: http://www.groklaw.net/pdf3/OraGoogle-1211.pdf
Note on the second page:
> With respect to Oracle’s claim for relief for copyright infringement, judgment is entered in favor of Google and against Oracle except as follows: the rangeCheck code in TimSort.java and ComparableTimSort.java, and the eight decompiled files (seven “Impl.java” files and one “ACL” file),
And here's Oracle’s reply brief in the appeal; the relevant part on this issue is under the heading THERE IS NO “DE MINIMIS” DEFENSE TO COPYRIGHT INFRINGEMENT.
Looking at an API and going "you could do this any other way than ours" is absolutely nothing more than a fundamental deconstruction of the entire field, at which point it's just Math. You're wasting everyone else's time. No one gets to copyright 2+2.
I'm not shoving in 3 API layers to represent "Math.max()".
The use of an API will be copyrightable too. Now you understand the depths of the disaster this will be.
This is a legal apocalypse for software.
Nice chap, but fortunately he was a school friend and not a colleague!
Maybe we should just use GUIDs for everything :-)
Plus Sun couldn't design a decent UI to save their lives, so Android probably wouldn't have been successful if Google had allowed Sun a large role in the platform.
From the same Chet Haase and Romain Guy that went into Android's GUI framework after Sun went under.
And for mobile there was
https://docs.oracle.com/javame/dev-tools/lwuit-1.3/LWUIT_Dev...
Plus, Google could have done just like any other OS vendor does with ISO C and ISO C++, plus whatever OS APIs they feel like adding.
Oracle's lawsuit is so bad-faith it is laughable.
https://en.wikipedia.org/wiki/Apache_Harmony#Difficulties_to...
And adding to that, the entire enforcement mechanism was through trademarks, not copyright. And trademarks are about the only IP construct not brought up in this case.
It's worse than that isn't it? Naming is how you link things. What happens to WINE if it is illegal to use the same names Kernel32 does?
I am very worried about this case.
WINE is using the Windows names for the purposes of allowing Windows programs to run. This is a case where a judge would easily grant fair-use because you have to use the API surface area to provide compatibility for existing programs.
Android is using the Java names for the purposes of allowing existing Java developers to be productive, not so that existing Java programs can run.
WINE could very likely win a legal battle through claiming a fair-use exemption (of course, if the case fails, they wouldn't have to go to court at all).
Where is the line? Is Android "compatible" with Java programs if those programs need to be recompiled first, but no source edits are necessary? What if source edits are necessary, but can be automated? What if recompiling isn't necessary, but you need to hex edit the binary?
"Compatibility" is a spectrum, and I'd say Android falls within that range.
There is no distinction between the two because these things are presented as evidence of Google's intent, it's not proof. There's no line. Google's case would be much stronger is Android-Java could run most Java software unmodified but it doesn't mean they'll lose just because it's not true.
Of course, in reality Google's decision was probably a little of both, right? They selected a technology based on a wide range of factors, including development costs and compatibility.
I'm still concerned that a decision in Oracle's favor would have a massive chilling effect on everyone else. All companies want to limit their potential liabilities. How can you prove in advance that you selected a language or API for the sake of compatibility, even when that is in fact the driving factor?
I wouldn't think that Google's development costs were part of the decision. There aren't that many Java APIs -- as the article says, it's ~11k lines of definitions -- so Oracle is seeking ~$818k per line. Assuming Google's lawyers predicted that there was some risk of a lawsuit like this, any engineering costs associated with redesigning the APIs would just be negligible compared to the legal risk.
One could argue that it is quite difficult to design a good API, but Java's APIs are frankly full of mistakes: Date/Calendar, immutable collections with no type safety, "optional" methods like Iterator.remove, etc. It wouldn't take a team of world-class engineers to come up with something better with the benefit of hindsight.
On the other hand, developer familiarity and compatibility with existing Java libraries could have had a significant impact on Android's adoption. I think that was what justified the legal risks.
https://www.cnet.com/news/android-chief-andy-rubin-said-java...
"Copyright and consequences: Google’s Andy Rubin defends Android to jury"
https://arstechnica.com/tech-policy/2016/05/copyright-and-co...
> "We've been over a bunch of these, and we think they all suck," Lindholm wrote. "We conclude that we need to negotiate a license for java under the terms we need."
Not centrally. The copyrightability issue is absolutely not about Google’s intentions (and if Oracle loses that, it's game over), and Google’s intentions are relevant to one half of one of four fair use factors (the “purpose and character of use” factor) which are weighed together (it's not a pass-fail each factor test) in the fair use portion.
>Since Oracle's claim is that Google's use of the Java APIs wasn't to provide compatibility to existing software written in Java but to have a _familiar_ language for Java developers it becomes a novel but normal copyright case.
You're making a distinction between "interopability" and "end user familiarity". But Lotus also sued Borland on the basis of "familiarity" of the menu "names and structure" and they lost. The Supreme Court's 4-4 split decision left the lower appeals court's ruling intact.
https://en.wikipedia.org/wiki/Lotus_Dev._Corp._v._Borland_In...
Sure you might not be able to take a legacy SWING Windows Java app and run it on android, but you can run entire libraries in your android app. It absolutely _is_ about interoperability in both cases. Perhaps to varying degrees
In contrast, Google didn't have their own independently developed programming language. They needed one so they copied the Java api and created one from there. They did not use the Api to create a compatability layer. It was used as a starting point to make their own copy of Java.
How would such a programming language be detectably different from being an implementation of Java?
Yes
>How would such a programming language be detectably different from being an implementation of Java?
It would have it's own unique API. As an example, Ruby can run on the JVM via JRuby and it's clear that Ruby is a different language than Java.
Its literally same difference.
In this example Google independently developed a language and made it compatible with the JVM.
In the real world Google wanted Java and didn't like the licensing terms. So they copied the Java API and from that starting point built out their own version of Java.
What you are suggestying is copying the binary API instead of the texual one. It is equally the subject of copyright.
In the real world Google deleoped their own equivalent of the JVM, which uses different bytecode. This is technically more difficult than putting together a language. But that has no relevance to the subject of copyright.
I mean, a programming language is fundamentally a set of instructions that produces output, right? So, a Java programmer writes `System.out.print("Hello")` and the Java implementation does the work to make "Hello" appear on screen. Similarly, a Windows executable running via Wine will tell the Windows API to print "Hello", and Wine will do the work to make that message appear on the screen.
This isn't an argument that has been made in court in anyway, and Google's use of the Java language hasn't been questioned.
Google could have used the Java language with completely different APIs (google.lang instead of java.lang for example). It's the APIs that this case is about.
Also, the key analogy is wrong anyway: while Android used java.lang and java.util and other related APIs, the key functionality of the phone was accessible via custom APIs that aren't copied. Note that the "interoperability" argument was lost by Google because of this exact thing.
Well, no, because many Java language constructs are defined in context to the standard library, for instance all classes being children of java.lang.Object. They'd need quite a bit of java.lang at the very least.
In 2020 it is still pretty much hint and miss getting a Java library working without changes on Android, given that the Android team cherry picks whatever they feel like from OpenJDK for their own Android API implementation purposes.
Easily to find that out from Gerrit commits and AOSP source code.
Meanwhile, effort has been spent ensuring that 100% of ISO C and ISO C++ are available on Android NDK.
Thus out of the window goes the interoperability argument.
Maybe if Sun didn't play games with access to the TCK in the past we wouldn't be here adn there'd be a valid test for compliance that wasn't "do what the official JDK does".
Do you have anything else to pivot to?
I am not pivoting, Google has only itself to blame for their little J++ adventure.
"James Gosling Triangulation's Interview on Google vs. Sun"
https://www.youtube.com/watch?v=ZYw3X4RZv6Y&feature=youtu.be...
Basically wanting Java as free beer, without paying Sun any money given that Java actually required licenses for handsets/embedded deployments in pre-OpenJDK days, in the not so good economical situation that they were, withdrawing them from possible Android license revenues.
That is torpedoing, regardless how Google employees, or wannabe employees play it.
That means they wouldn't have gotten any money from SavaJe like phones either.
The only people who "torpedoed" Sun was Sun themselves.
And yes, switching from an interoperabilty argument to 'they were morally obligated to buy Sun' is very much pivoting to a different argument.
Also, here's James Gosling later saying that APIs should not be copyrightable. http://nighthacks.com/jag/blog/397/index.html
Imagine you're a company using some Oracle database, and you want to reimplement some component of that system in order to migrate and escape their vendor lock-in... You can't, not without taking a huge legal risk.
In the short term, it's a victory for huge litigious corporations like Oracle. The good thing, I hope, is that in the long term, this will make people distrust closed source software even more. What Oracle wants, and has always wanted, is to bind you in the worst possible form of vendor lock-in. Open source and open standards are the answer. Refuse anything else.
But Oracle doesn't care one bit about anything else that's not Oracle.
Though it is still to be known how many reimplemented APIs from others does Oracle have in their products
Yes if you want to be certified and want to get a copy of the standards document you'll need to pay, but it's not necessary (and I doubt that Oracle did, given that they implemented SQL before the standard existed and probably were involved in drafting it).
Then that screwdriver turns itself instead of turning the screw.
> probably were involved in drafting it
Which also isn't done for free beer, ISO processes have associated costs.
The original point being made in this thread was that Oracle copied the API of SQL from IBM and thus is guilty of the same thing that they are accusing Google of doing. The counter-point was that SQL is an ISO standard and Oracle (allegedly) licensed it, which was then followed up by my point about Oracle DB predating the ISO standard. Hence why ISO is being discussed and why I was making the point that buying a standard document from ISO or paying for certification are not really relevant to this discussion.
I understood copyright to be something you had if you had created it.
Copyright... of the top of my head, I don't recall much about copyrightability of software.
[1] As a side note, IBM may not have been the first to license software but they certainly helped make it a standard practice. When they unbundled much of the System/360 software, they felt that copyright was a weak protection (given its uncertain legal status) so they combined it with a license.
... in the US of A.
Berne convention started a little bit over a full century before that.
Impressive that the superfluous “need” for the Copyright (c) YYYY notice still persists to this day in the mind of many.
I’ve made a life long habit of collecting and archiving these in my personal documents whenever I get my hands on one. Because these are valuable guidelines as to how things are supposed to work.
That's patching and is already disallowed by licenses in USA, but allowed by law, but that law was goofed up by a court.
Patenting an API makes sense, since APIs are essentially ideas. Copyrighting an API does not make sense.
You cannot patent the completely generic idea of "a tool to lift people in buildings", but you can patent an elevator.
Similarly, you cannot patent "the ability to scan a database", but you can patent an api for doing so, even without a complete implementation of that api.
You should see some of the software patents that get approved nowadays to see just how often "idea on a computer" gets greenlit.
Says who? Oracle is claiming exactly the opposite, and if they win this will become "law" in the USA. I think you've missed the whole point of this issue here.
> For instance "Linux" is a copyright owned by Linus Torvalds…
For starters: Linux™ is a trademark, not "a copyright".
> Your understanding is incorrect here.
It seems, at least to me, that you actually missed a few core point of the whole story. ;-)
It's worse than that. OpenJDK, including the java standard library, is GPL. It's open source.
Oracle is claiming that even though source code defining the API is open source, they retain copyright to the API itself.. regardless of the open source implementation of the API by themselves.
If this case goes through, you won't be able to mimic an open source project's API unless you also verify they provide the API under a similarly permissive license.
Are you sure they are claiming that? A weaker claim could be that Google's usage does not conform to the GPL. Indeed if you were correct and the ruling is in Oracle's favor then the GPL is broken as designed, I haven't heard anyone express that concern in connection with this case.
At the time at issue, Java wasn't under the GPL. That Google did not have a (public offer or private) license to Java is not in dispute.
The code at issue is pre-OpenJDK, and wasn't open source when used (though much of it may now also be available in OpenJDK, not that Google uses it under the GPL, or claims to, anyhow.)
But the GPL is irrelevant, Google has never distributed under the GPL terms. That whatever it was doing was not under a Sun/Oracle license is not in dispute.
Your code is just protected if it gets re-distributed, that's why google never ever has to opensource their "Server OS/Kernel".
Also they changed GCC to GPLv3 which is just a super stupid decision for a Compiler.
I was wondering where would the Oracle win hurt most, and I think there is worse than WINE.
The Unix syscalls would have been Bell Labs’ copyright. That copyright was sold to Novell, which was sold to… Micro Focus International plc?
So this British consulting company that is, according to its website, “powering digital transformation”, could transform the digital world by suing BSD, Linux, Apple and Microsoft for tremendous sums of money and forbid them from using the famous syscalls.
I guess a given set of CLI programs may also be seen as an application programming interface, which makes all of GNU liable too.
Is that correct?
Additionally, the contract is public. http://www.groklaw.net/pdf/USLsettlement.pdf Point 9C on page 14 has the university declaring that as far as they know, no AT&T IP is present in 4.4BSD, despite it clearly having a UNIX compatible API.
In other words: both primary care about winning the case. No matter how they get it done, or whatever the fallout/consequences will be for anyone but themselves. Arguably that is fine for any company, since their sole responsibility is to look after itself. But the legal ramifications of their (legal) actions can extend far beyond that, for which I certainly consider them and the US legal system responsible, collectively.
I sincerely wonder sometimes, that besides the potential damage many do recognize as a fallout of this court case, how many people realize that mud fight between two way-too-powerful sandbox bullies may end up being responsible for making the USA a pariah within the landscape of future software development?
Or does everyone believe that if this goes sideways, that the rest of the world will just respect this "funny logic" and all go with it?
In fact, how many Americans even realize that the increasing radicalization and absurdity of their intellectual property rules will inevitably harm the USA big time in the long run? Or does everyone still think that the USA will remain the center of everything and the only one dictating the rules?
Things like these do not happen in a vacuum. The rest of the world is watching.
You do realize that if literally all you do is change the names and spellings then you'll still be in violation of copyright, right? Translating a book into another language (where the names and spellings of every word are different) is still copyright infringement. The fact that the names and spellings are the same just provides evidence to the judge that copying occurred.
If you just rename all the methods and their argument variables you still open yourselves up to a lawsuit because all the plaintiff is going to do is show the judge a mapping between their and your names and it will be plain as day as to what happened.
In general that is largely true. In the particular type of copyright being argued in this particular case Oracle has stated that changing the name or spelling of the methods would have been enough to avoid being in violation:
Using the district court's "java.lang.Math.max" example, Oracle explains that the developers could have called it any number of things, including "Math.maximum" or "Arith.larger." This was not a situation where Oracle was selecting among preordained names and phrases to create its packages. As the district court recognized, moreover, "the Android method and class names could have been different from the names of their counterparts in Java and still have worked."
“Oracle has stated” doesn't make it consistent with the law. Sure, the Supreme Court could create a new rule in this case which would make it true, but there is no existing legal rule I can ser that would make thesaurus substitution not infringement of something that was otherwise infringement.
For example, someone writing a recipe for omelette has to say "2 eggs" simply because that's what omelette needs. You can't express it any other way, so it's not a creative act, so it can't be protected by copyright.
What we need the law to do is to distinguish between copying a piece of code and using a piece of code. Just because I use your code doesn't mean you own my code too. What we need the software industry to understand is that relying on a proprietary library makes it impossible to cheaply switch your code to an alternative implementation without rewriting your own code. Alternatives exist: use software with an open license model, or shim out the proprietary library.
You know, it might be worth asking the engineer who wrote java.lang.Math how he came up with those names. Actually, you don't--he already answered it one of the amici briefs. The answer was that he took it from C.
In other words, taking Oracle's argument at face value means that the example API it is accusing Google of illegally copying is itself an illegal copy of the UNIX copyright, whoever actually owns that now.
(You could also point out that JavaScript literally lifts java.lang.Math and java.util.Date into JS code as well, down to Date.getYear returning the Gregorian year - 1900).
Second, unclear what the legal status of libm is. It appears to implement a standard, thus is legitimate to ask whether the set of implemented functions and their names are the original contribution of libm authors, or are derived from the standards. Generally, if one wants to implement a standard, one needs to acquire the rights to do so, usually in the form of a reasonable fee.
Third, if there are significant overlapping parts that are the creative work of libm authors, and they can establish a prior art claim, they are entitled to seek fair compensation from Sun / Oracle.
https://docs.oracle.com/javase/8/docs/api/java/lang/Math.htm...
https://sourceware.org/newlib/libm.html
PS. Re: atan2, wikipedia: 'The function atan2(y,x) first appeared in the programming language Fortran (in IBM's implementation FORTRAN-IV in 1961). It was originally intended to return a correct and unambiguous value for the angle θ in converting from cartesian coordinates (x, y) to polar coordinates (r, θ).' Perfect example of a term that arguably migrates into the common technical vocabulary over decades.
Which were added in C99, which postdates the initial release of Java.
The fact remains that APIs are creative works. This can also be seen from discussions about APIs in the industry - everyone knows that the Unix APIs are often seen as elegant while the Windows APIs are seen as ugly. The C++ people love the design of their iterators and algorithms and data structures and believe it is superior to Haskell's equivalents.
I think people consider the UNIX CLIs ("do one thing and do it well") to be elegant, not UNIX APIs. UNIX APIs have quite massive (and well-known) warts in them.
Also, some Unix OS APIs are much preferred over Windows alternatives - e.g. many people think fork()/exec() is much more elegant than CreateProcess(), same for pthreads vs the Windows threading model etc.
The bottom line though is that people have opinions about API design, it is clearly seen as a creative process, it is not rote technicality.
That's not true, there were nine lines of source code (range check) copied verbatim, not counting the 11,500 lines of API declarations.
But the API declarations are source code, too.
> If Oracle ultimately wins, it seems like millions of programmers will have to reach for a thesaurus to find synonyms to name functions.
That really depends on how Oracle wins, and specifically what rule is articulated.
No, it was found to be a copyright infringement in the first trial; it's one point on which Oracle sought to have the district court upheld and Google sought to have it overturned in the original set of appeals and cross-appeals. (While on many other issues they split the other way.)
I believe GP is correct. The jury found it to be infringement, but then Alsup ruled it wasn't copyrightable in the first place, so the jury's finding was irrelevant.
edit: oops, sorry, didn't realize the rangeCheck scope of this subthread
No, the final judgement in the first trial by Alsup found the APIs weren't copyrightable, but that the literal copying of rangeCheck and some other compiled files was infringement. (For which no damages were awarded, by stipulation of the parties, I think because everyone was planning to appeal everything and didn't really want to wait for damage calculations to get that ball rolling.)
It's a short ruling: http://www.groklaw.net/pdf3/OraGoogle-1211.pdf
Or the companies that the developers work for pay the original creator of the API, which is the solution Oracle are angling for.
There's no technical way to not copy the interface, especially method names, and imagine what happens when you implement an interface: it's copied verbatim.
I think you are a bit off the mark on this line. (mostly agree with the rest of your post)
Google's goal was to make a white-room implementation of java that was 100% api compatible. This was explicitly to avoid licensing Java while still being Java compatible.
All they did was port the language to a new compile target. When you port a language over you also port the standard library or at least the parts that you need. This is standard across the industry. Every language implementation does it. What Oracle is trying to say is that you need a license to do it and that is a dramatic change in the industry practice right now.
It's also short sighted. If Oracle wins then you'll need a license to implement java the language (as opposed to the JVM) anywhere. Short term Oracle get's a pile of money. Long term everyone stops using Java. But then again if you are Oracle, with it's current values, Java's only real value is short term money gains. It's hard to make money on a programming language the way Oracle prefers to operate so this may be the best they can do.
You're building a new car company.
You see all the existing cars, the roads, and the garages.
So you measure the width of the car and the garage and you decide that the car should be exactly 6' wide.
Then you ship your car. Enjoy 15 years of market success.
Then you find that Oracle created the first cars and says they have copyright on the width of your car.
That's how stupid this is...
We aren't talking about user interfaces here. This lawsuit does not involve UX. We are talking about interfaces between functional components. The analogy is spot on.
The lawsuit involves UX for a software framework. Which its API constitutes. The user happens to be a developer here and their usage is software development.
Your argument that the copying is once-removed is unfortunately irrelevant to copyright law.
None of those things would work.
Besides, creating minor differences do not solve this problem as they would still be derivative works.
Your question is exactly my point. I'm suggesting what I said earlier:
>> I don't think that's a good analogy at all.
But sure, if you say so.
It's possible to extend any analogy in a way that doesn't make sense, which is what you've done.
It seems like your complaint may be that you simply don't like, or perhaps don't understand, analogies in general.
Let's improve the analogy!
My proposal => that you chose to make the door handles six inches because of UX, and Oracle showed up and said they made theirs six inches before you did.
(For reference none of this is meant to reflect my position on what the law actually is, or should be. I'm just considering analogies here.)
Upholding the API copyright would be like giving Craftsman grounds to sue Ryobi for manufacturing circular saws because Ryobi combined a power cord, an electrical motor, a toothed circular blade and a housing; a state of affairs that only seems even remotely plausible to endorse because source code is inherently a read product.
You look at it and see an authored work. I look at it and I see an n-dimensional turing-space relationship diagram as expressed through transform functions.
And last I checked, you could patent some math(RSA), but not not copyright it. Eventually it's just prior art.
That's how stupid car analogies are...
Recipes themselves aren't copyright protected. However, specific instructions for the recipes are protected.
In addition, though individual recipes aren't protected, a collection of recipes is protected.
There is a line, though, between copying a few recipes, and an entire collection. That line is not easy to define, but that doesn't preclude the existence of such a line.
So – is an API considered a single recipe? Or is it a "recipe collection?" That seems to me to be an important distinction.
If you were to copy one set of API function names that cover a limited area, then it could be argued that you used just one "recipe" and that it would be OK. However, if an entire collection of API function names across a very broad range of categories was copied, then it is harder to argue that you didn't copy any entire collection, and not just an individual recipe.
As an example, individual recipes are generally not copyrightable, but if you compile a set of recipes and publish them in a cookbook, the cookbook itself would be copyrightable.
As applied to Java, even if individual method signatures like max/min/split/replace/delete/etc might not be copyrightable, the fact that you've organized those specific methods into specific classes named Math/String/File and then organized those classes into specific packages named java.lang and java.io might meet the threshold for copyrightability as a "compilation".
While it would likely not be good for the software industry for reasons discussed in this thread, I would not be particularly surprised if the court ruled in favor of Oracle on this particular subject.
You're saying the textual contents of the interfaces that define the APIs are not part of the source code base? Of course Google copied them, or a nearly identical paraphrase of them.
I'm not quite sure what Google's legal theory is. Listening to the oral arguments this morning certainly didn't make that more clear to me. But I don't think it includes redefining what we mean by copying text.
And interfaces, in common parlance, are certainly lines of code.
Nor do I think Oracle's argument is that no one else can define interfaces that use the same words as in the Java standard library interfaces. read, write, get, put, etc. did not become Oracle's property by virtue of them being used as method names.
I have a bit of trouble with the concept "the threshhold of too much", too, as it applies to this case. Google copied or paraphrased essentially _all_ of the text of interfaces they used from Java libraries.
Well, they aren't part of the implementation, since they just describe the interface. Google's theory is that interfaces, being needed for interoperability, are not protected by copyright. Google's alternate theory is that, even if they are protected by copyright, using them is fair use.
Oracle is trying to argue that just because you intentionally left a bunch of implementation detail out because it isn't relevant toward transforming something like the Java API's to a new context, it should still count as copyright infringement because they Still yoinked everything they did take... Which seems circular to me.
Google's point is "no shit, Sherlock, it wouldn't be Java otherwise." Oracle is couching this issue from the perspective that Google should have invented a completely New language and runtime, absorbing the same costs of them doing so. Google argues, on the other hand, that what they made, in order to confer to the syntactic structure of the programming language known as Java, dictates the duplication of the organization of the fundamental functions, packages, and namespaces, and that furthermore, Oracle has no standing to call them on it, because those APIs are a necessary prerequite to drive the operation of the JVM, and are by definition the only way to do it, so that API constitutes a method of operation.
Is an API a collection of facts? I would hate to be a lawyer tasked with arguing this one in front of the Supremes. Programmers sweat bullets over API design, an API is very obviously not a mere collection of facts, it's a creative work. Copyright law protects creative works. Hence, Google's problem.
An API is not a mere collection of names either. The Java API is defined by the specification, which is contained in the JavaDocs. Thread safety rules, when callbacks are invoked, what sub-types can be passed into a parameter, all these are a part of the API as well. Strip out the source code of the methods but leave the types, prototypes and JavaDocs and you have the Java API - it's been done and the result is still huge.
Google's point is essentially one of convenience; the industry has never recognised APIs as copyrightable before and shouldn't now. This is not a legal argument at all so I am mostly expecting Oracle to give them a solid thrashing, because the SC is meant to interpret existing law, not simply agree to whatever one of the parties thinks the law should be. And other than declaring API reimplementation to be fair use, there's no obvious legal escape route to make APIs non-protected.
It's thus interesting to consider what happens if or when Oracle win. In the short run a lot of disruption, especially to projects like Wine and maybe WSL.
In the long run it's harder to say. Something unprotectable would have become protectable. We might see, for example, the birth of companies that specialise in nothing except API design. Today such a company would be unviable because there'd be no way to protect or own the results. You can imagine that this would occur in the same way that specialised agencies do graphics design, translation, logo design, API implementations, etc. This might lead to higher quality APIs across the industry: a difficult to anticipate side effect of expanding IP protection. It would also presumably reduce competition as it became even harder to compete with lockin via reimplementation of APIs. However, doing that is relatively rare today. I can't say for sure that the (small) loss of plug-compatible competing implementations of products would be worse than a hypothetical increase in API quality from allowing specialisation in it.
The easiest solution if the software industry wants to preserve the status quo is to just lobby Congress to amend the laws to explicitly distinguish interfaces from implementations.
Look at the way YouTube Content ID encourages innovation and then imagine GitHub Content ID.
“Your repository contains 3 copyrighted method calls. You’ve been issued a copyright strike.”
I’d love to see every open source repo on the internet go private for 1 day as a demonstration of what could be lost if copyright is allowed to weasel its way into APIs.
GitHub and NPM should give users the option to block their repos for a day. A bazillion failing builds would open some eyes IMO.
Really scary.
And guess what, all the American services have the upload filters already. So the point is moot
Github projects already should strive to use correct licensing, and comply with the license of code they use. There is nothing new here.
Wonder what happens if I call it "_write()"
OH and then when theyre about to drop in stock price because they dont know how to deliver valuable products, they use the US government to force other companies to buy their product otherwise the US government will kick that prospective customer out of US markets ^.^
Did you mean to say compatibility rather than computability?
> The entire software industry is built on the idea that APIs are not copyrightable.
The entire open source movement was built on copyright (ala FSF and the GPL). So this doesn't even make sense. It's not anarchy as you imply and copyright has a purpose.
Also, copyright is far more limited than patents. Patents are dangerous because it's like claiming ownership over a mathematical formula that anyone can derive. It's completely different.
You surely meant 9, not 10k, lines of code for rangeCheck(), didn't you?
>It says what Google has done is like taking key parts of those books — chapter titles, character names, the first sentence of each paragraph — writing a new book, and selling it.
If you're reimplementing APIs as Google has done then at some point you _need_ to copy the structure of the existing API, the method signatures, the names of the methods, the descriptions of what they do, etc, and while you may be able to dig out a thesaurus to claim enough original creative work at some point it's all for moot because there's only so much you can do before you'll start infringing upon Oracles creative expression of their API which severely limits what you are able to do with it.
If Oracle wins this case it will have huge implications for any reverse engineered work like Wine or graphics drivers where such projects will cease to exist, because it won't actually matter if it's 100% your own implementation as any interface to existing APIs or hardware _will_ infringe upon other companies copyright.
As far as Youtube Content ID goes it doesn't actually matter if it's 3 seconds or 3 minutes of copyrighted work, if it's matched then Youtube will let those companies claim revenue from your video which may be an hour long. The alternative here is the legal system and courts which may absolutely agree that 3 seconds of use in an hour long video is fair use, but you're still going to end up in court to defend that usage. It's unlikely that Oracle has enough sway to force Github to implement a similar content matching system but if they did it doesn't really matter what threshold the courts set for fair use for reimplementing APIs just like it doesn't matter for Youtube, best make sure all your repos don't use something like XMLHttpRequest() or your repo may disappear, and of course if Oracle doesn't have the sway to force Github into implementing such a system you're still going to have to go check through all your your repos because if they feel you've infringed upon their creative work they'll be able to issue takedown requests and your only recourse will be through the courts.
No it wouldn't. Lawyers and executives don't care about your error-prone CI/CD pipeline.
https://gitlab.com/gnu-clisp/clisp/blob/dd313099db351c90431c...
or something else?
I agree that many create that API barrier (ex: ZFS on Linux). Those that argue that ZFS on Linux is legally problematic agree with the FSF's definition (which I would argue leads to the belief that APIs are copyrightable). Those that think ZFS on Linux is on a fine footing believe that APIs aren't copyrightable and one can create a shim to decouple your non GPLd code from GPL "libraries", especially if the coupling that ends up happening is never distributed as done by the end user.
That's less Copyright in the sense that it's mandating the relinquishing of monopolistic control of the work product in question to the public. Oracle wants the opposite. They want Java used everywhere, and the right to sue anyone who does anything too similar to it too.
This is absolutely an act of monopolistic market shaping. No smaller firm would ever have utilized this nuclear option of a lawsuit given the widespread damage this could potentially cause to the entire software ecosystem.
This would honestly be enough to get me moving completely out of Software if the Court screws the pooch on this badly enough.
I'm not spending the rest of my life debugging code that as a matter of fact must be run through obfuscate steps to avoid copyright liability.
I don't know if it's different enough, but it's not the exact same issue.
If I expect the end user to have libreadline installed on their machine (from debian / redhat repos, and for argument sake Debian/Red Hat/et al aren't distributing my app), I think I'd disagree. I'm not distributing any GPLd code.
I think its a bit more complicated if Debian/Red Hat are distributing my non GPLd app that links against a GPLd library that they also distribute, but aren't really distributing them together. The reason I say this, is because even though they are "distributing" both "together", we wouldn't say that GPLd code and BSD code that they "distribute" "together" infects the BSD code.
I might also agree that its not exactly the same issue, but I do think it should make one think about it.
In the past people argued that streaming could not be copyright infringement since the recipient never received a copy of the movie. Courts however did not see much of an meaningful distinction between streaming a movie and downloading a movie since the experience from the user were close to identical and the perceived impact on the publisher were also identical.
During a conference I recall a lawyer explaining that a judge does not like arguments that try to use tricks to walk around laws. It makes the judge look like a fool and that annoys them.
But lets get into the weeds a little. Lets say I am distributing it according to all definitions. I'm allowed to distribute GPLd material. I'm allowed to distribute non GPLd material. I'm allowed to distribute them together even (say a linux CD without the GPL impacting the rest).
The question the judge would have to answer, is the non GPLd portion a "derivative work" of the GPLd portion and is that derivative work being distributed. I'm not so clear that this the case unless one really believes that APIs can be copyrighted (then it is clearly the case).
As a simple example: lets say we accept that it is a derivative work, but then lets say I made a replacement version of libreadline that was ABI compatible (but not feature complete) with the original one, so hence my program can be dynamically linked against both but it will be a better end user experience if they use the GPL version.
To provide a somewhat more concrete thought experiment (concrete as an ABI copatible reimplemntation under a different license, thought as its making up a fact):
imagine microsoft dual licensed windows with GPL and not and they believed that if one wanted to ship a non GPL program one had to pay them a license fee to keep the program not GPLd. Now, as wine has implemented the required APIs to run my program, can I ship a non GPLd program where I refuse to license the right to be non GPLd from Microsoft that will still run on Windows? Does it change because wine exists (i.e. the answer would be different if wine didn't exist) and if so why? This case isn't to nitpick how windows is different than libreadline or the like, but just as an example of ABI compatible non feature complete implementations can exist.
Technically the derivative work is the combination of the two, not just the non-GPLd portion. Part of the argument that a lawyer would have to do is to define what "the work" is, and arguing distinction in linking technology might not be that great strategy to an non-technical judge or jury. If you present a video player what people likely will see as the work is the video player, not some independent code, independent glue and 20-30 independent library dependencies. As programmers however we might see things a bit different in the same way a painter will look at paint on a canvas.
However I would agree that if there exist multiple interchangeable libraries the argument for two independent work seems to be much stronger. There are for example multiple libc implementations, and for those one could make a case that a program and its libc dependency does not create a derivative work. In practice however I doubt such argument would be much of a benefit in real GPL infringement cases.
The wine project has a rather strong fair use clause regardless of the outcome of this court case, since it would be a rather difficult argument for Microsoft to argue that wine has caused considerable commercial damage. Basically every point of fair use is applicable here, from "Purpose and character of the use", "Amount and substantiality", "Effect upon work's value" and additional values like acknowledgement of the copyrighted source (if the API is copyrightable). Wine is a compatibility layer, not an re-implementation. Courts would naturally have to consider if that distinction is relevant but I suspect they would have a much easier time than java on android.
Well, IANAL, but I fail to see how you are bound by the GPL in any way on that situation.
There used to be a market of proprietary software patches, that fixed stuff the software creator didn't bother changing. AFAIK, nobody ever contested its legality until EULA came and made it illegal to the end-user (instead of the distributor). There is a famous guy who sells proprietary security patches for Linux, isn't there? Your example is much clearer than patches.
The situation of RedHat distributing both isn't as clear.
Oracle claim is that google copies of header files requires copy right permission, with google saying that header files are either not protected by copyright or that using them is fair use.
FSF claim in regard to dynamically linked libraries is that using them in a work creates a derivative work. For C code, software without its dynamically linked libraries won't even load past the linker, and in their view, a judge/jury will see the program as a single work rather than two independent works.
This court case will not define what is a derivative work or when two combined works should be seen as independent of each other. It may explore the limits of what is copyrightable and what is fair use, which is interesting in terms of API's and compatibility but less so for defining the limits of the GPL as an copyright license.
Nothing in there is about API's. There is also nothing about linking. It just about what a judge would perceive as being "the work". FSF however do seem to have a policy about enforcing the license at the technical distinction of linking, but that is just a policy decision based on where they think a judge would likely side with them. Apple were free to go to court arguing that it is not a compiler but rather different independent works simply communicating with each other, but they chose not to do so.
Apple could have decided it wasn't worth the fight, i.e. the benefits of thei front end being GPLd or not being GPLd in the end made no difference, so no reason to fight it.
When it come to apple I strongly suspect there are a few things companies like them will try avoid putting lawyers and money on. What is the definition for derivative work and what is the definition of fair use. If you do want to stake money on that you likely want aspects of the case being stacked in your favor, and basing the majority of a product on a GPL code base is not that. A single function call to libreadline would likely be more favorable, but a company like apple would just rewrite such trivial amount of code.
This might prevent some of the parties doing huge upfront investments in some of the projects, but if we learned something from OSS and, most importantly, Linux is that gradual and tiny improvements over 30 years can compound to a behemoth that eats any commercial solution for lunch.
Actually, just one, the desktop.
In virtually every other market, Linux is either dominating or has a firm share.
So maybe MS dominates the withering on prem data center world. But that’s smaller than cloud nowadays.
For smartphones, Linux-based Android has the largest market share. It is linux dominated. For less smart phones, there are Linux based operating systems like KaiOS.
https://en.wikipedia.org/wiki/Android_(operating_system)
https://en.wikipedia.org/wiki/KaiOS
Linux based OSs having 87% market share in india: https://www.androidauthority.com/india-kaios-market-share-88...
Global 74% market share for Android: https://gs.statcounter.com/os-market-share/mobile/worldwide
> gaming like Xbox and playstation
Yes, I think most deployed devices don't use Linux, and I'm not aware of any major linux using gaming console, but it's not unheard of, e.g. SNES classic mini. Also, from what I saw, Linux has a good foothold for game streaming offerings, but it's a new market and not yet established that it'll last.
> smart TVs
smart TVs are almost exclusively on Linux!
https://www.statista.com/statistics/257778/number-of-smart-t...
WebOS, Tizen, Android TV, Roku OS, Firefox OS, Amazon Fire TV, all uses Linux.
Google can replace Linux with Zirkon tomorrow and 99% of Android apps won't even notice.
Just like TVs, who cares what OS a smart TV is running.
One advantage of copyright is that it does, indeed, give artists recourse when people use their works without compensation. The photographer whose picture was copied and pasted onto an advertisement. The musician trying to sell their first album.
You could argue that litigation is too costly for an individual, which may be true, but this is one reason artists choose to sell their images via Getty. They gain access to a marketplace, and Getty handles licensing and enforcement, which makes it easier for artists to be fairly compensated for their work.
This isn’t absolute either: there is enforcement too aggressive (ask any Youtube creator), or limits too long (Disney).
But I cannot help but think that, with no copyright whatsoever, then the little guys will have a harder time protecting themselves from folks who would otherwise like to use that art without compensating the creator.
Copyright is necessary but the laws today are draconian and far too extensive. For works since 1978, copyright lasts for the entire length of the author's life, plus an additional 70 years. The "Mickey Mouse" protection act (https://en.wikipedia.org/wiki/Copyright_Term_Extension_Act) increased this even further for some works.
There's a need to allow artists and writers to make money from their creations and not just get their work instantly reproduced by pirates. At the same time, it's in the public interest for their work to become widely available after a short period of protection. I don't know exactly how long that period should be to maximally benefit society, but 15 years sounds a lot more reasonable than life+75 years.
It's absolutely absurd that Arthur Conan Doyle's distant ancestors can today be suing people for creating derivatives of Sherlock Holmes, a literary character conceived in 1887. Sherlock Holmes belongs to the public, not some greedy relatives trying to leech a living from him.
The current system does not satisfy that standard. Artists and writers don't make money due to far-reaching copyright. Musicians make money by selling tickets to concerts and contract performances. Journalists make money from newspaper pay-walls and advertising.
(The software lead had an idea that users should be able to just store and share stuff on the site. She moved to Canada during the project to join a new team, and did the same thing for the game they were running. They noticed that a lot of people were using the feature to share photos. So they focused on that, and that became Flickr.)
Newspapers are already well down the road towards this future - as part of subscription you get comments sections, and forums, and dating sites, and wine clubs. Still, I see significant unused potential. Each newspaper should view itself as some mix of bloomberg/twitter/linkedin, and encourage interaction between its members audience.
You've seen this on a small scale in areas like clipart. It's not a very lucrative business though and it does mean you only have creators with either "passion" or money.
I don’t know, you see, sometimes I have some doubts about my uncertainty. But should I trust my memory about what might have happened in my head in the past?
>I think about art, and artists as a musician myself. One advantage of copyright is that it does, indeed, give artists recourse when people use their works without compensation.
Practices of art and culture, including music, long predate any copyright law. Or even money, most likely (an archeologist will tell you that with more confidence about the veracity of such a claim).
According monopoly of exploitation rarely turn into proliferation of diversity, most of the time it will fall into feedback loop where a few entities will "take it all" and widely spread the "best fit for all".
>The photographer whose picture was copied and pasted onto an advertisement.
There are different topic here. In the French droit d’auteur, you have a separation of "moral rights" – including who is granted to publish your work in which context – and "patrimonial rights" – how monetization of the work is managed.
I mean, cultural and social structures also play a meaningful part on what is enacted.
The topic behind copyright is not simply about copy, it's about who benefit of some exclusive privileges on cultural works and what kind of social inequalities are enforcable by law.
The only reason we know of that particular case is because they happened to charge the original creator.
The dynamic is ripe for corruption. If Getty failed to report all the works they were collecting for, and instead siphoned money off on the side, how would anyone know?
0) free to run the program as you wish, for any purpose
1) The freedom to study how the program works, and change it so it does your computing as you wish.
2) The freedom to redistribute copies so you can help others.
3) The freedom to distribute copies of your modified versions to others.
The only thing taking away these freedoms is copyright and public domain software gives you all these freedoms. The only caveat is with 1) in that one could use digital restrictions management to make this harder. However, there is a difference between "circumventing DRM is difficult" and "circumventing DRM is illegal".
In a world with no copyright the source code requirement dies, but all the remaining freedoms stay intact. Reverse engineering and decompilers become much more important.
It's the scope and duration of the protection that is a problem but I think it's too simplistic to say we don't need it at all.
Well, I don't agree with that. Music, games, movies, need those kind of protections otherwise look at what happens in China...
This case though, it's only Oracle being Oracle. A stupid greedy corporation trying to profit on other's successes.
IP disproportionately helps organizations rather than individuals. And the major owners of those organizations are the 0.01% class
What it would mean is the games that we all played as kids but are long since out of store shelves would now be free to distribute.
US copyright law is utterly broken.
I agree with that. IP also doesn't make any sense to me from a philosophical perspective. I don't understand why making one thing once should give me a monopoly on making things that are similar to that thing.
The fact that the question of how similar a thing must be to fall under my monopoly is so arbitrary and ill-defined also leads to an enormous amount of resources being wasted on litigation and designing around the law.
Non-disclosure agreements are sufficient to allow an inventor to be first to market. They should not be able to use the government to enforce a monopoly after that.
I cannot imagine wanting to write a book if I didn't have some recourse against people distributing my book freely.
The policy concerns around IP protection for both patent and copyright are clear: the minimum amount of protection that doesn't discourage innovation.
Lawmakers know or should know that we all benefit from a rich public domain, which is why there are limitations on both copyright and patents in terms of both duration and general application, and I am happy to argue that copyright is too strong, particularly in terms of duration (thanks Disney), but I simply can't agree that we "would be better off without any kind of copyright or IP".
Your lack of imagination is disappointing, and also hints at a failure of empathy.
But I guess the broader point remains, even if only 20% of potential authors are, like me, so evil that they wouldn't devote a year of their lives to writing a book that they couldn't monetize in some way, well that's still represents a 20% decrease in innovation on some level.
This is pretty much the FSF's argument in a nutshell. It's pretty obvious what the end game for "intellectual property" is once you read RMS's "Right to Read."
I wasn't able to listen to all of the arguments, but some general takeaways I had:
* The justices seemed to be asking mostly technical legal questions of Google (e.g., discuss merger doctrine) and mostly doom-and-gloom questions of Oracle (e.g., how does your argument impact QWERTY keyboards?). This suggests to me that they're more in favor of Google's position, and are querying how to arrive at that decision from a legal basis.
* Some of the questions suggest to me that the justices agree with Google's view that declaring code is categorically distinct from implementation code, and perhaps that copyright for the former doesn't exist.
* Thomas had an interesting question that went unanswered: "the four factors to determine fair use are not exhaustive, can you think of any other factors?" (paraphrased).
I wouldn't read that much into it. Google has made the argument that "this means doom-and-gloom" and Oracle that "this is technically illegal". It makes sense that they're interrogating the parties along the lines of the arguments that have been presented. I wouldn't say it's a signal that they favor one over the other.
Mueller is now telling us that the Court will find for Oracle in a near-unanimous, if not actually unanimous, decision: http://www.fosspatents.com/2020/10/supreme-court-inclined-to...
He points out that the justices have been asking some really pointed questions of Google since you made this post, questions which suggest that they don't buy Google's crap for a second and they think Google is trying to pull a fast one.
The law is pretty unambiguous that Google is liable for copyright infringement. Just because techies thought the law didn't work the way it does for decades doesn't actually change anything.
You could try and argue fair use, and it would be distinct from the case at hand so you might win, but fair use is always a fact intensive analysis and it's certainly not obvious that you would win.
Your toy language cannot read the API information into memory to compile with it, because that would be copying it.
https://www.scotusblog.com/2020/10/case-preview-justices-to-...
I know a lot of folks have created compatible APIs for Amazon S3, including Oracle themselves.
Does this become against the law if Oracle wins?
https://docs.cloud.oracle.com/en-us/iaas/Content/Object/Task...
Google did a similar thing with OpenJDK (which is GPL) starting with Android N, why they didn't do it in the first place I don't know, Sun published OpenJDK under GPL in 2007, first 1.0 Android release was in 2008.
Obviously if APIs cannot be copyrighted, then a ton of open source work geared towards making things compatible remains viable. Wine is one of the most obvious, but I can think of many others. Efforts to port CUDA code to non-Nvidia hardware. A potential effort to reimplement SwiftUI. And there are many more.
On the other hand, if APIs can be copyrighted, then buyers now know that there's a single-source risk for any API that's not released under a permissive open source license. So, to continue this example, Apple has the legal right to shut down any port of code written in SwiftUI to non-Apple hardware, and similarly for CUDA. This would immediately increase interest in actually open source alternatives; Flutter already exists, a Vulkan based runtime could be developed for TensorFlow, etc.
Sadly, I think this outcome is unlikely. What's more likely is that the ruling will be specific to the facts of the case. That basically means that there won't be clear guidance that you need to run away from proprietary APIs, but also not clear guidance that you can continue to rely on open source interop projects. Rather, any time any of this gets sticky, the only way through the mess will be to pay lawyers millions of dollars. That will have the effect of making it easier for the big players to dominate the market further, and harder for independent people to play. That's very much to the advantage of those in power, so I'm pretty sure that's what we'll see.
Buyers won't be very motivated to care because they are consuming the original product, not competing with it. The first mover to release an API frequently has no interest in allowing compatible, competing offerings to exist. It's the second mover, the competition, that desperately wants to be compatible with the first offering, so that they can effectively compete for the business of the customer who bought the original product.
>Generally, copyright law protection does not extend to song titles because they usually are short and lack sufficient originality. Therefore, you can (and often do) have multiple songs with the same name, and the first to name their song, for example "Crazy," does not have the right to stop other people from releasing their own songs named "Crazy." An exception to this is that some long titles may be found to have sufficient originality to be afforded copyright protection. I suspect that my friend's song entitled "The Concept of the Quantum-Mechanical Bodymind Has Sparked a Great Idea" is one of them. [1]
The whole article from [1] is worth reading. I wouldn't be surprised if the final verdict will be similar to song title laws from the music industry.
[1]: http://www.askamusiclawyer.com/archive/is-my-song-title-prot...
To quote The Verge:
"The absolute least important part of Ginsburg’s legacy is that she was the most reliable vote in copyright law cases, tending to vote in favor of rights-holders. Her loss also means that Google v. Oracle is being heard by eight justices and is therefore prone to a split court. (In the 1996 software copyright case Lotus v. Borland, an eight-justice court split evenly and was unable to set national precedent)."
"the amount and substantiality of the portion used in relation to the copyrighted work as a whole."
Trying to achieve full compatibility would seem to require copying more of the original API, not less.
Kind of like how Java is now open source and Google can use it but Oracle's lawsuit is about what Google did before it was open source.
But I'd guess there's some kind of statute of limitations or similar for infringement that old.
https://www.c-span.org/video/?469263-1/google-v-oracle-ameri...
Oral argument: https://www.supremecourt.gov/oral_arguments/audio/2020/18-95...
Oyez hasn't posted it yet, but it'd be up here later: https://www.oyez.org/cases/2020/18-956
If writing Java programs is okay, but the issue is copying the API, would it be okay to take 10,000 popular Java programs, read through their byte code, and use that to construct a set of classes and functions that those programs would need to run? It would, of course, be a nearly complete subset of the Java API, but it would be produced without any reference to the Java API itself. Instead, it'd be produced simply by examining programs you wanted to support.
So, the interface is published in every consuming application. If you look at an application which is missing a shared object and figure out how to implement the missing pieces in your own version of that shared object, you've re-implemented (part of) an API. So the question is, in doing so, have you infringed their copyright?
This is probably going to be complicated. I wouldn't be surprised to see a 8-0 outcome, but there's likely to be a concurring opinion or two, which will make the decision take longer. My expectation is that the opinion will come out in the January-March timeframe.
By way of comparison, Bilski v Kappos (the first big patent case in recent years) was a 9-0 case argued in November whose opinions only came out in the end-of-year opinion blitz.
If the court gets it wrong congress should fix it, but ideally we don't want a law that is a patchwork of tiny little exceptions because that fails to generalize to new things, so we would rather that the court just properly understands how to apply general principles.
Even if the court gets it wrong, my favored way of fixing it would be to modify the general principle to be less ambiguous to this case, not to explicitly make an api exception.
With a single legislative act, we need not worry about this or anything else, modulo constitutional issues which can also be fixed via amendments.
No, it is not obvious that API is a "functional thing" covered by existing law by the mere fact that SCOTUS has taken it on and it was a case to begin with.
I'm not sure why a trivial act of congress isn't the first thing we jump to rather than risk ruin. All the act needs to do is clarify what copyright means.
A copyright act for the digital millenium, if you will -- you can call it DMCA 2.0 :)
But APIs were never included, explicitly, in copyright in the first place. Why do they need to be explicitly excluded?
Jobs died thinking that Android (and particularly Eric Schmidt's part in sitting on the Apple board while Android was being cooked up at Google) was a personal affront to his magnum opus of iPhone, and the rumor is that Ellison agreed to hurt Android any way he could more or less without regard for the costs.
That is, in fact, how copyright works, and the original term was 14 years. Since then, the term has been extended several times in the name of "harmonization", and the term is currently so long it might as well be infinite, as far as software is concerned.
Google could have own Java, avoid the lawsuit and keep it Go style frozen at Java 6 instead.
And given Google's history they would have killed the other products even sooner than Oracle did.
And before the IBM example comes up, SQL is an ISO standard, that Oracle like every RDMS vendor pays for.
If techies want APIs to be uncopyrightable, the solution is to go to Congress and seek a carve-out exception in statute. Asking the courts to affirm what they assume to be the case undermines all of copyright. I know some Hackernews are okay with that, but I have friends and family who are artists and musicians, and they want to be able to put food on the table doing what they love.
By the same token, if we are rejecting judge made law that isn't expressly in the statute, if technies want APIs (or, for that matter, computer programs!) to be copyrightable, the solution is to go to Congress and get an explicit carve-in put in the statute. As it is, the only things explicitly included in copyright protection are:
--quote--
(1)literary works; (2)musical works, including any accompanying words; (3)dramatic works, including any accompanying music; (4)pantomimes and choreographic works; (5)pictorial, graphic, and sculptural works; (6)motion pictures and other audiovisual works; (7)sound recordings; and (8)architectural works.
--end quote--
Now, certainly some computer programs include things that fall on that list as components, and some might arguably be described as being interactive forms of one or the other category.
But APIs, themselves, don't fall into any of those categories, so why would they need an explicit carve-out when they aren't carved-in in the first place?
Therefore, it should be uncontroversial that APIs are subject to copyright and that Google was infringing.
When a work as a whole is copyrightable, that does not automatically mean that any subset of that work is copyrightable. You need to actually explain why and how your examples of chapter titles and headings are still eligible for copyright protection.
No, it doesn't (it's true that it implicitly does so with limitations on the protection that can be applied to them later than where it specifies what is protected, but it does not explictly include them in the list of what is protected, or explictly define them as “literary works” which are explicitly protected.) Computer programs (whether source code or otherwise) are processes. They aren't literary works describing processes. It's easy enough to see this is true.
If you change the expression of a literary work but not the process it describes, if someone is executing the process based on the new description as part of a larger set of processes, there is no impact—the process itself is unaffected.
If you change the supposed “expression” of a piece of computer source code, say by changing the names used for functions and arguments either that it calls or that it defines, and then compile it with other software it normally links with, it either breaks or creates object code that behaves differently at runtime. There is no “literary expression” that is not part of the process code describes, whether it relates to the compile time process the code describes, the link time process, or the runtime process. Code is pure process, and not only is process not explicitly protected it is explicitly not protected by copyright.
> API declarations constitute expression of an idea which has many ways to be expressed.
No, they are a concrete embodiment of a process (well, a set of potentially compile time, link time, runtime, and maybe other processes), and any change alters the process embodied materially. That's even more obviously the case with API definitions than it is with code generally, since the whole use of API declarations is to formally, mechanically define the functionality of the interface between separate pieces of code.
If the Supreme Court does not find in favor of Google, it most likely will do so by finding that the trial jury acted reasonably (not necessarily correctly -- because the litigants have a Constitutional right to a jury trial, judges or appellate courts aren't Constitutionally, or under the Rules of Civil Procedure, supposed to substitute their judgement of correctness as long as a jury could reasonably conclude as it did from the evidence) that Google's use was Fair Use, and that the CAFC was wrong to negate the jury verdict and act as the jury itself.
Now, sure, the Court could reach Google's copyrightability argument on APIs, but its a stretch to assume it would.
And even if it did, ruling that APIs are functional elements not subject to copyright for that reason would not "undermine the basis of copyright law entirely". It might weaken the basis for copyright applied to computer programs entirely, but that's a very different thing.
> if the unique expression of those Java APIs are not protectable by copyright
In order for use to be "fair use", the thing used must, in fact, be protectable by copyright.
Imagine if we took Google's argument seriously and extended it. What if code were inherently less copyrightable when it is more structural and boilerplate-filled? That could be a great thing, but Google themselves might be surprised at how little of their proprietary code qualifies for copyright under this standard.
For example, would Google's protobuf schemata still be copyrightable? They're needed for interoperability, after all. Would Google's client-side code for Youtube and Google Docs still be copyrightable? It's delivered in textual form to the end-user. Would Android's interface code be copyrightable? Probably not, by exactly the same argument that Google has been making before the courts!
If Google wins, then not only does Oracle lose, but the institution of copyright might also lose, which is an exciting proposition.
To me, the current copyright regime is what's "absurd" and "plainly ridiculous"; I am merely drawing conclusions based on what exists.