Supreme Court to Hear Google-Oracle Copyright Fight
axios.com
axios.com
The world is not going to be better for extending the protections Oracle wants here.
Alsup's ruling is sane, shows his clear understanding of coding and the history of Java and how it was licensed out to the world under Sun, and is really very simple to understand: http://www.groklaw.net/articlebasic.php?story=20120531172522...
The appeals court fucked this up, hard. I would like to think Alsup's ruling will be upheld -- groklaw has fantastic quotes from him during the trial. At one point, he himself notes he had coded from the spec some of the functions Oracle complained about and disagreed with Oracle counsel statements. Refreshing from our judicial branch, to say the least.
I'd be more concerned about emulators and actual chips. People have been assuming that copyright doesn't apply to APIs for so long that I'm sure there's any number of cases of accidental "copyright infringement as defined by Oracle". I'm just not sure that compilers are a prime example (at least as relating to instruction sets).
At least in the United States. China, on the other hand, will laugh at us as they lay claim to everything American lawyers prevent us from doing.
It would matter here too though as we do also want to sell software to US.
But if one stays out of US markets then things are as they have always been.
https://thetmca.com/equitable-estoppel-defense-denies-lego-f...
API compatibility doesn’t have any stylistic choices in it.
Silly example of course, can't think of any better. Feel free to substitute your own.
If a tree infringes in the woods and the silicon manufacturer doesn't hear it...
I hate to say it, but I'm with Oracle on this - but not for any reason that I've seen mentioned (so I guess I want neither party to win).
(Notwithstanding Sun's internal excitement at Google's use of Java prior to the Oracle acquisition.)
There is a justification on the grounds of obviousness for certain method headers to be uncopyrightable.
But for inobvious and complicated method headers I do not believe that the restriction should prevent the API from being subject to copyright, but rather to limit the applicability of the copyright for fair use purposes.
Specifically I believe the copyrights on such interfaces should not be applicable where interoperability is the justification for the reuse of the interface.
Google broke compatibility with Java. I do not believe that Google is using the API under fair use constraints.
I'm not sure how the law operates here - but I believe that the precedent set by a Google victory would be more damaging to my position. I'd like to see Google lose, and for someone later - operating with cross-compatibility in mind - to present and win a fair use case for reuse of an API.
Why does fair use for interoperability require perfect interoperability? That seems like a totally unreasonable bar. It would mean that making some fraction of an API ridiculously complex to implement a way from stopping anyone from implementing the rest of it.
From the UI perspective, there is actually a reasonable justification for limiting compatibility - but they went far further than what was reasonable.
They did this to prevent applications executable on any JVM from running on Android.
I think that underscores the point? That even legitimate JVM versions were not substitutable for each other.
You cannot make good law on this basis. Requiring compliance to a compatibility standard written by Oracle would give Oracle all the power, and render that kind of fair use exception effectively impossible to exercise. There's no good way to define what kind and degree of interoperability should qualify. The only regulatory option that doesn't trivially collapse into a complete win for Oracle is for API copyrights to not exist in the first place.
Not all of which will be Oracle certified, I would argue that each and every one of them should be free to exist regardless of that fact, on the grounds of fair use.
The courts have never been black and white entities - and there has long existed the legal notions of best and reasonable efforts. Which I think should be the standard by which a competing implementations interoperability should be judged.
This also ties in to another part of another response that I had not addressed - the reasonable efforts standard would protect against being required to implement needlessly complex parts of API.
In this instance, I believe both parties to be operating in bad faith.
My position is relatively simple, and despite the hate it seems to have inspired I stand by it: A complex API is a creative work that deserves the protections of copyright, fair use limitations should be applicable based upon a need for the existence of interoperable software.
The problem is a system that rewards bad actors - and yes Oracle is one of those bad actors.
The solution is to improve the system to disincentivise bad actors while continuing to provide time limited protections to those operating in good faith.
As I've mentioned in other comments best and reasonable efforts are standards already used in the legal system - and there is no reason that those standards could not be applied to reimplementation efforts.
All of the arguments that I've seen against what I'm suggesting are based around abuse of the system by bad faith actors - I think that they can be disincentivised without tearing it all down.
The legal system has largely failed in constraining copyright and patent abuse, and indeed has been key in massively expanding their reach (See "business process" patents and software patents, as well as stuff like the DMCA to shut down basically anything that involves interfacing with things).
API copyright is absolutely a _new_ concept invented whole cloth by the court, what advantage do you think it brings, vs the heavy tax on literally every piece of software ever created it imposes (after all CPU instruction sets are APIs).
You have repeatedly failed to present any actual advantage it provides beyond "it was hard work". What new APIs are going to exist because of this new law, that did not exist beforehand? What is the point of even trying to design a system where supposedly only "good faith" is rewarded? (good luck with that one)
Copyright is not about ownership because you created something, it is about benefit to society, that's why it expires and the public domain exists and also does not apply to all works.
No, sir, I don't like it.
I think that the system desperately needs to more actively punish those who abuse the legal system.
If a case is found to be frivolous I belief that the plaintiff should have to pay both fines and damages. The plaintiff's lawyers should also be punished - warnings, fines and eventual disbarment.
I'd prefer it if it didn't to come to that, and they lack the budget to do all that needs to be done, the system simply lacks enough good operators to act as a counterpoint to those operating in bad faith.
I think when you need that counterpoint at all, it's the system as a whole that needs to change. But this is getting way off topic.
(The answer is probably no, I'm sure a half decent lawyer would manage to distinguish that from this case since it is so simple).
Downvote if you like, but there's no other way to describe the absence of de minimis exceptions besides "idiocy." These judges are essentially monkeys in a machine shop.
I think this is another case where the law makers have been rather slow to keep up. Copyright is not really working in this era.
Isn't that exactly what the parent of your post called:
> These judges are essentially monkeys in a machine shop.
Blindly trying to apply an unfitting law, because those are the instructions?
https://docs.oracle.com/javase/6/docs/api/java/lang/String.h...
So...I guess this api signature for string concatenation is on the verge of being owned by oracle forever. Perhaps I can create a non-derived work by adding a few extra arguments.
1. Single sentence.
2. Usually obvious. In fact, just about every API definition in the above linked String method list is blatantly obvious, and many of the APIs look similar to ones in various other completely incompatible languages.
So even if you argue the copyrighted work is comprised of the whole set of APIs, it may be patent-able as an invention, but it does not seem reasonable to suggest it be protected by copyright.
Java: public String concat(String str)
Javascript: String.prototype.concat ( [ string1 [ , string2 [ , … ] ] ] )
Python: def __add__(self, *args, **kwargs)
C++: function <string> std::operator+ (string)This is categorically untrue. The discussion is not about anything called "API" but only certain kinds of APIs (code APIs, as opposed to protocols like REST "APIs"), and even then there is fair use.
[1]: https://www.law.cornell.edu/wex/fixed_in_a_tangible_medium_o...
Send a GET request to some_website.com/some_protocol to get back a jpg of a cat
If I just told you that verbally, and we did not write it down, record what I was saying via a mic, or anything else, then it would not be fixed. No one does protocols like that though.
The same applies to algorithms, BTW. If I write and publish an algorithm, it is possible that my paper and even the particular pseudocode I used is copyrighted, but that's not "the work" (of the algorithm) nor is it a part of it. That is why even though the paper is copyrighted, the algorithm itself is not, although it could perhaps be patented. As confusing as it may sound, in the US the situation is: the paper describing the algorithm is copyrighted, a program implementing the algorithm is copyrighted, the algorithm itself cannot be, but it can be patented.
Whether or not code APIs can be copyrighted, they are different from protocols just as programs are different from algorithms, as a certain fixed piece of text is certainly an important part of the work. That may not be a sufficient condition for copyright, but it is a necessary one.
Well really I'd probably need to have a few more APIs involved, such that I have a tree structure similar to classes, but the point stands.
All that this subdiscussion was discussing was whether or not REST APIs are fixed in a medium as required, they are.
> they are.
They most certainly are not. If you think REST protocols are like code APIs, you should be able to explain why algorithms are not copyrightable but programs are. The law already makes a distinction between those two, so you'll need to explain why that distinction does not apply for protocols vs. APIs.
And yet it is the only one you raised, and the only one I responded to in this thread. You are moving the goal posts. If these posts were legal briefs the judge would say you have waived the rest of your arguments and I would have won (Waiving arguments being the legal equivalent to moving goalposts).
But you seem to have interpreted the necessary condition that a work must be fixed in order to be eligible for copyright as "any fixed portion of a work is copyrightable." This is untrue both because being fixed is necessary but insufficient for copyright, and because tiny portions of a work aren't works in themselves. Also, I have not claimed that anything that might be called an API and is fixed is necessarily copyrightable. I only said what is definitely not copyrighted. So no goalposts have been moved, you just misunderstood the necessary condition and my point: Protocols (like algorithms), unlike code APIs (and programs), aren't fixed, and so cannot be copyrighted regardless of anything else that may or may not be. That some tiny portions of a protocol might be fixed does not change the status of the work.
For example, you and I could go to a sporting event and write down a description of it. Both of our descriptions are copyrighted, and any derivation of mine or yours are protected, but your description is not a violation of mine and vice versa, and neither is any other description by someone who saw the event but didn't derive her description from mine or yours.
Similarly for software, BTW. If you look at what a program does and then write a new program that does the same thing -- that's not copyright infringement, as you didn't derive your program from the fixed work of the original.
What you're describing is "how it should be", not the current state of the world.
> applies equally to REST
Nope. This is a case about a verbatim copy of about two hundred pages of text (11,500 lines). There are interesting legal questions about whether or not the text is copyrighted (because software copyright is more limited than some other forms of copyright), but REST protocols aren't a fixed piece of text to begin with. They are just not works that copyright law deals with.
> unless you can come up with a way for a server to not have the endpoint string literals in their code.
There is no problem with string literals. None of the words in Harry Potter is copyrighted, and most books, or program with string literals, containing all of them don't infringe on Harry Potter's copyright.
And the length of the verbatim copying doesn't matter, because these same ruling are rejecting de minimus claims.
Like please look up the legal rulings here. They're using different tests than you normally see with copyright. You're spreading a lot of misinformation here.
https://en.wikipedia.org/wiki/Structure,_sequence_and_organi...
You can use names verbatim. You can write a book with the names "Harry" and "Ron" and even "Dumbledore" without violating Harry Potter's copyright. In fact, if you take Harry Potter, translate it to French and change all the names so that not a single word is copied verbatim, that is a copyright violation. But regardless of what you copy, in order for a work to be protected by copyright at all, it must be some fixed piece of text (or an image, or an audio/video recording). REST protocols aren't.
> They're using different tests than you normally see with copyright. You're spreading a lot of misinformation here.
I'm not talking about this case, but about why this case doesn't apply -- whatever the result -- to REST protocols. What you linked to is about the following: Once a work is protected by copyright, what kind of derivations are disallowed? For example, Harry Potter is copyrighted, but I don't make a verbatim copy but a French translation. Is that protected or not? What about basic plot lines? But any such discussions are irrelevant to algorithms and protocols, which are not copyrightable works to begin with. There is also a question about code APIs, because there are other necessary conditions for copyright, but there's no question about protocols, as they don't satisfy the first condition -- there is no fixed work at all. Anyone who says this could affect protocols is spreading misinformation. Whether code APIs are copyrighted or not, protocols, like algorithms, aren't.
If this ruling passes the Supreme Court, you can't anymore in the context of software. That's the whole point of what has people up in arms. These points of copyright are left to the courts, and they can change the rules if they see fit.
I really don't understand your outright refusal to read the ruling or even the damn wiki page.
I won't be responding to you anymore until you make a good faith effort.
This is simply and totally untrue; it is nothing but uninformed panic. If you think otherwise, please point me to what makes you think that. In any event, a protocol is not a copyrightable work regardless of the result of this case, for reasons that have nothing at all to do with the discussion about the copyrightability of code APIs. Code APIs satisfy the basic necessary conditions for copyright, and there is debate over more nuanced ones. Protocols, like REST APIs, don't even satisfy the first requirement of copyright law -- they are not a work fixed in any tangible medium -- so they are completely irrelevant. Again, programs are copyrighted, algorithms are not -- even if the algorithms contain some fixed strings in them. If you don't understand that distinction, there is really no point in going further.
> I really don't understand your outright refusal to read the ruling or even the damn wiki page.
I have read pretty much everything written about this case, and the actual rulings. But understanding the basic tenets of copyright law is necessary in order to make sense of what you read.
The question of SSO is, once a work is copyrighted, is its SSO protected similarly to translation? For example, Harry Potter is copyrighted; if I copy the basic structure from Harry Potter is that an infringement? That's the subject of the discussion, which takes as a given that software is copyrighted. In the case of protocols -- like in the case of algorithms -- there is no work from the perspective of copyright law, so questions of what transformations of the work could constitute infringement are irrelevant.
I think that many people don't understand that copyright works like a two-stage process. First there needs to be a work satisfying some requirement to which copyright applies; second, once such a work exists, different kinds of deriving other works from it are determined to be infringing or not. This court case is about the second part, as it is recognized that software is a copyrighted work, and all discussions about the second step (like SSO) are under the assumption that the first step is OK. Protocols and algorithms don't even pass the first step, so any discusssion about the second does not concern them.
Any protocol worth protecting will have a tangible expression they can point to whether it be code or documentation. The need for a tangible expression doesn't make a practical difference in the de facto copyright of the REST API.
You keep using literary examples even though SSO treats software differently. I will be ignoring any literary allusions from now on, please use actual case law about software.
No, it doesn't work like that, just as if you implement an algorithm that's at the core of another program (without deriving your code from that other program) you don't infringe on the other program's copyright.
> Any protocol worth protecting will have a tangible expression they can point to whether it be code or documentation.
I don't know how to explain it any better than I have, so I'll mention yet again that your point applies to algorithms, and yet they are not copyrightable.
If you have a paper describing an algorithm, the paper is copyrighted, but the algorithm it describes is not. If you copy or translate the paper you may be in violation of its copyright; if you implement the algorithm described -- you are not. Same goes for recipe books, by the way. If you copy the recipe you could be in violation; if you implement it -- i.e. cook according to it -- you are not.
That the program is a fixed expression that manifests the algorithm or protocol is irrelevant. You are not allowed to infringe on the program's copyright, but the protocol or algorithm it describes are not copyrighted to begin with.
> please use actual case law about software.
Protocols are not software. SSO is irrelevant to them. Their relationship to software is the same as that of algorithms to software, and SSO doesn't apply to algorithms either, because they are not copyrighted works.
Any argument you'd like to make why this case has any bearing on protocols would also need to be compatible with the fact that programs are copyrighted while algorithms are not. If you make an argument that would also cover algorithms you can know you've made a wrong turn somewhere.
Since you obviously aren't interested in a good faith discussion that doesn't involve you adding strawmen, I shall bid you good day.
The lack of copyright protection for algorithms was never in question here until you started bringing it up.
I said good day.
For example, you said above that a program implementing a protocol becomes its fixed expression, and so every implementation of the protocol would violate that program's copyright. Well, that same argument can be applied to incorrectly conclude that algorithms are copyrighted as well. Same goes for an argument about certain fixed strings. I've explained directly why those arguments don't work, but if you don't understand the explanation, perhaps seeing that your argument would also apply for algorithms make you realize you've made a bad turn somewhere. To claim that this case affects protocols you'll need an argument that cannot be used to claim algorithms are copyrighted, too. If it can be -- it's a wrong argument.
The fact that you don't see the difference between copying an abstract idea like an algorithm compared to literal copying of the names necessary for the structure, sequence, and organization of the API belies your ignorance wrt to copyright.
One involves no "this piece of the original is listed here in the reimplementation, verbatim" and the other does.
So far you've given no examples as to why you think that literal copying of SSO of a clean room code library reimplementation isn't equivalent to literal copying of SSO of a clean room REST server reimplementation.
Do you understand SSO arguments?
An algorithm can contain literal names and you're allowed to copy them. You need to understand that what you're allowed to copy or not is the second step after having established that the work under discussion is a fixed expression (and satisfies all other necessary conditions).
> necessary for the structure, sequence, and organization of the API belies your ignorance wrt to copyright.
SSO applies after it's established that a work is a copyrighted fixed expression -- it's the second step; it does not, and cannot, establish that things that are not works are. The SSO of a non-copyrightable thing, like an algorithm or a protocol is not protected.
> One involves no "this piece of the original is listed here in the reimplementation, verbatim" and the other does.
What you're allowed to copy or not of a copyrighted work is irrelevant to what you're allowed to copy, or not, of a non-copyrighted work. You are allowed to copy, verbatim, anything that's copyable from non-copyrighted works.
For example, if I tell you an original story at a bar, the story is not copyrighted. Therefore, you are clearly allowed to repeat it verbatim, write it down etc. It's not that copying verbatim, SSO, translations of anything is not allowed; it's that doing those things for copyrighted works might not be allowed. The action matters only after the work is determined to be copyrighted. Another example: distributing photos of copyrighted images might be an infringement. Your face, if you show it in public, isn't a copyrighted work. Do you think that "the SSO argument" states that the SSO of your face is protected?
> Do you understand SSO arguments?
Yeah, but clearly you don't. SSO, like translation, is one of the kinds of protected derivations of a copyrighted work. It is not used to define what is or isn't a work. Protocols are not copyrighted, and so their translation and SSO are not protected. Programs are copyrighted works, and so the argument goes that their SSO is protected.
Once more, two steps: first, is it a work that satisfies the necessary conditions for copyright (yes for programs, no for algorithms/protocols); second, if the first part holds, what kinds of copies and derivations are allowed (SSO, translation, verbatim copies of small parts etc)?
You don't need to concern yourself with SSO or verbatim copies until you've established that the work is copyrighted. If it's not -- like in the case of an algorithm or a protocol -- the argument is completely irrelevant.
A reimplementation of a protocol will, by definition, have another implementation that has SSO copyright over the API.
Same for an algorithm.
What you're saying now is this: forget the protocol, which isn't a copyrighted work, let's look at some program that implement the protocol. If you reimplement you will violate the program's copyright. It doesn't work like that because your reimplementation isn't derived from that program. You probably don't even have any direct access to the program's executable, let alone its source. Think of two reporters covering some news event. The news event itself isn't copyrighted, but each article is. Still, because they're both reporting the same event, they will have the same quotes. Still, they're not infringing on each other because their source wasn't the other article but something (the event) which isn't copyrightable. If your source is something that isn't copyrighted, you can copy it even if some copyrighted work copies it as well.
And again, your argument would work to explain why implementing an algorithm is a copyright violation. It isn't, so you can know your argument is wrong.
None of this, however, is relevant to discussions of works that are not copyrighted in the first place, as they do not even satisfy the most basic necessary conditions, like algorithms and protocols, of which REST "APIs" are instances. The case is about stages 2 and 3; they fail at stage 1. Partial, translated, complete, verbatim etc. copies of non-copyrighted works is outside the bounds of copyright law, and have nothing whatsoever to do with this case.
Look at it this way, if oracle loses, then what’s the implications of the software licenses in general. The whole point is that they were protected by copyright. If that’s shot down, then what’s at stake?
Not saying I side one way or the other, simply that I don’t think it’s clear. Depending how the court rules one way or the other could have a huge impact (as you pointed out).
An Oracle loss would not damage the legal framework that the software industry has been operating under. Oracle's loss would only confirm the non-existence of a new class of copyright that Oracle is trying to invent (one that appears to be patent protections with copyright duration, enforced in part by trademarks). An Oracle loss would not undermine the legal foundations of existing copyrights on code that implements an API.
No one has ever thought that you could stop people from copying APIs. If they did all sorts of things like Linux (hi Unix), Wine, Windows Subsystem For Linux, AMD x86 CPUs (ok, Intel might have licensed them to avoid anti trust issues), Intel x64 CPUs, and so on would not exist.
Rooting for Google itself, who is simply pursuing the most effective solution for their own business (and brand)? That’s something entirely different.
Turns out, inventing a whole language every time you need to write a new library is an enormous pain in the ass.
(I'm all for crapping on Oracle, I guess the lesson is to weave that into any post on this topic).
So yeah, I'm rooting for Google and I have no hesitation or shame rooting for Google -- because for better or worse, Google is the company fighting for my rights in this case, and I want to win.
I’ve always found it strange that other programmers are so dismissive of APIs as copyrightable work. They’re they hard part! Building APIs requires creativity and careful thought.
If you support the idea that APIs can’t be copyrighted, and ignoring the evilness of Oracle and Google, what’s your reasoning?
The reasoning is quite simple and obvious: We have long-standing statutory and case law that defines specifically what is or isn't eligible for copyright protection, or patents, or trademarks. Your gut feelings about whether your API deserves protection because of how much effort you put into it are completely irrelevant to that legal framework.
There was a time when software didn’t have copyright protection. Somebody had to make the first move.
And all of the above is about the legal, technical questions about what the law is. The public policy question of what the law should be is a different matter entirely, and opinions about that generally should be addressed to Congress, not the Supreme Court.
I think you're mixing up different types of intellectual property:
- Trademarks are intended to identify a source. Trademarks cannot be functional, they have to be descriptive.
- Copyright must express a creative idea. That idea can be artistic, or functional. Computer code and APIs can be copyrighted (as they most often are), but they can also be patented.
- Patents cover inventions with some utility. One can definitely patent a piece of art if it provides some utility.
It's not uncommon for companies to throw all three at whatever they are cooking up.
Are they though?
Implementors aren't piggybacking on APIs because they can't come up with anything better, they can ... easily. They are implementing those APIs because they want compiled Java programs to run on their runtime.
Well, that's a difference without meaning. Familiarity with the syntax is important but we're not talking about copyrighting the language structure and syntax.
The other aspect is that of the wider ecosystem. Once you commit to Java, you have to reimplement the existing APIs because every Java library relies on those APIs. And it is that ecosystem that is the true value prop. The API itself isn't special itself (in fact, the Java one is frequently maligned for how bad it is), and devs adapt quickly to different ones when they move to another programming language. There would be no point in selecting the Java language without being able to partake in the ecosystem, no matter how brilliant the API design is. And if it was brilliant, they could have aped it in another language (Dart?) ... I'm making an assumption that presumably adapting the API to another language would be fine by you? Because if not, the mess you would cause in the industry would be immeasurable.
The long version of both of those is made much better than I could hope to make it in the various briefs. You can find them all here: https://www.supremecourt.gov/search.aspx?filename=/docket/do...
Google's brief probably provides the best version of the legal arguments, that being their job. Read the text under the heading "The Federal Circuit erred in holding that the Java API declarations were copyrightable." on pages 16 to 21 and the text under "This Court Should Grant Review To Decide Whether, As The Jury Found, Petitioner’s Use Of A Software Interface In The Context Of Creating A New Computer Program Constitutes Fair Use" on pages 21 to 29. I personally find the merger doctrine arguments particularly convincing, starting on page 17. Here's a direct link https://www.supremecourt.gov/DocketPDF/18/18-956/81532/20190...
As for why it would be disastrous for the software industry, I particularly like this amicus brief, and would suggest reading section 2. It was written by 78 particularly famous computer scientists, including Steve Wozniak, Guido van Rossum, Ken Thompson, Bjarne Stroustrup, Martin Odersky, Peter Norvig, Brian Kernighan, and Alan Kay. https://www.supremecourt.gov/DocketPDF/18/18-956/89487/20190...
Here's an except, where one of the programmers for Java says that while he was creating Java's standard libraries he copied APIs in the same way ("Amicus" in this context means one of the computer scientists who wrote this brief to help better inform the court)
> Sun reimplemented existing APIs for Java. Java reimplemented C’s math API,which includes methods for calculating a variety of mathematical functions. While at Sun, amicus Joshua Bloch oversaw Sun’s reimplementation of the Perl programming language’s regular expression API for Java, which allows sophisticated text searches and alterations. Oracle’s attempt to copyright Java’s API and hold Google liable for infringement of the resulting java.util.regex API ignores Java’s own history of API reimplementation.
Here's an excerpt about an API you are probably familiar with, which hopefully underlies just how bad a compatability nightmare this ruling will create
> In 1983, the Berkeley Systems Research Group released the Berkeley Systems Distribution (BSD) sockets API. Sockets control the endpoints for any communication over the Internet. Because the BSD sockets API was not copyrighted, it became widely adopted: Every major operating system reimplemented it to enable Internet communication. Thus, programmers can write standardized software compatible across computers to manage Internet connectivity.
But really, read the whole of section 2.
Copyright is the thing that applies to works of authorship, like short stories and music. You can't copyright a fuel pump for a jet engine. You can't copyright function. That's patents, not copyright.
Software is somewhat unusual in that it's at the same time a work of authorship (code, copyrightable), and a set instructions for a machine to interpret (functional), and pure mathematics (facts about the universe, not subject to patent or copyright).
But an API is at the intersection of the functional part and the factual part. What distinguishes a literary work from a fact is that the literary work leaves room for creative expression. A copyright on an expression of a fact isn't a copyright on the fact itself, because someone else doesn't have to use your expression. They can create their own expression, so you having a copyright over your expression doesn't exclude them from using or conveying the same factual information.
When someone creates an implementation of an API, the API itself is a fact about how to interact with implementations of that API. There isn't any other way to interact with other implementations, so there is no room for creative expression in that aspect of a compatible implementation, so there is nothing there to copyright. You have to use the same API for entirely functional reasons or it's not compatible. And you can't copyright function.
Does the presence of third party Skyrim mods mean that everything they refer to is an API and therefore non-copyright? The game geometry, maps, characters and events are facts about Skyrim that those mods need to operate. Does this therefore imply that a hypothetical person could sell their own re-implementation of Skyrim on the grounds that all those things (characters, missions, events, geometry, models, etc) were function required for mods to continue to operate?
Or, to stretch it in a different direction, let's suppose I write some functions. If you write some functions that call them, presumably my API is therefore functionality and non-copyright? But what about if you don't call them, and only I happen to write calling code. It's still an API, it's still functionality required for other code to operate (my own), so is it still non-copyright?
What about whether I mark my code public? If I omit "public" from the same function definitions so they can't be called externally do the definitions become artistic and copyright? If so then is the artistry in the lack of a public keyword? If not then is any code structure copyright - it's all functionality that calling functions requires to operate.
Yes, that's deliberately playing logic games and taking things to extremes to see if there's a clear line in the sand. It's going to be interesting to see what the court determines, anyway, because it seems like a big question.
You're supposing that function being uncopyrightable narrows the copyright in the expression, but they're really just two completely different things.
Let's try an even more extreme example. Remember those anti-piracy book codes from a few decades ago? They'd sell a game with a printed manual and then to start the game you'd have to type in the third word of paragraph two on page seven of the manual.
We'll take the game copyright itself out of the equation by saying that the software is cheating by trying to restrict a copyright year 1800 work (expired copyright) using a copyright year 2000 book.
The book itself is clearly subject to copyright. It could be Harry Potter for all that matters. But the third word of paragraph two on page seven? That's a fact about the book. As is the fourth word of paragraph two on page seven, and so on.
If you collect every single fact about the book, you have all the information you need to reproduce a copy of the book. That neither means that facts are copyrightable nor that books are not. If you used all the facts to reproduce a printed copy of the book, that would clearly be copyright infringement. But if you collected and used all the facts only to solve the book code, not so much. Interoperability is solving the book code, not reproducing the book. Function, not expression.
And it has nothing to do with publication vs. secrecy because that's a copyright thing. Facts are facts whether you intended anybody else to know them or not.
We cheered for Compaq when they reverse engineered the IBM PC and started selling computers that could run software built for the IBM. We cheered Linux when it created a free alternative to the proprietary Unix interface. We cheered WINE when it made Windows APIs available under Linux. This kind of interoperability gives the rest of us the ability to reuse our own software without being beholden to the companies that created the original target platform.
Incidentally, there's a slight distinction in wording around API copyrights. I don't think there's a doubt that they can be copyrighted. Anything that is written down, recorded or filmed automatically receives copyright protection. The interesting question is whether there is a fair use exemption for interoperability. I think it would be obviously wrong if Google had taken Java and its APIs, renamed it Gava and then started pushing developers to write Gava software instead of Java. But they didn't, they just made Java be able to run on a new class of devices. If all you're doing is helping to ensure that existing code written by other developers can work with your product, that's a benefit for those developers too as well as the end users that buy and run the software.
Most relevant to this case is the merger doctrine. Ideas that can be expressed in only a small number of ways are not copyrightable.
Even more on point to your comment is the concept of copyright misuse. If you try to use your copyright (a government granted temporary monopoly on the reproduction of your work) to gain monopolies on other things you can not only lose the infringement case but in extreme cases even lose the copyright entirely.
https://en.wikipedia.org/wiki/Copyright_misuse
https://en.wikipedia.org/wiki/Idea%E2%80%93expression_distin...
Does the work become public domain or government royalty subject in that case? If the latter, it is worse since the government cannot be sued for copyright misuse, either.
The CC's opinion is of interest here:
> We further find that the district court erred in focusing its merger analysis on the options available to Google at the time of copying. It is well-established that copyrightability and the scope of protectable activity are to be evaluated at the time of creation, not at the time of infringement. See Apple Computer, Inc. v. Formula Int'l, Inc., 725 F.2d 521, 524 (9th Cir.1984) (quoting National Commission on New Technological Uses of Copyrighted Works, Final Report at 21 (1979) ("CONTU Report") (recognizing that the Copyright Act was designed "to protect all works of authorship from the moment of their fixation in any tangible medium of expression")). The focus is, therefore, on the options that were available to Sun/Oracle at the time it created the API packages. Of course, once Sun/Oracle created "java.lang.Math.max," programmers who want to use that particular package have to call it by that name. But, as the court acknowledged, nothing prevented Google from writing its own declaring code, along with its own implementing code, to achieve the same result. In such circumstances, the chosen expression simply does not merge with the idea being expressed.[7]
> copyright misuse
Inoperability with customers who have decided to use a service or product or lock-in due to said inoperability itself does not necessarily make the provider of the original service a monopoly.
Interoperability arguments have relevance in fair-use, but the courts have yet to determine if Google has a right to the APIs under fair use. Google and others may be entitled to the APIs under fair use, but the CC has determined that the SSO of APIs are copyrightable.
And fair use is yet another can of uncertainty, since usurpation of market share counts negatively to one's case for fair use.
====
In the case of APIs, a competing service can create a functionally identical competing API, but differently structured and organized and named, and then provide a competitor2us.sh script to help their customers migrate.
That said, I think fair use is more likely to apply than copyright misuse in this case. I just brought it up as one way that the judiciary is empowered to be lenient in their judgment on copyright infringement because of compatibility and lock-in.
This is factually untrue. Many things written down, recorded, and filmed do not receive copyright protection in the united states. A common example is recipes.
There is extremely good reason to think that APIs specifically fall into the set of things that can not be copyrighted. That's what the original ruling in this case was (overturned on appeal by the federal circuit). That's what a good portion of Google's brief argues.
But I also think that it is better for the world with much less copyright protection in general.
I honestly don't get the Oracle hate from HN people, even if I do understand it from the Slashdot folks.
I accompanied Sales Account managers with fellow female engineers to client meeting where they, and I’m not kidding, discussed which strip clubs they would go to after the meetings.
If Apple is a designer culture, and Google is an engineer culture, then I‘d say Oracle is driven by a hierarchy of sales culture.
Isn't Oracle a legal driven company [0] :)
Another perspective is that Oracle is one of just a few tech companies left that has a proper dedicated research lab that does long-term research without asking about profit. I worked on my research project there for six years and nobody once asked me how we were going to make money from it, let alone talked about sales. That’s pretty special these days.
Oracle even paid me a senior developer salary while I worked on my PhD. Hard to say that’s ‘completely sales driven!’
And so what anyway? Google is also good at supporting things not sales driven means that Oracle isn’t?
There's plenty of lab research going on.
I personally think stripclubs arre a waste of money, but I know femenists that would take exception to either of those above.
No matter how "woke" or allied you think you are, there's no way the lived experience of a white person reacts the same way to people reinforcing systemic racism than that of those who have to live under that experience.
The analogy I use to describe Oracle is that they're this kind of massive lumbering beast that just lays around and occasionally swallows other companies alive and whole. Then those companies run around inside, burning existing customer good will for a while until Oracle finishes digesting them or generating whatever news-reports or vendor lock-in they wanted in the first place. Then Oracle goes out to find another company to eat.
I saw a slow movement with my particular department away from developing useful software towards, "just keep on releasing things, just keep on trying to figure out what looks good at trade shows, just keep the department moving forward like a zombie while it gets eaten away and resources get shifted to new acquisitions and lawyers and salespeople." The software wasn't even a secondary concern, it was just a very minor part of the company that happened on the side. Writing code was a side-effect of the business, our real business was sales and grand promises and multi-year contracts that everyone was going to regret.
As a developer that wants to build products that actually help businesses and users, it felt really, really bad -- and my impression interacting with other parts of the business and other departments felt the same. Like they were just kind of lumbering on, that they existed because a few companies were locked in or were still buying them, and a few more dollars could be extracted before they starved to death or until their staff was fully absorbed into new projects.
I won't go into any more specific detail than that; for better or worse I feel like I have some responsibility to be a little vague. But by the time I left I was convinced that any company Oracle bought or any project it maintained was doomed as soon as they touched it. It's one of the reasons I won't work with Java -- I just don't want to tie myself to a technology that's owned by a company like that.
The current case with Sun is to me perfectly in character with the company. Oracle bought Sun, killed everything that made it Sun, and now their lawyers are out trying to extract every last penny they can get out of its mostly rotted corpse, all under the guise of 'protecting their investment' or whatever.
I'm very cynical on Oracle now, and I wasn't even at the company very long. Since moving on I've been able to work on industry-scale software that's actually being designed for customers and that actually cares about helping them accomplish business goals. It's a massive breath of fresh air that I'm still grateful for to this day. It makes a huge difference to be able to get up in the morning and feel like there's an actual reason you're going to work beyond buying Ellison a new yacht.
Somewhat amusingly, Java becomes more dangerous to use if Oracle wins this case, because they would then be able to kill OpenJDK and any other implementations whenever they want.
It's either an elaborate joke, or McAfee wrote it himself. Or both.
In any case, if I was an US citizen and had to choose between him and Trump, well, that would've been a very hard choice. They both deliver.
What about removing Oracle's devs contributions from Linux kernel?
Which is kind of ironic, hate them, but then willing accepting whatever comes from them, 'cause hey it is free.
What is schizophrenic is having a community that hates big corporations, but happily takes anything they decide to offer,
i would be more worried when they propose that we all abandon this adequate gpl tool for this permissive licensed code they seriously didn't write, but here's ten fantastic contributions they made.
I only see that among FOSS folks, seldom among other kinds of activism.
Removing contributions to the Linux kernel? I don't think so. The kernel is free software and people contribute to it knowing that it is free software, so they cannot hold any code hostage. Once you release as free software, you give up that control.
I didn't till I had to become one of them this year. Mnesia is real, it's prime time, but not in place of something like Oracle.
> comparing an oil rig driller to a fisher price screwdriver.
Better analogy would be Comparing SQL Server to Redis. Mnesia is, at it's heart, a(n optionally) Transactional K-V lookup that can be run distributed. It's use case it works VERY well, but I wouldn't consider it a substitute for Relational storage.
My last company was entangled in the Oracle web of vendor lock in. Before renewing our contracts, Oracle wanted literal access to our proprietary code - much of which is older code that mixes business logic and logic that works directly with Oracles products. Many of the algorithms we had implemented were 100% proprietary and secrets - not something we want just anyone to see, especially a competitor. On top of that, this company had IT contractors that had built all kinds of functionality using one off features only available in Oracle - shit that didn’t scale with new and upcoming use cases but also just a huge pain in the ass to migrate off of.
People think AWS or Azure risk vendor lock in. Oh boy you do not know what true evil actually is - Oracle literally prays on this happening. It’s the foundation of their business model. Not features, not innovation, nothing else - but solely ensuring your customers have no alternative but to use your products at whatever cost you want or drown in litigation.
https://bbvaopen4u.com/en/actualidad/patents-apis-or-copyrig...
The original Java license mandates that mobile usage is differently licensed. Google basically writhed their own JVM just to bypass this - not for any other technical reasons.
You're begging the question. This Supreme Court fight is over whether a clean room reimplementation lets them do that legally.
And if it turns out that Google loses this case, then all sorts of things that we take for granted for interoperability (like WINE, and, before the MS acquisition, Mono) are actually copyright infringement and shouldn't exist. I don't think we can claim with a straight face that WINE or Mono were created with malice intended toward MS, so we should give Google the same courtesy.
And nowadays Android holds hostage any Java developer that wants to target Android, because one needs to constrain ourselves to Android Java's view of the world.
Isn't the way the law is written the real root cause here? Judges and courts don't write laws...
Basic questions pop up (hey look "pop" that's an API) in my mind like: is copyright on code a thing that should exist?
This reply I already wrote serves as a good answer to that question (though I'm not the person you asked): https://news.ycombinator.com/item?id=21550702
> Isn't the way the law is written the real root cause here? Judges and courts don't write laws...
This is a complicated question, but I would argue that the answer is no. Congress trying to anticipate every corner case ahead of time would be a nightmare, so instead the courts exist to take general laws and apply them to specific cases.
Even if congress tried to write a law with no unspecified edge cases, they would fail, because any law they pass has to be within the powers granted to them by the constitution, and those powers are vague. The relevant power here is literally "[the United States 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". That's it, one sentence, it's vague and there is no fixing it. If congress tries to legislate something that falls a bit outside of it, or that violates any of the various rights and freedoms specified in equally vague sentences, the law, at least as applied such that is violates the constitution, doesn't exist.
It's also not quite true that judges and courts don't write law in our common law system. They do, that's what the "common" part is about. Statutory law takes precedence, common law fills in the gaps. Here's an example of a case where the Texas Supreme Court directly addresses that they are creating new exceptions to the law, and that they can do so because the relevant law in the first place was invented by the courts: https://www.casemine.com/judgement/us/59148e86add7b04934555a...
"James Gosling Triangulation's Interview on Google vs. Sun"
https://www.youtube.com/watch?v=ZYw3X4RZv6Y&feature=youtu.be...
Google should face the same penalty as Microsoft did, plain and simple.
GCC is an ISO C++ and ISO C compliant compiler, plus a set of language extensions.
Any ISO C++ or ISO C code will compile under GCC.
Not every piece of standard compliant Java code will compile under Android Java.
Not only this produces a burden writting portable Java libraries, it creates a false perception to many developers that learned Java via Android and assume Android Java == Java.
The later point is usually used by Google when they sell how Kotlin fares against Java, because naturally if they would compare it against a proper up to date version, some of the plus points wouldn't uphold.
Even Jake Wharton already complained about this publicly, and he is now working at Google, go figure.
> Happy Tuesday Android developers! Java 13 out today. Java 8 is now 5½ years old. Here's your bi-yearly reminder that Android is holding back the Java library and language ecosystem.
https://twitter.com/JakeWharton/status/1174020113466568704
> The Android platform is on the cusp of holding Kotlin back. New bytecodes not being available both in the Dalvik set but also on devices in the ecosystem means Kotlin is forced to target older Java bytecode versions which can hinder new language functionality.
https://twitter.com/JakeWharton/status/1017597264225857536
> Kotlin is great but there's no reason anyone should need to target Java 6 bytecode and APIs in 2019. IntelliJ platform switched to 8 in 2016.1 and 11 in 2019.1. Servers are mostly 8 trending towards 11.
https://twitter.com/JakeWharton/status/1174024747400777729
So we are just in the same position as if J++ would be kept being a product, any Java library author that wants to have market share on Android needs to constrain themselves to the Android's view of what means to be Java.
And I have to bow to Jake as he is doing a very good job adding support to R8 and D8, to at very least desugar modern Java features into Android Java.
Java 7 byte code was a big mistake. People complained but Oracle didn’t listen. As always.
http://chrononsystems.com/blog/java-7-design-flaw-leads-to-h...
They forked the shit out of it too with tons of base functionality being in org.dvb. and javax.tv.
Not just because of this issue, but because of tons of other mistakes made by Oracle: users shouted, Oracle ignored.
The net result is inertia is high, but Java is stable declining. Existing projects continue to be developed in Java, new projects often choose something else.
Had Google used a completely different language instead, this market wouldn't exist at all, and Java library authors wouldn't even have the option of choosing to target it.
I don't disagree that Google's handling of the language is bad, but that doesn't mean it should be illegal. Creating a bad legal precedent harms us all.
I worked on and with lots of APIs back in the day. They are all gone. All of them. Eliminated for business reasons. The internet has become a tool for carving out fiefdoms of engagement to be monetized, it's not about connecting people or systems anymore.
Hopefully as things continue to the cloud with private options and their loss of the JEDI contract puts them right out of business.
1. Good APIs are hard.
2. Under Alsup's ruling, good luck competing with AWS sales org when they decide to offer your own APIs as a service.
3. Nothing prevents Google from inventing their own APIs, and licensing them under whatever terms they like.
As of Google vs. Oracle, it's pretty clear that Google appropriated Java to benefit from its penetration in the market place, instead of putting in the hard work to build their own. Apple has built their own ecosystem, ObjectiveC/Cocoa/Swift/SwiftUI. Microsoft has built their own ecosystem, C#/DotNet, or adopted and contributed to open standards, HTML5/Javascript/Typescript. Heck, even HP has built WebOS around open standards.
If the only advantage you have over AWS is that developers would have to change the function names in their code, you're dead anyway. And copyrightable APIs mean that you can't offer an API compatible with AWS as a way to get developers to try your platform in the first place.
The exposed function calls of an API are meant to be implementation-blind.
Let's say car-company A builds the first ever car that's operated with a steering wheel, gas pedal, brake pedal, clutch pedal, and shifter.
Then, Company B comes along and - both to create a complete control system for the car AND to potentially benefit consumers who are already familiar with those controls - also uses a steering wheel, gas pedal, brake pedal, clutch pedal, and shifter.
The steering column and its inner workings are completely different. The gas pedal activates a V8 combustion engine instead of an I4. The clutch pedal triggers a dual clutch for faster shifting between gears. The brake pedal activates disc brakes instead of drum-brakes.
The appeals court is, in effect, saying that Company B has violated copyright because, when faced with the same problem, they came up with a solution that looks very similar on the outside. They turn a blind eye - willingly or unwillingly - to all the new engineering that went on to improve the product and create a new expression of an automobile.
Sounds a bit like what Peter Vessenes is doing to 25,000 creditors of MtGox, even after being offered an incredibly generous $10 million dollar kiss off.
At the same time, Oracle’s characterization of their API as “original software” is not entirely off base, as anyone who has spent time and energy creating and API would know. The amount of design and work required to create an elegant and useful API is huge, and while it would irreparably harm software as a field to call it copyrightable, calling it anything other than an “original” work is a weak position.
Personally, I’m dreading the outcome of this case.
"So long as the specific code used to implement a method is different, anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification of any methods used in the Java API. It does not matter that the declaration or method header lines are identical."
The more immediate argument is that APIs aren't copyrightable material, since there isn't more than one way to write them. You can't write the API differently and still let existing java programs run with your standard library.
It's not the internals of the functions that this case is about, it's literally about "class ArrayList { void clear() { [this part excluded from case] } ... }"
there is a big difference between an API exposed to all other programmers in the world - versus one that is there for say compatibility.
Their entire API works the same way as Java system and you program it as Java - it would be very different if say Android was programmed in Go and they had a way to translate Java programs into Go.
It's more of a nitpick, but your reply also exaggerates the scope of the case. No one is arguing in this case that Google was not free to implement Android or an API in Java, they are arguing about re-implementing Java's standard library APIs. As far as this case goes I don't think there is any salient distinction between implementing android in Go, and implementing android in Java with a different standard library api.
I always thought that every PC maker did have to pay royalties to Phoenix or one of the other BIOS vendors.
I know that open-source BIOSes, e.g., coreboot (formerly known as LinuxBIOS), exist, but I got the impression that even at this late stage in the BIOS game, only a minority of machines ship with them.
I always thought that Compaq created its clean-room implementation because IBM outright refused to license their BIOS (to Compaq or anyone else).
Imagine a world where Compaq was unable to create a cleanroom implementation of IBM's BIOS because that involved re-implementing the copyrighted APIs.
coreboot is not an open source BIOS, it's open source firmware. It can be combined with SeaBIOS, which is an actual PCBIOS implementation (that may or may not be in violation of IBM's APIs given this case) to provide a PCBIOS-alike boot environment.
It can also be combined with Tianocore, Intel's open sourced implementation of the high level APIs of UEFI, so that this approach would be less affected by the court case (since that's using code verbatim that was specifically published for that purpose). But who knows if the Oracle case wouldn't affect this approach as well?
coreboot can also be combined with other code for customized boot concepts, like on Chromebooks, which are probably the largest consumer deployment of coreboot, at ~6% of laptops and desktop in the US, apparently (The numbers on https://en.wikipedia.org/wiki/Usage_share_of_operating_syste... vary wildly depending on the detail each is covering)
> I always thought that Compaq created its clean-room implementation because IBM outright refused to license their BIOS (to Compaq or anyone else).
Apparently Google (or Android before they were bought? not sure) also tried to license Java for Android and that fell through. They didn't clean-room because there was the Harmony stuff to work from that nobody seemed to have a problem with. These days Android's Java is based on OpenJDK which gives it a whole new twist (it being licensed by Oracle under GPL terms).
That being said, I feel ruling against Oracle would be also very perilous for open software from for profit entities, as it would have a harmful chilling effect on companies trying to dual license or keep their technology open. Arguments Google had made in earlier stages used the GPL-licensed OpenJDK to justify using their non-GPL implementation.
Would WINE be legal if Oracle won? Would Oracle's OpenOffice be able to read and save Microsoft document formats? Replicating APIs has always been a huge part of the Open Source movement.
WINE would be fair use because it’s purpose is to allow programs written for Windows to run on Linux.
Google’s use of the Java API would be infringement because Google’s use of the API is to provide a familiar environment for Java developers and it was easier to borrow the Java API than design a new one.
Edit: also why do those emails matter? The facts of the case aren't dependent on them. There's nothing wrong with a company looking to build a semi interoperable replacement to avoid license fees. That's why sun bought and continued development on OpenOffice; they figured out that was cheaper than the MS Office fees at their scale.
To me the intention matters. If you copied it so that you could market that you work with existing software then I think you ought to be fine. If you copied it because designing a query language is hard then probably not.
If Oracle wins, software engineering will be seriously hampered. And that's not hyperbole. If you are on Oracle's side you directly jeopardize the livelihoods of most of the contributors of this board. So not only am I not surprised by the downvotes, I think they're appropriate.
Some terms about API use would likely change in some software agreements. Google would fess up about 8 billion dollars. And not much else would happen.
Software engineering is a vital part of the world and the economy and it will not go away because the law got enforced.
Then they could demand licenses for any C toolchain as well as any piece of code (libc, Linux) that included libc/UNIX compatible declarations.
This could be highly beneficial to software engineering since it would discourage the use of languages like C and Java, as well as UNIX-like systems. ;-)
Obviously IANAL, but to me as a game designer, mechanics aren't any less creative work than narrative. In fact, I'm spending more of my creative energy on mechanics than I am on story. So the lines to me just seem incredibly arbitrary, or at least I don't understand the legal differences well enough to figure out intuitively where they lie. I am incredibly grateful that game mechanics can't be copyrighted, but game mechanics don't feel like inventions to me. A game mechanic is how I express an idea.
I tried to make a prediction about which way this would go, and I genuinely don't know -- not even that my prediction is uncertain, I don't feel like I know enough to even make a prediction at all.
It does make me nervous. I think it's important that the Supreme Court hear it, and I'm glad they agreed to, but it would be utterly disastrous if this got decided in Oracle's favor. My (perhaps incorrect) impression is that the Supreme Court is not particularly fond of the 9th, and have something of a history of slapping down attempts at copyright expansion. A ruling against Oracle would be fantastic, and would maybe even open the door for talking about blocking copyright on grounds of compatibility.
I guess I'm just nervous because it feels like the stakes are really high.
At this point, there's nothing really that people like me can do, right? It's just up to Oracle and Google's lawyers?
Yes, with regard to this case, there’s nothing we can do at this point.
In the longer term, it’s up to law makers on the state and federal level to address shortcomings and expansions of copyright law. So vote! (Or, I guess if you are particularly wealthy, lobby!)
I thought the 9th wasn't involved here, and that the appellate ruling originated from the federal circuit?
SCOTUS has not looked kindly on CAFC when it comes to patents, almost always overturning CAFC's decisions as being utter lunacy. I hope that same skepticism will transfer to copyright.
But that's mostly immaterial at the Supreme Court, as the Supreme Court isn't deciding based on whether the CAFC correctly applied 9th Circuit precedent.
Sorry but this is FUD you see going around. The most overturned court circuits are as follow.
6th Circuit - 87 percent; 11th Circuit - 85 percent; 9th Circuit - 79 percent; 3rd Circuit - 78 percent;
Furthermore the 9th Circuit does the most basis and almost all of their court cases are not taken up by the Supreme Court, that means less than 1% of Court Cases are overturned.
Source for numbers but other places have written about this.
https://www.politifact.com/punditfact/statements/2017/feb/10...
Although having just said that, the Blurred Lines, "these songs sound similar so that's good enough to say they're infringing" case didn't get overturned, and I think that's almost as dangerous a precedent as this. And a few other commenters are saying that it's actually more just patent-law expansion that the Supreme Court has been wary of.
So maybe it's entirely wishful thinking on my part.
I dunno. I just want someone to tell me it's all going to turn out OK :)
The supreme court (according to the same article) overturns 70% of all cases it takes. The 9th circuit (and 3/4) is within 10% of the average.
I agree, to me it is a bit annoying seeing asset flips like Wargroove being hailed as new innovative games. They took the units from Advance wars straight offs. AA gun -> Wizard (fast good against infantry and air but weak against armor), Light-Tank -> Knight (fast, good against most targets and armored), Medium Tank -> Giant (slow heavy unit), Recon -> Dogs (very good against infantry, see invisible units), AA missile launcher -> Ballista (ranged unit that only attacks air), Bomber -> Dragon (strong flyer that only attacks ground) etc.
I don't think that anyone making an original game would have made those choices, like why can dragons only attack ground targets? Makes sense for bombers, not for dragons. Why are wizards so fast and weak against armored targets? Usually it is the other way around. Why can ballista only attack air? Historically they were used against ground targets, etc etc. The only original unit in wargroove not straight up taken from Advance wars is the Amphibian.
I wonder how much faster they got their game made thanks to just stealing the entire combat system from Advance wars...
For instance, recipes, and tables of contents aren't copyrightable.
Going into case law, Sony v Bleem made it pretty clear that clean room reimplementations of APIs are on the table.
Going into US code, the otherwise crappy DMCA explicitly allows reverse engineering for interoperability. ie. interoperability even when the original vendor won't even tell you what the API is.
Going into practicalities, who owns SQL? Who owns POSIX?
The entire idea that APIs can have copyright is blatantly in contrast to decades of law, and is only happening because the CAFC is going off on it's own and ignoring 9th circuit precedent.
For those who would like more detail on this, the major case on this in the US is Feist Publications, Inc., v. Rural Telephone Service Co., 499 U.S. 340 (1991) [1].
This is not necessarily the case in other countries. See [2].
[1] https://en.wikipedia.org/wiki/Feist_Publications,_Inc.,_v._R....
Sony sued Bleem because of screenshots. The legality of compatible products such as emulators was not evaluated by the court.
https://scholar.google.com/scholar_case?case=118372240780525...
> The legality of the emulator is not at issue in this lawsuit.
> The issue in this appeal is the validity of the method by which Bleem is advertising its product.
> In various advertising media, Bleem has included comparative "screen shots" of Sony PlayStation games.
> We conclude that it is a fair use for Bleem to advertise comparatively only between what PlayStation games actually look like on a television and what they actually look like on a computer when played with the emulator.
The technical point of view needs to be combined with the legal one here, and —
> At the same time, Oracle’s characterization of their API as “original software” is not entirely off base, as anyone who has spent time and energy creating and API would know. The amount of design and work required to create an elegant and useful API is huge, and while it would irreparably harm software as a field to call it copyrightable, calling it anything other than an “original” work is a weak position.
just because something takes a lot of work, that doesn't automatically mean it is copyrightable.
An API doesn't implement anything, it describes a function. Even if it describes a lot of functions and they mesh together really well, there's a distinction between "what" a program does and "how" a program does something.
To compare with literature copyright, there are a ton of romance novels out there — pretty sure you can find a lot of common patterns on "what" story they tell. However, only the "how" is copyrighted, you can't prevent anyone from writing a story with the same outline as an existing one.
(For literature, the problem becomes really tricky since the crossing over from "what" to "how" is kinda fluid; e.g. you can't just swap out character names. Software is actually easier there.)
API is what defines a software. For instance, if someone copies Microsoft suite full public interface (including the UI which is part of the interface it would be a problem even if the implementation was different).
API signature is the UI equivalent for a library/programming interface software. So, I agree with the original commentors concerns here. Oracle's got a point too.
It isn't. "A main window with toolbars and an edit area." is the equivalent of the API signature. The layout, icons, ordering, etc. is artistic work of the "how" and copyrightable.
(FWIW by your logic, LibreOffice would be violating Microsoft's copyright already and we could only ever have one office suite in the world.)
The analogy with phone books is if someone else published a competing phone book, with the same positions for adverts and paid listings, and same distinctions between adverts and paid listings. The courts would find that such a phone book infringes as well.
To make the analogy more accurate, many consumers have since come to be used to the layout of the old phone book, and do not want to switch because they have to retrain their habits to use the competitor book. Competitor book argues that the old phone book layout has merged with the idea of a phone book, or that the old layout is essential to the use of a phone book. The circuit court disagrees.
It's much more similar to recipes. Recipes, like programs, are functional; they exist to produce useful output. Two different recipes calling for different ingredients/proportions can be used to bake similar cakes. However, the two cakes are fundamentally different, and copying the ingredients/proportions/steps of a recipe might be the only way to produce a cake quite as tasty as the one from the recipe.
Recipes themselves are not copyrightable because of the idea-expression divide. Authors can express the recipe using different words/formatting, and that expression is copyrightable. Likewise, an API, including the SSO, is merely an idea and so can't be copyrighted, while the implementation is the expression of that idea and so can be copyrighted.
I think if we take the phone book analogy to it's logic conclusion, it must be okay for Google to use the API only if they change it to make it sufficiently non-interoperable, which seems highly unintuitive.
According to the 9th Circuit opinion, for the purpose of whether an API is copyrightable, interoperability (with client programs) does not factor in. Interoperability comes into play on a case-by-case basis when considering whether or not the use of a copyrighted work is fair use.
So, to use the telephone book example, if machines have been built to interoperate with the old telephone book layout and cannot accept the new telephone book layout, the competitor may have a fair use case, but the competitor cannot argue that the layout of the original could not be copyrighted; at the time of designing the layout, there were many avenues to lay out the pages, but the holder chose a particular layout.
Intuitively, this differs from trademark law where use in a generic manner dilutes the trademark. With copyright, there was copyrightable creative expression in the API's SSO when it was designed, and because others have come to rely on the SSO aspects doesn't mean that the copyright of the API's SSO has become diluted.
> Recipes themselves are not copyrightable because of the idea-expression divide. Authors can express the recipe using different words/formatting, and that expression is copyrightable. Likewise, an API, including the SSO, is merely an idea and so can't be copyrighted, while the implementation is the expression of that idea and so can be copyrighted.
At the time when the API is created, there is creative expression as to what the API should look like.
At the time a recipe is created there is creative expression as to what ingredients will be in the recipe. Creativity/originality is a necessary but insufficient condition for copyright.
> According to the 9th Circuit opinion, for the purpose of whether an API is copyrightable, interoperability (with client programs) does not factor in.
I disagree with the 9th circuit here. To be clear, my argument is not that because copying is necessary for interoperability, APIs are not copyrightable. Rather, the argument is that because only one API (including SSO) fits any given purpose and because it is not functional in itself, the API is closer to an "idea", a "system", or a "method of operation" rather than a "literary work" under the Copyright Act section 102. A data structure with enqueue, dequeue, and size operations is an idea, not a concrete expression of that idea.
Plus I believe if the Supreme Court upsets 50 years of practice in the industry, they are essentially legislating.
> At the time a recipe is created there is creative expression as to what ingredients will be in the recipe. Creativity/originality is a necessary but insufficient condition for copyright.
To use the recipe analogy, just as the functionality the API necessarily must provide are uncopyrightable, so a list of ingredients is uncopyrightable.
But once someone organizes their ingredients list; e.g. according to the first time they must be used in the recipe, that organization is copyrightable just as the hierachical organization (SSO) of Java's standard library is copyrightable.
> Rather, the argument is that because only one API (including SSO) fits any given purpose and because it is not functional in itself, the API is closer to an "idea", a "system", or a "method of operation" rather than a "literary work" under the Copyright Act section 102.
The Fed Cir. cites case law suggesting that the 9th, 10th, and 3rd, among others, found that just because something is a "method of operation" does not mean that they are uncopyrightable.
> A data structure with enqueue, dequeue, and size operations is an idea, not a concrete expression of that idea.
For a data structure with enqueue, dequeue, and size, there aren't really enough creative choices choices that can be made. The Java API is different; e.g. as the CAFC points out, their API for dates and timezones are organized very differently from iOS's, and there is sufficient creative choice there.
> Plus I believe if the Supreme Court upsets 50 years of practice in the industry, they are essentially legislating.
With regard to the effect on the software industry, it may be less than you think. For general cases a competitor may be able to provide a competitor2us.sh to convert uses of a competitor API to a functionally equivalent API.
====
For reference these are the Fed Cir opinions
deciding copyrightability: https://scholar.google.com/scholar_case?case=151970920513696...
deciding fair use: https://scholar.google.com/scholar_case?case=107451649356761...
Unfortunately, that is also a definition for the whole of programming: describing functions. In Java, the method signature gives only a very incomplete definition, but that is a factor of the programming language itself.
For example, you might wish to imagine a hypothetical language that has a type system so refined that the behaviour of any function is completely described by its type (1). In such a case there would be no difference between its description and its implementation.
(1) We'll leave aside the question of whether this is strictly possible. It would be possible to have more powerful type systems than Java's, and program designs that use such small and clear function definitions, that if you have the type signatures then filling in the code for them is more straightforward than designing the function definitions was in the first place.
Also when the commenter said "wrote the API", he was referring to the Oracle/Sun Java API, not the Google Android API.
This is not merely a technical benefit, it's a practical one and represents the status quo. The fact that there's no precedent isn't because it's new, it's because no one ever thought it was infringing before.
I really do think the determination for this case ought to be if you copy an API to facilitate interaction with existing software then you should be in the clear. If you do the same because it’s easier than coming up with your own then I think it should be infringement.
APIs are facts, and facts are not copyrightable. How is an API a fact? You have a system, in the real world. It is a "thing". There are facts about this thing: if you send it particular bytes, it does X, if you send other bytes, it does Y. The fact that it does this is empirically derived. There are not two or more options for it, it's like gravity or electromagnetism. APIs are facts about the systems they apply to, so while there is creativity in designing them, there is no creativity in building a system that interacts with them. There is exactly one way derived from the empirical fact of how it works.
Where the case IS weak is that there IS creativity in how you document and organise the API. And I'm pretty sure Google's re-implementation was very similarly organised to the real Java. That will be the crack Oracle will be trying to exploit here. But its not actually about the original work being "original" or even "creative".
Facts are not copyrightable no matter how much time/energy/cost went into compiling them, and this is clearly established law.
Google's case is that an API specification or implementation is more like a set of facts. Which as a software engineer, seems pretty plausible to me, they do seem like a set of facts, a description of fact about how software works. On the other hand, unlike facts, they were not purely observed, but were indeed invented by humans -- but recipes aren't copyrightable either, even though they are not observed but invented too. Neither are the rules of a game. These are all considered more like 'facts' than creative works. Doesn't matter if eg you spent years and millions of dollars researching food chemistry to make your recipe.
I don't think its entirely clear who will win, but I don't think Google's case is as weak as you think, although i agree that Oracle's contention isn't entirely off base. . In particular, in general, how much time and energy went into making something is not generally one of the most significant factors in determining copyright or fair use. (Additionally, the well-established law around reverse engineering and creating clones -- that it is allowed -- is in Google's favor, as that analogy seems pretty strong too). Copyright law is -- has always been, or at least for 100 years -- about a bunch of competing factors balanced against each other.
And when it comes to technology advances, has always relied on analogies to previous technologies and industries, and who has the most persuasive analogy. And then we have the fact that the people deciding what analogy applies best may not entirely understand the technology as a social fact...
I agree that designing good APIs requires a great deal of work, but Sun/Oracle were not alone in doing this work. In fact, they had considerable help from community, competitors and customers.
Java APIs are to a great degree a collaborative effort and it isn't right that Oracle should be the sole benefactor of this uncompensated work that has only made their product more valuable.
If this is true for these particular APIs isn't very relevant in my view. What is relevant is that the Java platform as a whole has gained much from its community. Without the Java platform the APIs would hardly have any relevance at all.
If you are asking for my opinion: extorting those who use your API is always a poor long term business decision because it proves ill faith and undermines trust.
Oracle already has a problem with corporations making a conscious effort to move away from their database platforms.
We can adapt our license to allow anyone to use the API except if they're using API licensing themselves, at which point they would be in violation.
Oracle's "original software" is not. It is derivative of other work, for example, Smalltalk and its libraries. The idea of including explicit interface declarations with each module was, I think, introduced by the programming language SUE designed by Rick Holt.
Copyright does not protect ideas; copyright can only protect the expression. And when the two are intrinsically combined, there cannot be copyright.
Fair use doctrine was obviously never intended to apply to reimplementing API's either way because it didn't exist yet.
Rather than have a court make up some kind of ultimately arbitrary precedent ruling either way, Congress should be debating the ramifications of whether reimplementing API's is explicitly fair use or not, considering both pros and cons to the economy, with opportunity for all tech companies to weigh in -- and then pass a good law.
Courts interpret law, they aren't supposed to make it, and the Supreme Court certainly isn't even remotely qualified to determine what's the best policy for a healthy dynamic tech economy here. The law is so ambiguous here that Congress is shirking its duties by not establishing relevant law here.
In times like these where Congress is often deadlocked, someone needs to make decisions. Congress can pass a new law if they can get their act together.
Google now has 45 days to file a brief on the merits that explains their position.
Once that is filed, Oracle has 30 days to file a brief on the merits that explains their position.
Google then has 30 more days to file a reply to Oracle's brief. That brings us to the 28th of February, assuming everyone uses all their time (and no more).
The court can extend all those deadlines.
Once all the briefs have been filed the case will (probably) be scheduled for oral argument. It looks like oral argument is usually scheduled several months out, and the last day for oral argument this term is April 29. It might meet that deadline, otherwise it will be pushed to next October. If the oral argument is heard this term then we can expect a ruling by the time the court goes into recess for the year (end of june).
Of course a ruling doesn't mean the case is over, it may well then return to lower courts for more argument. (It almost certainly will for various details, like attorney's fees and/or damages).
This case started August 13, 2010. It's been almost a decade. Something is very wrong with how our court system functions.
Meanwhile, the system can be surprisingly agile if it needs to be. New York Times Co. v. United states only took 12 days from the first hearing to the Supreme Court ruling! Of course that was because Nixon wanted to rush the case, but in the end he lost hard and the heat of public opinion probably didn't help, either. In the case of Google v. Oracle, nobody seems to be particularly in a hurry. Both sides can afford to drag out the dispute as long as they want to.
To be honest I mostly included that line out of frustration with a Canadian Supreme Court ruling today, that said having a juvenile trial go on for 18 months can be "sufficiently speedy". Which is definitely off topic here, but still one I consider important.
https://www.cbc.ca/news/politics/supreme-court-youth-justice...
But as I said, this is a double-edged sword. People need time to collect evidence and arrange witness testimonies, so insisting on a quick resolution could create bias in favor of those who can pay for a lot of lawyer-hours up front.
For civil cases between large companies, this speed doesn't seem entirely terrible. Criminal cases and civil cases between individuals are another story.
I don’t understand court systems but man I would love to have some sort of SLA.
Creating an API is of course a creative process. Getting the API right is, for me, the most creative part of programming. When well written, it describes to a human how the software truly works, with the implementation really being the computer version of what the function name is already telling you. A browser rendering engineer could be defined just as much by the model that the DOM API describes as it is defined by the actual source code. They both describe the outside and inside of the same thing, a system which, when it’s interface is shared, is shared between us all and not just under the sole ownership of the first person to describe it.
It’s hard to see an API therefore, particularly a published one, as a traditional piece of intellectual property that can be subject to copyright. One cannot copyright F=ma or e=mc^2. Once these object models about software are discovered they are like descriptions of the natural world and their formulae are open and shared for all to use.
Yes: how you build your specific machine that makes use of and conforms to the API — the actual source code for function implementations — can be your intellectual property, but the underlying description of the natural world and its API are discoveries that are part of the commons, for all to interact with, use, and re-use.
The only difference between natural laws, in my analogy to physics, and software APIs is that there is only one physical world with a limited set of natural laws that describe it. With software engineering we create our own new universes everyday, but they are common universes for us all to share.
Serious question: which part of Oracle buying Java from Sun was innovative?
Oracle’s upcoming design of continuations I think is genuinely novel and will inspire a lot of other languages’ implementations.
And I'm cautiously optimistic. The Supreme Court has shown itself to be far more sane on IP than the Federal Circuit.
This is in direct contrast to decades of consensus that APIs are not copyrightable, and furthermore, there is a particular procedure to go through [clean room technique, which Google did] to ensure that the API is reimplemented without infringing any copyright.
Letting this ruling stand would mean that nearly every piece of software you use infringed someone's copyright.
*corrected from "second district court"
More: Recall that copyright lasts close to forever. (95 years for corporations, if I recall correctly.) This ruling, then, would have allowed IBM to sue every BIOS clone maker, and keep a stranglehold on the PC market, and still have that stranglehold to this day, and be able to keep it until 2076. Then, on August 2, 2076, then we could get IBM-compatible PCs.
Compare that to actual history, and you can see why I think the current ruling is horrible.
Congress passed in 1982 a statue called the Federal Courts Improvement Act, where instead of having a random judge make decision, you now instead have selected judges specialized in IP. Those specialized judges comes from lawyers who have worked for companies protection their IP, and thus a bias in favor of IP in the court of appeal. When the case goes to the supreme court this bias goes away.
No.
Instead of the geographic Circuit Courts of Appeal hearing patent cases, any first appeal of a case with any patent claims involved goes to court specialized in Patent cases.
Other IP (copyright, trademark, trade secrets, right of publicity) cases are not affected and have appeals go through the regular geographic circuits, so substituting “IP” for “patent” is incorrect.
(Oracle v. Google is a copyright case, so why is CAFC and not the 9th Circuit involved? Because there were also patent claims in the case, so even after they were dead the Federal Circuit “owned” the appeal.)
As an example, the Z80 and the 8080 were interoperable and it was better for everyone.
The Constitution only says
> 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.
most of copyright is defined in statute (the various copyright acts) and court precedent.
Most stuff in the Constitution gives the government the power to do X (sometimes stating explicitly that it's for reason Y). The structure of the copyright clause is that Congress has the power to do Y, using mechanism X — a strict reading of that means that the government cannot do X for reasons other than Y, and cannot pursue Y using means other than X, and definitely shouldn't do X for reasons of not-Y.
Every programming language has stolen large portions of their API from other languages. Even Java.
Remind me: Did Microsoft file an amicus brief in this case? If so, on which side?
https://www.supremecourt.gov/DocketPDF/18/18-956/89566/20190...
Competitors can still publish a functionally identical but differently organized API, then provide a competitor2us.sh script to statically change references to their own API. Sure, the friction is higher, but not unreasonable.
Not wanting to pay licensing fees, and therefore writing your own interoperable clean room reimplementation is both legal and moral.
For a programmer, the weight of the evidence against copyright for APIs is conclusive as presented in the briefing. Unfortunately, there are no programmers on the Supreme Court; while Judge Alsop did learn Java Programming so he could understand the issues,the Circuit Judges who reviewed Alsop's decision were not so dedicated.
Software has a real and tangible value. Songs ... well, you decide their value, but I don't understand why the value songs create should be protectable, but software not.
That's really what this is about. This is about granting to those who write software the same rights to that property as anyone else who has rights to what they write.
Ask yourself, "Why did they copy the Java API? Why didn't they use Python or Go or Dart?" They invented Dart after all.
Private entities create things of value and share them with an incentive to recover their investment, and then some.
If it's possible for anyone, including private entities like Google, to CTRL-A, CTRL-C, CTRL-V it into their own use, then there is negative incentive to create that kind of value for the world.
In 3 words or less, compare and contrast this to the Google-Oracle copyright fiasco...
I mean, API-copyright plumbing wouldn't be my first choice of work, but might make for a decent part time remote job while I spent most of my energy on something else that is actually useful.
No more openjdk, etc.
The SC has already denied to hear on whether APIs' SSOs are copyrightable, suggesting that it agrees with the Fed. Cir. opinion that they are.
This hearing is about Google's Fair Use defense.... and I don't expect Google to win on fair use unless the SC intends to really break new ground on fair use analyses.
This isn't always a problem. When Compaq did the same thing to create the first IBM compatible PC's, they did so very carefully, ensuring there was no one working on the team with prior knowledge.
I don't believe Google did the same thing and that's where my problem is. If they can look through Oracle's code, and just re-write it slightly to do the same thing to avoid commercial licensing, that doesn't help Open Source, it hurts it.
If creators of property cannot protect their property, there will be less return on that property and thus, less incentive to create it.
Oracle bought Sun, and with that purchase, the ownership of intellectual property in the form of the Java API. Google then proceeded to copy that property into their own property without abiding by the usage restrictions Oracle, the property owner, specified. That was theft of Oracle's property.
If the Supreme Court does not uphold protections of property, I believe, we will see less investment in such property.
I am not sure if that is good or bad for the future of the world, but I do believe had Sun not had property rights to Java, they wouldn't have created it.
Owning a property doesn’t give you the right to sue other people who develop a property that offers the same services.
If I write a book and you read it, love it, and then retype the book, print it and sell it, you have violated my property rights.
You and many others here don't want it to be that way, but it is exactly that way.
Bad analogies are inevitable, and aren't the commenter's fault. It's the Federal Circuit's fault, for trying to blur the lines between functional matters (the domain of patents) and copyright matters. Any analogy that's simple enough to quickly understand will suffer from basically this same flaw, or else not apply to this case.
Ultimately, the problem for Oracle is that the APIs are too functional to be eligible for copyright protection, too abstract to be eligible for patent protection, and too generic to be eligible for trademark protection. But that doesn't stop them from trying to get the best features from all the above.
One is an accurate analogy, the other is a false analogy.
"Jack and Jill ran down the hill."
into
"Gil and Jacky descended the mound."
It's exactly the same story just with different implementations that exhibit the same behavior. They didn't make something compatible with Java -- they replaced Java with something exactly like Java.
It's even worse than the example above, because they kept the same names of the classes, interfaces, etc.
What is protection supposed to mean there? Happy to expand my definition of that word if I am interpreting it too narrowly.
To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries;
https://constitutioncenter.org/interactive-constitution/arti...
Sun invented Java. Oracle bought Sun. Oracle owned Java. Google copied Java without compensating Oracle, who owned the rights to Java.
It's pretty clear. The Supreme Court should confirm that Google owes Oracle compensation for the use of Oracle's intellectual property.
More importantly, how is any part of the government obligated to extend IP rights to be as powerful as you want to treat them? Congress was granted the power to create copyright law, but they chose to do so with more limitations than just duration.
The industry wouldn't have to grind to a halt if it had been respecting those rights from the beginning.
If companies want to provide their code, API's, or any other intellectual property to the world at large, a la public domain, they are free to do that. No one is stopping them.
But if someone in the software industry wants to protect their IP, they should have those rights, just like any other inventor/writer in any other industry.
Those "property laws" you allude to don't cover software. Software is covered by separate laws that are designed to function similarly in many ways, but the differences are real.
> The industry wouldn't have to grind to a halt if it had been respecting those rights from the beginning.
There's no legal precedent establishing the existence of those rights, and quite a bit to the contrary.
> But if someone in the software industry wants to protect their IP, they should have those rights, just like any other inventor/writer in any other industry.
No. Copyright doesn't apply to every kind of idea or writing. This has been explained elsewhere in this thread, and in most previous discussions about this case.
Software is copyrightable: https://www.nolo.com/legal-encyclopedia/how-register-copyrig...
The precedents establishing those rights are long, they go back decades. You really don't have the facts.
I didn't say these rights extend to every kind of idea or writing. I said software writers and inventors should have the same rights as writers and inventors in any other industry.
Really, I ask this in all seriousness, why shouldn't software writers have rights over what they write? Why are words in software different than those in books or movies? Why shouldn't inventors of software have the same rights as inventors of mechanical devices?
So, I ask you, why shouldn't inventors of software have the same rights as inventors of mechanical devices?
> Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.
Knowingly glossing over important distinctions is not appropriate.
That is illegal. Google intentionally committed that illegal act due to the financial incentive. Sun explicitly told Google they cannot do that. Google did it anyway. Now, Google should have to make amends.
That is exactly what I am saying. It is exactly what I have been saying. You are saying I'm saying something else or saying what I have said isn't the case, but provided no evidence to support that.
I have repeatedly provided evidence that what I am saying is true. You have provided no evidence to support your case.
I'm not glossing over any distinctions. You are saying there are distinctions, but you are not saying what those distinctions are. You are saying there is common law property and other kinds of property and that is relevant, but I am saying, the laws governing the kind of property Google appropriated for their own financial gain is exactly the kind of property that is governed by the laws I have stated, specifically copyright law and patent law.
For some reason, you are claiming those laws don't apply or something like that. I'm not sure why you believe that, but the court precedents have already been set to indicate that they do.
Clearly, the courts are debating this already because someone agrees with you and someone agrees with me.
What I do know, is that Google has flagrantly broken copyright law to their own ends since their inception. They have copied books. They have copied newspapers. They have copied people's private healthcare information.
Google does not respect people's rights to their property and intellectual property is property, regardless of what you are saying about common law property. Yes, I agree that "intellectual property" under the law is distinct from "real property" under the law in the form of land or real estate, however, I am not claiming Google broke those laws. I am claiming Google broke Intellectual Property Laws and they have done that -- very clearly -- many, many times.
I hope the Supreme Court, once and for all, puts Google in their place and says, "No, Google, You do not have the right to break the law simply because you want to."
You have the order backward. Google made Android with the full consent from Sun. Their CEOs had a handshake deal, and neither of them believed there was any need for a legal contact.
Fourish years later Oracle bought Sun and promptly sued Google. The handshake deal wasn't legally binding, apparently.
I know this doesn't necessarily change the legal picture, but it certainly changes the ethical one. Your timeline makes Google out to be a predator, maliciously stealing Oracle's precious IP. The actual timeline makes Oracle out to be the predator, buying Sun for little other purpose than to sue people.
I suspect Google wouldn't have gone with Java if it were owned by Oracle at the time. Which would have made for an interesting alternate timeline. Maybe they'd have gone with D? Who knows. C++03 was kind of ass, but if they'd have gone with c++ we'd have new c++ as a first class citizen which would also be rad.
> Android, Inc. was founded in 2003 by Andy Rubin, Rich Miner, Nick Sears, and Chris White to develop a mobile phone platform.[7][8] Google purchased Android in 2005 and continued developing the Android operating system.[8] During development of Android, Google wanted to incorporate the Java Standard Edition libraries. Google's executive chairman Eric Schmidt had approached Sun's president Jonathan I. Schwartz about licensing the Java libraries for use in Android. Sun offered a licensing deal of between US$30 and 50 million. Schmidt said Google would have paid for that license, but they were concerned that Sun had also requested some shared control of Android along with the fee.[9][10][11] Google states that they wanted more control in order to open source the language and allow third parties to take better advantage of its code;[9] Oracle states that Sun refused because Google's intention was essentially to fork Java to a Google version of the language, and to prevent it being inter-operable with other versions, an idea which was "anathema" to the "write once run anywhere" basis of the language.[12] Because of these differences of view, the negotiations failed to reach a deal and Sun refused Google a license for Java.[12]
> At this point in time, the OpenJDK implementation offered by Sun was not as mature or complete as the Java Standard Edition.[13] Instead of licensing Java, Google chose to develop a cleanroom version of the Java Standard Edition libraries
The wiki article is leaving out a suspicious amount of facts in the case.