Hacker News new | past | comments | ask | show | jobs | submit login
Google: Oracle Java win will kill software development, so SCOTUS must rule (zdnet.com)
65 points by rbanffy on Jan 29, 2019 | hide | past | favorite | 76 comments

So here's a question: supposing APIs become copyrightable, doesn't that imply there also must be a way to license API implementations, including issuing free and open licenses?

So although the idea of copyrighting an API strikes me as generally stupid and it could clearly be problematic for some developers in the short term, surely this isn't really that much of a hassle in the long term? People will just explicitly state whether or not they want to allow others to implement their API?

I don't really consider that an improvement, but neither does it seem all that disastrous.

I'm also curious how this will affect the geography of software development. Since the SCOTUS' jurisdiction only covers the US but there are international copyright treaties, will this decision affect development outside the US?

In theory, the market will adapt to track this layer of copyright, but the short-term shock effect is large. Since nobody's assumed APIs are copyrightable 'til now, nobody's been keeping track. So every API currently in use is under threat (especially since in the US, you don't have to file a copyright claim to have copyright; if you can just prove your API came first and there's reason to believe the younger API was familiar with your own, you can claim statutory damages, IIUC).

It'll be exciting to see how many of Oracle's APIs are 100% derivative of some software released under Copyleft licenses... ;)

As APIs (at least those the court ruled on) are code, it appears they are licensed along with the rest of the code. Java's APIs would, therefore, be dually licensed under either a commercial license or an open-source license (Android originally complied with neither; I believe it now complies with the open-source license).

The thing if that API compatibility is huge when it comes to migrating from one service to another. If an open source project can't reimplement an API then it means that it's way harder to migrate from a proprietary solution to an open one.

The problems will come when it is claimed that some other thing is really just an API, and also subject to this ruling.

Is public inheritance and interface implementation no longer allowed in Java? I can think of several ways to duplicate parts of the Java API. I don’t see how courts will draw a legal distinction.

IANAL, but there are several things going on:

> The problems will come when it is claimed that some other thing is really just an API, and also subject to this ruling.

This is not so simple. The court ruled only about a particular case that concerns an API under the "traditional" definition (the only thing we used to call API until not long ago) -- an API that is actual code -- and not other things that some are calling APIs, such as protocols (so-called REST "APIs"). One cannot simply claim that the ruling applies to other kinds of things, like protocols, regardless of whether programmers think they are similar or even "essentially the same." For example, in the US programs are protected by copyright but not patents while algorithms are protected by patents but not copyright. I imagine that at least part of the reason for this distinction can be found here: https://www.law.cornell.edu/uscode/text/17/102

(a) Copyright protection subsists... in original works of authorship fixed in any tangible medium of expression...

(b) In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.

A program (and an API) are some text "fixed in a tangible medium of expression" while an algorithm (and a protocol) are an idea described in some text (although the description text itself may be copyrighted; an algorithm book, including the pseudocode of the algorithms, is copyrighted, but the algorithms themselves are not). Ideas can be covered by patents, not copyright.

> Is public inheritance and interface implementation no longer allowed in Java?

Leaving aside the fact that Java is 100% open source and the license explicitly allows this kind of use (and in a non-viral way thanks to "the classpath exception")[1], your question is similar to, if a recording is copyrighted, is listening to it no longer allowed? One can make fair use of copyrighted works. This would not only apply to subtyping or calling APIs, which, like listening to music, is obviously their intended use but even -- and this is implied in the discussed ruling -- copying them and implementing them in order to enable third-party interoperability (the court ruled that in this particular case Google did not make fair use of the APIs[2])

[1]: http://openjdk.java.net/legal/gplv2+ce.html

[2]: https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google...

> This is not so simple. The court ruled only about a particular case...

But this case would be a very significant precedent...

This seems dangerous to anyone reverse engineering an API to, say, port it to another language or runtime. Is the Win32 API copyrighted? If so, is the ReactOS project in danger? Is Haiku?

First, porting to another platform may well fall under fair use: https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google...

Second, companies don't sue you just to make a point or to show they're right; success is never guaranteed, and corporate lawsuits are expensive -- not only in direct monetary cost but in PR costs as well. Companies use lawsuits when there's actual serious damage done to them which they want to recuperate, or to prevent such imminent danger of serious damage.

If you cause serious damage you should expect to be sued regardless of whether you did something wrong or not, and even if you do something wrong but don't cause serious damage, chances of a lawsuit are low[1]. So while certain things may certainly increase your exposure, what puts you in danger is the harm you do more than the rules you break.

Projects that mimic or port the Windows API would be in danger -- whether now or before the lawsuit under discussion -- when they can cause serious damage to MS.

[1]: This may be different for trademark violations; I think trademarks require vigilant defense or they could be lost.


This case has been going on so long it's funny to think about how differently I used to perceive both Oracle and Google back when it started.

I was thinking the same thing. At the time Google was the unsung hero defending our rights. Now Google won't let you subscribe to podcasts in their app unless you turn on location history storage, like those two things are actually mutually exclusive.

It's unbelievable that Oracle is still pursuing this, despite the obvious consequences _for its own survival_. Their main product copied APIs and even the SQL language itself.

Their main product copied APIs and even the SQL language itself.

This is a really interesting point. Presumably IBM owns the copyright on SQL ("SEQUEL"); is there anything that prevents them from suing Oracle (and everyone else) for royalties?

In this case Oracle should hand over 90% of all profits since 1979 to IBM...

That'd be fun, wouldn't it?

Oracle probably has a good couple parents that are absolutely essential to IBM or that would have already happened. MAD works.

> Now Google won't let you subscribe to podcasts in their app unless you turn on location history storage, like those two things are actually mutually exclusive.

Have they made any statement on why that? I don't use their podcast app, but that's particularly egregious.

I've seen similar stuff with Android Auto/Google Assistant requiring Web & Location History; but I gave them a bit more benefit of the doubt because that data could be used for needed context to answer voice queries, and I could see them not wanting to create special cases that did not use those permissions for business reasons.

Do you have an android phone? It would literally take you 1m30s to verify this.

> At the time Google was the unsung hero defending our rights. Now Google won't let you subscribe to podcasts in their app unless you turn on location history storage, like those two things are actually mutually exclusive.

Okay, so you don't like how their podcast app works, but how does this violate your rights?

Quick question: what is their podcasting app?

I use BeyondPod, so I wasn't aware Google had any offering in this space.

You can subscribe to podcasts with Google Play Music:


They also apparently have a standalone podcast app:


I see google doing the same thing twice. Now... which one do I gamble won't reach EOL first.

They actually had an app way back called Google Listen, which was EOL'd...


Google play music has podcasts as well.

Sorry, what? Oracle is still on another deeper level of hell than any other major software company.

Anyone else irked by the keyboard shortcut analogy Google's lawyers keep using? It clearly didn't help them last time they used it. I think if I was a judge I would feel … insulted by such an obvious oversimplification. And the result is both vaccuous and debatable. Keyboard shortcuts aren't perfectly consistent, many people don't actually use them very much anyway, and many more people wouldn't care if they were different between different "computers" (?!) because they only use one and feel lost in the other kinds anyway. Surely Google's team of lawyers, in the space of nine years, can find a better source for analogies here…

The evidence suggests that they can’t come up with a better analogy. Perhaps there are legal principles at play that prevent them from using something seemingly better. They are smart people. I think a better a question or observation would be, “What prevents them from using X as an analogy?”. Or maybe the case isn’t so clear cut in favor of Google that its lawyers have to traverse a minefield of legal traps and this is the best they can come up with.

How many SCOTUS judges have a technical background? Zero.

How many have used copy and paste? Hopefully all of them.

If Oracle wins, it will just solidify my resolve to never use proprietary languages, EVER.

Unfortunately, the scope of the case is broader than proprietary languages. It doesn't matter what language you use---if you copy an API (including, IANAL-but-I-assume, recapitulating that API in an entirely different language), you're at risk. This covers a plethora of use-cases.

Can anyone elaborate how this could impact tools such as GNU Octave? It would fall under this classification, right?

I would like to know if it impacts mathematics and scientific libraries for python that I use in lieu of MatLab.

if Octave shares a bunch of function signatures with MATLAB, yes, it would be at risk for a copyright claim.

what about instruction "signatures"? i.e. the machine instruction sets? every compiler is potentially performing millions of counts of copyright and or license violations on a large scale?

I suspect that the implementation of any API would come under the shadow of this ruling. For instance, replacing a proprietary product with an open-source variant that has the same API would also be illegal or subject to licensing fees.

In my opinion, this will be bigger than proprietary languages and cover drop-in replacements for pretty much any proprietary code, thus providing yet another way to lock customers into a particular product.

Yeah, using an ISO standard language (https://en.wikipedia.org/wiki/Category:Programming_languages...) avoids this problem. There a spec is specifically produced so that there can be multiple implementations.

But regardless of what language you use, this legal precedent is saying if you, for example, copy Twitter's RESTful API to create your own messaging service where all the existing Twitter clients can change a few constants and adopt you as a target, Twitter could sue. That's not something ISO protects against (unless there's an international standard for asymmetric message services you can design against).

What is a proprietary language to you? Java? Then you will have a hard time using many languages since it is open source and copyrighted by its owner like many languages.

A proprietary language in this context is one that does not have an ISO standard.

Luckily, Java is fully open source now, with OpenJDK. I concur though with never using proprietary languages (which is a part of me not using C#--of course, that is now also open source, but C# is still kinda bad on Linux afaik).

Edit: _sigh_ The downvotes without any reason hurt. See [1]. Since OpenJDK is GPL v2, and since TCK tests have been open sourced and Java EE given to Eclipse, I would call the Java ecosystem fully open source. Feel free to correct me if I'm wrong of course.

[1] https://openjdk.java.net/legal/gplv2+ce.html

OpenJDK is an open source implementation of the Java API. However the question here is about the openness of the Java API itself, not any particular implementation of it. Google already uses a totally separate implementation which is different from both Oracle Java AND OpenJDK.

Does that make Java/OpenJDK any less open source? If I take OpenJDK and start selling it, how could Oracle get me if OpenJDK is GPL?

We're not talking about re-implementing the JDK/JRE spec; the author mentioned he/she wants to use only open source languages...

This is similar to what AWS recently did with providing MongoDB interface with its DocumentDB offering.

If Oracle wins, it logically goes then AWS would not be allowed to provide MongoDB interface to DocumentDB.

If I think back in time, Java was just reference implementation of the API. Sun JDK VM being one implementation of it, OpenJDK being the other. By that extension, Google wrote its own VM for it, that worked on mobile phone OS.

ironically, I remember AWS ramblings that providing s3 compatible api was violation of amazon IP rights.

Let's say Oracle gets everything they want. What impact would this have on the legality of certain programming practices in commercial settings like inheritance and the wrapper pattern?

Google should just do what Microsoft did with dotnet. Fork their Java projects, change method names from lowercase to uppercase then give it a new name.

Better yet, why not adopt .NET as the runtime for Android? :)

Because Microsoft is just as eager as Oracle to extract whatever money they can through patents that they hold.

Microsoft has issued a legally-binding promise to not assert .NET patents against standards-compliant .NET framework implementations.

See: https://raw.githubusercontent.com/dotnet/corefx/master/PATEN...

Oh, sorry. I guess I've woken up in a magical parallel universe where Microsoft didn't just spend the better part of the past decade extracting billions of dollars every year from Android phone manufacturers.

... and thus out of the ashes rose Rust lang...

As someone who has recently tried Rust and uses Java in his day job, why do you think that Rust is the obvious successor? Wouldn't C# be a better fit for people looking to leave Java?

I agree that C# would be a better fit. In terms of this ruling, I don't think the language really matters. Re-implementing any API that is copyrighted will be a problem no matter what the language.

In terms of re-implementing the language, I believe that C# is just as free as Rust in this regard; it can be done without fear of a lawsuit.


Java was also unique in that Sun was only charging licensing fees for mobile implementations, providing motivation for Google to build their own implementation of the language. With mobile devices being as high powered as they are, I don't think that model makes sense anymore.

A. It was a joke.

B. What about Scala? Would you say Scala is a "good fit" for people leaving Java because it's also built on top of the JVM? Or would it be a "bad fit" because the idioms and functional-nature of Scala are vastly different than Java? Or how about Kotlin?

I'm not thinking about "successor" in terms of "Java-specific" design patterns. I'm thinking successor in terms of - can Rust, with concurrency as a first-class-citizen and C-like perf with a safer programming model, replace Java for many of the "higher-level" applications that would've typically been written in Java?

Ya. Rust is for C++ refuges.

A Java programmer would be so confused by Rust.

I really hate this view of the world. I'm a developer, not a "C++ developer" or a "Java developer". I write code in C++, Java, C#, Python, Matlab, Rust, and other languages.

My current project has me working primarily in a mix of C++ and Java, and I would love nothing more than to rewrite the whole thing in Rust. Sadly, I did my job too well the first time around, and it's hard to justify a full rewrite of a codebase that already works.

Precisely. In this world view, A Java programmer would also be confused with Scala, which is a JVM language.

(Or I guess you could write Scala in a non-functional, Java-y way, but that would defeat the purpose of using Scala...).

Google starting to hit the presses about this probably means they realize they are fucked. This is an attempt to steer public opinion in their favor in order to influence either the outcome or start the discussion about mitigation for the expected outcome.

I don’t know how they could steer the relevant public opinion any more in their favor--is there anyone in the industry who doesn’t work in Oracle’s exec suite who thinks this is anything but an incredibly stupid and destructive precedent?

That's entirely possible, but it's also not super-great if this precedent stands. APIs have generally been understood to be a tool for communicating between layers, not a work of art that are themselves copyrightable and proprietary. It throws sand in the gears of cross-system integration if a company can get you on their copyright ownership of an API (especially since in the US, copyright is assumed and one is not required to file formally for it).

I like open source, and I don't like how patents and proprietary software has made the life of the developer difficult, but to be fully honest I don't like java either, I would really prefer to see languages like C++ thrive instead of java, especially today with the new iterations of C++.

I just don't understand what makes java more appealing than C++. I guess the garbage collector? I just wish python was just in the same league of performance of java...

You realize the ruling on this case would affect everybody using every programming language, and not just Java?

fully virtual (C++'s being mixed is a blessing and a curse), portable (C/C++ depends on architecture details) high performance compared to other high level languages - with less of C++'s complexity arising from "you don't pay for what you don't use", standard packaging (JARs, WARs or maven-like stuff) + standard compiler, relatively standard options for building, a broad set of largely compatible application servers.

It's the fastest and most mature platform for its level of complexity around (namely, less than C++), C# is a close and viable second and outshines it in some ways - and can be thought of as a descendant in some ways, if you squint a little bit (of Microsoft Java).

> Google positions a decision in favor of Oracle as a disaster for all developers.

That's a bit of hyperbole, because it requires a company to sacrifice developer good will (if it has any, unlike Oracle) to claim ownership/copying.

Also, where they reasonably can, people need to stop building on tech owned by companies they despise. Of course this is not reasonable in many cases, but for me, I won't use Graal and will actively tell others not to because it's easy not to. I don't have a problem w/ Google or FB like many others on here, but if you did, not using Go or React is probably unreasonable, but not using Google Cloud might be reasonable.

Also, we need to start holding privileged developers accountable for their chosen employer. I'm not talking about the underprivileged intern, I'm talking about the Oracle engineer that continues to work there at this time. If it's on your resume of late, I won't hire you. I also might not accept your PR if you are employed there.

> If it's on your resume of late, I won't hire you.

Then they can't leave. I'm not sure that's what you want.

> Then they can't leave. I'm not sure that's what you want.

It is, my statement is about industry-wide stigma henceforth, not specific literal effects on existing employees.

I'm not sure how your clarification addresses MBlume's concern.

A mass culture of "If you have X on your resume, I won't hire you" puts pressure on people who have X to stay in the space where X is true rather than try to exit it. It could put pressure on incoming software engineers to not join X, but if X's perks are good enough, will it? I'm reminded of the fact that undocumented immigrants in the US rose after the beginnings of tightened border security during the "war on drugs"---if the flow back and forth is easy, people flow back and forth. But if the flow is blocked, people will tend to stay where they are (or, worse, migrate to where the perks are better...).

Sorry, I was unclear and didn't address the concern specifically. I meant it is still overall what I would want even with that downside. Granted I recognize that there will likely be no observable effect to such a limited, hard-line stance on these principles, but that's the case with many other principled choices too. I wouldn't suggest it if it was hard or unreasonable.

GraalVM is Open Source and licensed under the same license as OpenJDK: https://github.com/oracle/graal

It is true that GraalVM has a proprietary version too, that AFAIK has extra features, but the open source version is impressive on its own.

What developers really need to do is to stop building on platforms based on how much they like a company. Stop treating companies like sports teams. Your feelings for a company are completely irrelevant because its culture can always change, or it can be sold to the highest bidder.

Things that matter much more:

1. Is it Open Source? This is important for having control. E.g. no matter what Oracle does next, there is now a community dedicated to maintaining and improving OpenJDK and in fact OpenJDK has cool features that Oracle’s Java does not, like a cool new low latency GC contributed by Red Hat.

2. Does it have an ecosystem around it?

GraalVM is new, but it piggybacks on Java’s ecosystem and Java is huge. In fact that’s also why Google piggybacked on Java too.

Speaking of which, I’m not defending Oracle’s lawsuit, I think they did it because they are greedy bastards, however the elephant in the room is that Google fragmented the Java ecosystem.

It is 2019 and Android’s SDK still does not support Java 8’s bytecode.

So how is Google any more special than Microsoft and what they did with Java (J++) back in the day? I don’t see a difference. And now the Java ecosystem can’t move on to Java 8 due to Android.

We have a huge double standard. Back in the day when Sun sued Microsoft people cheered for Sun.

> If it's on your resume of late, I won't hire you.

Thank you for saving good employees from a bad boss.

> good employees

An assumption at best. Those of us that have the leverage to choose our employers can be judged by that choice.

That's ridiculous self-serving high-horse grade-a bullshit. You've chosen a single feature among countless other's and decided to give it disproportional weight and treat it as a perfect predictor.

> You've chosen a single feature among countless other's and decided to give it disproportional weight and treat it as a perfect predictor.

Not true. It's not a predictor of anything and I never claimed it was. I said that is a feature that is a disqualifier, especially in the current market of employer/employee choice. There are many other features like this too, including the attitude presented by your comment.

Please relinquish any power you hold over other humans.

>If it's on your resume of late, I won't hire you. I also might not accept your PR if you are employed there.

And who told you these (or any other) people are looking forward to be hired by you?

How about we attach an "industry wide stigma" (sic) on you for proposing something so inane and inconsiderate?

Maybe if you get fired under such pressure on your employer and can't find a job you'd reconsider how nice "blacklisting" of the type you propose is?

> I also might not accept your PR if you are employed there.

That's a little ridiculous.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact