Hacker News Reader

Comment by jasode | Hacker News Reader

>This is a complete dramatization. Are you copying 10k lines of code from a licensed code base into your project without permission and using it in your commercial product?

To point back to the substance of the thread and Oracle's claims...

Google didn't copy any of Oracle/Sun's Java source code base into Android Java. Oracle lawyers acknowledge this.

Instead, Google copied the API of function name spellings and also the hierarchy of organization (tree of namespaces) of those API methods. I asked about this in a previous comment and some folks more familiar with the case replied with citations of court opinions: https://news.ycombinator.com/item?id=7852100

So to give a flippant summary of the current situation: you _can_ copy some exact spellings of API function names (e.g. other browsers Chrome/Firefox/Safari can copy Microsoft IE XMLHttpRequest() exactly without renaming it to RetrieveHttpXtensibleMarkupLang()) -- as long as you don't copy too much of the API surface area. The threshold of "too much" and getting in legal trouble is yet to be determined by The US Supreme Court.

If Oracle ultimately wins, it seems like millions of programmers will have to reach for a thesaurus to find synonyms to name functions. We'll have to waste brain cycles coming up and alternative spellings of methods to stay away from copyright infringement.

View on HN

> If Oracle ultimately wins, it seems like millions of programmers will have to reach for a thesaurus to find synonyms to name functions. We'll have to waste brain cycles coming up and alternative spellings of methods to stay away from copyright infringement.

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?

From everything I've read, Wine would quite clearly be illegal if the court rules in favor of Oracle.

I am very worried about this case.

I don't think it would be infringement. The main difference between WINE and Android is where the interoperability integration points are.

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.

You are making a distinction when there isn't one from the legal opinion perspective.

There is actually, and the court argued as such: if Android had been compatible with Java programs, Google could have claimed a fair-use exemption. Since Android can't run many Java programs, by design, they can't claim such an exemption.

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).

Why is the distinction between "runs with zero changes" and "runs with minimal changes"—or even just "runs with fewer changes"—so critical?

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.

Because the actual implementation isn't what the courts are looking for. This is a case about Google's intention for copying the Java API. Oracle is claiming that Google copied their API because it was easier than designing a new language; Google is claiming that they did it for interoperability reasons.

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.

Thanks, that's interesting! It seems reasonable—if Google was explicitly trying to enable compatibility, that should be allowed, whereas if they were just trying to save a buck, that should be illegal.

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?

> Of course, in reality Google's decision was probably a little of both, right?

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.

Many libraries comes from Java world are able to use by copying API. So saved lines is not just ~11k.

"Android chief Andy Rubin said java.lang APIs are copyrighted in 2006 email"

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."

> This is a case about Google's intention for copying the Java API.

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.

>I don't think it would be infringement. The main difference between WINE and Android is where the interoperability integration points are. [...] 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...

It's not just about "developer interoperability" vs "program interoprability". Implementing Java APIs means that entire libraries can run.

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

Correct, and I was always surprised that Google didn't argue this point more. In my Android apps I've used Java libraries that were created years before Android even existed, and they work perfectly. And vice versa; I've reused code I originally wrote for Android in a Java desktop app with zero changes.

Wine makes programs written for Windows work on Linux. The key difference is that Linux is an independently developed system. The extent that wine copies Windows code is limited to a compatability layer. It doesn't transform Linux into just a copy of Windows.

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.

Didn't they though? They've had their own vm and bytecode for as long as Android has been released. The use of Java is for making libraries compatible.

They did have their own vm and byte code but not a programming language.

Is bytecode not a language?

Yeah, so mov or iload instructions would be protected copyright if Oracle wins.

I would say no but either way it's not what Google copied.

If I'm understanding your argument, if Google independently developed a programming language, and then they implemented a compatibility layer that accepted Java bytecode invoking Java APIs and translated it in realtime to their not-Java programming language, then this would be okay?

How would such a programming language be detectably different from being an implementation of Java?

>If I'm understanding your argument, if Google independently developed a programming language, and then they implemented a compatibility layer that accepted Java bytecode invoking Java APIs and translated it in realtime to their not-Java programming language, then this would be okay?

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.

This doesnt make sence - you jyst replaced the textual API used at compiletime with a binary API used at runtime.

Its literally same difference.

They're clearly different.

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.

But "making it compatible with the JVM" would involve implementing the Java standard library, right? Recognizing terms like "java.lang.String" or "java.lang.Math.max" and doing the right thing? To do that, aren't you creating a copy of the Java API?

Nobody is arguing that you can't copy the API if it's fair use. Copying the API in order to make a copy of the software isn't fair use.

Strange, in hardware land I thought that a clean-room reimplementation of something (where you make something with the same interface -- the API of the hardware) was legal.

Only if the clean-room re-implementation was properly done with separate teams, proven in court that both teams never had any contact with each other beyond written specification architecture documents.

Developing a programming language does not give you brownie points with a judge, and has no bearing on the matter.

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.

But one of the reasons Android chose Java was for compatibility with existing Java software. It was code rather than binary compatibility, but I'm not convinced that's a meaningful distinction.

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.

> 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.

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.

> Google could have used the Java language with completely different APIs

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.

Which even after their adoption of OpenJDK still isn't compatible out of the box with the standard library available at https://adoptopenjdk.net/

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.

Nothing happens to the interoperability argument. Nothing says it need to be 100% interoperable, or else you wouldn't be able to ship an MVP for any reimplementation of an API. And hell, the official JDK isn't even 100% interoperable with it's past selves.

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".

Maybe if Google had bought Sun after torpedoing it, we wouldn't be having this discussion and everyone was enjoying a Go style management with Java stuck at version 6.

You shouldn't have to buy someone to ship a competing implementation. And Sun wasn't torpedoed.

Do you have anything else to pivot to?

If Google didn't wanted to be sued (IBM would likely have done the same), their solution was to own Java instead of hoping that their torpedo would have sunk Sun's ship without a hiss.

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.

Except Sun never charged for handset/embedded deployments. They charged for access to the J2ME trademark. This case is neither about trademarks nor J2ME.

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

It's bad for programmers everywhere. If Oracle wins, you couldn't reimplement a compatible version of anything that's not open source. You couldn't make a third-party implementation of a corporate-owned programming language without putting yourself at risk.

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.

by the by... wasn't Oracle's original product a relational database management system (RDBMS) that offered a SQL API... which was invented/copyrighted by IBM ?

https://en.wikipedia.org/wiki/SQL#History

Of course.

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

Nope, they pay for ISO which Google hasn't done for Java.

You don't have to pay for ISO to implement an ISO standard. In addition, Oracle released their database software in 1979 but SQL only became an ANSI standard in 1986 (and an ISO standard in 1987) so they did originally reimplement an API which wasn't a public standard.

Sure you do, because the ISO documents aren't available for free nor the certification process.

I'm pretty sure that a fair number of commonly used QR libraries were not developed by people who shelled out for a copy of ISO 18004 (they probably just looked at descriptions of how it works outside of the standard document). Similarly, you can implement your own SQL dialect without needing to read the ISO standard for it.

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).

Sure that is how 1€ product shops work, which doesn't mean the final product actually does what it supposed to do.

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.

I'm not disagreeing with the validity of ISO or anything like that, I don't know where you got that impression.

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.

Some bmc commentary on that:

https://www.youtube.com/watch?v=-zRN7XLCRhc&t=2280s

It's the whole "Disney wants the copyright laws to prevent anyone from doing to Disney what Disney did to the Brothers Grimm" thing.

Yes and no. Yes, Oracle was a database with a SQL API. Yes, SQL was invented by IBM. No, it wasn't copyrighted by IBM, because at the time, nobody thought you could do that.

I thought you couldn't 'copyright' something?

I understood copyright to be something you had if you had created it.

Ah, brain cramp. I was thinking of patent, not copyright. Until State Street, nobody thought you could patent software, so nobody tried.

There was still controversy about software copyrightability in 1974. That said, I expect IBM still explicitly copyrighted their implementation of SQL (and licensed it [1]) as they had first started doing with some of the System/360 software during the prior decade. Note that, in 1974, you still had to explicitly copyright something; it didn't just happen automatically like today.

[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.

> it didn't just happen automatically like today.

... 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.

There can still be advantages to being explicit as I understand it to enforce copyright/collect damages. For example, most people don't actually deposit copies in circumstances where they're technically supposed to.

Pre-1976, authors had to explicitly add a copyright notice. The Copyright Act of 1976 changed all that. Creative works automatically gained copyright the moment it was created.

SQL is an ISO standard, which Oracle like everyone else also pays for.

You can make an open-source database that uses the SQL language without paying a dime to anyone or signing any contracts. You don't have to pay for the ISO standard document to implement it - you can just infer behavior based on what you already know about sql.

The state of SQL databases would be better if more people did pay for and try to actually implement the standards as written... same goes for many of these expensive standard documents.

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.

Which isn't what ISO says it should be.

>you want to reimplement some component of that system

That's patching and is already disallowed by licenses in USA, but allowed by law, but that law was goofed up by a court.

Could you be more specific? What law allows it, and how was it goofed up by a court?

It's allowed by DMCA, but a court ruled that the license overrides law, and now all licenses have "don't patch" clause.

Let us assume for a moment Oracle wins this so what? Android will become illegal and then Oracle would ask Google to do what? Pay royalties? Pay Damages? Ask all the android programmers in the world to stop using Android ? Abandon android runtime? I think what is gonna happen realistically is capitalism will take over they will settle it among themselves and share user data as a bargain probably get some royalties. The worst that can happen is Google will abandon android runtime or transfer the development to Oracle. Either way nothing much is gonna happen. Android has already won now say from tomorrow Oracle develops and owns the android development toolchain, so what, from a programmers perspective nothing much.

Nothing much? This isn't just about the Java API. This is about EVERY API. You might not be able to write a web server anymore, depending on who owns the copyright for HTTP. You didn't invent GET, PUT, and POST, you thieving copyright abuser.

Back when I was working for Nokia, the APIs were patented, this is nothing new.

Patents and copyrights aren't the same thing.

Patenting an API makes sense, since APIs are essentially ideas. Copyrighting an API does not make sense.

You can't patent an idea. You can patent the implementation of it if you're specific enough.

Well sort of. You don't need to have built the actual thing to get a patent.

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 cannot patent the completely generic idea of "a tool to lift people in buildings",

You should see some of the software patents that get approved nowadays to see just how often "idea on a computer" gets greenlit.

Like that Sony patent from 2005 to control the brain without conducting any experiments to confirm if that even works:

https://arstechnica.com/uncategorized/2005/04/4785-2/

You and your Stockholm syndrome.

Nope, I just don't live from rainbows and happy music tunes.

Quite interesting claim as Nokia was still an EU company back then and software "as such" can't be patented to this day in the EU. (That's sadly not true in practice any more for some time by now as more and more software patents are granted under the notion beeing "computer aided inventions". This also overlaps with strong political will to finally lift the general ban on software patents. Thankfully some people are fighting this nonsense though[1]).

[1] https://fsfe.org/activities/swpat/swpat.en.html

I dont think so, Webserver are based on HTTP protocol which is an Open web standard published by IETF. https://tools.ietf.org/html/rfc7231 It could be copyrighted but its usage doesn't mean you are thieving it. For instance "Linux" is a copyright owned by Linus Torvalds, Redhat isnt thieving it. Your understanding is incorrect here.

> It could be copyrighted but its usage doesn't mean you are thieving it.

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. ;-)

> If Oracle wins, you couldn't reimplement a compatible version of anything that's not open source

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.

> Oracle is claiming that even though source code defining the API is open source, they retain copyright to the API itself..

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.

> A weaker claim could be that Google's usage does not conform to the GPL.

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.

I very much doubt that anyone in big tech wants to open the can of worms that is GPL enforcement.

> OpenJDK, including the java standard library, is GPL. It's open source.

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.)

Sun released Java under the GPL in 2006 and most of JDK in mid-2007, but the first release of Android was in 2008. Or is the issue that they were developing it behind closed doors while it was still proprietary, even though they never distributed it to anyone?

The first public release of Android was a beta in 2007 (also, layer in 2007, the first SDK preview was released), and it was released to OHA members before that.

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.

Yeah I agree the GPL is not relevant to the case at hand, though it does raise the question whether (assuming Oracle wins) the logical conclusion is that the Java APIs are under the GPL/Proprietary dual-license Oracle offers today or that the copyright license itself doesn't apply to the API and a separate license is needed -- in which case I guess it's high time for GPLv4.

Except anti-GPL folks have made GPL almost irrelevant outside Java, Linux kernel, GCC and a couple of GNU tools.

That's because the GPL is not as Hippie as you might think.

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.

> What happens to WINE if it is illegal to use the same names Kernel32 does?

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?

4.4BSD was cleared in 1993: https://en.wikipedia.org/wiki/UNIX_System_Laboratories,_Inc....

That was only under the assumption that the APIs themselves weren't copyrightable.

Looks like the case was settled fairly quickly, so exactly what the claims were aren't as clear, and whether or not the API is part of the settlement depends on the exact details of that contract which aren't public.

It was very established ninth circuit case law at that time that APIs weren't copyrightable. This exact point came up today during oral arguments, with Oracle not denying it but instead saying that the terms "interface" and "API" weren't intended to apply to something so massive as the structure, sequence, and organization of the Java standard library.

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.

In addition to the specific claims and their validity, one fact remains. Oracle bought Sun for the sole purpose of suing Google. Full stop. I used to date someone involved in the case when it was just getting started. Oracle can go pound sand.

Thing is Google were also nasty towards Sun and helped it go under quite well. In many ways this is karma but too bad there's so much externality to it.

IIRC they were going to use the reference impl of Java but Sun wanted to inject themselves and the Java brand all over Android.

Plus Sun couldn't design a decent UI to save their lives, so Android probably wouldn't have been successful if Google had allowed Sun a large role in the platform.

Actually they did, but too many developers are lazy to buy books and apply their learnings.

http://filthyrichclients.org/

From the same Chet Haase and Romain Guy that went into Android's GUI framework after Sun went under.

And for mobile there was

https://docs.oracle.com/javame/dev-tools/lwuit-1.3/LWUIT_Dev...

Plus, Google could have done just like any other OS vendor does with ISO C and ISO C++, plus whatever OS APIs they feel like adding.

Yeah I don't think the problem with Sun's UI stuff was an individual or a group but probably big corp politics.

As much as I loved Sun workstations and Solaris, I'm pretty sure Sun went under all by itself.

With the Java licenses that Google have stolen from them, they could have eventually survived.

Everyone seems to have forgotten that Sun licensed Java under an open license that would have allowed Google to use these interfaces without issue, if they had met certain criteria for supporting the full Java platform. Google essential thought "Well, we have too much bloat, and these parts are totally unneeded in our platform, so we're going to strip them out."

Oracle's lawsuit is so bad-faith it is laughable.

I seem to recall Sun refusing to allow Apache Harmony's implementation of the Java stdlib to be certified, or didn't allow access to the TCK or something like that. It may have seemed at the time like trying for an official certification for Android was pointless.

Yep.

https://en.wikipedia.org/wiki/Apache_Harmony#Difficulties_to...

And adding to that, the entire enforcement mechanism was through trademarks, not copyright. And trademarks are about the only IP construct not brought up in this case.

Nope, Sun's license did not allow for Java SE on mobile devices without a proper license, hence the J2ME partners licenses.

there was no other reason to buy sun?

This isn't how copyright works though. It's neither necessary or sufficient. If you copy an API but change the words using a thesaurus you are still copying it so it would still be infringement. If by happenstance you come up with the same wording in your API, then that would not be copyright infringement because you didn't copy anything.

>If you copy an API but change the words using a thesaurus you are still copying it so it would still be infringement.

From the previous thread I referred to, a commenter cited an excerpt from a circuit court opinion about alternative naming :

[...] Using the district court's "java.lang.Math.max" example, Oracle explains that the developers could have called it any number of things, including "Math.maximum" or "Arith.larger." This was not a situation where Oracle was selecting among preordained names and phrases to create its packages. As the district court recognized, moreover, "the Android method and class names could have been different from the names of their counterparts in Java and still have worked." Copyrightability Decision, 872 F. Supp. 2d at 976. [...]

[1] don't know where the canonical source is so I provide a Google search link: https://www.google.com/search?q=Using+the+district+court%27s...

If I take a book, say Harry Potter, and use a thesaurus to change words to their synonyms in the hopes of avoiding copyright, no court is going to agree that I can now publish Barry Otter and the Association of the Eagle as my own creation.

I don't know if that's true. At least it you wrote a story which is almost exactly like Harry Potter from scratch, without referencing the original and with none of the original characters, I don't believe this would be an issue under current copyright rules.

But you won't. I don't think the law cares about hypothetical occurrences that have probability less than 10^-100000000000.

That's true, but not relevant to the point of the comment you are replying to. Taking a copy of an existing work, and simply replacing words with synonyms and renaming characters would still count as copying. Maybe there would be enough creativity in your choice of synonyms to make your work separately copyrightable as a derivative work, but that would still require permission of the existing work's copyright owner.

Producing a new work that happens to be similar to, or even word for word identical to an existing work, if you truly created it yourself from scratch without taking anything from the existing work, would not be copying.

As a practical matter, unless you had extraordinary proof that you really had never read Harry Potter books, watched the movies, read the plot summaries on Wikipedia, attended a party shortly after one of the books came out where everyone was talking about it, you would lose in a copyright infringement lawsuit. If you work is very similar to Harry Potter and you had access to Harry Potter, that's sufficient for the plaintiff to make their case, switching the burden to you to prove that you did not copy it.

A book is subject to veru different considerations - it has a plot, main characters, and other characteristics that you would be copying. All of these are a protected product of the author's creativity.

There is no plot in an API, no main characters, etc. It communicates matters of technical nature, and there aren't five different way of writing 'sqrt()' or whatever. It is more appropriately compares to architechtural blueprints and other technical documents.

My vague recollection of this case is that Oracle was kind of up a creek with the "java.lang.Math.max" argument, because max() itself is such a well-understood mathematical function and has been defined in numerous programming languages before Java. This put some constraints on Oracle, and thus "the name is the copyrightable contribution" became their (weak) argument. This does not necessarily mean that changing the function name (as opposed to calling interface and interface organization) would have been sufficient to avoid copyright infringement in every case (in Oracle's opinion.)

Which is amusing, because Sun almost certainly chose "max" in part for "compatibility" with the C standard library.

Scratch the "almost", the developer of java.lang.Math explicitly said in one of the briefs that he did it for exactly that reason.

> This isn't how copyright works though. It's neither necessary or sufficient. If you copy an API but change the words using a thesaurus you are still copying it so it would still be infringement. If by happenstance you come up with the same wording in your API, then that would not be copyright infringement because you didn't copy anything.

That also isn't how copyright works.

You're essentially asserting copyright over the semantics of an API.

The semantics of an API may (although I would argue otherwise) be protected, but if they are it would have to be either as a design patent, or as trade dress, not as copyright.

That said, even if the un-synonymized API is protected by copyright (and I would generally argue otherwise), reimplementing it must be seen as fair use, all the more so an API with renamed functions.

For a more recent example: Amazon's DocumentDB reimplements the MongoDB API. This should be allowed, even though we could wish Amazon had acted otherwise.

Here is the crux of the matter: unless there is some sort of no-man's-land between the various intellectual property regimes for software, no interoperability will be allowed except that which a vendor explicitly opts into. If copyrights, trademarks, and patents overlap sufficiently, even clean-room reimplementations will be forbidden.

We can argue about which aspects of software should be protected, for how long, and by what means, but at the end of the day there must be an unprotectable area of some kind, or we're all going to be doomed to either working entirely within vendors' vertically integrated stacks, or else implementing NSidedWheelAPIFactoryFactory() all the way down to bare metal for the foreseeable future.

> The semantics of an API may (although I would argue otherwise) be protected, but if they are it would have to be either as a design patent, or as trade dress, not as copyright.

Wouldn't semantics be functional and thus require a utility patent, rather than a design patent or trade dress?

Wouldn't semantics be functional and thus require a utility patent, rather than a design patent or trade dress?

The argument being made by Google (and stipulated by Oracle) is that the reason Google copied the API was for its familiarity to developers, rather than any inherent quality or functionality.

This is, essentially, a "look-and-feel" lawsuit, only applied to code, rather than UI.

That's how they're trying to make copyright work though. The protection being asserted here is over the "Structure, Sequence, and Organization" of the API.

I think in the case of Amazon selling hosted MongoDB calling it DocumentDB, they are actually using a fork of mongo's previously open source codebase. Prior to their license change in 2018 from AGPL to SSPL [0], Amazon would have been free to use mongo's codebase directly if they didn't need to make any changes to it.

[0] https://jira.mongodb.org/browse/SERVER-37651

> We'll have to waste brain cycles coming up and alternative spellings of methods to stay away from copyright infringement.

You do realize that if literally all you do is change the names and spellings then you'll still be in violation of copyright, right? Translating a book into another language (where the names and spellings of every word are different) is still copyright infringement. The fact that the names and spellings are the same just provides evidence to the judge that copying occurred.

If you just rename all the methods and their argument variables you still open yourselves up to a lawsuit because all the plaintiff is going to do is show the judge a mapping between their and your names and it will be plain as day as to what happened.

You do realize that if literally all you do is change the names and spellings then you'll still be in violation of copyright, right?

In general that is largely true. In the particular type of copyright being argued in this particular case Oracle has stated that changing the name or spelling of the methods would have been enough to avoid being in violation:

Using the district court's "java.lang.Math.max" example, Oracle explains that the developers could have called it any number of things, including "Math.maximum" or "Arith.larger." This was not a situation where Oracle was selecting among preordained names and phrases to create its packages. As the district court recognized, moreover, "the Android method and class names could have been different from the names of their counterparts in Java and still have worked."

> Oracle has stated that changing the name or spelling of the methods would have been enough to avoid being in violation:

“Oracle has stated” doesn't make it consistent with the law. Sure, the Supreme Court could create a new rule in this case which would make it true, but there is no existing legal rule I can ser that would make thesaurus substitution not infringement of something that was otherwise infringement.

You are misinterpreting that argument. To prove copyrightability, Oracle had to show that designing an API is a creative act and not a purely mechanical/functional one. That is the purpose of this argument: if the function would only work if named java.lang.Math.max and not work if named Math.maximum, then anyone describing the same concept would be forced to use the same name, so the name wouldn't be copyrightable. They are not stating that Google would have been in the clear if they had named it differently, they are just trying to show that Google could have named it differently without changing the meaning of the code one iota.

For example, someone writing a recipe for omelette has to say "2 eggs" simply because that's what omelette needs. You can't express it any other way, so it's not a creative act, so it can't be protected by copyright.

Designing an API is a creative act. An API is source code. Witness thousands of languages, all with recognizably different standard libraries, including languages like Go or Dart created by Google themselves. The problem is less with individual examples like "max" vs "maximum" or "write" vs "scribble", but more with thousands of packages, classes and methods, 99% of which have the exact names and structure as the Sun's Java ones. That is blatant theft. Google stole Java code from Sun. Shame on them.

What we need the law to do is to distinguish between copying a piece of code and using a piece of code. Just because I use your code doesn't mean you own my code too. What we need the software industry to understand is that relying on a proprietary library makes it impossible to cheaply switch your code to an alternative implementation without rewriting your own code. Alternatives exist: use software with an open license model, or shim out the proprietary library.

> The problem is less with individual examples like "max" vs "maximum" or "write" vs "scribble", but more with thousands of packages, classes and methods, 99% of which have the exact names and structure as the Sun's Java ones. That is blatant theft.

You know, it might be worth asking the engineer who wrote java.lang.Math how he came up with those names. Actually, you don't--he already answered it one of the amici briefs. The answer was that he took it from C.

In other words, taking Oracle's argument at face value means that the example API it is accusing Google of illegally copying is itself an illegal copy of the UNIX copyright, whoever actually owns that now.

Perhaps the Sun engineer did indeed copy from UNIX to some mild degree The line between "inspired from" and "copied from" is a fine line indeed. When does a term stop being proprietary and enter the vernacular of a specific profession or of humanity at large? I lean rather liberal on this question, and I hope the law will too. OTOH, what is blatant theft is for your 'original' work to overlap 99%, in both names and structure, to prior work. Google engaged in blatant theft, there is no doubt about it. We are not even talking about a derived work, we are talking about copying word for word a substantial part of somebody else's work.

Look up the names of the functions in java.lang.Math. They are exactly the names and semantics used in the libm functions. Even down to the presence of the atan2 function which computes tan¯¹(y / x).

(You could also point out that JavaScript literally lifts java.lang.Math and java.util.Date into JS code as well, down to Date.getYear returning the Gregorian year - 1900).

First, this is not a 99% blatant copy. I see things on the java side that are not in the libm side, like addExact, IEEEremainder or nextDown. I see things on the libm side that are not in the java package, like fpclassify, gamma or jN. I see things that have been adapted to match java conventions, like copySign vs copysign. The Jaccard similarity index appears to be pretty far from 1, whereas it is a perfect 1 in the case of Google. The perfect 1, up to keeping the 'java' in 'java.*', makes it a 'blatant theft' in the case of Google.

Second, unclear what the legal status of libm is. It appears to implement a standard, thus is legitimate to ask whether the set of implemented functions and their names are the original contribution of libm authors, or are derived from the standards. Generally, if one wants to implement a standard, one needs to acquire the rights to do so, usually in the form of a reasonable fee.

Third, if there are significant overlapping parts that are the creative work of libm authors, and they can establish a prior art claim, they are entitled to seek fair compensation from Sun / Oracle.

https://docs.oracle.com/javase/8/docs/api/java/lang/Math.htm...

https://sourceware.org/newlib/libm.html

PS. Re: atan2, wikipedia: 'The function atan2(y,x) first appeared in the programming language Fortran (in IBM's implementation FORTRAN-IV in 1961). It was originally intended to return a correct and unambiguous value for the angle θ in converting from cartesian coordinates (x, y) to polar coordinates (r, θ).' Perfect example of a term that arguably migrates into the common technical vocabulary over decades.

>I see things on the libm side that are not in the java package, like fpclassify, gamma or jN.

Which were added in C99, which postdates the initial release of Java.

Almost completely irrelevant side note: atan2 is immensely useful because it actually does more than calculate the arctangent. It handles all the corner cases in converting a 2d vector to an angle. There's no chance of division by zero, it gets the answer into the correct quadrant automatically, and so on. Those things add up to an annoying series of if statements if all you have is an arctangent function.

Java namespaces fall into the latter category, since there is an embedded graph of symbolic coordinates. The existence of Refactoring negates that it can be seen as an accidentally creative act.

Refactoring is somewhat similar to translation, and it similarly does nothing to affect the notion of copyright. A novel is copyright-able even though it can be mechanically translated into a different language.

The fact remains that APIs are creative works. This can also be seen from discussions about APIs in the industry - everyone knows that the Unix APIs are often seen as elegant while the Windows APIs are seen as ugly. The C++ people love the design of their iterators and algorithms and data structures and believe it is superior to Haskell's equivalents.

> everyone knows that the Unix APIs are often seen as elegant while the Windows APIs are seen as ugly

I think people consider the UNIX CLIs ("do one thing and do it well") to be elegant, not UNIX APIs. UNIX APIs have quite massive (and well-known) warts in them.

Sure, there is a lot of nuance - for example, the Unix CLI is very much seen as a kind of API, and appreciated mostly for API-level decisions (pipe-able commands, everything is a file, everything is text), not necessarily so much for CLI-level features (such as variable handling, looping etc.).

Also, some Unix OS APIs are much preferred over Windows alternatives - e.g. many people think fork()/exec() is much more elegant than CreateProcess(), same for pthreads vs the Windows threading model etc.

The bottom line though is that people have opinions about API design, it is clearly seen as a creative process, it is not rote technicality.

Oracle proposes a change for the sake of uniqueness, but uniqueness is not copyrightable. And if non-copyrightable change is all you can reasonably do, then there's little if any room for creativity. Also it's obvious `max` is not a creative, but a traditional name for such function, not to mention one can't copyright a common word in wide use.

There's no technical way to not copy the interface, especially method names, and imagine what happens when you implement an interface: it's copied verbatim.

> Google didn't copy any of Oracle/Sun's Java source code base into Android Java. Oracle lawyers acknowledge this.

That's not true, there were nine lines of source code (range check) copied verbatim, not counting the 11,500 lines of API declarations.

But the API declarations are source code, too.

> If Oracle ultimately wins, it seems like millions of programmers will have to reach for a thesaurus to find synonyms to name functions.

That really depends on how Oracle wins, and specifically what rule is articulated.

Folks realize some of the people at Google were actually previously on the Java team.

IIRC Judge Alsup (the original judge, and the only person in this whole shit-show who knows anything about programming) ruled against this, as he determined that there were only so many ways to write a range-checking function. He said it was entirely plausible that the Google developer would have come up with the exact same function independently.

Yeah, he did. Not common, but hey, Haskell is his middle name. (Really, it is.)

> IIRC Judge Alsup (the original judge, and the only person in this whole shit-show who knows anything about programming) ruled against this, as he determined that there were only so many ways to write a range-checking function.

No, it was found to be a copyright infringement in the first trial; it's one point on which Oracle sought to have the district court upheld and Google sought to have it overturned in the original set of appeals and cross-appeals. (While on many other issues they split the other way.)

> No, it was found to be a copyright infringement in the first trial

I believe GP is correct. The jury found it to be infringement, but then Alsup ruled it wasn't copyrightable in the first place, so the jury's finding was irrelevant.

edit: oops, sorry, didn't realize the rangeCheck scope of this subthread

> The jury found it to be infringement, but then Alsup ruled it wasn't copyrightable in the first place, so the jury's finding was irrelevant.

No, the final judgement in the first trial by Alsup found the APIs weren't copyrightable, but that the literal copying of rangeCheck and some other compiled files was infringement. (For which no damages were awarded, by stipulation of the parties, I think because everyone was planning to appeal everything and didn't really want to wait for damage calculations to get that ball rolling.)

It's a short ruling: http://www.groklaw.net/pdf3/OraGoogle-1211.pdf

I used to know a very bright chap who refused to use meaningful identifiers - his argument was mainly that you could never capture enough information in an identifier to be really accurate so you shouldn't even try.

Nice chap, but fortunately he was a school friend and not a colleague!

Maybe we should just use GUIDs for everything :-)

Hello, I'd like to talk to you about Urbit. Have you accepted Curtis Yarvin as your personal savior of your digital life?

You should check out Unison https://www.unisonweb.org/

The problem isn't that programmers will have to get more creative with naming, it's that it will be fundamentally impossible for pieces of software owned by different entities to communicate over shared names without an explicit license agreement. That's a much, much bigger deal.

It's not just the names, it's the structure as well. Oracle is implying that the structure (heirarchy) is also a signifier of the API. You can't actually get around that if you're trying to mirror an API but do a white room implementation of the underlying code. It would still be considered illegal if the SCOTUS decides for Oracle. You would still have to license or hope you didn't get found out.

I wonder how a meaningful discussion about namespace trees and API spelling takes place at the Supreme Court considering the background of the justices.

They're smart people and these are not hard concepts.

It still requires domain-specific knowledge and there are vested interests from both sides. I'm afraid because the world has little to gain and much to lose from the outcome of this case.

These people are experts at getting up to speed on diverse topics and have amazing teams clerking for them and a huge bench of experts to call on. I'm sure the domain-specific knowledge will be fine although the vested interests will clearly be a problem.

I have never been involved in a US Supreme Court case but back in 1999 or so I was asked to prep a barrister in the UK on the guts of TCP/IP. I literally jumped in a black cab at short notice with 6 or 7 volumes of W. Richard Stevens and spent an afternoon showing him and a few others from his chambers packet dumps and TCP state diagrams and drawing some diagrams of my own showing what a webserver, browser does, how caching works, etc. The next day using my information synthesized with some really archaic law about what is and isn't a document he issued his opinion about where particular actions occur (and therefore what legal jurisdictions apply) when someone does something on a website. It was extremely thoughtful and nuanced and literally a day earlier he didn't even know what a webpage was.

This doesn't really surprise me. I think it's a bit of an ego-condition that the tech industry believes because only tech people understand technology that only tech people should be allowed to set policy on it.

In reality, technology (and technology companies) mirror their predecessors in other industries. And often abuses of copyright or antitrust by tech companies really isn't much different than the actions of companies decades ago, just obscured by a layer of technology magic.

Especially since there's no actual "tech" in the discussion here. 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.

Of course they are smart people but they are also quite backwards when it comes to technology and I doubt they would take the time to learn the real differences between APIs, code, algorithm implementations vs theory, etc. They will probably try to use a car analogy in their final arguments and rulings.

as long as its not a horse..

Do you wonder the same for an abortion hearing or a sanitation case? The court system can and must decide regulations on many things they are not personally experts in, and usually does so quite successfully.

No, I don't because I'm not an expert in those fields. To be clear, I'm not suggesting that they can't understand the subject matter or that they need to be experts in it, I'm just curious about how much technical detail is communicated and how.

I would assume a great deal in what I imagine are the many expert witness reports that both sides have submitted.

The one I helped write an expert witness report for a technology-related case, there was quite a bit of technical detail in it (although it was written so as to be intelligible to a non-specialist).

The book analogy in the linked article is a good example of an interface and should be understandable without background.

The problem for Google is that "compilations" in copyright law may be considered copyrightable even if the underlying data being compiled is not. The legal requirement is that the data needs to be "selected, coordinated, or arranged in such a way that the resulting work as a whole constitutes an original work of authorship". (https://www.bitlaw.com/copyright/database.html)

As an example, individual recipes are generally not copyrightable, but if you compile a set of recipes and publish them in a cookbook, the cookbook itself would be copyrightable.

As applied to Java, even if individual method signatures like max/min/split/replace/delete/etc might not be copyrightable, the fact that you've organized those specific methods into specific classes named Math/String/File and then organized those classes into specific packages named java.lang and java.io might meet the threshold for copyrightability as a "compilation".

While it would likely not be good for the software industry for reasons discussed in this thread, I would not be particularly surprised if the court ruled in favor of Oracle on this particular subject.

Here's a good analogy for non-programers.

You're building a new car company.

You see all the existing cars, the roads, and the garages.

So you measure the width of the car and the garage and you decide that the car should be exactly 6' wide.

Then you ship your car. Enjoy 15 years of market success.

Then you find that Oracle created the first cars and says they have copyright on the width of your car.

That's how stupid this is...

I don't think that's a good analogy at all. A car's precise width is not part of its interface nor a part of its design anyone particularly cares about. Its interface is more like, the design of the UX... how the steering wheel, dashboard, etc. look and feel. If a company copied those but changed everything underneath so that people could buy a cheaper alternative without seeing a difference on their usage... I don't know, is that actually legal?

The car's width is absolutely its interface with respect to roadway interoperability.

We aren't talking about user interfaces here. This lawsuit does not involve UX. We are talking about interfaces between functional components. The analogy is spot on.

The interoperability width is already set by the road... you're copying the road at that point, not the car.

The lawsuit involves UX for a software framework. Which its API constitutes. The user happens to be a developer here and their usage is software development.

And this is why Google had to copy the interface -- otherwise their runtime would not operate with other existing products. As you can see given your example, the analogy is a perfect fit.

Your argument that the copying is once-removed is unfortunately irrelevant to copyright law.

You're saying a car that's 1 inch narrower somehow wouldn't fit the same roads?

What does "1 inch narrower" mean to you, in the context of this analogy? Are you suggesting the interfaces have different names? Different sized arguments?

None of those things would work.

Besides, creating minor differences do not solve this problem as they would still be derivative works.

> What does "1 inch narrower" mean to you, in the context of this analogy? Are you suggesting the interfaces have different names? Different sized arguments?

Your question is exactly my point. I'm suggesting what I said earlier:

>> I don't think that's a good analogy at all.

It sounds like the original analogy is apt, and your followup analogy isn't.

I wasn't the one who compared this with the width of a car and then got confused what a shorter width would even mean.

But sure, if you say so.

Program identifiers use exact matches. The analogy works fine understanding this context.

It's possible to extend any analogy in a way that doesn't make sense, which is what you've done.

It seems like your complaint may be that you simply don't like, or perhaps don't understand, analogies in general.

> A car's width is not its interface.

Let's improve the analogy!

My proposal => that you chose to make the door handles six inches because of UX, and Oracle showed up and said they made theirs six inches before you did.

You can't seriously suggest copying the width of 1 door handle is equivalent to copying all of the Java API, right? I don't think if Google provided an alternative for 1 function it would be in this lawsuit. Your analogy is just a tiny portion of the alternative I already portrayed: they copied the entire structure of the framework. Copy 1 door handle, 1 steering wheel, 1 precise dashboard design, 1 glove compartment, etc. and I feel your analogy would result in a lawsuit just the same?

(For reference none of this is meant to reflect my position on what the law actually is, or should be. I'm just considering analogies here.)

The issue is that in engineering there are certain patterns of implementation that are simply converged on.

Upholding the API copyright would be like giving Craftsman grounds to sue Ryobi for manufacturing circular saws because Ryobi combined a power cord, an electrical motor, a toothed circular blade and a housing; a state of affairs that only seems even remotely plausible to endorse because source code is inherently a read product.

You look at it and see an authored work. I look at it and I see an n-dimensional turing-space relationship diagram as expressed through transform functions.

And last I checked, you could patent some math(RSA), but not not copyright it. Eventually it's just prior art.

What if Google copied the name of Oracle's car and stamped it on the back? What if Google also copied the name of the in-car entertainment system and put all the buttons in the same place and stamped the same name on the dash? What if the shape of the car was exactly the same, and was only available in the exact same colors as Oracle's car? What if Google opened a car dealership next door to every single Oracle dealership with giant signs that said their cars are effectively interchangeable?

That's how stupid car analogies are...

There will likely be no such thing as "drop-in" replacement anymore either.

Or it will create api compatibility layers (shims).

Wouldn't the compatibility layer be infringing copyright?

This is where I think a lot of people are talking past this case. If you use the API surface area for the purposes of interoperability with existing software then you're covered and it's not infringement.

If you use the API surface area for your own software because you like the design, copying it is easier than coming up with something new, or you want to provide a familiar programming environment to developers then you're looking at infringing.

> If you use the API surface area for the purposes of interoperability with existing software

But wasn't that one of Google's original goals for Android? Making porting existing Java apps easy?

Google is making this case, we'll see if the judges buy it. Just because porting Java apps to Android is easier because Google copied the API doesn't suddenly absolve them when it's Google's intention that will decide this case.

> when it's Google's intention that will decide this case.

Why do you presuppose to know the legal rule that the Supreme Court will articulate in its decision? I mean, you seem to presuppose that the Court will uphold the Federal Circuit on all contested questions of law and only reconsider whether the decision on the facts is reasonable, which is...mighty presumptuous.

It's quite conceivable that Google could win on a more fundamental ground, since the question of whether the API is even protected by copyright or unprotected as a functional element (which also does not turn on Google’s intent) is a love issue in the appeal. They win on that, and the Court doesn't have to touch anything else.

Even if they do need to address the fair use question because Google loses on copyright ability, the Court a lot will turn on the standard of review and the Seventh Amendment as to whether the Court is really probing Google's intent (de novo review) or merely probing whether any reasonable jury could have concluded that the use was fair, as the actual trial jury did here, preserving the right to jury trial. I would expect the latter, the Federal Circuit seems to have gone completely off the rails invoking de novo review to overturn the jury verdict.

That seems to be what a lot of legal folks are speculating. That an 8-person court will find essentially technical legal reasons to overturn the appeal and essentially punt on making a major copyright ruling one way or the other.

A ruling overturning the CAFC on the basis that fair use is a fact issue for the jury not subject to de novo review on appeal would still be a major (though not transformative, since outside of the CAFC in this case that seems to be how it has historically been treated) copyright decision.

> If you use the API surface area for the purposes of interoperability with existing software then you're covered and it's not infringement.

Google did that: for compatibility with existing Java tooling, which is software.

Sure, Java apps aren't, unmodified, compatible with Android, but the compatibility makes tooling and intermediate libraries compatible, which is a functional, interoperability concern.

Google tried to argue for fair use under the idea of interoperability, but the (few) intentional differences from Java that prevent most Java programs from running unmodified on Android pretty much bombed that case...

Note that Google won both the jury trials (first on not violating copyright, and then on the violation being fair use after the first was overturned on CAFC).

In other words, Google won on most or all of its arguments at the jury trial level, and CAFC kept overturning all of its arguments. The sentiment I'm getting from the oral arguments is that SCOTUS is leaning much more towards "CAFC is off its rocker" here.

Wait, you have access to the oral arguments? Source?

Oral arguments are happening via teleconference as a result of coronavirus, so they've been streamed live by C-SPAN.

You can find the replay here: https://www.c-span.org/video/?469263-1/google-v-oracle-ameri...

> Wait, you have access to the oral arguments?

Don't need oral arguments for the results of the first trial and the arguments filed in the appeal of that first trial.

Here's the final judgement from the first trial: http://www.groklaw.net/pdf3/OraGoogle-1211.pdf

Note on the second page:

> With respect to Oracle’s claim for relief for copyright infringement, judgment is entered in favor of Google and against Oracle except as follows: the rangeCheck code in TimSort.java and ComparableTimSort.java, and the eight decompiled files (seven “Impl.java” files and one “ACL” file),

And here's Oracle’s reply brief in the appeal; the relevant part on this issue is under the heading THERE IS NO “DE MINIMIS” DEFENSE TO COPYRIGHT INFRINGEMENT.

http://www.groklaw.net/pdf4/OraGoogleAppeal-134.pdf

Distinction without a difference. My code is an interoperability layer between making a computer do a particular computation and other developers or composers of software.

Looking at an API and going "you could do this any other way than ours" is absolutely nothing more than a fundamental deconstruction of the entire field, at which point it's just Math. You're wasting everyone else's time. No one gets to copyright 2+2.

I'm not shoving in 3 API layers to represent "Math.max()".

No, it isn't providing api, merely using api (but providing it's own api). If using an api was copyrightable, our civilzation would collapse.

And how will you use that API? If it is based on things like headers, you can no longer have a copy of that header to refer against. The compiler can no longer read that header into memory, as that's a copy.

The use of an API will be copyrightable too. Now you understand the depths of the disaster this will be.

This is a legal apocalypse for software.

> Google didn't copy any of Oracle/Sun's Java source code base into Android Java. Oracle lawyers acknowledge this.

You're saying the textual contents of the interfaces that define the APIs are not part of the source code base? Of course Google copied them, or a nearly identical paraphrase of them.

I'm not quite sure what Google's legal theory is. Listening to the oral arguments this morning certainly didn't make that more clear to me. But I don't think it includes redefining what we mean by copying text.

And interfaces, in common parlance, are certainly lines of code.

Nor do I think Oracle's argument is that no one else can define interfaces that use the same words as in the Java standard library interfaces. read, write, get, put, etc. did not become Oracle's property by virtue of them being used as method names.

I have a bit of trouble with the concept "the threshhold of too much", too, as it applies to this case. Google copied or paraphrased essentially _all_ of the text of interfaces they used from Java libraries.

> You're saying the textual contents of the interfaces that define the APIs are not part of the source code base? Of course Google copied them, or a nearly identical paraphrase of them.

Well, they aren't part of the implementation, since they just describe the interface. Google's theory is that interfaces, being needed for interoperability, are not protected by copyright. Google's alternate theory is that, even if they are protected by copyright, using them is fair use.

>I have a bit of trouble with the concept "the threshhold of too much", too, as it applies to this case. Google copied or paraphrased essentially _all_ of the text of interfaces they used from Java libraries

Oracle is trying to argue that just because you intentionally left a bunch of implementation detail out because it isn't relevant toward transforming something like the Java API's to a new context, it should still count as copyright infringement because they Still yoinked everything they did take... Which seems circular to me.

Google's point is "no shit, Sherlock, it wouldn't be Java otherwise." Oracle is couching this issue from the perspective that Google should have invented a completely New language and runtime, absorbing the same costs of them doing so. Google argues, on the other hand, that what they made, in order to confer to the syntactic structure of the programming language known as Java, dictates the duplication of the organization of the fundamental functions, packages, and namespaces, and that furthermore, Oracle has no standing to call them on it, because those APIs are a necessary prerequite to drive the operation of the JVM, and are by definition the only way to do it, so that API constitutes a method of operation.

Oracle's argument isn't legally circular or anything like that. It's actually very strong, which is why it's problematic: the industry status-quo consensus that you can't copyright APIs has no obvious basis in copyright law beyond the notion that you can't copyright "facts".

Is an API a collection of facts? I would hate to be a lawyer tasked with arguing this one in front of the Supremes. Programmers sweat bullets over API design, an API is very obviously not a mere collection of facts, it's a creative work. Copyright law protects creative works. Hence, Google's problem.

An API is not a mere collection of names either. The Java API is defined by the specification, which is contained in the JavaDocs. Thread safety rules, when callbacks are invoked, what sub-types can be passed into a parameter, all these are a part of the API as well. Strip out the source code of the methods but leave the types, prototypes and JavaDocs and you have the Java API - it's been done and the result is still huge.

Google's point is essentially one of convenience; the industry has never recognised APIs as copyrightable before and shouldn't now. This is not a legal argument at all so I am mostly expecting Oracle to give them a solid thrashing, because the SC is meant to interpret existing law, not simply agree to whatever one of the parties thinks the law should be. And other than declaring API reimplementation to be fair use, there's no obvious legal escape route to make APIs non-protected.

It's thus interesting to consider what happens if or when Oracle win. In the short run a lot of disruption, especially to projects like Wine and maybe WSL.

In the long run it's harder to say. Something unprotectable would have become protectable. We might see, for example, the birth of companies that specialise in nothing except API design. Today such a company would be unviable because there'd be no way to protect or own the results. You can imagine that this would occur in the same way that specialised agencies do graphics design, translation, logo design, API implementations, etc. This might lead to higher quality APIs across the industry: a difficult to anticipate side effect of expanding IP protection. It would also presumably reduce competition as it became even harder to compete with lockin via reimplementation of APIs. However, doing that is relatively rare today. I can't say for sure that the (small) loss of plug-compatible competing implementations of products would be worse than a hypothetical increase in API quality from allowing specialisation in it.

>In the long run it's harder to say.

The easiest solution if the software industry wants to preserve the status quo is to just lobby Congress to amend the laws to explicitly distinguish interfaces from implementations.

No where in the copyright statute does it explicitly call out a software API as being copyrightable. The representation of one may be, but not the API itself extending copyright protection to APIs now is nothing less than legislating from the bench. It should be a legislative decision, not a judicial one.

> If Oracle ultimately wins, it seems like millions of programmers will have to reach for a thesaurus to find synonyms to name functions.

I think you are a bit off the mark on this line. (mostly agree with the rest of your post)

Google's goal was to make a white-room implementation of java that was 100% api compatible. This was explicitly to avoid licensing Java while still being Java compatible.

I don't think this is true. Google doesn't let you run java that was compiled for the JVM. They have an entirely different mechanism that is not the jvm for their java code to compile to.

All they did was port the language to a new compile target. When you port a language over you also port the standard library or at least the parts that you need. This is standard across the industry. Every language implementation does it. What Oracle is trying to say is that you need a license to do it and that is a dramatic change in the industry practice right now.

It's also short sighted. If Oracle wins then you'll need a license to implement java the language (as opposed to the JVM) anywhere. Short term Oracle get's a pile of money. Long term everyone stops using Java. But then again if you are Oracle, with it's current values, Java's only real value is short term money gains. It's hard to make money on a programming language the way Oracle prefers to operate so this may be the best they can do.

Assuming Oracle wins, could the people at WG21 sue anyone who implemented C++? They wouldn’t as they work on the compilers, but I’m asking in theory.

Or better yet let's not talk about the people at WG21, but instead their employers (and whoever acquires their employers in the future) and what is in those employees' contracts about IP they create that is owned by those companies.

Let's compare this to a completely different field: cookbooks.

Recipes themselves aren't copyright protected. However, specific instructions for the recipes are protected.

In addition, though individual recipes aren't protected, a collection of recipes is protected.

There is a line, though, between copying a few recipes, and an entire collection. That line is not easy to define, but that doesn't preclude the existence of such a line.

So – is an API considered a single recipe? Or is it a "recipe collection?" That seems to me to be an important distinction.

If you were to copy one set of API function names that cover a limited area, then it could be argued that you used just one "recipe" and that it would be OK. However, if an entire collection of API function names across a very broad range of categories was copied, then it is harder to argue that you didn't copy any entire collection, and not just an individual recipe.

It's always the case that if Oracle wins we lose.

I think if Oracle wins, what really needs to happen is we need to begin lobbying congress to explicitly exclude APIs from copyright protection. I think that this could definitely work, particularly since so much software relies on APIs not being copyrighted.

Or we could have companies Oracle copied sue them. For example: IBM for SQL.

Nitpick: initially Windows implemented Microsoft.XMLHTTP ActiveX controll, then Mozilla implemented XMLHTTPRequest

Not if you marry a good lawyer. Just a tip.

Just hope you never have to divorce them.

Not if you marry another lawyer.

Generally speaking, you have to divorce the first one before you marry the second.

Not if they are marriages in separate jurisdictions.

Unless the first marriage is viewed as invalid in the second jurisdiction (which simply occurring in another jurisdiction usually won't do), or the second jurisdiction allows polygamy (in which case, it doesn't need to be a separate jurisdiction, anyway), that generally is insufficient.

Or the companies that the developers work for pay the original creator of the API, which is the solution Oracle are angling for.

If the original creator is willing to license them at all.

It might also be worth mentioning that this case is first and foremost a big money power play (arguably even with abuse of the legal system), between two immensely powerful businesses (each of which probably deserve to be called a criminal enterprises, but hey .. this is America), and very little about the merit of their respective arguments.

In other words: both primary care about winning the case. No matter how they get it done, or whatever the fallout/consequences will be for anyone but themselves. Arguably that is fine for any company, since their sole responsibility is to look after itself. But the legal ramifications of their (legal) actions can extend far beyond that, for which I certainly consider them and the US legal system responsible, collectively.

I sincerely wonder sometimes, that besides the potential damage many do recognize as a fallout of this court case, how many people realize that mud fight between two way-too-powerful sandbox bullies may end up being responsible for making the USA a pariah within the landscape of future software development?

Or does everyone believe that if this goes sideways, that the rest of the world will just respect this "funny logic" and all go with it?

In fact, how many Americans even realize that the increasing radicalization and absurdity of their intellectual property rules will inevitably harm the USA big time in the long run? Or does everyone still think that the USA will remain the center of everything and the only one dictating the rules?

Things like these do not happen in a vacuum. The rest of the world is watching.

Reply on news.ycombinator.com