Yeah, but Google copied only "declaration code" (i.e. the class structure of Java to make it compatible). There are a few other lines, yes, but those came about due to being utterly trivial code that looks more like two people choosing the same trivial implementation randomly from what I recall.
Also, regardless of intent, this would have the effect of making APIs copyrightable. That would be terrible for compatibility and would destroy the viability of a lot of work for no good reason at all, unleashing a lot of copyright parasites to go around suing for trivial nonsense.
I'm sorry, but this is basically a phone book that can be used by machines of where to find the code that does X. It shouldn't be copyrightable any more than the actual phone book and the structure was copied only to make it compatible.
It'd be like suing everyone for making similar electrical plugs, ignoring how they have to meet certain requirements to actually fit in the socket.
I was wondering about physical equivalents. Does anyone know if the Torx system was copyrighted/patented? Not a trademark on the name Torx, a real protection on that design of screw head/driver
> Many companies do patents as means to protect their IP when copyright isn't enough.
It's hard to believe that 95 years of protection after publication (or 120 after creation) "isn't enough" for corporations, but I'm sure they'll find longer terms in one country and then push the others to "harmonize" on the new value at some point or what have you.
Walt might lose his incentive to create new works if the Mouse's copyright is allowed to expire on January 1, 2024.
Copyright and patents apply to different works. In the case of software in the US, patents apply to algorithms or protocols (more precisely, to their implementations on computers) while copyright covers code.
Source code, which is what we're discussing here in Oracle vs. Google, may be covered by both, despite some Supreme Court rulings that tried to limit what may be claimed to at least avoid simple recitations of a standard computer.
Of course, my view is that the real problem is that 101 can be met piecemeal. The novel part doesn't have to be patentable subject matter and the patentable subject matter doesn't have to be novel. So one would just recite claims of allegedly novel software running on an non-novel, but otherwise patentable computer. If novelty had to reside in the part of the claims that was patentable subject matter, I think a lot of the nonsense would have vanished, though I might well underestimate their cleverness in finding new and strange ways to disappoint us.
You're using the legal term, I'm using the ordinary definition of the word. In other words, you can't use the code without a patent license, just as you can't use the copyrighted work without permission.
> this would have the effect of making APIs copyrightable
No, only if there has been some copying of substantial portions of copyrighted works. Talking about analogies is irrelevant if you're unfamiliar with the legal framework that determines the suitability of the analogies. For example, one could claim that copyrighting code is "just like" copyrighting algorithms, yet it is established that code is copyrighted (but not patentable) and algorithms are not copyrightable (but are patentable), and the legal system is perfectly fine with that. Why? Because there are important distinctions here, and the question is not whether things are "the same" in the eyes of developers, but whether they're the same in the eyes of IP law. If you don't understand the legal distinction between code and algorithm, then you're missing the most essential background material.
As to the rest of your arguments, the relevant ones are the subject of this case. I suggest you read the actual arguments; they're quite interesting.
> No, only if there has been some copying of substantial portions of copyrighted works.
The only 'substantial portions' at stake in this lawsuit are the API declaration itself, which merely tells the system where to find the right code and does not implement any logic.
It is absolutely required to copy that and other APIs in order to be compatible, which is why I'm really worried about a lot of judges who have minimal, if any, understanding of the ramifications of this deciding it.
Alsup actually understood the issues, but he got overruled by clueless judges.
> which merely tells the system where to find the right code and does not implement any logic.
This is not true (declarations in Java are evaluated at runtime and compiled to real machine instructions -- i.e. they perform very real logic; also, what algorithm or logic does the following "implementation" Java code describe `return a + b;` ?), but even if it were, I don't see the relevance to copyright. Maybe there are other arguments for excluding such code from copyright, but I am not aware of exclusions for "code that doesn't implement any logic". That's just not the law.
> It is absolutely required to copy that and other APIs in order to be compatible
That is a fair use question, and it is certainly possible that copyrighted code can be copied for compatibility as a fair use. But this case is about Android, and Android is not and was never intended to be compatible. Google admitted that in court, and said that their goal wasn't compatibility but reaching a large pool of developers who would be familiar with the general structure. I don't know if "familiarity" is a fair-use defense, but that is another question before the court.
> This is not true (declarations in Java are evaluated at runtime and compiled to real machine instructions
Yeah, so what? That's just the system putting the right values in the right place. Also, it obscures the fact that this resulting JVM bytecode could, in fact, be very different for Google & Oracle's implementation, though some parts of it will likely be similar just because programmers choose the simplest/most efficient ways to do things and those are necessarily similar.
> what algorithm or logic does the following "implementation" Java code describe `return a + b;` ?)
Addition, normally, though operators can be overridden so it might be string concatenation or whatnot depending on the types.
> That is a fair use question, and it is certainly possible that copyrighted code can be copied for compatibility as a fair use.
More to the point, Google won as to fair use before the jury before a judge overturned their verdict...
Anyhow, yes, changing all the names means that you have to do trivial and stupid rewrites of lots of code to replace names. Whether someone named something to return the maximum of several elements max() or maximum() or what have you is not the sort of 'creativity' that Congress ever had in mind to protect.
Copyright was designed in an age when written works were creative rather than functional and several of the doctrines need to be adapted to make any sort of reasonable purpose out of this.
The fact is that making APIs copyrightable would cause a lot of legal destruction--senseless lawsuits that enrich only lawyers and impoverish the public--while destroying a lot of innovation and open source that the public already has for the sole benefit of IP law firms.
It shouldn't be surprising that only those who hope to profit by trolling the people who actually make useful stuff are excited by this.
> That's just the system putting the right values in the right place.
Not in Java, but again, it's irrelevant for the question of copyright.
> Addition, normally, though operators can be overridden
This line could be one of three or more different algorithms in Java. Both it and the declaring code together define the operation. But this, too, is hardly relevant.
> Also, it obscures the fact that this resulting JVM bytecode could, in fact, be very different for Google & Oracle's implementation
This has nothing to do with copyright. The law doesn't say that as long as you don't copy everything it's OK to copy anything. It does, however, take into consideration the amount of material copied when it comes to fair use. For example, it's possible that it's OK to copy a small, simple API, or that it's even OK to copy a large API for the sake of compatibility, as neither of these is the case being discussed here, and the size of the copied code, and the fact that it's not compatible are crucial elements of the case, and a focus of the court.
> Whether someone named something to return the maximum of several elements max() or maximum() or what have you is not the sort of 'creativity' that Congress ever had in mind to protect.
True, and if you'd read the court documents you'll know that this is not at all the case here. The corresponding code in the, say, Swift or C# standard libraries is drastically different, yet it was this particular very large chunk of code that's been copied; not from C#, not from Swift. They copied hundreds of pages of unique code.
> The fact is that making APIs copyrightable would cause a lot of legal destruction
Maybe, but that this is about "copyrighting APIs" is just some an opinion and one possible interpretation of the case. Would punishing a company for copying hundreds of pages of code, for commercial gain, and not for compatibility cause a lot of legal destruction? Are you familiar with many other cases of people doing that?
Prove this? Also prove how it compares between Google and Oracle's JVMs. I believe it's just setting up the stack and registers with the right values, one of which should be whatever the JVM's equivalent of the stack pointer is (e.g. finding the right code to run).
> This has nothing to do with copyright.
Perhaps, but only because the law is ignorant of it. It's not really much of a "copy" if it's a purely functional description that gets translated into very different software doing different things. That goes to my point that it's an interface for compatibility, not something copied because it was desirable in its own right.
> True, and if you'd read the court documents
Please don't give me that, when I've been reading docs since this first came out, enough to remember these old filings on a long-defunct site:
That was later overruled by a judge, yes, but there has been no jury finding other than fair use. When you go down into the weeds of this, there just isn't any real creativity there that's being protected by this and a broad precedent that "APIs are copyrightable" would be a terrible thing for all people who use computers, except only for a few lawyers to get rich off of suing.
> Maybe, but that this is about "copyrighting APIs" is just some people's opinion, and is just one possible interpretation of the case. Would punishing a company for copying hundreds of pages of code, for commercial gain, and not for compatibility cause "a lot of legal destruction"?
In this case, on this set of facts, yes. Oracle's plan was always to buy Sun and make Google (and everyone else) pay for it. It's just how they are, they love suing/auditing even their own customers, it's part of their sales pipeline or something.
The above is merely your opinion and not one that seems to be widely shared. I know I certainly do not. Can you point to a more detailed line-by-line discussion of the allegedly copied code than Groklaw had?
All code is "functional" and yet creative and copyrighted. While the function of a quicksort routine — namely the quick sort algorithm — cannot be copyrighted (although it could be patented), any specific implementation of it in code is copyrighted, just as a news event isn’t copyrighted, but each and every written report of it is. That this particular expression is creative is also obvious from the fact that while the Swift standard library performs similar functions, its expression is completely different (and saying that the thousands of choices that went into the design, took years, and are unique among other runtime libraries are "trivial" is just factually false). That the function of declaring code is required for compatibility, and therefore copying it might be fair-use, in this particular case, Google did not create a compatible implementation nor intended to (although maybe they could have other valid arguments for fair use).
The problem with the interpretation of "copyrighting APIs" is that there can be many different kinds of interfaces. Some of them are code, some are algorithms, and some are physical. This case is not about copyrighting the concept of an interface, but of the copyright of about 11KLOC. Analogies that do not involve the copying of hundreds of pages of a copyrighted work are irrelevant.
I am not saying that we should or should not exempt declaring code from the copyright of the work it is part of; I am also not saying that fair-use should or should not apply to Google's copying. I am saying that the statement that this case is about "copyrighting APIs" in general is biased, because the case here is peculiar and extreme. I cannot think of any other similar case in the history of software, and the number of cases that are somewhat similar can probably be counted on one hand (we've certainly never seen copying of this magnitude).
For more details and discussion of this actual case (rather than a general issue which may or may not be pertinent), see former Sun executive Scott McNealy's amicus brief: https://www.supremecourt.gov/DocketPDF/18/18-956/133505/2020... It is of particular interests because it actually talks about the specifics.
This is how he starts:
> This case is about Google’s unlicensed copying of approximately 11,000 lines of Java SE code written and copyrighted by Sun/Oracle
and then goes in more detail into what was copied, the creativity involved, the common understanding in the industry that at the very least these particular APIs (regardless of others) were protected etc.
So before people start hypothesizing whether and how this case could generalize, I think they better understand the specifics.
> Prove this?
In Java, declaring code specifies complex class resolution, loading and initialization algorithms.
> All code is "functional" and yet creative and copyrighted.
People used to say that about logos too, but Sega v. Accolade put a stop to a particular misuse of copyright in a way that I believe is similar to what Oracle is trying to achieve here.
As for whether the copy was meant to be "compatible" we both know that's a huge can of worms, it was meant to make source usable with minimal porting effort (i.e. on the level of the old "write once, run everywhere" Sun once touted Java via) rather than meet the particular Java compatibility test scheme that existed.
Also, there are always going to be compatibility bugs between versions, but I don't see that as having any bearing on this being a fair use and neither did either jury who found fair use...
> This case is not about copyrighting the concept of an interface, but of the copyright of about 11KLOC
The bulk of which is merely an interface.
> I am saying that the statement that this case is about "copyrighting APIs" in general is biased, because the case here is peculiar and extreme.
It is peculiar, but I strongly feel that it would go in the wrong direction. I believe the original ruling in Alsup's court was correct, if somewhat novel.
> In Java, declaring code specifies complex class resolution, loading and initialization algorithms.
That's not what I'm asking to prove and that, again, is just a matter of finding the right code and putting the right values in place (i.e. an interface).
Java doesn't give a damn what's implemented in the JAR file's classes, it just knows that it was asked to find the code there with a specific class name and pass it specific values that were named. The actual bytecode is nothing alike, so the "copying" is just to let compilers find the right code to link up, trying to make good on Sun's old write once, run everywhere promise.
So it's just an interface to find the right code and feed it values.
I don't understand what any of what you said has to do with established copyright law, and are you saying that IFTTT or Zapier are not copyrighted because they're "merely an interface" (what Java does for declaration code is as complex as what they do)? What about Haskell's mtl or lens that do even less? They seem to think they're copyrighted: https://github.com/ekmett/lens/blob/master/LICENSE
Oracle sued over the act of copying of 11K lines of extremely creative code for commercial purposes and not for compatibility. Nothing of this kind and magnitude has happened in the software industry. Any claim that this is about "copyrighting APIs" in general or changing anything about copyright and fair-use are biased interpretations.
Also, regardless of intent, this would have the effect of making APIs copyrightable. That would be terrible for compatibility and would destroy the viability of a lot of work for no good reason at all, unleashing a lot of copyright parasites to go around suing for trivial nonsense.
I'm sorry, but this is basically a phone book that can be used by machines of where to find the code that does X. It shouldn't be copyrightable any more than the actual phone book and the structure was copied only to make it compatible.
It'd be like suing everyone for making similar electrical plugs, ignoring how they have to meet certain requirements to actually fit in the socket.