Oracle's history highlights a possible downside to its stance on API copyrights
arstechnica.com
arstechnica.com
I believe that's a fair price to pay for breaking the software industry.
There is a theoretical legal question of whether APIs should be copyrightable, and then there are the practical issues.
As a purely legal matter, there is a strong (but not slam-dunk) case that an API is copyrightable. As a practical matter however, everyone in the software industry has been operating as if APIs were free to copy for decades, and enforcing such a copyright would break a ton of things.
Practical effects of a legal ruling are generally not "officially" considered by the judge, but more-often-than-not, they're operating behind the scenes and judges craft their opinions to support an established status-quo.
I believe the Z80 was a copy of the 8080 architecture - it used the same binary opcodes but it used an assembly language with different words.
So an API is at source level, so it uses words which seem more aligned with copyright of text. I wonder what would happen if the api had the text "oracle" in the function names?
p.s. and amusingly when intel did the 8086, it was source level compatible with the 8080, but not binary.
https://en.wikipedia.org/wiki/Sega_v._Accolade
> As a result of the piracy and unlicensed development issues, Sega incorporated a technical protection mechanism into a new edition of the Genesis released in 1990, referred to as the Genesis III. This new variation of the Genesis included code known as the Trademark Security System (TMSS), which, when a game cartridge was inserted into the console, would check for the presence of the string "SEGA" at a particular point in the memory contained in the cartridge. If and only if the string was present, the console would run the game, and would briefly display the message: "PRODUCED BY OR UNDER LICENSE FROM SEGA ENTERPRISES LTD." This system had a twofold effect: it added extra protection against unlicensed developers and software piracy, and it forced the Sega trademark to display when the game was powered up, making a lawsuit for trademark infringement possible if unlicensed software were to be developed.
[...]
> The Ninth Circuit reversed the district court's order and ruled that Accolade's use of reverse engineering to publish Genesis titles was protected under fair use, and that its alleged violation of Sega trademarks was the fault of Sega. The case is frequently cited in matters involving reverse engineering and fair use under copyright law.
Maybe he mentioned that in his .plan file that you had to use finger to access.
Edit: Sort of correct. A bunch of details here: http://www.gamers.org/dEngine/license/quakeedit.html
In this case perhaps a gameboy cartridge could differentiate the sequence of reads for nintendo bitmap detection (which could be argued as API) and reads for the actual boot display and present different data... that's assuming they are separate reads, if the gameboy handles boot display all by itself and checks in the same step then i guess it's indefeatable.
https://dhole.github.io/post/gameboy_custom_logo/
Of course, you still have to include a copy of the Nintendo logo to get past the BIOS check, even if it's not displayed, which I think is supposed to be the trademark infringement.
> Of course, you still have to include a copy of the Nintendo logo to get past the BIOS check, even if it's not displayed, which I think is supposed to be the trademark infringement.
Yeah i think this is the bit that a brave publisher could have argued in court, I think for it to be a trademark violation it would have to be visible somewhere beyond the raw content of the ROM. That's why i'd argue it's essentially being used as an API token, and trademark definitely doesn't cover that.
Written by someone who worked on MSN Messenger. Talks about repeatedly reverse-engineering the AOL messenger protocol, and AOL's attempts to stop them.
Wouldn't affect copyright law too much, but Oracle could probably raise a trademark infringement claim too.
Yup. However, I suspect that Ubuntu gives a pretty permissive trademark license in their distribution.
This isn't a theoretical argument, the Android OS is open source, but the "Android" brand is a protected trademark. If you're a cell phone manufacturer, you can use the Android code freely, but if you want to put an Android sticker on your phone, you have to follow Google's rules.
Java was different because Sun was actively trying to prevent the "SQL" or "UNIX" semi-compatible fork scenario. IANAL, but bad analogy.
Sure, Sun sold Java (and the farm) to Oracle, but what if IBM sold SQL to Google? Do the same takesie-backsies apply?
Sun and Google had negotiations about licensing Java, and they certainly did not end with shaking hands.
Old post, so just saying this guy is factual-free.
And hopefully leave a radioactive crater large enough to dissuade anyone from ever trying this one again.
We did that. That's why they bought and tried to kill MySQL.
Amazon had a celebration when they turned off their last Oracle system ...
I doubt it. Oracle has done a great job dissuading new business by suing customers for discussing benchmarks, suing customers for discussing security, auditing customers, jacking up prices, jacking up penalties, suing everyone else, etc... Plenty of reasons to drop already.
Everyone left stays because they're in deep and migration would be worse.
Do you have some sources, or specific instances I could do my own searching for? Feel free to email me privately. I'm somewhat serious about trying to kill Oracle in retaliation for what they've done here.
Threatening benchmarkers:
* https://www.brentozar.com/archive/2018/05/the-dewitt-clause-why-you-rarely-see-database-benchmarks/
* https://news.ycombinator.com/item?id=15886333
* https://www.theregister.co.uk/2018/03/22/oracle_shoddy_service_license_denials_aimed_to_force_adoption_of_cloud_service_lawsuit_claims/
* https://outline.com/YUFYFK
* https://boingboing.net/2015/08/11/oracles-cso-demands-an-end-t.html
* https://www.theregister.co.uk/2017/01/26/oracle_sues_employee_undo_arbitration_loss/
The current SG's opinion that Google's fair use claims aren't reasonable is new to this administration.
I thought IBM is mostly a consultant company now and the goal of a consultant company is to make money.
Considering that I don't think IBM and Oracle would be on the same page on who they regard as enemy.
As opposed to which company ?
I meant to say that IBM likely doesn't have any deterrents to sue Oracle as they are no longer on the same page with regards to their business markets.
Weakening Oracle won't affect IBM's business.
That being said Oracle and IBM still compete in many markets such as cloud computing and software platforms. Since Red Hat became part of IBM the areas where they compete has increased lately.
But the information that IBM and Oracle are still competitors in many markets is explicitly what I was unsure about. Thanks for reminding me about the Red Hat acquisition, I completely forgot about that already.
ISO is not some organization created by the statute with the right to take your copyrights and make them public domain...
IBM's potential claim on SQL wouldn't be a threat to Oracle.
IBM uses Java heavily. The most likely outcome is that the two companies reach a deal to cross-license with maybe a modest amount of money exchanged, freeing them each to go after everyone else.
https://en.wikipedia.org/wiki/List_of_Java_virtual_machines#...
Even some non-compliant like MicroEJ, https://www.microej.com/product/sdk/
None of them was ever sued, because they play by the rules, instead of playing the "I am the big boy, I follow no rules" that is Google's stance at this.
Java compatibility is enforced by trademarks. In order to call something Java it has to pass certain tests and there is a cost attached to it. There has been many free Java implementations before that had to call themselves something else to be in the clear, IcedTea being perhaps the most well known.
This litigation, however, was never about trademark law. Oracle knows that would be a short lived process. They instead made up argument about how function definitions under certain circumstances could be copyrighted, that could keep their lawyers busy for a long time. By throwing a lot of money at this they could sow fear about their competitor's business model. It's straight out of the Microsoft, by way of SCO, playbook.
Worse, Google cleverarly takes advantage of their Android Java fork stagnation to sell Kotlin over Java, while being fully aware that modern Java makes many of those code examples pro Kotlin worthless.
Google could be 100% tracking newer Java language features and Oracle would still have made this lawsuits. It's financial compensation or competitive advantage they are after or something, compatiblity and feature parity is very low on Oracle lawyer's list.
Sun and Oracle never sued other JVM implementations, only Microsoft and Google, aka J++ and Android Java.
If Google did not wanted a lawsuit, they could have easily made an offer to buy Sun after torpedoing their profits helping the company to close doors, no love for Google from my side on this story.
This all would have been avoided if Google wasn't a bad actor in the first place. They wanted to play by different rules than everyone else and thought they had enough weight to get their way. Now someone in their own weight class came along and we all get to live with the fallout.
I don't think it was an issue of monetary value. Sun simply wasn't going to offer terms that would allow Google to make Android with Sun's blessing, because Sun wanted to retain tight control over the feature set of different Java editions.
> This all would have been avoided if Google wasn't a bad actor in the first place. They wanted to play by different rules than everyone else
Please don't do this. The irony of making such a silly claim using a software stack that is so thoroughly built on those "different rules" is too much.
> Please don't do this. The irony of making such a silly claim using a software stack that is so thoroughly built on those "different rules" is too much.
Give me a break. You just said yourself they circumvented Sun's licensing. If software licensing and trademark usage doesn't matter, then why do even bother with them?
Please don't conflate trademark licenses with copyright licenses.
If Google doesn't get a pass on doing what the whole industry is doing - then no one will get a pass - that is a bad thing regardless of your thoughts on Google. Reimplementing interfaces is the lifeblood of compatibility, and has been for decades. A win for Oracle is a win for vendor lock-in: open source and upstarts lose.
That's because you're repeatedly failing to see the distinction between trademark law and copyright law. The Visual J++ lawsuit that was settled was a trademark infringement suit, because the Java trademarks are what Sun had locked behind license terms mandating compliance to their compatibility test suite. Google was more studious about avoiding use of Sun trademarks in Android, and chose to not seek a license for those trademarks. Now they're being sued over copyrights, not trademarks.
At the end of the day, Google wanted to use Java and not really be compatible with Java, so they tried to skirt around it and got called out for it. This was evident by pages they had that stilled referred to it as Java and by passages of code taken in whole. So, yes, I'll contend that Google tried to get away with something and hoped they were big enough to come out of it unscathed.
It's not like this was unforeseen. And it's not like Sun or Oracle has sued any compliant Java implementations. They could have just used OpenJDK, but didn't want to play by those rules either. If you don't like how this is shaping up in the courts, it's fair to say that it could have all been avoided by Google being a better actor.
OpenJDK didn't exist at the time.
And the only reason that Harmony (the base used in Android) isn't compliant is that Sun changed the terms of the TCK in a way that was in conflict with open implementations. https://en.wikipedia.org/wiki/Apache_Harmony#Difficulties_to...
Whoever is paying their salaries has the right to decide how they get used.
If this is the way to fix Android Java, or fully replace it with Flutter, then so be it.
You could say the same about the design of an electrical plug or a radio signaling protocol. That doesn't make the functional aspects of the design subject to copyright.
Even implementators of languages considered free beer like C and C++, have at the end of the day have someone paying for those 100 CHF.
Naturally there are black markets to work around those issues, then if a fire can be tracked back to a not-certified plug, the insurance can consider it isn't responsible for paying.
So then what do you need copyright for? Do the same thing for your API. Copyright is the wrong tool for this.
But in particular, notice that if your "market compliance processes" start trying to charge monopoly rents, someone will reverse engineer the thing and launch a competing compliance process which insurance companies will happily accept as long as it has reasonable quality.
Also notice that the compliance process for things like that is generally shepherded by a third party non-profit like UL or IEEE and not a competitor in the same market.
What I have more of a problem with is that we have no clear precedents for how API copyright will work in practice if it is suddenly foisted upon the real world. What does it mean for an API to be licensed under the GPLv2, or any other copyright license that was written with source code and object code in mind but not APIs? How will we determine which license agreements executed long ago should be retroactively considered to include or exclude the APIs? How many industry standards will have to be assessed for whether the relevant APIs are available under FRAND licensing terms as the relevant patents usually are? Is there a distinction between providing vs using an API, for the purposes of determining copyright infringement?
Using DRM for a programming language in order to create a walled garden is a bit harder. We can imagine a Java 2.0 (evil version) where the byte code has DRM that checks for unauthorized java compilers, but it won't work if the physical programmer can choose to move to a new platform. DRM can thus not create a wall garden for a programming language unless there is legal walls that prevent a competitor to create a compatible platform.
I don't anticipate a doom-and-gloom scenario if APIs were all-of-a-sudden copyrightable. Today, open source software is backed by powerful companies, and there is far less lock-in to any particular set of software functionality. The likely outcome is that big tech companies would just cross-license their basic APIs like Win32, SQL, NTFS, POSIX-like functionality, and other basic interface layers.
Today in 2020, the value is not in the interface, but data. Facebook probably wouldn't care if you created a clone that used the same API structure. But if you started imported their user data, you could expect a lawsuit.
This multi-year cross licensing project wouldn't be a big impediment. It happens all the time in standards setting organizations, and wouldn't slow down progress significantly.
The worst case scenario would be trolls somehow obtaining the copyright to a foundational API and collecting money from everyone. That would be a pretty big annoyance, but that too would't be a doomsday scenario. Patent trolls have been active for decades and have had minimal impact on overall progress.
Where did you get this from? It's mighty hard to quantify what might have been. Patent trolls disproportionately affect small organizations that are not on anyone's radar unless and until they deliver. They die with not a roar but a whisper.
That's a funny misspelling of GAFA+Microsoft+IBM.
Sometimes courts uphold the letter of the law, but say the legislature should change it.
IBM sued Handwell Corporation, and Handwell settled [1].
IBM sued Eagle Computer Inc., and Eagle settled [2].
[1] https://books.google.com/books?id=gy4EAAAAMBAJ&lpg=PA15&pg=P... [2] https://www.nytimes.com/1984/02/22/business/eagle-ibm-settle...
That's just you being unreasonable. I've literally never seen anyone else make a similar assertion or assumption, while the opposite is very common—most APIs that get copied are ones where the source code to the implementation is not even readily available to be copied, or where even looking at the original implementation's source code is dangerous for the author of a clone because of its license terms.
Confusing the API with the entire standard library implementation is not a common mistake, especially among people who pay any attention to this legal case.
> The "SSO" language is not an arbitrary or legal distinction. It is a technical one that is necessary to convey the exclusion of the implementation precisely because people would otherwise assume we were also talking about the implementation when we say "API".
The "SSO" language is not about clarifying that the API is separate from the implementation; that distinction is pretty clear on its own. It's about trying to make sure the API doesn't run afoul of copyright law's exclusion of "any idea, procedure, process, system, method of operation, [...]", by making APIs out to be something more than just a collection of parts that are individually not copyrightable.
The implementation was different in this case though, so apart from the above the answer to this question also doesn't support what you are arguing.
"62 classes (and some of their methods), spread across three packages within the Java API library, must be used. Otherwise the language itself will fail."
"On remand, the parties stipulated that only 170 lines of code were necessary to write in the Java language. It is undisputed, however, that Google copied 11,500 lines of code — 11,330 more lines than necessary to write in Java. That Google copied more than necessary weighs against fair use."
[1] https://scholar.google.com/scholar_case?case=107451649356761... [2] https://www.leagle.com/decision/infco20180327178
"Oracle has portrayed the Java programming language as distinct from the Java API library, insisting that only the language itself was free for all to use. Turns out, however, that in order to write at all in the Java programming language, 62 classes (and some of their methods), spread across three packages within the Java API library, must be used. Otherwise, the language itself will fail. The 62 "necessary" classes are mixed with "unnecessary" ones in the Java API library and it takes experts to comb them out. As a result, Oracle has now stipulated before the jury that it was fair to use the 62 "necessary" classes given that the Java programming language itself was free and open to use without a license"
"That the 62 "necessary" classes reside without any identification as such within the Java API library (rather than reside within the programming language) supports Google's contention that the Java API library is simply an extension of the programming language itself and helps explain why some view the Java API declarations as free and open for use as the programming language itself. At least to the extent of the 62 "necessary" classes, Oracle agrees."
[1] https://casetext.com/case/oracle-am-inc-v-google-inc-19#N196...
I don't suppose it will persuade you that String (and many other classes) are in the Java.lang package.
From the prior source [1], immediately below the previously-quoted text:
"Trial Exhibit 980, The Java Application Programming Interface, Volume 1, is a book that covers four packages and refers to them as the "core packages." According to the back cover of the book, these four packages "are the foundation of the Java language. These libraries include java.lang, java.io, java.util, and java.net. These are the general purpose libraries fundamental to every Java program."
[1] https://casetext.com/case/oracle-am-inc-v-google-inc-19#N196...
https://www.docketalarm.com/cases/California_Northern_Distri...
Sounds like a "clean room implementation" is needed, and that Google copied more than what was needed for inter-op.
If so, Google might lose the case, but the legal precedent would be you can copy apis but not implemention (unless that's the only way to implement them).
https://www.allaboutcircuits.com/news/how-compaqs-clone-comp...
IBM tried to regain control with the PS/2 architecture, but it failed to do so, and only the mice connectors survived.
Big difference in regards to legal process.
Siding with the company that created a fork in the Java eco-system, just like Microsoft did with J++, just because "Do no evil", without legal understanding, is just typical.
Like wishing for IBM to sue Oracle for SQL, without understanding unlike the way Google screwed Sun and the Java community, there was eventually an agreement between both companies, because hating Oracle is cool in some circles.
There is also a circle that mourns over rise over open source software and evangelizes proprietary software out of pure prejudice.
I thought it was SCO who were the bad guys in that one?
It is hard to find any popular blog post that faithfully represents the sides' claims, so it's best to read what they actually are in one of these locations:
* https://www.supremecourt.gov/search.aspx?filename=/docket/do...
* https://www.scotusblog.com/case-files/cases/google-llc-v-ora...
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.
Many companies do patents as means to protect their IP when copyright isn't enough.
If anything this might be a welcome change to the culture of free beer.
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.
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.
A piece of code can infringe on a patent, but it can't itself be patented (although the algorithm it describes can).
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.
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.
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.
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.
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:
http://www.groklaw.net/staticpages/index.php?page=OracleGoog...
You may not remember, but we went over the examples Oracle gave pretty much line by line and many people discussed just how trivial it all was.
You also still seem to be ignoring the point that a jury already found this to be fair use -
https://news.ycombinator.com/item?id=11781053
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?
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.
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.
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.
The project for some compilers courses is implementing a compiler for a subset for Java. Would the current ruling mean that doing the project is copyright infringement?
Fair use would probably protect you because you're doing it for non-commercial educational purposes. But further, this lawsuit is not over the Java language, but it's libraries.
"Alternatively, the Supreme Court could hold that software interfaces are sometimes eligible for copyrights but that Google's copying falls under the fair use doctrine. This would save Google from writing Oracle a 10-figure check, but it could still drag the software industry into a legal quagmire."
Explanation: The merger doctrine is the doctrine that if there is only one way to write something it isn't copyrightable/copyright infringement. Alsup (the original judge) interpreted this as being interpreted at the time Google copied the API, at which point in time there was only one way to write an API compatible with existing java programs, thereby killing Oracle's case. The federal circuit reversed based on the idea that it should be interpreted at the time of the creation of the copyrighted work, at which time there was no reason to favor calling something "java.lang.String" instead of "java.std.String" and so on.
Fair use is a lot more complicated to deal with than the merger doctrine. Ruling based on it will almost certainly result in a lot more pointless court cases as people debate whether or not this instance is fair use.
This would factor into the fair use analysis and the damages analysis, but not the analysis of whether or not the material was copyrightable in the first place.
PS. For what it's worth I agree with you that this isn't copyright infringement, I just think it's important to get the arguments for why it isn't copyright infringement right. The two arguments I like best are "the merger doctrine" (If there is only one way to write something, in this case a API that existing java libraries can use, then it isn't copyrightable) and "fair use" (Vaguely speaking an exception for copying we as a society don't mind, defined in the law here https://www.law.cornell.edu/uscode/text/17/107).
IBM wanted companies to embrace SQL - because then people implement applications already compatible with their database product, and conceptually could migrate without rewriting their applications.
Amazon wanted companies to embrace S3 - for the same reason. Or maybe they didn't, but they decided that the API was the least significant compelling part of their product - that people would still choose S3 regardless of whether other storage offerings had the same API - for the cost, and durability.
Sun wanted Google to use Java. Because more developers using the language, regardless of the underlying implementation is better for the entire ecosystem.
Oracle doesn't.
So to some degree i do feel like consent matters here. It doesn't matter if Oracle copied Amazon's S3 API illegally if Amazon doesn't care enough to pursue it.
Finally, I hate arguments that say "It's just the API". We all know a good API makes or breaks developer tools.
Ultimately, I feel like it goes without question that a decision in Oracle's favour will cause irrevocable damage to the industry and permit all sorts of bad actors to start looking to purchase ownership to APIs just so they could sue those they consider infringers.
But I can't help but feel that ultimately Oracle has a point :(
Copyright is not some innate right. Interfaces should not be copyrightable just because they require some level of competence to design.
If it was a patent then at least the term would expire, but copyright lasts a very, very long time. Car companies would love to copyright mechanical interfaces and so prevent anyone from making aftermarket parts.
The purpose of copyright, according to the constitution is "[t]o promote the progress of science and useful arts". So generally, things should be copyrightable if granting the copyright results in more and higher quality work. If APIs are indeed protected, there it is plausible argument that we will have more of them and they will be of higher quality.
You're wrong. The constitution grounds copyright (and other IP rights), in utilitarianism. Meaning, if granting stronger protection promotes overall welfare, then that is justification.
The problem with utilitarianism is that it's very difficult to determine what is greater "overall welfare". By its nature, it's an empirical decision. Once you start invoking data (rather than basic rights), lots of people and companies will come out of the woodwork to promote their own data points.
Sure, but that immediately brings to mind the question of whether such fragmentation will be a hindrance to technological progress. And there's little doubt about which way the evidence tilts on that question—there's way too much mainstream software that would not have been legal without the right to reimplement an API without a license. So then it becomes a question of whether it is better for the law to promote good API design, or to promote actual useful software.
It seems extremely likely that the human race may not exist long enough for current works to ever have their copyright expire.
Why would it? Giving a company the right to prevent interoperability does not necessarily mean they will invoke that right. It also might promote alternative APIs potentially fragmenting the market, but also inventivizing various approaches. It's not clear that this is the case, but it's not clear that it isn't either.
You may as well argue standards have lowered innovation.
> Giving a company the right to prevent interoperability does not necessarily mean they will invoke that right
I hope that whoever created int max(int a, int b) is benevolent because just about every programmer has reinvented that at some point. What about Response get(String url) which returns an HTTP GET response. We have probably all written that at some point and most HTTP libraries implement it.
FUD. You're using extreme arguments that traditional copyright law handles them well. API functions like "max" or "get" are so basic and general that they would not be protected by copyright law because they are not original "creative" works... a "max" function can only be written in a few ways that don't really rise to the level of creativity.
However, a massive amalgamation of functions and classes, could be protected. I don't see any theoretical reason why they shouldn't, just practical ones based on what the software industry has expected as standard behavior.
Given the choice between honest work and preying on our fellow human being its always easier to exploit. This is why despite being proposed as a means to inspire creation copyright theoretically expires 7O years after you die and realistically never. Once someone has conceived of a way to extract value out of their fellow human beings that extraction becomes a right regardless of how it effects civilization as a whole and most of this value doesn't even flow to creators it flows to soulless intermediaries who have inserted themselves between creator and consumer. Why given the opportunity to exploit more would they NOT?
Your argument is not really about intellectual property rights, and is more about property rights and capitalism generally. If you don't believe in property rights or investment, then sure, IP rights don't make sense either.
I don't see this as a mess at all. I see this as very positive experimentation and eventual consolidation. Would it really be better if one company came up with a GUI and everyone latched on to it?
> Oracle doesn't.
> So to some degree i do feel like consent matters here. It doesn't matter if Oracle copied Amazon's S3 API illegally if Amazon doesn't care enough to pursue it.
If consent matters, then Google implicitly received it from Sun, but had it removed afterwards by Oracle. So if you actually support Oracle here, I don't understand how you can say "consent matters". The consent was given, yet you yourself don't consider it in Google's favor.
By your reasoning, IBM could spin-off a division with intellectual property rights to SQL, sell it to Google for 10B, who could then claim "we never agreed SQL should be free!" and sue Oracle into bankruptcy
Source: https://twitter.com/joshbloch/status/1237518298922745861
(I suppose just saying "Trump backs.." can be a signal indicating what the Trump supporting readers ought to think. OTOH, the same language on CNN has a similar effect in the opposite direction.)
The GNU AGPL has additional restrictions that require redistribution of the source code under the GNU AGPL to users which access the software over a computer network (AFAIK those particular restrictions have not yet been tested in court, so it's entirely possible that they're unenforceable).
This case is also about fair use. Like all copyright licenses fair use give people exceptions when the exclusive right of copyright can be broken.
1) the comparison may be inapplicable. The case in hand does not rise or fall on hypocrisy. I am a bad actor does not forbid me pursuing a law case based on the law I break myself in another matter.
2) IBM has at least three strategies
a) leave alone: let sleeping dogs lie b) pursue oracle but settle for cash or in-kind or IPR swap or RAND, or some outcome which advantages them (Redhat?) but nobody else c) be an advocate for a movement and take a posture in the wider interest.
What do you think is more likely?
Unethicalprotip: publish proprietary source to bait copying. Then sue.
Google and I happen to agree with your interpretation, but it misses the point of the case.
Why are specs fundamentally different than implementations?
Implementing an API spec is not just using the "abstract ideas" in the spec. It requires copying the specific text of the API: a function named DoSomething will incompatible with one named do_something.
I don't think that's a valid way to distinguish copying APIs and implementation.
On a purely theoretical basis, I do think APIs could be copyrightable, I don't think there is a valid way to distinguish them from implementation. The main argument against copyrighting APIs is practical: everyone has been doing it for decades, and changing the status-quo will be disruptive.
Another practical reason is that copyrighting APIs will decrease competition by impeding companies from creating better drop-in competitor products to established players. But this is really an argument against all software copyright, not just API copyrights.