It's worse than that isn't it? Naming is how you link things. What happens to WINE if it is illegal to use the same names Kernel32 does?
Imagine you're a company using some Oracle database, and you want to reimplement some component of that system in order to migrate and escape their vendor lock-in... You can't, not without taking a huge legal risk.
In the short term, it's a victory for huge litigious corporations like Oracle. The good thing, I hope, is that in the long term, this will make people distrust closed source software even more. What Oracle wants, and has always wanted, is to bind you in the worst possible form of vendor lock-in. Open source and open standards are the answer. Refuse anything else.
It's worse than that. OpenJDK, including the java standard library, is GPL. It's open source.
Oracle is claiming that even though source code defining the API is open source, they retain copyright to the API itself.. regardless of the open source implementation of the API by themselves.
If this case goes through, you won't be able to mimic an open source project's API unless you also verify they provide the API under a similarly permissive license.
The code at issue is pre-OpenJDK, and wasn't open source when used (though much of it may now also be available in OpenJDK, not that Google uses it under the GPL, or claims to, anyhow.)
But the GPL is irrelevant, Google has never distributed under the GPL terms. That whatever it was doing was not under a Sun/Oracle license is not in dispute.
Your code is just protected if it gets re-distributed, that's why google never ever has to opensource their "Server OS/Kernel".
Also they changed GCC to GPLv3 which is just a super stupid decision for a Compiler.
Are you sure they are claiming that? A weaker claim could be that Google's usage does not conform to the GPL. Indeed if you were correct and the ruling is in Oracle's favor then the GPL is broken as designed, I haven't heard anyone express that concern in connection with this case.
At the time at issue, Java wasn't under the GPL. That Google did not have a (public offer or private) license to Java is not in dispute.
But Oracle doesn't care one bit about anything else that's not Oracle.
Though it is still to be known how many reimplemented APIs from others does Oracle have in their products
Yes if you want to be certified and want to get a copy of the standards document you'll need to pay, but it's not necessary (and I doubt that Oracle did, given that they implemented SQL before the standard existed and probably were involved in drafting it).
Then that screwdriver turns itself instead of turning the screw.
> probably were involved in drafting it
Which also isn't done for free beer, ISO processes have associated costs.
The original point being made in this thread was that Oracle copied the API of SQL from IBM and thus is guilty of the same thing that they are accusing Google of doing. The counter-point was that SQL is an ISO standard and Oracle (allegedly) licensed it, which was then followed up by my point about Oracle DB predating the ISO standard. Hence why ISO is being discussed and why I was making the point that buying a standard document from ISO or paying for certification are not really relevant to this discussion.
I understood copyright to be something you had if you had created it.
Copyright... of the top of my head, I don't recall much about copyrightability of software.
[1] As a side note, IBM may not have been the first to license software but they certainly helped make it a standard practice. When they unbundled much of the System/360 software, they felt that copyright was a weak protection (given its uncertain legal status) so they combined it with a license.
... in the US of A.
Berne convention started a little bit over a full century before that.
Impressive that the superfluous “need” for the Copyright (c) YYYY notice still persists to this day in the mind of many.
I’ve made a life long habit of collecting and archiving these in my personal documents whenever I get my hands on one. Because these are valuable guidelines as to how things are supposed to work.
That's patching and is already disallowed by licenses in USA, but allowed by law, but that law was goofed up by a court.
Says who? Oracle is claiming exactly the opposite, and if they win this will become "law" in the USA. I think you've missed the whole point of this issue here.
> For instance "Linux" is a copyright owned by Linus Torvalds…
For starters: Linux™ is a trademark, not "a copyright".
> Your understanding is incorrect here.
It seems, at least to me, that you actually missed a few core point of the whole story. ;-)
Patenting an API makes sense, since APIs are essentially ideas. Copyrighting an API does not make sense.
You cannot patent the completely generic idea of "a tool to lift people in buildings", but you can patent an elevator.
Similarly, you cannot patent "the ability to scan a database", but you can patent an api for doing so, even without a complete implementation of that api.
You should see some of the software patents that get approved nowadays to see just how often "idea on a computer" gets greenlit.
I am very worried about this case.
WINE is using the Windows names for the purposes of allowing Windows programs to run. This is a case where a judge would easily grant fair-use because you have to use the API surface area to provide compatibility for existing programs.
Android is using the Java names for the purposes of allowing existing Java developers to be productive, not so that existing Java programs can run.
>Since Oracle's claim is that Google's use of the Java APIs wasn't to provide compatibility to existing software written in Java but to have a _familiar_ language for Java developers it becomes a novel but normal copyright case.
You're making a distinction between "interopability" and "end user familiarity". But Lotus also sued Borland on the basis of "familiarity" of the menu "names and structure" and they lost. The Supreme Court's 4-4 split decision left the lower appeals court's ruling intact.
https://en.wikipedia.org/wiki/Lotus_Dev._Corp._v._Borland_In...
Sure you might not be able to take a legacy SWING Windows Java app and run it on android, but you can run entire libraries in your android app. It absolutely _is_ about interoperability in both cases. Perhaps to varying degrees
WINE could very likely win a legal battle through claiming a fair-use exemption (of course, if the case fails, they wouldn't have to go to court at all).
Where is the line? Is Android "compatible" with Java programs if those programs need to be recompiled first, but no source edits are necessary? What if source edits are necessary, but can be automated? What if recompiling isn't necessary, but you need to hex edit the binary?
"Compatibility" is a spectrum, and I'd say Android falls within that range.
There is no distinction between the two because these things are presented as evidence of Google's intent, it's not proof. There's no line. Google's case would be much stronger is Android-Java could run most Java software unmodified but it doesn't mean they'll lose just because it's not true.
Of course, in reality Google's decision was probably a little of both, right? They selected a technology based on a wide range of factors, including development costs and compatibility.
I'm still concerned that a decision in Oracle's favor would have a massive chilling effect on everyone else. All companies want to limit their potential liabilities. How can you prove in advance that you selected a language or API for the sake of compatibility, even when that is in fact the driving factor?
I wouldn't think that Google's development costs were part of the decision. There aren't that many Java APIs -- as the article says, it's ~11k lines of definitions -- so Oracle is seeking ~$818k per line. Assuming Google's lawyers predicted that there was some risk of a lawsuit like this, any engineering costs associated with redesigning the APIs would just be negligible compared to the legal risk.
One could argue that it is quite difficult to design a good API, but Java's APIs are frankly full of mistakes: Date/Calendar, immutable collections with no type safety, "optional" methods like Iterator.remove, etc. It wouldn't take a team of world-class engineers to come up with something better with the benefit of hindsight.
On the other hand, developer familiarity and compatibility with existing Java libraries could have had a significant impact on Android's adoption. I think that was what justified the legal risks.
https://www.cnet.com/news/android-chief-andy-rubin-said-java...
"Copyright and consequences: Google’s Andy Rubin defends Android to jury"
https://arstechnica.com/tech-policy/2016/05/copyright-and-co...
> "We've been over a bunch of these, and we think they all suck," Lindholm wrote. "We conclude that we need to negotiate a license for java under the terms we need."
Not centrally. The copyrightability issue is absolutely not about Google’s intentions (and if Oracle loses that, it's game over), and Google’s intentions are relevant to one half of one of four fair use factors (the “purpose and character of use” factor) which are weighed together (it's not a pass-fail each factor test) in the fair use portion.
In contrast, Google didn't have their own independently developed programming language. They needed one so they copied the Java api and created one from there. They did not use the Api to create a compatability layer. It was used as a starting point to make their own copy of Java.
How would such a programming language be detectably different from being an implementation of Java?
Yes
>How would such a programming language be detectably different from being an implementation of Java?
It would have it's own unique API. As an example, Ruby can run on the JVM via JRuby and it's clear that Ruby is a different language than Java.
Its literally same difference.
In this example Google independently developed a language and made it compatible with the JVM.
In the real world Google wanted Java and didn't like the licensing terms. So they copied the Java API and from that starting point built out their own version of Java.
What you are suggestying is copying the binary API instead of the texual one. It is equally the subject of copyright.
In the real world Google deleoped their own equivalent of the JVM, which uses different bytecode. This is technically more difficult than putting together a language. But that has no relevance to the subject of copyright.
I mean, a programming language is fundamentally a set of instructions that produces output, right? So, a Java programmer writes `System.out.print("Hello")` and the Java implementation does the work to make "Hello" appear on screen. Similarly, a Windows executable running via Wine will tell the Windows API to print "Hello", and Wine will do the work to make that message appear on the screen.
This isn't an argument that has been made in court in anyway, and Google's use of the Java language hasn't been questioned.
Google could have used the Java language with completely different APIs (google.lang instead of java.lang for example). It's the APIs that this case is about.
Also, the key analogy is wrong anyway: while Android used java.lang and java.util and other related APIs, the key functionality of the phone was accessible via custom APIs that aren't copied. Note that the "interoperability" argument was lost by Google because of this exact thing.
Well, no, because many Java language constructs are defined in context to the standard library, for instance all classes being children of java.lang.Object. They'd need quite a bit of java.lang at the very least.
In 2020 it is still pretty much hint and miss getting a Java library working without changes on Android, given that the Android team cherry picks whatever they feel like from OpenJDK for their own Android API implementation purposes.
Easily to find that out from Gerrit commits and AOSP source code.
Meanwhile, effort has been spent ensuring that 100% of ISO C and ISO C++ are available on Android NDK.
Thus out of the window goes the interoperability argument.
Maybe if Sun didn't play games with access to the TCK in the past we wouldn't be here adn there'd be a valid test for compliance that wasn't "do what the official JDK does".
Do you have anything else to pivot to?
I am not pivoting, Google has only itself to blame for their little J++ adventure.
"James Gosling Triangulation's Interview on Google vs. Sun"
https://www.youtube.com/watch?v=ZYw3X4RZv6Y&feature=youtu.be...
Basically wanting Java as free beer, without paying Sun any money given that Java actually required licenses for handsets/embedded deployments in pre-OpenJDK days, in the not so good economical situation that they were, withdrawing them from possible Android license revenues.
That is torpedoing, regardless how Google employees, or wannabe employees play it.
That means they wouldn't have gotten any money from SavaJe like phones either.
The only people who "torpedoed" Sun was Sun themselves.
And yes, switching from an interoperabilty argument to 'they were morally obligated to buy Sun' is very much pivoting to a different argument.
Also, here's James Gosling later saying that APIs should not be copyrightable. http://nighthacks.com/jag/blog/397/index.html
I was wondering where would the Oracle win hurt most, and I think there is worse than WINE.
The Unix syscalls would have been Bell Labs’ copyright. That copyright was sold to Novell, which was sold to… Micro Focus International plc?
So this British consulting company that is, according to its website, “powering digital transformation”, could transform the digital world by suing BSD, Linux, Apple and Microsoft for tremendous sums of money and forbid them from using the famous syscalls.
I guess a given set of CLI programs may also be seen as an application programming interface, which makes all of GNU liable too.
Is that correct?
Additionally, the contract is public. http://www.groklaw.net/pdf/USLsettlement.pdf Point 9C on page 14 has the university declaring that as far as they know, no AT&T IP is present in 4.4BSD, despite it clearly having a UNIX compatible API.