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?
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.
That's a funny misspelling of GAFA+Microsoft+IBM.
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.
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.
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...
"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).
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.
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.