Hacker News new | past | comments | ask | show | jobs | submit login
Google’s copying of the Java SE API was fair use [pdf] (supremecourt.gov)
4103 points by pdoconnell on April 5, 2021 | hide | past | favorite | 932 comments



Threads are paginated for performance reasons (yes we're working on it), so to see the rest of the comments you need to click More at the bottom of the page, or like this:

https://news.ycombinator.com/item?id=26699106&p=2

https://news.ycombinator.com/item?id=26699106&p=3

(If you've already seen a bunch of these, I apologize for the annoying repetition.)


While the result is a big relief, I think it's not as decisive as I'm noticing some headlines (and commenters) are claiming.

One of the big open questions is "are APIs copyrightable?" The court skirted that question, and instead focused on whether it was fair use:

> To decide no more than is necessary to resolve this case, the Court assumes for argument’s sake that the copied lines can be copyrighted, and focuses on whether Google’s use of those lines was a “fair use.”

That said, this case does establish a precedent that if your copying of an API is primarily for purposes of matching an interface so that developers can reimplement it, you're in fair use territory:

> Google copied these lines not because of their creativity or beauty but because they would allow programmers to bring their skills to a new smartphone computing environment.

I'll count that as a win, on balance.


While the result is a big relief, I think it's not as decisive as I'm noticing some headlines (and commenters) are claiming.

It is even less decisive than you're saying.

The fact that the Supreme Court decided not to overturn the decision of the Court of Appeals for the Federal Circuit that APIs are copyrightable means that binding precedent on every court except the Supreme is that they are. And for fair use, one of the statutory factors is the "effect" of the copying on the "market for or value of the copyrighted work."

That said, this case does establish a precedent that if your copying of an API is primarily for purposes of matching an interface so that developers can reimplement it, you're in fair use territory:

The fact that one statutory factor points one way doesn't stop another from pointing the other. And part of their decision is the conclusion that Google's copying increased the value of Java. That will generally not be true when APIs get copied.

In particular if I am trying to create a product that competes with yours, and I copy your API for the purpose of interoperability, I'm going to have an uphill battle claiming fair use. Because my product directly reduces the market for your product.

To name some historically important examples, Microsoft copied the APIs for JavaScript from Netscape, Microsoft copied APIs from Lotus 1-2-3 for Excel, and Wine copied APIs from Windows for Linux. The outcomes famously were that Netscape went out of business, Lotus 1-2-3 was discontinued, and Linux became somewhat more viable.


> The fact that the Supreme Court decided not to overturn the decision of the Court of Appeals for the Federal Circuit that APIs are copyrightable means that binding precedent on every court except the Supreme is that they are

No, it doesn’t. Because the Court expressly declined to examine the question, the CAFC decision is binding only where it would have been without the Supreme Court decision, i.e., those courts bound by the CAFC’s interpration of how Ninth Circuit law applies. As it turns out, that is exactly zero courts.

The reason the Supreme Court often likes to find the narrowest grounds possible for a decision is to avoid making more binding case law than is called for; giving the lower court rulings on all questions not addressed (including those the Supreme Court explicitly avoids) the same binding effect as the actual Supreme Court holding would defeat the purpose, and it is very much not how things work.


It was zero courts before, too, no?

CAFC does not have natural jurisdiction over copyright and thus always applies circuit law.

Here, this was also a 3-judge panel of the federal circuit, and en banc review was denied.

Those decisions are already not binding on future 3-judge panels IIRC (it's been a while, honestly), and definitely not binding on the circuits


> It was zero courts before, too, no?

Right, and I think this played an important role in why the Supreme Court ducked API copyrightability; they’d rather not do so absent a binding lower circuit decision, or especially a conflict between circuits, preferring to let the issue percolate (and also provide Congress more time to intervene) of there is another basis dor resolving particular cases with less sweeping impact.


>The fact that the Supreme Court decided not to overturn the decision of the Court of Appeals for the Federal Circuit that APIs are copyrightable means that binding precedent on every court except the Supreme is that they are.

Federal Circuit's ruling would only be precedent in the 9th circuit. As it does not have original jurisdiction in copyright disputes (only patent cases), it doesn't supercede any copyrightability rulings in other circuits, for instance the 1st circuit's holding in Lotus v Borland that the Lotus macros were not copyrightable as a "method of operation". And today's opinion cites Lotus v Borland several times even though the original 1996 Supreme Court case was deadlocked at 4-4.


> Federal Circuit's ruling would only be precedent in the 9th circuit.

I think it's even narrower than that: the Federal Circuit's ruling on non-patent aspects of the case isn't binding precedent outside of Oracle v. Google. District courts in the Ninth Circuit and the appeals court are free to ignore the Federal Circuit ruling in future cases and look to only rulings from the Ninth Circuit and Supreme Court as binding precedent.


The federal circuit's ruling is not precedent or binding in the 9th circuit. Because of it's lack of jurisdiction, it doesn't supersede anything, not just "other circuits" They have no subject matter jurisdiction over copyright, and so they only apply pre-existing regional law. Their decisions on that pre-existing regional law have no force within that circuit.

This is similar to when federal courts have to apply state law.


Wine was not really as much of an organized commercial endeavor so was not as much of a target


You could sue wine to take a swing at everyone building on wine. Valve/Steam for example.


Federal Circuit's ruling would only be precedent in the 9th circuit.

No, not only 9th circuit.

The Court of Appeals for the Federal Circuit is binding nationwide. And if the case includes claims about patents and/or trademarks, even if those specific claims are thrown out, then the Court of Appeals for the Federal Circuit becomes the court that the case is appealed to.

Which is how this particular case wound up there in the first place.


When ruling on aspects of a case that fall outside of their subject matter jurisdiction (eg. copyright rather than patents), the Federal Circuit is supposed to follow the local circuit's precedent, ie. rule how they think the Ninth Circuit would have ruled on those issues. And my understanding is that the Federal Circuit's rulings on eg. the copyright aspects of a case like this do not overturn Ninth Circuit copyright precedent and do not establish new copyright precedent anywhere, not even the Federal Circuit (since in future cases they will again be required to apply the relevant local circuit's copyright precedents as they exist at that time).

The Federal Circuit's copyright decision is binding on the parties to the case at hand, but the precedent for future cases is non-binding at best.

This was one of the arguments that the FSF and SFLC put forth in their amicus brief recommending that the Supreme Court not take up Google's appeal of the API copyright question:

> The court below predicted, on the basis of no compelling evidence, that the Ninth Circuit would depart from settled existing law in a novel direction which, as amici supporting the petition have said at length, would be destructive alike of commercial certainty and freedom to implement, thus inhibiting the progress of science and the useful arts. Neither the Ninth Circuit nor any other regional Court of Appeals is likely to defer to this improbable supposition, so the error is largely self-limiting. Such erroneous predictions of other courts’ holdings are not a suitable employment of this Court’s scarce resources in review by certiorari.


IP lawyer here — @wtallis's summary is how I understand the impact of the Federal Circuit decision as well.


> No, not only 9th circuit.

Not even the 9th Circuit. For cases arising from thr 9th Cir., 9th Cir. case law binds the CAFC, not the other way around, on issues that are outside ofnthe subject-matter for which the CAFC has nationwide jurisdiction.

> The Court of Appeals for the Federal Circuit is binding nationwide

No, it’s decisions are only binding nationwide on the issues within its special jurisdiction, which copyright is not. On other issues, it is instead bound by the case law of the circuit that would otherwise be responsible for the case, and notionally is just an interpreter of that circuit's case law. It’s decisions on those collateral matters on cases brought before it because they also touch on one of the issues reserved to the CAFC aren’t binding on any other court.


> issues within its special jurisdiction

How are those issues defined?



Thanks.


Lotus' failure was more because they failed to port to Windows, betting instead on OS/2.

Lotus was at a crossroads. DOS was obsolete, was the future OS/2 or Windows? They chose OS/2.

Lotus was a big, cash rich company at the time. Their fatal error was not realizing they should have ported 1-2-3 to both OS/2 and Windows. Then they would have been secure regardless of which prevailed.


At that point(1989), the future was less clear-cut than Windows vs OS2. Windows was more a graphical shell for DOS than a real OS, and there were other graphical shells for DOS. From the top of my head: I vaguely remember GEM, I have used one from Tandy. There was something else installed on our school computers, Dynamic Environment or something . Windows before 3.0 (1990) was inferior to a lot of these DOS shells.

If the choice was between 2 options, 'both' might be a viable response. But 3 or more, especially with a market expectancy that everything DOS-based would disappear?


You may be thinking of DesqView? It provided some level of virtualisation and multi-tasking, if you had a competent-enough CPU. Eventually, there was also DesqView/X which allowed you to export DOS and DesqView-aware applications over X11, which was actually kind of cool.


I completely forgot about DesqView. Never used it of saw it, but yes, that was another well-known one.


Right, and Microsoft was still putting so much development work into OS/2 in 1989 that there was still some sort of feeling that OS/2 was possibly the future of Windows. (OS/2 development kits were shipped from Microsoft with Microsoft branding prominently on them right up until the OS/2 3.0 [WARP] split and the origins of Windows NT.)

In hindsight it is much more obvious that Microsoft's involvement in OS/2 was something of a trojan horse to fund early NT development and a short-term hedge in case people did trust the IBM brand more than the Microsoft brand, but at the time it was much more confusing.


There was little doubt at the time that DOS based systems were rapidly becoming obsolete, and the future would be 32 bit Windows or OS/2.


> Lotus was a big, cash rich company at the time. Their fatal error was not realizing they should have ported 1-2-3 to both OS/2 and Windows. Then they would have been secure regardless of which prevailed

That’s...optimistic. The transition to GUIs undermined a major hold they had, which was user-familiarity-lock-in. That transition was going to be an opening no matter what, especially for a competitor that also controlled the platform that won out underneath the application.


Lotus bet the farm on OS/2. Not being on Windows made it an easy decision for customers to buy Excel.

Lotus was bigger than Microsoft for most (all?) of the 1980s.

Wordstar was another company that failed to understand the shift to GUIs.

Of course, Wordstar had another major marketing problem. Despite its dominance, nobody knew the name of the company (MicroPro) that made it. Far too late they realized the mistake and changed the company name to Wordstar. Microsoft never made that mistake.


Lotus 1-2-3 was on Windows so I think I am missing some context here around version differences?


Timing, IIRC. Lotus was late to Windows, opening the door for Excel.


Yeah it seems to be 1989 v 1991 based on the wiki but it also sounds like there might be some version differences. 2 years was a long time back then.


It's still a long time! You try being two years later to a major market than Microsoft and still beating them. How often has that happened?


Windows Mobile - iPhone Tablet PC - iPad Internet Explorer - Google Chrome MSN Messenger - Facebook Messenger, iMessage, etc Microsoft Band - Apple Watch Zune Pass (2006) - Spotify (2009, 2011), Apple Music, etc Skype - Zoom Hotmail - Gmail


Windows Mobile may have been there before iOS but it came after Blackberry and palm. iOS and iPhone was also revolutionary. Smartphones changed substantially from that.

Internet Explorer wasn't the first browser on the market but by the time Chrome had come around Microsoft had let it languish and it became pretty awful. For a long time Microsoft had convincingly won the browser war.

Same with MSN messenger, it didn't keep up. And nobody has ever decisively won that chat app war anyways .

Smartwatches have been around for a very very long time. What Apple did was get smartphone integration right.

Zune Pass isn't a streaming service, its a DRM laden online music store. So more akin to iTunes than Spotify or Apple Music. And it was very late to the game.


Skype -> Whatsapp, Zoom


Windows Mobile/iOS? Arguably Office and Google Docs.


Google Docs was released 20 years after Office, after Office had already killed all the rest of its competition in the early 90s.

iOS is a good example though. Windows Mobile had not yet come to dominate the market.


Netscape went out of business because their browser crashed far more frequently than Explorer. I've heard all the sob stories, but I was sick of the constant crashing of Netscape, and so tried Explorer. Explorer crashed too, but not nearly as often.


Hmm, I worked at a large company in 1995 as a web dev, and they were paying a license fee "per copy" of Netscape Navigator. I distinctly remember this, because we had 10,000 licenses. But we did get phone support with that, and I talked to Netscape's help desk a few times with various issues I faced as a developer.

Commercial users were paying for Netscape in 1995. It was only free for personal use. Even articles from 1996 mention the cost of Netscape as $49. [1]

So at least part of the reason IE displaced Netscape was that it was free for enterprises. And Netscape was not, until it was too late.

[1] https://www.fastcompany.com/27743/nothing-netscape


FWIW, Netscape got bought out by AOL, but not before it spun off Mozilla. https://en.wikipedia.org/wiki/Netscape

It may be hard to believe, but the first iteration of Internet Explorer on Macintosh (back on System 8) was __solid__. IE, at least on PowerMacs, was way faster and more reliable than either NCSA Mosaic or Navigator.


Hell, AOL still runs Netscape as a discount ISP, same logo since 1999 and everything: https://isp.netscape.com


God that's a beautiful website. Loads fast. Not too many graphics. Nothing moves unless I tell it to.


> Netscape got bought out by AOL

That makes it sound like Netscape had no say in the matter. Netscape sold itself to AOL.


"Bought out" is a common enough way to describe any company sale. "Sold itself" introduces way more unnecessary sub-textual baggage just by being a more unusual construction.


Microsoft had FrontPage create pages that crashed Netscape.


Netscape crashing on a web page is Netscape's fault.

Similarly, if the D compiler crashes when compiling a D source file, it's the D core team's fault.


If the people that make the OS whose APIs you are reliant on, are also the ones trying to make your code crash, I'd bet most of us would end up with crashing code.


I've never heard of any evidence that Microsoft planted:

    if (NetscapeIsRunning()) corrupt_data();
in their OS API calls. If they had, I'm sure it would have come out at the anti-trust trial, and would have made it an open and shut case. Did that happen?

As I recall, the anti-trust case revolved around Microsoft including IE for free with Windows, not sabotage. (Of course, every OS comes with a free browser these days. Even my Kindle.)


The claim by tinus_hn is that FrontPage - Microsoft's HTML editing tool - created pages that crash Netscape.

While it would arguably be Netscape's fault if Netscape actually crashes (rather than simply failing to display a malformed input) at that time in the browser wars there were plenty of energy going into creating incompatible new 'features' - such as Microsoft's own JavaScript competitor, VBScript [1], vector imaging format (AutoShapes) and animation tags (DHTML)

And Microsoft did intentionally sabotage competitors products in the 1990s with approval from the highest levels of the business - such as DR-DOS [2].

So while I'm not aware of any claims Microsoft sabotaged the OS to make Netscape crash, they'd sabotaged the OS to make other competing products crash, and they certainly added a lot of 'features' so web pages wouldn't render right on Netscape.

[1] http://www.gbengasesan.com/fyp/43/ch5.htm [2] https://en.wikipedia.org/wiki/AARD_code


I know about the AARD episode, and Microsoft lost a lawsuit over it, which was the right result.

There's zero evidence Microsoft sabotaged Netflix.

There's zero evidence Netscape crashed for any reason other than buggy Netflix code. Making a web page that crashes Netflix is a bug in Netflix. Microsoft is under zero obligation to work around Netflix bugs.


Netscape produced a browser that could be crashed by a malformed page.


> Explorer crashed too, but not nearly as often.


Netscape was not selling their browser so that did not matter. I worked at a startup that used their server. We wanted to pay for it but they would not invoice us. Just sending money without an invoice would have been a donation. I sat for hours on their customer support line trying to get an invoice but they never sent one until they went out of business.


I worked on Netscape Enterprise Server it had JavaScript as the scripting language. Did you work on that? Before NodeJS....


They absolutely did sell their browser to enterprises. It was only free for personal use.


I think that’s what cloudwizard is saying. They knew that Netscape cost money for professional use, but in trying to get an invoice to actually pay for it, Netscape did nothing.


I worked at a company in 1994 that had 10,000 licenses to Netscape Navigator. I had a support person I could call. So on some scale, there was definitely a way to send them money.


Yup, I can clearly remember Netscape crashing very very often. It was definitely the worse browser.


Exactly this. There's a lot of historic revision that says IE was never good, but there was a significant chunk of time around IE2 and IE3 where it slaughtered Netscape on Windows. Better performance, less crashing all around.

IE4 is where ActiveX and browser bloat started to become more obvious, then IE5 was an improvement again.. but we were only a short time from the launch of what would become Firefox. By that point, people were tired of the constant IE issues.


At some point, I was using IE 5, then IE 5.5, then Opera and then Firefox 0.8! Used some Neoplanet as well, but I cannot remember when anymore, must have been before Opera... IE 5.5 was great at the time, though mouse gestures and tabs on Opera were better.


Bingo and I distinctly remember when IE's CSS support was significantly better than Netscape's at a crucial point in time when it really mattered to nascent Web design and development.


Explorer also launched a lot faster than especially the late versions of netscape.


Yep. Netscape crashed at least every 30 minutes.


I should point out that in the Ninth Circuit, there's already plenty of strong, citeable precedent in favor of fair use for the purpose of interoperability; separate from the purpose of programmer convenience that the Supreme Court endorsed. It's my opinion that programmer convenience is strictly wider than interoperability. The only reason why SCOTUS needed to rule this way is:

1. Google did not copy Java APIs strictly for the purpose of interoperability (they specifically did not want interoperability with other Java environments).

2. Ninth Circuit court precedent does not apply in the Federal Circuit, which is the only reason why Oracle even had a leg to stand on.

Had Oracle not had a patent claim in this lawsuit, it would have wound up in the Ninth Circuit, we would have gotten another respectable decision limiting software copyright from that court, and the only thing SCOTUS would have had to have done would have been to deny cert to Oracle after they lost. It's entirely due to the Federal Circuit not respecting basic concepts of how software works and ruling on something that shouldn't have been in their jurisdiction that we got here.


What about Microsoft J# or Microsoft J++? A directly relatable example.


To be fair, Netscape lost because their product, at the time, was inferior. Netscape blew IE out of the water at first, but IE kept getting better. Netscape 3 was excellent, but when IE 4 came out, it was just better. Then came Netscape 4. 'Nuff said.

Lotus couldn't make the transition to Windows, and so lost to Excel (and perhaps Quattro Pro... it's been a long time and I don't remember details). This had nothing to do with copying APIs. Of course, it probably had everything to do with Microsoft's anti-competitive advantage by having access to Windows internals and undocumented features, but that's another matter.


I wonder how this would effect things like Preact too, which for operability sake, uses the exact same API as React.


In that specific example, I don't think it would really affect them, since both React and Preact are MIT licensed.


One of the issues here is that it's not even clear under which license the API should be covered. Does the existing software license also cover the API, or must it be explicitly defined?

What happens when an API is co-created by different software developers which each creates their own software under different licenses, through communications which themselves aren't explicitly licensed (like over email lists), and then summarize what they agree on in text instead of code (like the RFC process)?

At no point have either one of them explicitly given permission to use their respective contributions under another license. Even if they agree that the RFC text is public domain, that technically do not extend to implementations of the API which it describes (as those are different works!). And there exists no official reference code with legal approval from all contributors, whose license could be adopted by other developers.

It would be such a mess...


> both React and Preact are MIT licensed.

Huh, I had no idea the React license wasn't still "you're free to use React unless you ever assert a patent against Facebook".


Concern about the licensing was eventually sufficient that they resolved it a few years back.


Not a lawyer, seems like this case will hold precedence then. The whole idea of copy righting an API is insane.


DOS also copied APIs from CP/M (though that was before Microsoft bought it I assume)


Can any of those companies copying APIs in the past be sued now due to this precedent?


> That said, this case does establish a precedent that if your copying of an API is primarily for purposes of matching an interface so that developers can reimplement it, you're in fair use territory:

>> Google copied these lines not because of their creativity or beauty but because they would allow programmers to bring their skills to a new smartphone computing environment.

It's even weaker than you think. It was important that Google's use of Java's API was on a non-competing product. It's still quite up in the air what happens if you provide a generic library using your competitor's API without licensing it from them.


The dissent point out “non-competing” is a bit of a stretch as this affected contracts oracle had.


How is J2ME not competing?


Because

A) J2ME targeted feature phones.

B) Google isn't accused of copying J2ME when you get down to it. The parts that make ME distinct from SE weren't reimplemented in Android's Harmony fork (looking strongly at javax.microedition), and a lot of packages that SE implemented that ME didn't were present in Android.


In general the court seems to try to go to the easiest decision point in a case. The copyrightability of an API is less relevant if the user being sued should win regardless because of fair use. This is better than a plurality decision where there's multiple reasonings on API copywrite that make future decisions difficult. Here at least the court gives guidance on how to think about evaluating fair use in this context, which lower courts can apply.


  One of the big open questions is "are APIs copyrightable?" 
The Australian equivalent to the US Supreme Court considered this over 20 years ago, and imho got the correct result (not copyrightable): http://www.austlii.edu.au/cgi-bin/viewdoc/au/cases/cth/HCA/1...

IMHO they got the Huffman table wrong, although arguably it was the result compelled by an overprotective approach.


It seems that it was somewhat inevitable given the US vs Australian distinction on whether to protect Creativity vs Effort (years ago I investigated this rabbit hole when I had a client who wanted to set up a White Pages clone site by buying the data from someone who had digitised it [with a lot of manual entry!] by low-paid Indians. They were very disappointed when I told them to contact an IP lawyer because it was almost certainly going to get them sued)

I did cry a little at the court's assertion creating the huffman table required "a very great deal of hard work". Gather a corpus of databases you have lying around, count the occurrences of each byte value and apply a <50 line algorithm that has been around since the 1950s and is a pretty standard university assignment. "a very great deal of hard work" indeed.

Presumably division 4A / s47D would now allow the cloning of the data table if decided today -- are you aware of any post-1999 case law?


Thomas's dissent explicitly points this out. Without diving into "are APIs copyrightable?", the majority are skipping what should have been evaluated first before saying if they were fair-use or not.


Yeah, but Thomas said "The majority can not square it's fundamentally flawed fair-use analysis with a finding that declaring code is copyrightable".

Which is obviously false. A fair use analysis can -only- take place if the assumption is the code is copyrightable; if the majority had first decided the code was not copyrightable, fair use is immaterial.

Thomas' argument, if followed, would either have led to this same decision, or would make the opposite point he was trying to make.


> Thomas said "The majority can not square it's fundamentally flawed fair-use analysis with a finding that declaring code is copyrightable".

Which is obviously false. A fair use analysis can -only- take place if the assumption is the code is copyrightable

You are not disputing Thomas's point; you are agreeing with it. Thomas's point was exactly that, before even embarking on a fair use analysis, the Court should have first decided the question of whether the code was copyrightable. In the absence of a finding that the code was copyrightable, fair use analysis indeed makes no sense.

The "cannot square" part of Thomas's statement is just saying that the reason the majority did not even attempt to decide the question of whether the code was copyrightable was that the reasoning they would have had to use in order to find that it was copyrightable--which they would have had to do to even embark on a fair use analysis--would also have completely invalidated the reasoning they used to decide that Google's use was fair use. In other words, they are simply ignoring a glaring inconsistency in their position.

A decision that the code was not copyrightable in the first place would have been consistent, but the Court did not do that. A decision that the code was copyrightable and Google's use was not fair use would have been consistent, but the Court did not do that either. Instead, Thomas is saying, the Court decided that Google's use was fair use, on grounds that are inconsistent with the code even being copyrightable at all. As much as I hate to side with Oracle, I have to agree with Thomas on this point. The Court should either have ruled explicitly that the code was not copyrightable at all, or should have refused to let Google get away with what is obviously not fair use if the code is copyrightable.

> Thomas' argument, if followed, would either have led to this same decision, or would make the opposite point he was trying to make.

No, Thomas's argument, if followed, would end up with the opposite decision from the one the Court made: that Google's use was not fair use and that the decision below should have been affirmed, not reversed.


Not so. The appeals court found in Oracle's favor, not Google's. Meaning they found that the API was copyrightable, and that Google's use was not fair use.

The majority supreme court opinion basically said "even assuming it is copyrightable, this IS fair use", with the implication that if it's not copyrightable, there is no case, so the same outcome, a win for Google. They intentionally were keeping their decision as little precedent setting as possible.

Thomas' dissent said "you can't decide this based on hypotheticals! You have to decide whether it's copyrightable or not first!" - had justice Thomas felt the code was not copyrightable in the first place he could have written his own concurring opinion. In fact, he did not; his position, as made clear in his dissent, was that he felt APIs -were- copyrightable, AND that this was not fair use.

The court did not agree with him. And had the court first started with addressing whether an API was copyrightable, the outcome would have either been they are not (a more far reaching decision, but still a win for Google), or that they were, and that this was fair use (so the same outcome, but now with, again, a more far reaching decision).

You claim that Thomas is saying that "if the court decided it was copyrightable, then they would have also had to have found this was not fair use". If that is indeed what he said (not my take on it, but I'll grant it), that is false on the face of it, as that is -explicitly what the court did not do-. They accepted it was copyrightable as a hypothetical, and then focused solely on, if that is true, was this was fair use? And they found that it was. To form an argument in this way is logically consistent; Thomas may disagree with it, as is his right, but the statement that the court has made a logical error is absurd.


> Not so. The appeals court found in Oracle's favor, not Google's. Meaning they found that the API was copyrightable, and that Google's use was not fair use.

Again, you are not disagreeing; you are agreeing. Thomas is arguing that the appeals court's ruling, which you correctly describe, should have been affirmed. Which is the opposite decision from the one the Court made, just as I said.

> The majority supreme court opinion basically said "even assuming it is copyrightable, this IS fair use"

Here is the exact quote from the opinion:

"we assume, for argument’s sake, that the material was copyrightable. But we hold that the copying here at issue nonetheless constituted a fair use."

In other words, the Court did not even consider the question of whether or not the material was copyrightable. They assumed it "for the sake of argument", which is just a dodge. They should have considered the question directly; and here is what Thomas says about that:

"The majority purports to assume, without deciding, that the code is protected. But its fair-use analysis is wholly inconsistent with the substantial protection Congress gave to computer code. By skipping over the copyrightability question, the majority disregards half the relevant statutory text and distorts its fair-use analysis."

Further comments below.

> You claim that Thomas is saying that "if the court decided it was copyrightable, then they would have also had to have found this was not fair use".

Yes, because the relevant facts that would support a ruling, based on the statute, that the code was copyrightable, also indicate, based on the statute, that Google's use was not fair use. But by skipping over the copyrightability analysis, the majority is simply ignoring those facts and those portions of the statute. That is Thomas's point.

> To form an argument in this way is logically consistent

Not if it ignores additional information that is not consistent with information used in the argument. Thomas is not saying that the Court's argument is logically inconsistent on its face. He's saying that it's inconsistent once you put back in the information that the Court left out: the facts that support a ruling, based on the statute, that the code was copyrightable, also support a ruling, based on the statute, that Google's use was not fair use. The majority is simply failing to consider those facts.

In other words, the Court can't just "assume for the sake of argument" that the code is copyrightable in a vacuum. They have to take into account the relevant facts of the case that support such an assumption, and consider the implications of those facts, and the relevant parts of the statute, for the fair use analysis.


>> Not if it ignores additional information that is not consistent with information used in the argument

That is your assumption. You assume the majority ignored that additional information. You say the court is failing to consider the facts that would indicate it copyrightable; that is -assumption- on your part. The court had the same set of facts in front of it (read: the entire body of relevant law); the majority chose to apply them to a different problem than the one Thomas wanted them to be applied to, and came to a different outcome than the one Thomas wanted.

The court can totally "assume for the sake of argument"; it does not reduce the surface of the law, it does not take facts out of the equation. It just makes arguing one part of it moot.


> You assume the majority ignored that additional information.

If they didn't, why is it never even mentioned in the opinion? Why does the majority not even acknowledge the fact that there are other facts involved, which do not support their conclusion?

Of course any answer I might propose would also be an "assumption" to you, but I'll propose one anyway: because the majority knew quite well that if they did mention or acknowledge any of those other facts, it would be obvious to anyone reading the opinion that their argument was not cogent. My reading of many, many other Supreme Court opinions over the years tells me that that kind of thing happens all the time. At least dissenting opinions are available, though it seems like the ones that really point out fundamental flaws, like this one by Thomas, never actually get any traction.

> The court can totally "assume for the sake of argument"

The court can of course do whatever it pleases; there is no higher court of appeal to overrule them, and the Justices serve for life so they can simply not care what anyone else thinks of their rulings.

That doesn't make it right when they twist the law, or outright ignore it, to produce rulings that are in accordance with their ideological preconceptions. Which, again, is something that happens all the time.


Why would the court be obliged to reason front to back? Surely this is no different from e.g. "the defendant had adequate grounds for killing in self-defence, so there is no need to examine whether they intended to kill the victim".


This is more like deciding whether there was a murder to begin with before deciding it was self-defense.

The thing is that fair use implies the underlying data was copyrighted, but something being copyrighted doesn't imply fair use, which is why I think your analysis is backwards.


To run with this analogy -

Majority Opinion: "We do not presently wish to venture an opinion on how this person died, but we can say authoritatively that the accused was not at the location the death took place at the time it took place. Therefore, even if a murder took place, the accused is innocent of murder"

Thomas' Dissent: "We can not decide the person is innocent of murder unless we decide whether a murder took place or not. Further, here are all the reasons I think the accused murdered the victim."


I would state these differently:

Majority Opinion: "We assume for the sake of argument that the deceased was murdered; we then argue that the accused did not do it, and rule that the accused is innocent."

Thomas's Dissent: "The facts of the case that support a conclusion that the deceased was murdered also support a conclusion that the accused did it. So if you are assuming that the deceased was murdered, you should also conclude that the accused is guilty."


The thing is that fair use is a defense to infringement -- so saying this is fair use implies they would have been infringing if not for that factor.

"I didn't commit murder at all" doesn't have the same relationship to some hypothetical murder, rather it's claiming there's no link there at all.

The analysis does feel like it puts the cart before the horse and possibly ends up implying or easily being argued as implying a statement I think they were trying to avoid opining on absent developments in the lower courts.

I get why they would do that, but it doesn't make it less strange and I would worry that this could be analyzed to say, in effect, that APIs should all be subject to copyright.

It wouldn't even be the first time a Supreme Court ruling one way on IP had been turned on its head, either. That has happened a lot with software patents, for example.


> saying this is fair use implies they would have been infringing if not for that factor

Yes, I agree.


> The thing is that fair use implies the underlying data was copyrighted, but something being copyrighted doesn't imply fair use, which is why I think your analysis is backwards.

For those who may not understand: in the US, fair use is a defense, not a right. By arguing that your usage was fair use, you are admitting to copyright infringement. Just that your infringement was fair use. The analogy above to self defense is a good one; By arguing your killing was self defense, you are admitting that you killed somebody, but that it was justified.


> By arguing that your usage was fair use, you are admitting to copyright infringement.

No, its actually fairly common to argue both that an act wasn’t infringement but, if it was, it would be fair use.

One way you might do this is to argue that the thing copied was outside the scope of copyright, bur then argue that, if it was covered by copyright, it would be fair use.

That was, in fact, Google’s argument in this very case.


Your honor, I will show that (1) my client never received the Ming vase from the plaintiff, (2) he returned it in perfect condition, and (3) it was already cracked when he got it.

I agree such arguments are fairly common, but that doesn't make them any less fishy, in my view.


http://acronymrequired.com/2011/10/the-four-dog-defense.html

Where there are contradictory assertions of fact in the various defenses, I agree there's something... uncomfortable about it, at least.

But I don't think that applies in a case like "it's fair use, anyway." If we imagine a case where someone copied a small bit of written material for criticism or educational purposes, something clearly fair use, introducing uncertainty about whether the document had been placed in the public domain doesn't cloud the question of whether the behavior was okay, and answering the question in the easier way doesn't force any conclusions about the other matter.


> If we imagine a case where someone copied a small bit of written material for criticism or educational purposes

...then we are imagining a case totally unlike this one, where Google copied the entirety of Oracle's API interface declaration code for the purpose of using it to make money. This is one of the key points Thomas makes in his dissent. So this case is not a case of "we weren't sure whether the material was copyrightable, but in any case our use was clearly for a purpose that would be fair use if it was".

Another point in this respect that Thomas makes is that Google tried four times to get a license from Oracle to use their Java API code, before just copying it and using it anyway. That shows what, in legal terms, would be called mens rea--Google clearly knew the code was copyrightable, because if it weren't, they would not have tried to get a license. So Google now saying they aren't sure the code was copyrightable, as they did in their brief in this case, is, to say the least, disingenuous.


> ...then we are imagining a case totally unlike this one

That was my intent. My comment was meant to move to a setting where judgement was clear and then bring it back to see what was preserved; I don't think it did a good job of the second half of that.

> Google tried four times to get a license from Oracle to use their Java API code

Did Google try to license just the API? My understanding was that they tried to license the implementation, and eventually went with a (purported?) clean-room reimplementation. That doesn't seem to indicate a belief (or even a worry) that the interface itself is covered by copyright.

> Google clearly knew the code was copyrightable, because if it weren't, they would not have tried to get a license.

Even ignoring the previous point, I don't think that follows. Outcomes in law are rarely certain; "pay not to have to deal with the question" is not necessarily a bad response to ambiguity (particularly when that ambiguity was created by law and the courts rather than the counter-party, in which case there is concern about motivating more such ambiguity).


Apropos of the "four dog defense", Dashiell Hammett in The Thin Man has a woman say to a man she is walking out on: "I don't like crooks, and even if I did I wouldn't like crooks that are stool pigeons, and even if I did like crooks that are stool pigeons, I still wouldn't like you."


Over the years, the STEM professional in me has become increasingly intrigued by the ways in which law progresses because it is so fundamentally different from my preferred method of making sense of the world.

Within that, and with my incredibly limited understanding of how law evolves in the courts...it seems like Thomas says demonstrably incorrect things more frequently than I am comfortable with.


Interesting. In my very limited understanding I have a very opposite view, specifically around Justice Thomas.

If you read pdonis’s reply to your parent, you will see that Thomas was rather correct in the way law should have applied in this case. I find that in the limited few of few cases I have read , I politically like the judgement made but I identify more with how Thomas thought about the case.

Really fascinated by the American legal system. In some ways really elegant and so much better than the legal system in my own country.


Why should it have been evaluated first?

I understand the intuition you're getting at: logically, the first question could make the second irrelevant. But if the second question resolves the issue even when the first is construed in favor of the other party, what's the rationale for demanding the court focus on the first question?


IANAL, but I can imagine something like the following:

A. We decide this is fair use based on the small number of LOC used and call it a day

B. OR we can decide that APIs are not copyrightable even though they're self-evidently creative works because of the importance of interoperability based on something something related to Borland v. Lotus, a case that we couldn't agree on the last time it came up.

Hey folks. Let's do A.


While I agree that APIs should not be copyrightable, the Supreme Court has been criticized for "legislating from the bench".

Avoiding the temptation to set bigger and more far-reaching precedents than is strictly necessary for the case at hand avoids giving the impression that the judicial branch is doing the job of the legislative branch.


This is something I struggle with, personally.

I have fundamental problems with an unelected council that serves for life creating law.

However, we have an extremely inefficient form of Government that doesn't allow for quick adaptation, and legal questions will arise tomorrow that did not occur to legislators today. The courts are supposed to help resolve any ambiguity.

The question over whether or not APIs are copyrightable is, however, not a question of ambiguity. APIs are software (or documentation, or source code, etc), and any category you place them into is copyrightable under the current law. If we don't want APIs to be copyrightable, then they must have explicit exemptions carved out in the law. The courts are bound to consider an API as copyrighted right now, and the only question is whether violating that copyright is fair-use.

I think the Court did the right thing in skirting the question. That's up to legislators, the Court cannot help. We need fundamental reform of IP protections for software anyway.


> We need fundamental reform of IP protections for software anyway.

That really is the root issue here. So many problems we're seeing (Pai's clownshow in the FCC, SCOTUS legislating from the bench, federal agencies trampling citizens' rights, etc.) stem from the legislative branch abdicating their authority to third parties -- the librarian of Congress, the FCC, SCOTUS, and even (by legal reference) professional organizations and laws in other countries. It's ridiculous.

A first principle of a democratic government is that citizens can soon fire someone whose legislation and/or executive decision they do not like. We would all have voted Pai out if we could have... but he shouldn't have had the power to do what he did in the first place (remove network neutrality rules). Congress gave him that power - which I would argue was an abdication of authority vested in them.


> Congress gave him that power - which I would argue was an abdication of authority vested in them.

Legislators assigning regulatory power to bureaucratic agencies is one of the cornerstones of modern democracies - it wouldn't work otherwise. Many of our legislators are barely qualified to send their own emails, let alone decide what is a telecom utility or how much ppb in drinking water is safe for a toxic chemical. Assigning that power to regulatory agencies allows experts to decide those issues in a neutral setting.

Pai's FCC aside, that structure prevented significant disruptions in the last four years and our country continues to function despite decades of increased partisanship and deadlock at the highest level.


> it wouldn't work otherwise.

Agreed that regulatory agencies are indispensable. But their job is to carry out the law, not make the law. Of course, the law has to delegate some decision-making responsibility to them -- the law can't make every decision ahead of time. But (a) the law can codify principles that regulatory agencies must uphold, and (b) lawsuits can be filed when someone disagrees that a principle has been accurately upheld -- the courts can decide.

We as a country ought to be arguing and disagreeing about principles, and the results (decided by legislators who are under the gun of potential non-reelection) ought to be codified as laws. A lack of principle in congress and in law is what really causes this abdication and delegation of authority.

An ideal legal corpus represents (as much as possible) a simply and directly expressed set of principles under which the country operates.


> regulatory agencies allows experts to decide those issues in a neutral setting

It is difficult to talk about "regulations" in the abstract but I would suggest that many regulations aren't about a perfect solution devised by an expert. They are more often about finding a tradeoff, a balance between competing goals. Those sorts of decisions can be informed by "expert" knowledge, but I think it is a mistake to think that domain experts are necessarily best positioned to resolve tradeoffs in public policy.

I'm not arguing against expert knowledge being incorporated into construction of regulations -- just pointing out that expert knowledge may be necessary but not sufficient to finding a workable public policy.


I fear that you will remain disappointed, because no prescriptive specification of law written by legislators can be detailed enough to catch every edge case.

If your democratically elected legislators don't like a bench ruling, they are free to make a new law that specifically overrides that ruling. The legislature is the ultimate source of authority in the land. The courts only have a bit of wiggle room in interpreting unclear statutes.

The system is designed well. Unfortunately, democratically elected legislators at the moment would rather obstruct, wreck, and go on wild-ass conspiracy rants, than legislate.

If that legislature spent half the time it complains about activist judges actually drafting law, it would have nothing to complain about. If you, as a constituent are unhappy about the current state of affairs, vote in legislators who are willing to do their job.


Slow legislation is a feature rather than a bug. Less opportunity for reactionary laws based on emotion or a collective misunderstanding of events that we later regret. It's not a perfect deterrent, obviously, e.g. the Patriot Act


Cipyright law needed reform for like 40 years. Thre is slow, and there is dysfunctional


However, the main reform that people are asking for is a shortening of copyright terms which really isn't a factor that plays into this case or, for the most part, with computer software generally. One can imagine copyright reform that broadly and explicitly exempts interfaces from at least copyright protection but that has generally not been one of the top issues historically.


Copyright law has received many reforms over the last 40 years. It may not have received the particular reforms you want, but that’s a very different issue.


It doesnt matter what I want, it has not addressed the issues that need to be adressed, in either way.


AFAIK, the Court's overt mission is to interpret and regulate the intent of Congress. They literally must legislate from the bench where Congress has left them an obligation to do so. And Congress can legislate when they feel the Court has taken too much liberty with interpretation or regulation.

But I really do think this case falls squarely inside the parameters of "interpretation" as most members would see it.


That is part of the dynamic. More importantly, though, a narrow decision makes a broad decision easier. If some justices think the code isn't copyrightable, they can increase their voting power by agreeing to set a less sweeping precedent that more justices agree with.


With what I know of Amy Coney Barrett, I’m very surprised she had no part in this decision. You did an absolutely wonderful job of explaining her whole feeling on the bench in two paragraphs. Seriously friend, that’s some excellent writing - excellent excellent job!!


The case was argued weeks before Barrett was confirmed to the court.


That’s the perfect explanation!!! :) I’m dumb - thanks so much!!!!


> Avoiding the temptation to set bigger and more far-reaching precedents than is strictly necessary for the case at hand avoids giving the impression that the judicial branch is doing the job of the legislative branch.

Well, that's the theory.

In fact, they are doing the job of the legislative branch, they can't stop people from noticing this, and sticking to this approach just means they're doing their job badly.


> Hey folks. Let's do A.

In an earlier concurring opinion when he was on the D.C. Circuit — i.e., before joining the Supreme Court as Chief Justice of the United States (his official title) — John Roberts referred to "... the cardinal principle of judicial restraint — if it is not necessary to decide more, it is necessary not to decide more ...." [0]

[0] https://scholar.google.com/scholar_case?case=192785774326304...


This is what the Supreme Court does in general. They decide on the narrowest of rulings possible.


But if the second question resolves the issue even when the first is construed in favor of the other party, what's the rationale for demanding the court focus on the first question?

The main influence of the Supreme Court is in setting precedent. In the absence of a ruling from the Supreme Court, the previous ruling from the Court of Appeals for the Federal Circuit is binding precedent on the whole country that APIs are copyrightable. That means that the most important precedents set in this case are still an issue for the software industry.


> In the absence of a ruling from the Supreme Court, the previous ruling from the Court of Appeals for the Federal Circuit is binding precedent on the whole country that APIs are copyrightable.

This is not true - other circuit courts are free to set their own, conflicting precedent. Each circuit's decisions are binding only on its own judges, and suggestive but not binding on other circuits.

Circuits deciding differently (a "circuit split") is uncommon, and considered urgent grounds for the Supreme Court to take up a test case to resolve the ambiguity; but it's not considered a "breaking" of precedent by either circuit, just a difference of interpretation for the Supreme Court to resolve


For most circuits what you say would be true. But the Court of Appeals for the Federal Circuit is special. As http://www.cafc.uscourts.gov/the-court/court-jurisdiction says, their jurisdiction is national and determined by subject matter.

That said I do not actually know whether they would be binding on another circuit court. But they are definitely binding on all federal courts lower than that.

However that question is sort of moot. It is extremely easy for the entity filing the case for infringement to include something about patent or trademark in the suit, which guarantees that you wind up in the Court of Appeals for the Federal Circuit. Where that ruling is binding.


> their jurisdiction is national and determined by subject matter.

Copyright is not part of their subject matter jurisdiction.

> However that question is sort of moot. It is extremely easy for the entity filing the case for infringement to include something about patent or trademark in the suit, which guarantees that you wind up in the Court of Appeals for the Federal Circuit. Where that ruling is binding.

It’s not, though; outside of its own subject matter jurisdiction, CAFC is bound by the law of the Circuit to which the trial court belongs, which it, in theory, merely applies. Another case coming up through the Northern District of California like Oracle v. Google did would be governed vy Ninth Circuit, not Federal Circuit, copyright precedent even if heard in the Federal Circuit because of other issues in the case.


> the previous ruling from the Court of Appeals for the Federal Circuit is binding precedent on the whole country that APIs are copyrightable.

No, its not.

The CAFC’s interpretation of Ninth Amendment case law on copyrightability in this case (before and after the Supreme Court sidestepped it) is binding on no one except future courts hearing cases on issues and between parties so closely related to those in Oracle v. Google that res judicata rather than rules of precedent is the deciding factor


That point is super weird, because the court has a tendency to make the narrowest ruling that is able to resolve the case in front of them. Clearly the fair use question is more narrow than the question of copyrightability of APIs.


APIs and most code is copyrightable, they are original works of authorship fixed in a tangible medium, all that is required by he Copyright Act of 1976. It doesn't look like either party in this case claimed the code was not eligible for copyright either

If they shouldn't be copyrightable because the world would be better off, interoperability between business is harmed, it is up to congress to change the law. Historically legislation like this harms smaller companies mostly, larger companies can better afford to deal with the requirement to license or the cost/work required to stick to fair use or litigate over it, so the larger companies that can afford to lobby to change the law aren't going to want them changed.

This case certainly sets precedent that API re-implementation can be fair use, not that it always is. Fair use is very fact specific, based on a four part test where having one part in favor can be fair use, and having three parts in your favor can still be infringement. A future case with products that would have a more substantial effect on the market of the original work, or had more of the original work reused than was strictly necessary could very well be infringement. With regards to "the amount and substantiality of the portion used" in this case less than 1% of the original code was copied just measuring the lines of code. Substantiality is harder to put a number on, but arguably it was only a small portion of the original product. This is a very low and for many other APIs a more substantial portion would need to be copied to be useful. The precedential value of this case is unclear without either the law changing, or further litigation.


How often does the API itself exceed the level of creativity of uncopyrightable plain lists of facts? It's not clear to me that it should be considered copyrightable on its own, especially with the fact that copyright explicitly do not cover functional elements. The declarations only instructs you on how to interact with the actual code, and AFAICT rarely add any creative height on top of what's in the main source code.

If presence and order of keywords was sufficient, such legal precedence would create collateral damage at levels that is beyond absurd - outside of software, this would extend to atypical calendar formats, plenty of paper forms, automatic telephone voice menus, map projections, and so much more. Calling it "destructive" wouldn't suffice. Entire industries would be leveled by uncooperative rent seekers that hold old copyrights.


The threshold of originality is extremely low for a work to be considered a work of authorship. From the linked decision, " a work is “original” if it is “independently created by the author” and “possesses at least some minimal degree of creativity.” Feist Publications, Inc. v. Rural Telephone Service Co., 499 U. S. 340, 345 (1991). The lines of declaring code in the Java platform readily satisfy this “extremely low” threshold. "

Paper forms are often protected by copyright, as long as they have creative non functional elements. And they are licensed much like stock photos in some industries.

There would be some APIs or code that only contain functional elements and aren't eligible for copyright protection, but in most cases there is a substantial amount that is not only functional.

Copyright protects works fixed in a physical media, not the underlying idea. Many people can create similar works based on the same underlying ideas. Like with a map projection a specific implementation can be protected by copyright. But the idea of a map projection where a constant bearing in the real world corresponds to a straight line on a map cannot be protected by copyright, someone else could create their own version that does the same thing without infringement.

Copyright only protects against copying, not against independent creation of the same work. With something like a calendar, or in some cases an API that only has a few creative elements, multiple people could make the same choices and create the exact same thing without there being any infringement.


Re forms: I did primarily mean rather simple ones (like say attendance forms), but there's a bigger argument here;

This type of API copyright would post likely not just mean the paper form is under copyright protection, but that the software to OCR scan it and parse it would also likewise be protected - as it is an ordered series of keywords with types, etc. It would then be a license infringement to parse forms without a license.

Independent creation is legal defense, not a cause for dismissal of a suit. You need to prove it - which becomes harder if they can argue you saw their work first and imitated theirs.

There's precedence where people have created their own works from scratch and held to be infringing because they mimicked an existing work too closely (like one case of a photo of a red London bus), and in civil copyright lawsuits the other copyright holder only needs to show its likely, which may reduce to showing you knew their work existed.


I think the focus on fair use is even better. It means that EVEN IF you can copyright the API, it doesn't matter because others can reimplement it. So not only can corps not stop that, but courts might rule later that the copyrights are totally invalid.


Exactly this, the same protection that memers have in editing content (but not copying the full implementation), software engineers now have too thanks to fair use.


I noticed that comment too early on. Breyer's opinion comes pretty close to saying "it's at best 'thin copyright'" but the fact that it's explicitly disclaimed makes me think that this is to some extent a compromise position: rather than arguing about whether SSO is copyrightable and risk a bigger split, just concede it because the fair use is sufficient here.


That's exactly why fair use exists. A teacher showing a movie in class is fair use, editing a clip for memes is fair use, making backups is fair use. APIs are copyrightable, but independent implementations are fair use, this is an outright win IMO. SSO might or might not be copyrightable in all of these cases, but we have certainty with fair use for specific cases.

In deference to OP, the question was never "Are APIs copyrightable?" The question was is what Google did in taking header information and doing their own implementation fair use, and it's unquestionably good now that the SCOTUS said this is fair use. Make sure to actually do your own implementation though.

Sun/Oracle didn't want to fragment Java, they copyrighted the language spec, and provided the JVM under SCSL before GPL. Java isn't fragmented, Sun/Oracle got what they wanted.


When SCOTUS accepted the cert petition, it granted two questions: a) are APIs copyrightable and b) if they are, is Google's use fair. Breyer's opinion explicitly lays this out, but doesn't explore API copyrightability any further than "assume it is for this discussion."

Playing Kremlinology here, it feels like Breyer originally had an opinion that explained that APIs were not copyrightable, but sacrificed that section of the opinion to build a 6-2 majority. It's really weird that the opinions took so long to come out for how simple they end up being--why is this coming it in early April instead of early/mid February if it's written like this? My supposition is that there was a much more sharply divided court, running a 3-3-2 or 4-2-2 opinion, and by dropping the discussion of whether or not the APIs were copyrightable and instead saying "it's at best thin copyright" (i.e., it's copyrightable but good luck ever winning infringement) the opinions collapsed down into a more simple outcome. One thing's for sure: this is the case I'm most interested in finding out all the backroom discussions that went on here.


Thomas/Alito get wrong that computer programs are an expression in every form, not invention in any way. Patent law does this too I'd reckon. They then refuse to do the work it takes to determine fair use in this field, which Alsup (and this court) did very well. Open source code being copyright (or copyleft et al) fits in perfectly well with this fair use analysis.

From the market effect part of the opinion, it's Oracle who should be worried if they're different enough from AWS or maybe not if learning any widely-used API means it's a loss if not copied. The WINEs of the world should be safe, Microsoft was never going to bring Win32 or DirectX to Linux.

In my cursory readings about merger doctrine, it's been around for decades, but hasn't been widely adopted by courts, and the justices by little surprise couldn't agree (3-3 or 4-2). The open source lawyers love it, but that means little. Fair use is about as good as it was ever really going to get for the foreseeable future. The industry is just going to have to settle for this or maybe pool it's copyrights like OIN does for patents.


Ops, I meant to say s/APIs/software projects/ are copyrightable, as the question of copyrightable APIs within software projects was sidestepped by the court.

It's a lot easier to say what Google did was fair use than decide where to draw the line on where an API is in a software project and whether it is copyrightable or not.


> One of the big open questions is "are APIs copyrightable?" The court skirted that question, and instead focused on whether it was fair use

Also what people fails to realize with fair use is that it is up to the defendant raise a fair use defense and then a judge has to approve of that defense as a valid one (Viva Frei explains this https://youtu.be/AzQz1LrjCWk?t=253 ).Meaning Oracle can still go on with its lawfare campaign against those who made the mistake of basing their tech on theirs.


Oracle would have to come up with new patent claims in order to get another case before the Federal Circuit, which is their best (only?) hope for having their API copyright claims upheld.


Fortunately, although it is pay-to-play, it's not pay-to-win. Oracle (or any other well-heeled player) can spend half a million or more in legal fees trying to go after a small company, but that doesn't mean that company has to match costs.


> That said, this case does establish a precedent that if your copying of an API is primarily for purposes of matching an interface so that developers can reimplement it, you're in fair use territory

Well, if you can an API for any primary purpose that not making software compatible with the one you are copying, then it's not really an API. It's perfectly fine if you can't frame it and sell around as a painting.


Not from U.S. Would the discussions, consultations between the judges and the independent subject matter experts be published? Surely there must have been such extensive discussions right? Or is the judgement based upon the subject matter experts presented as witness from both sides themselves?

I'm intrigued by how judgements are passed in such intricate technical matters.


> Would the discussions, consultations between the judges and the independent subject matter experts be published?

No such consultation exists.

> Or is the judgement based upon the subject matter experts presented as witness from both sides themselves?

Since this was a decision as a matter of law, and not one turning on disputed facts (the Supreme Court can decide cases on either basis), the judges are the relevant subject matter experts.


Thank you for the succinct answer.


> Google copied these lines not because of their creativity or beauty but because they would allow programmers to bring their skills to a new smartphone computing environment.

I'm waiting for an ambitious attorney to figure out how to frame this as poaching talent from an ecosystem to bring to another.


Exactly. Coming from law, sometimes like in this case, some topics can be left undecided, if it does not change the result. Even if the code could have been copyrighted, it would still be considered fair use.

Translated into developers speech: this is some sort of early return. ;)


Always seemed crazy to me that interoperability was ever in doubt.

Copyright in a private, internal API seems reasonable in principle.

RIP kotlin-first on android?


Kotlin never fixed anything on this area, beacause it is a guest language for the JVM, and the whole Android tooling depends on Java and JVM, ART only runs on the devices.

So to be fully Java/JVM free with Kotlin-first, Google and JetBrains would need to re-write the Android world to run on ART or Kotlin/Native, including anything that might come from Maven central.


> One of the big open questions is "are APIs copyrightable?" The court skirted that question, and instead focused on whether it was fair use:

Doesn't deciding that it's fair use specifically mean that they think it is copyrightable? The fair use doctrine specifically refers to the use of copyrighted material.


> Doesn't deciding that it's fair use specifically mean that they think it is copyrightable?

No, deciding it would be Fair Use even if it was copyrightable means you can cutoff the process considering copyright.

(Its perhaps useful to think of legal cases as consisting of a set of parallel questions connected by logic operators—once enough of them are resolved to reach a decision which no resolution on the others will change, the process is free to conclude without waiting for the others to be resolved.)


No. "Assume it's copyrightable. It's still fair use." That means you don't have to answer "Is it copyrightable?" The Supreme Court generally prefers to not answer questions that they don't have to answer.


So in programmer speak

    if (!isFairUse(workUnderInvestigation) && copyrightable(originalWork)) {
      bigCopyrightPayout();
    }
Short circuit on the and operator. It's fair use, so copyrightable will not be evaluated. Evaluating copyrightable has an obervable side effect of creating a precedent.


Yes, exactly that. Why do the && in that order? Because isFairUse(workUnderInvestigation) was a much less expensive operation than copyrightable(originalWork) for this particular value of originalWork.


That is the order scotus considered it.


Right, and that's why SCOTUS considered it in that order. Deciding API copyright was a much bigger decision than deciding fair use.


A shame, because as test cases go that wouldn’t have been a terrible one.


>The court skirted that question, and instead focused on whether it was fair use

Because the federal courts already ruled that APIs are eligible for copyright [0].

Google wanted to overturn the ruling that they were in violation of copyright and argued they used Java's APIs fairly under copyright law.

The court will not answer questions not put to it, and Google (I presume) felt they had a better shot at getting the court to agree it was fair usage, rather than arguing copyright should not apply here.

0: https://www.paleudislaw.com/federal-circuit-rules-that-apis-...


> The court will not answer questions not put to it, and Google (I presume) felt they had a better shot at getting the court to agree it was fair usage, rather than arguing copyright should not apply here.

This is false; Google appealed on both copyrightability and fair use, and the Supreme Court agreed to hear both issues.


I suppose Supreme court decision over this matter sets precedence for any future cases.


Why the downvote? You can read more about it here: https://en.wikipedia.org/wiki/Precedent


Making APIs copyrightable is a GOOD thing. It means they aren't patentable.


What does that even mean?

Algorithms and logical constructs like computer code aren't patentable under US law if that's what you're talking about.


I'm not buying it. What you patent is a bunch of text that is clearly copyrightable.

If you patent a method how to organize APIs, that would be perfectly reasonable. In fact we have a bunch of patents like that for networking stuff.


Could you explain your line of thinking here a bit more?



Generally, a comment such as this should also include some words from you about what kind of point you're trying to make by referring to the longer work. I think you're trying to use this blog post as evidence that patent and copyright protection are mutually exclusive, but from skimming this post it seems to only say that they should be mutually exclusive, while the Federal Circuit apparently disagrees. So at the very least, you would need to also point out how this Supreme Court decision reaffirms the blog post's position and strikes down the Federal Circuit on that question. But that seems to be far beyond the subject matter that the Supreme Court has actually ruled on today.

And you still haven't addressed why anyone should prefer APIs to be covered by copyright rather than patent law, when patents have much shorter duration and are more easily challenged.


> Generally, a comment such as this should also include some words from you about what kind of point you're trying to make by referring to the longer work.

Those words were in the previous post.

> And you still haven't addressed why anyone should prefer APIs to be covered by copyright rather than patent law, when patents have much shorter duration and are more easily challenged.

If we know it would be fair use, then copyright is rendered harmless. So in the choice between patents and neutered copyright, it patents are worse.


The blog post presents legal arguments why (with existing SCOTUS rulings) they should be considered separate. I could repeat all that, or just ask you to read it.


It's not an either/or.


I'm not sure why it's claimed they skirted the question... If I understand correctly, the Court answered the question when they issued bench instructions that APIs were to be considered copyrightable.

Is the difference that there's no SCOTUS precedent on the issue because it wasn't addressed in this case? Because (IANAL but) I'd assume the bench direction is itself precedent... In that if another circuit court tried to run a case as if the question was in the open, the Court would again ruler-slap them and say "No, assume APIs are copyrightable, plain language of the law."


They did not say that APIs were copyrightable, they said that if "we assume, for argument's sake, that [APIs are] copyrightable, [...] the copying here at issue nonetheless constituted a fair use".

From page 1 of the opinion, i.e. the actual ruling, which follows the "syllabus" in the pdf. The syllabus is basically just a summary. It's page 5 of the pdf.


I see; the difference is SCOTUS vs. circuit court of appeals precedent. I was referring to the decision of May 9, 2014 that overrulled the Alsup court assertion that APIs are not subject to copyright. But that decision was not from SCOTUS but from the appeals court for the circuit.

Current status, if I understand correctly, is that SCOTUS has not weighed in on whether APIs may be subject to copyright, and precedent in (Edit: Ninth Circuit) should be that they are to be considered copyrightable (and, I suppose, "no precedent in this circuit or from the Supreme Court" in all other circuits).


I don't think federal circuit rulings on non patent matter are binding precedent anywhere? I could be wrong about that. I certainly doubt there binding precedent on just one federal district (and not either all the district courts in the relevant circuit, or all district courts period).


Yeah, the CAFC rulings aren't precedent in the circuit courts were this would normally be appealed.


> "Google copied approximately 11,500 lines of declaring code from the API, which amounts to virtually all the declaring code needed to call up hundreds of different tasks. Those 11,500 lines, however, are only 0.4 percent of the entire API at issue, which consists of 2.86 million total lines. In considering “the amount and substantiality of the portion used” in this case, the 11,500 lines of code should be viewed as one small part of the considerably greater whole. As part of an interface, the copied lines of code are inextricably bound to other lines of code that are accessed by programmers. Google copied these lines not because of their creativity or beauty but because they would allow programmers to bring their skills to a new smartphone computing environment."

Sanity prevailed! This judgment could have had devastating consequences and turned software development into a copyright nightmare.


I'm glad about this outcome, because I agree the other outcome would have had a devastating effect on software development.

I also appreciate this fair use argument, especially when you point out the code in question was 0.4% of the entire API.

Still, I'll always struggle with the idea that "the amount and substantiality of the portion used" when copying an interface is comparable to copying an implementation. The interface is, intellectually, the substantially heavier, "bigger picture" component of the API than the implementation. In my view they are apples and oranges.

So, I'm glad this was the outcome. But I'll always feel like there was something wrong with Googe taking the Java SE interfaces and using them like they did, gratis.


> especially when you point out the code in question was 0.4% of the entire API.

Honestly, the fact that it's 0.4% is a BS heuristic. What if they spent a year and all they did was refactor the code so that codebase was 1.43 million lines instead of 2.86? Would that mean these lines of code are 2x as powerful?

Lines of code is an indicative heuristic, but not a deterministic one.


I think they took "line" to refer to a Java method signature/prototype, so even if a method signature has each parameter wrapped to its own physical line on-disk, the whole method declaration still counts as "one line".

...at least I hope that's what they did.


It's one thing to steal algorithms but for interoperability to remain possible it is necessary for API to remain "fair use". I can't agree with you that this is a bad thing for them to copy Java SE interfaces.


I understand we can’t have copyrights on APIs, but something about it just doesn't feel "fair" to me, though.

Fair use makes sense to me when you're talking about the table of contents of a book. If I take the table of contents of a famous novel and write my own chapters, it makes sense to me that the owners of that book shouldn't be able to sue me. No one is going to read my book instead of Faulkner's. There's no equivalency there.

If I take an API (the table of contents equivalent of software), that's seems totally different, if not the opposite really: the interface is what matters, and the implementation is secondary. If you apply the analogy to a novel, it's as if I took the table of contents of a famous novel, write my own chapters, and it'll be equivalent to the famous novel. My chapters could be slightly "worse", but readers wouldn't necessarily notice a difference between my version or Faulkner's.


> the interface is what matters, and the implementation is secondary.

But that's kind-of the point IMO - if we take a free-market approach to this, copying (or sort of "standardizing" onto) an API allows for more innovation, since it's not a prohibitive up-front cost to switching the implementation. We don't copyright (or I guess patent, and I know they're different) the user interface of a fridge. Any fridge can have 2 doors and a slide-out freezer, but it's the actual implementation that would matter to a user - how energy-efficient it is, how cold it can get, extra conveniences (maybe akin to API extensions) like a water/ice dispenser that still can be "copied"/used by other fridges. And I'm sure that maybe those "interfaces" were patented originally, but it seems absurd now that they're so commonplace to restrict who can implement them.


If you copied the table of contents of a famous book and happened to make the book significantly better then there's a chance people would read your book instead of the famous one. Should the original owner be allowed to sue you in that case?

I think the same applies for APIs. It's only taking away users from the original implementation if the new one is better.


Substantiality was only one factor in the decision. There were lots of others, such as raison d'être of copyright, "promoting the progress of science and art". Because allowing copying of APIs is more important to the "progress of science and art" than the economic impact on the creator of the API, APIs are thusly not copyrightable.


> APIs are thusly not copyrightable

This is NOT what the Court found. At the very top of the Opinion, it says "we assume, for argument’s sake, that the material was copyrightable. But we hold that the copying here at issue nonetheless constituted a fair use."


Fair enough. I had taken that to mean they were assuming a given to then prove the negative.


if I remember my history correctly Google did not, Android was purchased by Google by that time the choice to use Java SE as the API was already made


While true, it's not particularly relevant. When you acquire a company you're taking on its liabilities along with its assets.


There's a line in here that says "In the 1990s, Oracle created a programming language called Java." that is funny on its face, but is written this way for the exact reason you're talking about.


To their credit, they are explicit (in a footnote I believe) about equating Sun and Oracle.


Yes, it is one of the first footnotes.


But the comment was not really about liabilities, but even in that context I think the history is still relevant.

Rewriting history the way we do in the context has all kinds of problems associated with it


With that logic, Oracle didn't create Java either. It was purchased by Oracle from Sun in 2009, after Google had already created the Android API.


I can recommend focusing on Justice Thomas' dissent, which contains a section related to this topic. I believe Justice Thomas agrees with your assessment, and he raises concern that the SCOTUS has essentially made APIs practically uncopyrightable (in that they will 100% of the time find that it's fair-use to use them). I actually disagree with him, but only in one sub-category: I think a SCOTUS ruling would be harder to predict in a situation where someone 100% copied an API that had no implementation. That removes the mitigating factor of what portion of the work was used.

Ironically the most protected APIs may be the ones nobody implements.


Had Justice Thomas' opinion prevailed, most everything within POSIX was originally copyright by AT&T USL as part of System V, and would be owned by the current holders of that intellectual property.

Anyone using fork(), stat(), open(), or other basic parts of the UNIX development environment would be in violation.

Those copyrights were purchased by Novell at some point, and I believe ended up with Attachmate.

One would think that the C Programming Language is also covered by copyright via the K&R books, which would put anyone using printf() in the same position.

That is truly a nightmare scenario.


> That is truly a nightmare scenario.

Absolutely, but courts are supposed to interpret the law, not rule whichever way avoids nightmare scenarios.

The risk of going too far in that direction (and this is by no means the first case in which SCOTUS c̶l̶e̶a̶r̶l̶y̶ may have rationalized a decision for pragmatic reasons) is that it makes the court more corruptible. I am glad the majority ruled this way, because I agree that it leads to a better outcome in this case. On the other hand, any departure from a pure interpretation of the law is very dangerous, because it normalizes the more-corruptible mode of operation, and that can lead to another kind of "nightmare scenario".


> On the other hand, any departure from a pure interpretation of the law is very dangerous

You should read the law in question. This would be Section 107 of the Copyright Act, which defines "fair use". It's extremely vague and is best interpreted as a set of considerations that the courts should take into account so that they can handle situations like this one on a case by case basis. If Congress wanted to be more prescriptive, they could (ETA: and if they become unhappy with the courts' decisions they still can in the future), but I think that would lead to worse outcomes.


Makes sense, and I am definitely not an expert on fair use. I'll cross out "clearly" in my aside above.

I was really just responding to the implication that SCOTUS did the right thing because "it would be a nightmare scenario" otherwise.


> courts are supposed to interpret the law

The law also states that copyright's purpose is to stimulate progress of the arts, and that's why fair use is possible. Interpreting the law also means establishing the limits of fair use.


No, fair use is possible because of the First Amendment. While it is now adopted in statute, the statute was codifying a Constitutional limit that courts previously found in copyright protection grounded in the First Amendment, not the Copyright Clause.

But, still, yes, determining the scope and applicability of fair use is part of applying the law.


Ah, I had heard of the first amendment thing but I thought it was why government work must be in the public domain (i.e. putting it under copyright would prevent reproduction and therefore infringe first amendment rights).


Good point.


If it reaches SCOTUS, it means the law is already ambiguous the way its written and that no one interpretation is obviously the correct one.


You would certainly hope so, but that logic just passes the responsibility to interpret law faithfully onto the lower courts, which are also perhaps more easily corrupted.


I believe Justice Thomas agrees with your assessment, and he raises concern that the SCOTUS has essentially made APIs practically uncopyrightable (in that they will 100% of the time find that it's fair-use to use them).

That would seem a reasonable outcome, for much the same reason that copyright not protecting the appearance of fonts under US law is reasonable. Yes, it is overriding copyright protection for a creative work that would otherwise apply. However, it does so because a greater good is served, in this case by ensuring that interoperability cannot be encumbered, something which (as the majority opinion alludes) goes against the very purpose of copyright under US law.


> Yes, it is overriding copyright protection for a creative work that would otherwise apply. However, it does so because a greater good is served

One could argue that this is for the judicial branch, not the legislative branch, to decide.


The judicial branch did decide this.


Sigh, I made a mistake mixing up the order of judicial and legislative in the sentence.


The main legal basis for the majority opinion seems to be fair use, so isn't the system operating as intended? The legislators set out a principle of fair use in statute. The court applied that principle in the context of this specific case.


Thomas is almost always on the wrong side of history. If you want your API non copyrightable, don't make it public. Problem solved.


I think you mean “If you want your API copyrightable, don't make it public”, not “If you want your API non copyrightable, don't make it public”

Now, how do you let third parties program against that non-public API? Would only showing it to licensees be a legal way to do that?

If so, and if the API becomes popular, I don’t see how to prevent those licensees from leaking the API to the world, say through small code snippets on Stack Overflow.


That’s a good thing. The ability to copy an API allows more competition, helps improve services as others provide similar functionality, and forces improvement because it becomes easier to migrate from one service to another.

One thing I do see happening is that sensitive and expensive to develop algorithm internals may be prevented from leaking into APIs. I, again, don’t see this as anything other than a win for devs. An API is fundamentally used to get stuff done, if a developer doesn’t need to know the implementation details I overall think this is a win for the developer using the API.


[flagged]


Please make your substantive points without calling names.

https://news.ycombinator.com/newsguidelines.html


An idiot, in modern use, is a stupid or foolish person. I don't think I have used the term incorrectly.


Calling someone stupid or foolish is calling names in the sense that the site guidelines use that term. They ask you to omit all that from your posts to HN. Would you please review https://news.ycombinator.com/newsguidelines.html and stick to the rules?


> This judgment could have had devastating consequences and turned software development into a copyright nightmare.

It’d sure have made the practice of taking someone else’s API and re-implementing the innards a lot more interesting:

https://docs.oracle.com/en-us/iaas/Content/Object/Tasks/s3co...


The WINE and ReactOS guys must be cheering!


It's a win for all open software. Torvalds and Stallman didn't ask Bell's permission before re-implementing Unix


Why was this comment downvoted? Does GNU/Linux not largely reimplement proprietary Unix?


Yes why? Doesn't it?


It does. There are some who would argue that the Linux copyright fight is already resolved because of the SCO suits, but that's wrong because

A: some of those suits are still ongoing, and

B: the suits never alleged infringement based on the API alone, SCO was claiming that Linux copied functional code in multiprocessing modules (we don't know which functions because they demand secrecy, even though it's open source).

Not even SCO, trolls that they are, were insane enough to claim that the APIs themselves are copyrighted.


It's also good that Breyer wrote this opinion, given that he was one of the two judges who dissented in Eldred v. Ashcroft almost 20 years ago[1]. Lessig called that opinion "perhaps the best opinion [Breyer] has ever written"[2] in his retrospective on the case.

[1] https://en.wikipedia.org/wiki/Eldred_v._Ashcroft

[2] https://www.legalaffairs.org/issues/March-April-2004/story_l...


Were there any Breyer counterfactuals?


> Google copied these lines not because of their creativity or beauty but because they would allow programmers to bring their skills to a new smartphone computing environment.

Also known as compatibility and interoperability. I'm so happy to see that judges understand their importance.


> Also known as compatibility and interoperability.

Actually, not really. Both this ruling and the lower courts' rulings in the case operated under the strange assumption that Android was not interoperable with Oracle Java, leaving programmer familiarity as the only reason Google copied the APIs. For example, in the Federal Circuit ruling that the Supreme Court just overruled, they complain that Google "points to no Java apps that either pre-dated or post-dated Android that could run on the Android platform". True; but of course third-party libraries often can run on both Android and Oracle Java, and their importance seems to have been lost on everyone involved in the case... including Google's own lawyers.

Thankfully, Google won anyway, so any defendant in a future case who can make a better interoperability argument will be in an even stronger position.


Read Thomas' dissent, it'sabsolutely insane. He says how those 11k lines are basically 97.5% of Java's entire usefulness, and billions of dollars of value to Oracle from an Amazon deal. Absurdity.


Thomas lives in a weird alternative universe where logic works differently. His dissents are always a trip.


He really doesn, he and Scalia were the reliable crazy uncles of the court. Looks like Alito is trying to take up Scalia's mantle. I sear to god if Thomas had to rule on a runaway slave he'd rule for the slaveholder.


I don't agree with this.

I _hated_ Scalia while he was on the bench. I fundamentally disagreed with him on a significant amount of his opinions.

Their actual opinions though are of such a different quality to me. Scalia's opinions I could absolutely follow the logic, and at times I found myself sometimes dispairing as I became convinced he might be right on an issue. Essentially, Scalia's logic usually felt on point to me, we just had deep axiomatic differences in how the law should operate and how the constitution should be applied to laws.

Thomas, though, I sometimes have a hard time understanding the argument he's presenting, and sometimes have a "how do you even believe that" reaction to his opinions.

Again, I think I disagreed strongly with Scalia opinions about as often as I do Thomas opinions, I just think they were for very different reasons.


I agree Scalia wrote very tight opinions, but his personal biases were in such intense conflict with the actual constitution that the internal consistency just dosn't make it fly for me. But I see your point.


++ I almost always disagreed with Scalia, but he was a master legal mind in his written opinions. Like, they're not even comparable to Thomas or Kavanaugh, IMO.


Yeah. He's got a strange mind.


I agree with the majority here, but how is that crazy? One major point in the fair use analysis is that Android (for smartphones) did not directly compete with Java SE (for laptops and desktops). Showing that Android is a viable alternative for other Java uses, and did indeed supplant other Java contracts, seems relevant.


What Amazon deal? Did Amazon pay Oracle to license the Java API?


Yeah for the original Kindle. It's brought up in the court's decision.


An alternative take, which I'm sure won't be popular, is that now, with an interpretation taken to the extreme, a megаcorporation can basically steal your (let's say a small startup's) platform (in case you refuse to sell it for ethical or some other reasons), by re-implementing it and investing much more resources which you don't have, to make it more attractive to customers.

I'm ok with either decision, but, depending on how this precedent going to be interpreted, it could have far reaching consequences, maybe unintentional/undesired ones too.


I think that's always been a threat. If a large business decides to target an area you develop a system for, you're basically out of luck unless you have some novel IP that's difficult to replicate. You really have to have something niche, patent it, etc. otherwise you just roll the dice that massive entity X doesn't steamroll your livelihood out of business.


Well, before this decision in a situation like this you would at least be able to retain your existing customers who are already invested in your platform, due to API incompatibilities etc, but with the ability to painlessly re-implement platforms the large business would take your existing customers too, and reuse the platform momentum that you've built.


So companies would have to compete on pricing, availability, customer service etc etc instead of by being first to create lock in?

Seems like a net benefit to me :-)


It stifles innovation and rewards big business. Why risk developing something if it will be taken from you? A winner-take-all kind of situation. It leaves little room for the platform's authors to generate revenue other then hiring themselves to said big business, and probably at depressed rates.


Because you can always outcompete them?

No, it is not a first class ticket to unicorn valuation, but it is trivially easy to differentiate

- from Google by just providing any kind of customer service to all paying customers

- from AWS and GCP just by allowing on premise solutions

- from Facebook by not reliably failing to protect and/or actively exploit your customers all the time

- etc

Need proof? See Slack, WhatsApp and Instagram (before the acquisition), Basecamp etc etc.


>An alternative take, which I'm sure won't be popular, is that now, with an interpretation taken to the extreme, a megаcorporation can basically steal your (let's say a small startup's) platform (in case you refuse to sell it for ethical or some other reasons), by re-implementing it and investing much more resources which you don't have, to make it more attractive to customers.

GNU/Linux, a free reimplementation of AT&T's Unix interfaces, is largely why commercial Unix isn't really a thing any more.


Yes, but the situation is a bit different -- the majority of UNIX rights owners were actually promoting open standards through initiatives like POSIX, X/Open, so the re-implementation did not violate the copyright. As far as I know SCO's suits were not about interfaces of any kind, and the Linux kernel uses C standard library and other posix compliant libraries as an interface.


Thats what patents are for. API is like designing your own custom plug to your device. You can't copyright that plug design, you can patent it its novel and new.


And if you are opposed to algorithmic/software patents it would be an unpleasant choice to make. Also, copyright is probably (I'm not sure) easier/cheaper to litigate, because it's much more evident when something is copied, compared to divinating whether something violates a patent or not.


Happens today, like AWS Elasticache and AWS Aurora. I do think you're right in that it will make those decisions easier. Particularly for AGPL/GPL things. Now they can be reasonably sure that cloning the end user facing API bit is "fair use".


Ho you mean Amazon AWS?


Question from a layman: Does "interoperability" as a concept have any legal relevance here? Like focusing on programmer skills seems kind of beside the point, which is really for two pieces of software to be able to interoperate.


Interoperability does have legal relevance, but because of programmer skills. Part of the fair use analysis turns on the legitimate goal of allowing programmers to use their skills in Java on the new platform.

IAAL but IANAIPL and most emphatically IANYL


Yes, interoperability is relevant, because it affects the necessity of copying that particular code rather than making one's own substitute, which in turn affects fair use.

But Google's lawyers (inexplicably, in my opinion) failed to talk much about the fact that many Java libraries are interoperable between Android and Oracle Java, leaving the courts to think only in terms of full applications which are not interoperable. Thus the courts have treated this case as if the only benefit to Android's reuse of Java was programmer familiarity.

Thankfully, Google won anyway, so any defendant in a future case who can make a better interoperability argument will be in an even stronger position.

Edit: For example, in the Federal Circuit ruling that the Supreme Court just overruled, they complain: "Indeed, given the record evidence that Google designed Android so that it would not be compatible with the Java platform, or the JVM specifically, we find Google's interoperability argument confusing. [..Google] points to no Java apps that either pre-dated or post-dated Android that could run on the Android platform." [1]

[1] http://www.cafc.uscourts.gov/sites/default/files/opinions-or...


Google didn't argue on interoperability since that would have torpedoed their core arguments that Android is a transformative work creating a new market outside of, and different from, Sun Java Standard Edition.

To argue interoperability Google would have needed to copy the entire JAVA SE API.

The key difference is that Java SE (designed for desktops) API was considered by Google mostly not required on smartphone/mobile devices envisaged for Android. Sun would only licence Java SE complete (Sun was the one wanting complete interoperability).

To the extent the concept of interoperability enters into it, it was on the human side; the arguments were about leveraging existing programmer knowledge to the extent that Android's requirements were shared with and common to Java SE.


> To argue interoperability Google would have needed to copy the entire JAVA SE API.

Only if Google wanted to argue interoperability as defined by Sun/Oracle. I've never seen a coherent argument why Sun's TCK should be considered the sole authority on what degree of interoperability should have legal significance in this copyright case, particularly given that Sun's TCK was part of their trademark licensing program.

And there are obvious reasons why a court would shy away from letting something like Sun's TCK be used as part of a significant legal test; for example, it's really awkward for legal purposes to define something as copyright infringement while it's a work in progress, but it suddenly becomes okay as soon as it attains the status of being 100% compatible and bug-free. It's also not clear how the law could reasonably handle a definition of interoperability that Sun/Oracle can unilaterally make into a moving target and add arbitrary requirements to.


There's already Ninth Circuit precedent in favor of it. For example, Sony tried to sue two commercial PlayStation emulator developers and the Ninth rejected the lawsuit on all counts (and one of those cases is even cited in this opinion).

The court has to talk about programmer skills because Android (at least, the versions before they switched to OpenJDK) was not entirely source- or binary-compatible with Java SE programs. In fact, the reason why they couldn't license Java SE was that Sun insisted on Android being locked into compatibility in the first place. So this entirely represents an expansion of existing fair use precedent: now, not only does fair use apply to full reimplementations for the sake of interoperability, but also partial reimplementations made for the sake of programmer convenience.


Yes, reverse engineering for the purpose of interoperability is one of the things explicitly allowed by laws such as DMCA.


The decision talks about "interoperability" as a general concept, but neither the DMCA nor reverse engineering is at all relevant to its legal reasoning.


Also speaking as a layman, but yes. Fair use has, as one of its four factors, the purpose and character of the use, to which interoperability is of definite relevance. It explains -why- the API was reused, even if the internals are entirely different. Not because it saved Google work, or there was some sort of competitive edge against Java SE to be gained by doing so.


IANAL: Merger Doctrine is closest thing I'm aware of.


I wouldn't celebrate a victory yet. As is often the case, the court's choice of tests simply will serve as a blueprint for others on how to avoid themselves being caught in the same kind of result.

Based on this court decision, it's apparently fair use to lift someone else's API and use it to jumpstart programmer familiarity with your product, if the author of the API previously tried to achieve success in that narrowly-construed, retroactively-interpreted exact same market segment and wasn't very successful.

I see a few things coming out of this. IP holder companies will become even more common: they will be used to hold copyright to one API and license it out to customers -- including independent companies that you would currently recognize as part of the same platform.

But because the IP holder does not provide an implementation and therefore does not 'compete' in a market segment, any unlicensed use of it is necessarily infringing: there's no innate functionality with which one can interoperate under the doctrine of fair use.


> IP holder companies will become even more common: they will be used to hold copyright to one API and license it out to customers

Not after this precedent, which says that APIs are free.

What will happen: Intel licensing the i86 instruction set will not be possible from now on, same for ARM.


This ruling doesn't really change anything with respect to CPU instructions. The fair use defense doesn't cover patents.

Patents are what are generally what is used by Intel, etc to protect (and license) new CPU instructions and provide protection for novel ideas/inventions for up to 20 years.

Copyright generally protects specific expressions/implementations of an idea and last up to 95 years for corporate patents, or 70 years + the lifetime of the author for individual patents.

For completeness there is also trademarks which cover names and logos which can last indefinitely, as long as they are in commercial use.

The text of a CPU instruction specification would be covered by copyright, the algorithm for implementing the instruction by a patent, and the branding (ex: MMX) by trademark.


Say one black-box reimplements x86? Say one makes a "transformative work" with a number of extensions?

I fail to see why an ISA is fundamentally different than a standard library.


> I fail to see why an ISA is fundamentally different than a standard library.

As GP said, the difference is whether it's patented. If Sun had patented parts of the API (or algorithms necessary to implement it), then Oracle would have another weapon against Google even after Google was granted a fair-use defense.


Sure I'm not disagreeing with the legal history, but on what merits is one patentable, and the other either fair use to reimplement or not even copywritable!!

I could understand Intel having a CPU patent for specific CPUs, but an specific ISA?!

A really interesting test case would be to implement an isomorphic encoding to x86 with same instruction widths and what-not such that it's trivial to convert binaries from one to the other, and modify compilers (especially the JIT ones).


We shouldn't necessarily assume that the x86 patent war chests are legally sound. Rather, Intel and AMD have a mutually assured destruction cross-licensing arrangement and they need each other to stay viable to fend off antitrust regulators. But they would prefer not risking an unfavorable precedent by actually wielding their patents in court, so their deterrent operates more on the promise of protracted and expensive litigation, rather than on the promise that Intel would actually win against an upstart CPU vendor.


> Not after this precedent, which says that APIs are free

No, it doesn't. It says the "fair use" doctrine covers copying an API's "task calling" system, i.e. nomenclature and ontology.


Those are protected by patents, not copyrights.


Wow, that's an insanely brilliant evil business plan. And plausible, too.

The copyrightability of APIs will have to be determined.


Yeah it sounds like they were being sued over building a compatibility layer. That's nuts. Good thing the right decision was made :)


Can't this argument be used to copy the x86 interface and avoid paying license fees to either Intel or ARM for the instruction set?


The word on the street is that is primarily protected by patents, which explicitly protect against from scratch competing implementations, unlike copyright protection which only protects against verbatim copying of the original work.

On the plus side though, they only get 20 years of protection. x86-64 in it's original form should be up for grabs pretty soon here.



Yes... Sanity prevailed, no thanks at all to SCOracle.


It is fascinating that code is now being measured quantitatively. Number of "lines of code".


I suppose it makes sense from the perspective of copyright law, which protects artifacts. After all, one could say the same for quoting from a famous literary work .."ha now they're valuing literature in terms of number of words of prose!"


The dissent clearly highlights the fallacy of the ruling, where it discussed the importance of the "heart" of the work, rather than the portion of exact lines copied.

Aka, that you could clone Harry Potter's plot, characters, and story while not copying each word of the book verbatim, and it still be a copy of Harry Potter.


>Aka, that you could clone Harry Potter's plot, characters, and story while not copying each word of the book verbatim, and it still be a copy of Harry Potter.

Would that be a copyright infringement? Probably just trademark infringement at that point?


I know of one legal blogger who complains that certain copyright lawsuits really ought to be trademark suits (e.g., https://scrivenerserror.blogspot.com/2007/11/accio-lawsuit.h... , https://scrivenerserror.blogspot.com/2005/05/fan-fiction-tan... , https://scrivenerserror.blogspot.com/2005/05/fan-fiction-end... , https://scrivenerserror.blogspot.com/2005/05/fan-fiction-tan... ). But the courts generally play along and accept “copyright” suits that seem to be judged on trademark principles (but punished according to copyright law).


It would be trademark infringement to use the names, it would be copyright infringement to use the meaningful content of the plot and story.


Not sure that’s correct.

Copyright attaches to the actual text (illustrations, etc; whatever is “fixed in a tangible form”), not the ideas.

You could write a story about a boy of humble origins who is whisked off to a special school, discovers he’s special, and fights evil. There aren’t that many original plots, after all....

You’ll only get into trouble if the main character is called Harry Potter of 10 Privett Drive, where he resides with his mother’s sister and her awful family, and he later attends Hogwarts, etc.


While true, there's been (imo wrong, as it breaks the Idea–expression dichotomy) expansion of copyright to things like characters[1].

[1] https://en.wikipedia.org/wiki/Copyright_protection_for_ficti...


Copyright covers derivative works. If a story is plainly the same with names changed, the original copyright extends to it. This can be applied to the point of absurdity in music copyrights.


The derivative work has to be literally derived from the original "such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted." (per 17 USC 101). https://www.law.cornell.edu/uscode/text/17/101

The merger and scenes a faire doctrine permit lots of overlap in terms of themes, tropes and set dressing. You could certainly write a coming-of-age story set in a magical boarding school; indeed, Harry Potter is neither the first nor the last such novel. One of the classic cases is Walker v. Time Life. The two works, which were found to be non-infringing, both start with a double murder of two cops (one Black, one white) in the South Bronx, both feature demoralized Irish-American cops, and both have similar tropes (rats, cop-talk, etc). A reviewer might reasonably describe it as derivative (and a few did, I think), but not legally so.

What you probably couldn't do is publish the (non-parodic) story of Perry Hotter and his substantially-similar adventures at Pigworts, though that's also absolutely spoiling for a trademark fight.

Music gets weird because it a) seems like there are a lot of possible note sequences but b) there aren't really.


It’s generally not trademark infringement to refer to the actual thing the trademark refers to (”nominative use”). This would actually be a claim unlikely to succeed unless you are intentionally claiming that are writing the true original Harry Potter stories.


Tell that to the Sir Arthur Conan Doyle estate :)

I don't know if their beef is with copyright vs trademark.


Would it violate copyright to take a painting's colour palette and produce a different work with it?


"Harry Potter and the methods of rationality" - affly known as HPMOR - https://www.hpmor.com/


They do state, copy-write isn't the same in the programming world. Programming is always functional in nature, unlike a book.


To use your Harry Potter comparison, it would be like asserting that Magic Boy Adventures violates Harry Potter's copyright because one of the characters in MBA was similar to the Neville Longbottom.

Or in other words, a tiny fraction of the original work would essentially be allowed to monopolize the entire space of works involving magical kids going to school.

(And this is why Justice Thomas is widely regarded as the least competent justice of at least the past half century.)


Incorrect, because as Justice Thomas states, the "heart" of the work being copied is at issue, not a given percentage. Neville Longbottom is obviously not the "heart" of what a Harry Potter book is.

Presumably the issue would be if one wrote a book substantially about the same character as Harry Potter who went through the same plot events in significant detail, but only 0.4% of the sentences were identical and the main character's name was Barry.


Incorrect, because the "heart" of the work is not being copied, and therefore, the entirety of Justice Thomas' dissenting opinion is just pointless blathering.

Thomas would allow copyright on code regardless of any creativity. This would destroy the software industry. Anyone who is first in time would monopolize entire swaths of software functionality.

And that is what he wants. Thomas is an ideologue, and his sole goal in allowing the copyrighting of code is to destroy the tech industry, which he views as hostile to Republicans. You can see it in the logic of his dissent, which would require the court to override decades of settled case law all supporting the proposition that code and other functional expression. In order to justify his nonsensical arguments, Thomas is forced to come up with an entirely new category of code that is not supported by legislative history or judicial history. Thomas' only justification for this category is...that it's "not fair" to a multi-billion dollar company that the non-copyrightable portions of their code were copied by another corporation. Pity the poor multi-billion dollar corporation, they just can't ever get a break.

Even he notes that his dissent is nonsensical when he admits "declaring code is 'inherently bound together with uncopyrightable ideas.'


> Pity the poor multi-billion dollar corporation, they just can't ever get a break.

This would sound like a convincing position if the company abusing them wasn't a trillionaire corporation. Oracle is literally "the little guy" here.


Now their positions are greatly reversed. But at the time of the copying in 2005, Oracle was many times Googles' size.

This case began in 2010 as Oracle attempting to smother a similarly sized competitor...after Oracle acquired the actual creators of Java.


Now? I've personally heard quantities of code measured in "lines of code" (or, thousands of lines of code-- "K-LOCs") going back to the mid-90's. An acquaintance who worked for IBM in the 70's said it dates back at least that far (measuring developer productivity in the "K-LOCs" they produce).


It's been going on since the 1960s (maybe longer).

Personally, I think the best code is the code I don't write.

A significant part of my refactoring, is removing as much code as possible, by tweaking algorithms, deriving common base classes, and removing unused code branches.

Every line of code is a potential bug. The less code, the less bugs.


Negative lines of code are a good day's work.

https://www.folklore.org/StoryView.py?story=Negative_2000_Li...


Love that story!


There's a number of times I added significant new function to programs while ripping out great gobs of code.

My favorite was replacing a function call with a single character constant.

Then there were two employers who demanded code proliferation (management incentives tied to KLOCs?). Didn't last long at either place.


See Mythical Man-Month published in 1975 - https://en.wikipedia.org/wiki/The_Mythical_Man-Month


https://www.youtube.com/watch?v=GqFYsvxHZOs&t=1205s

(start at 20:05 if timestamp fails).


This Ballmer clip is the first thing I think about when I hear K-LOC.


My first manager, when I was a young engineer at Raytheon would like a word.


It's 2021 and I still come across managers that use this as a metric.


It may be a poor metric, but it's not like we have any other metrics to measure code by.

Well, "dollars / year", if you work in an industry where you can directly A-B test against revenue, but I think most of us are happiest not knowing whether our particular lines of code are EV-positive.


we absolutely have other metrics. Features, Stories, Ease-of-use, Dev Friendly, Qualitive Value. LoC is simply broadcasting how complex either A) the problem is (fair) or B) how you've made it (not fair) - most fall into the latter camp.

Code bases like kubernetes come to mind for LoC far exceeding its value. Code bases like Quake3 come to mind for LoC that provide tremendous value. Every line is an explicit decision to improve the code or make it worse.

Refactoring a system to be generic and re-usable, for example, would reduce LoC yet provide tremendous value. If I were her manager, would I deduct points for -2000 LoC? Would I praise her for taking copy-pasta and making a pattern? I know which I'd choose.


Number of lines is actually a pretty good (though imperfect) measure of how difficult a code base is to work with, which is why many developers are delighted by the opportunity to delete code.


How else do you determine what amount infringes? One of the four factors is "The Amount or Substantiality of the Portion Used".


I'm actually ok with that metric in this case as it's easy for judges to understand and it's actually a good proxy.


LoC is an old and classic software size metric. It's not perfect, but not completely useless either.


Objective measures are better suited to uniform application of justice vs subjective ones.


So if I copy the entire A volume of Encyclopedia Britannica, but leave B-Z alone, I'm good?


No but it’s okay to copy all the entry names in the encyclopedia and fill in the content yourself


Wikipedia already does this. For instance, there is currently a list of Australian Dictionary of Biography articles missing.[1]

I maintain a reflist of women in the ADB who have no Wikipedia article.[2]

1. https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Australi...

2. https://en.wikipedia.org/wiki/User:Chris.sherlock/Australian...


I think all entry names in encyclopaedia would fall under collection of facts that is not copyrightable... Same goes for recipes. I don't see how list of words existing and being used would qualify as work under USA copy-right. The entries themselves though are likely in many cases protected, but likely not all.


This is an excellent metaphor but now I am curious, is it literally true?


Would have to be tested in court.

Certainly, the fact that competing encyclopedias exist, and have for hundreds of years, with > 99% identical entry names (but of course, substantively different content), and that predicated not on any given invention or IP but rather the common use English language, would, I think, make the judges rather reluctant to rule differently even should there be 100% match in entries.


Two distinctions come to mind: the encyclopedia text doesn't have a "functional purpose" in the same way as the implementation of an API does, and thus there isn't a market of users who have pre-existing skills with encyclopedia entries that they could put to use if the entries were copied to another platform. In my non-lawyerly reading of the first bit of the decision it seemed they leaned on those aspects quite a bit.


Probably not? The crux of the opinion seems to grant fair use because it enabled a "new and transformative use," which is a box that a different line of encyclopedias doesn't seem to check.


Yeah I was giving an analogy similar to what Google is doing, but I am not sure of the legality of the exact case


Yes.


are you clerking for Justice Thomas, perchance?


So if Java had just bloated their code and those apis code footprint represented a larger % of the overall they’d be guilty? Or if Java trimmed a bunch of non essential packages into modules/extensions Google would be guilty

It seems to me the judge is saying, “the house was full of 10 tons of jewelry but the robbers only took 10 pounds so that isn’t really stealing lol “


Copyright and fair use is a nuanced balance between giving copyright owners the ability to restrict the actions of the rest of society and encouraging the creation of works that will more than balance out the onerous restrictions undertaken. A situation not all of us even agree on.

The class of actions classified as fair use describe situations where arguably society can loosen the reigns to substantial benefit to society without destroying the incentive to create.

A classic example would be quoting books to discuss them. The free exchange of ideas greatly enriches society while encouraging not replacing readership.

Reducing it to an analogy to physical property obscures instead of enlightens because it misses all the ways a copyright is different than a right to physical property.


> So if Java had just bloated their code and those apis code footprint represented a larger % of the overall they’d be guilty?

Under the fair use doctrine, maybe. Fair use in the US is literally about being able to use "limited" parts of a copyrighted work without getting permission from the copyright holder. What is "limited"? It depends, but 0.4% could reasonably be called limited.

> It seems to me the judge is saying, “the house was full of 10 tons of jewelry but the robbers only took 10 pounds so that isn’t really stealing lol “

Copyright and fair use apply to the creative substance of the work (in your example, the design on the jewelry, perhaps), not to physical instances of it (the actual pieces of jewelry in the house).


More like 10 million pages of books, Reading 10K pages does not mean one stole all the knowledge.


I think this part here is important regarding your interpretation — it‘s not just about loc

> Google copied these lines not because of their creativity or beauty but because they would allow programmers to bring their skills to a new smartphone computing environment.


Now the jewelry stores will have to become smaller so that there will be 1-2 jewels per store. When something gets stolen, it'll be 50-100%.


Who is this "Java" you're personifying?

Perhaps the measurement should have been a count of bytecode instructions rather than lines of code.


> "Google copied approximately 11,500 lines of declaring code from the API, which amounts to virtually all the declaring code needed to call up hundreds of different tasks. Those 11,500 lines, however, are only 0.4 percent of the entire API at issue, which consists of 2.86 million total lines. In considering “the amount and substantiality of the portion used” in this case, the 11,500 lines of code should be viewed as one small part of the considerably greater whole. As part of an interface, the copied lines of code are inextricably bound to other lines of code that are accessed by programmers. Google copied these lines not because of their creativity or beauty but because they would allow programmers to bring their skills to a new smartphone computing environment."

> Sanity prevailed! This judgment could have had devastating consequences and turned software development into a copyright nightmare.

This judgment is the equivalent of someone taking a movie script, shooting a new movie out of it without changing a word, and the court declaring this "fair use" of the script.

Software development wouldn't have turned into a nightmare unless you decide to steal a platform. Which most people don't need to do in order to do their work.


Not a great analogy. People aren't looking to make "interoperable movies". But let's play that out for a moment. Would a copy of star wars with different actors, different scenic design, different music be much of a salable product? I don't think so.

While I think it would be GREAT to see what Nick Nolte (Lucas was considering him) would have done with Han Solo over the wooden Harrison Ford, I'm not sure I care enough to sit through it all again to find out. Blech.


Actually it's been done randomly. Usually it's Hollywood remaking some not-made-in-the-us movie because they think they can do better, and failing.


Seems appropriate to create a burner account when you are this wrong and you know it. This is why many of us would like an easy ability to block greens.


Do you feel like Wine, Linux, or any web browser is also "stealing a platform" from Windows, Unix, or Netscape?


> This judgment is the equivalent of someone taking a movie script, shooting a new movie out of it without changing a word, and the court declaring this "fair use" of the script.

Ethics aside, as a viewer, it'd be kind of cool if this were a thing. Small-time movie makers might like it too.


Shot for shot remakes have been a thing for half a century. https://en.wikipedia.org/wiki/Shot-for-shot

In fact, they've become a fannish pastime the past few years: https://www.theverge.com/2017/7/20/16006112/revenge-of-the-s...


I don't think it's fair to compare a programming interface, which is more analogous to designing something like the plumbing architecture for a house, to a movie script, which is art. Yes, a well-written API can be considered art, but with the plumbing analogy, a "copy-cat" would just be making sure the same pipes are connected to the toilets in the same positions. What's going on under behind the dry-wall wouldn't matter.

Movie scripts and APIs aren't really comparable as you have presented them.


Bad analogy, architecture schematics are subject to copyright and you can't just take them and use them, either.


People can and do steal architectural patterns all the time for reuse in their own structures. Are your getting it wrong on purpose?


Not wholesale, anyway.

This decision suggests you could include say, the negative of the neighboring building’s facade so that the two “interoperate” in a sensible way.


Maybe it is the same as using a similar plot, but with 0.4% of code lines being the same I think the analogy doesn’t carry through to using a script word for word.


[flagged]


Please don't post in the flamewar style to HN.


yes and most of the api is similar or copied from programming languages that came before java.


I think you're also ignoring the "transformative" clause written into the fair use doctrine in the US.

...the extent to which the use is transformative. In the 1994 decision Campbell v. Acuff-Rose Music Inc,[13] the U.S. Supreme Court held that when the purpose of the use is transformative ... is more likely to favor fair use.


Your example is more like rewriting GCC in Rust and then claiming it no longer needs to be GPL. What Google did would be like writing a set of stock superhero character descriptions and then releasing them under a Creative Commons license so that other movie writers could use them in their movies.


I spy an Oracle employee.


I think you missed the rationale for fair use.


It's interesting reading Thomas' dissent. As per typical Thomas appears to be arguing that it's the letter of the law that matters, whereas it's the majority opinion that the motivations and substance of the law are primary.

Hackers and programmers tend to try and read the law like computer code to be "hacked" and exploited based on the letter of the law. So you'd expect us to be more sympathetic to Thomas' view. So this is a great example to smack hackers with when they try and "hack" the law, treating it like code rather than something more human. It's a great example because this is a case where the majority is obviously the "right" decision to any true code hacker.


No, when the code allows an exploit, that's a bug. Thomas is supposed to help us understand the intent of the code - what the Requirement was. Yes, it's better for us if the code reflects the intent perfectly. But to the degree that's not possible, we need someone to Interpret the code.

Textualists are trying to ignore the fact that there's a difference between intent and implementation.

The Legislature should do a far better job making their intent clear. But to the degree they make mistakes, leaving the intent unclear in some situation, it's good to have Case Law to inform us.

I am not a lawyer. I don't know much about the law. But I do know metaphors, and when someone talks about exploiting the law, this is what comes to my mind.


Tangent, but you said something I find really telling, in conjunction with OP's post.

Textualism to its proponents is very much like exploiting a system; figuring out the exact rules it defines and finding workarounds. It may not even be to a person's own goals (hence the individual not feeling biased when thinking this way), but is enjoyable in its own right in finding those loopholes (like the meme of the referee allowing Airbud to play, "there's nothing in the rule book!").

To its critics, it's like blindly implementing the ticket as written, rather than asking questions and making sure the intent is understood and the problem is being solved correctly.

Which explains, in a surprisingly empathetic way, why I am not a textualist, and why some of my family are, when it comes to political discussions.


My understanding of strict textualists' arguments (especially Gorsuch), is that they view it as a separation of powers issue.

By only looking at the text of the statute, the Court—which consists of unelected officials with lifetime terms—is trying to limit its power. If the text is unclear, they feel it should fall on elected officials to clarify it.


Certainly, but there's a problem with that. Because an outcome will still happen; an outcome determined by the law, -and its interpretation-. Even an interpretation of "we should (overturn lower court's decision/uphold lower court's decision) because the law is unclear" is an interpretation of the law.

After all, it is as equally fair to say "The wording of this law leads us to a clear understanding of the intent to mean X, and if the legislative body feels that to be in error they should pass new legislation to clarify it" as it is to say "The wording of this law leads us to an unclear understanding, and irrespective of intent we will decide !X until the legislative body passes new legislation to clarify it".

While the non-textualists may be explicit in trying to understand the intent of a law in accordance with their own biases, the textualists are still interpreting the law according to their own biases. There have even been some...really interesting cases of logic to try and do so (i.e., earlier generations' understanding of 'sex' matters when interpreting anti-discrimination statutes, but earlier generations' understanding of 'gun' does not matter when interpreting the 2nd amendment). It's incredibly rare (pretty much unheard of in the case of a few of them) for them to decide against their own predictable biases because a law is ambiguous, or a situation is novel.


> At least at the Supreme Court level, whether a justice professes textualism, purposivism, intentionalism, or pastafarianism as a method of statutory interpretation is likely to play less of a role in his or her decisions than ideological druthers. None of these approaches or any other is close to fully determinate, giving a good deal of room for a judge's values to play a major role. Moreover, even when a methodology appears to point reasonably clearly towards a result, judges sometimes disregard their methodological commitments in favor of their ideological ones.

http://www.dorfonlaw.org/2016/06/does-textualism-have-bias.h...

Here's Richard Posner on Scalia:

> Does an ordinance that says that “no person may bring a vehicle into the park” apply to an ambulance that enters the park to save a person’s life? For Scalia and Garner, the answer is yes. After all, an ambulance is a vehicle—any dictionary will tell you that. If the authors of the ordinance wanted to make an exception for ambulances, they should have said so. And perverse results are a small price to pay for the objectivity that textual originalism offers (new dictionaries for new texts, old dictionaries for old ones). But Scalia and Garner later retreat in the ambulance case, and their retreat is consistent with a pattern of equivocation exhibited throughout their book.

> One senses a certain defensiveness in Justice Scalia’s advocacy of a textualism so rigid as to make the ambulance driver a lawbreaker. He is one of the most politically conservative Supreme Court justices of the modern era and the intellectual leader of the conservative justices on the Supreme Court. Yet the book claims that his judicial votes are generated by an “objective” interpretive methodology, and that, since it is objective, ideology plays no role. It is true, as Scalia and Garner say, that statutory text is not inherently liberal or inherently conservative; it can be either, depending on who wrote it. Their premise is correct, but their conclusion does not follow: text as such may be politically neutral, but textualism is conservative.

https://newrepublic.com/article/106441/scalia-garner-reading...


...sic that most American of phrases, getting off on a technicality.


In the D&D world that I'm familiar with, we call these sort of people "rules lawyers", and there too, they ruin the game for everyone.


Oh, 100%. I shared Thousand Year Old Vampire with a relative that matches this, thinking his love of history would make it an interesting thing, and his response was "I can already think of ways to beat the system", even before he actually read the system. It's like...yeah, it's a single player pen and paper RPG. You probably can. Why...why would you though?

But that's what I mean; exploiting perceived flaws in the system is a greater goal -even when it ruins the game for themselves-. Because there is a greater sense of satisfaction in finding loopholes. And I understand that sense; I just find more value in understanding the underlying goal and intent and delivering on that.


Textualism invariably turns out to be a shuck: people who claim to be textualists are textual only when they can find a way to make textualism produce the answer they wanted.

Legal language is slippery enough that this is almost always possible. On the few occasions when it is not possible, we learn the truth. Scalia famously revealed his true colors on occasion.


>The Legislature should do a far better job making their intent clear.

That would require a wholesale redesign of creator's monopolies in software; CONTU basically said "oh yeah, judges can just use fair use to wriggle out of any market harms software copyright might cause" and Congress went with that.

Furthermore, Congress's actions over the past few decades have generally not squared with any sort of actual copyright reform. The last major actions I can think of were:

- Implementing the EU's reciprocal copyright extension so that Mickey Mouse could get more copyright protection in France (Sonny Bonno CTEA)

- Implementing an overbroad and policy-laundered set of protections for DRM that companies took to mean "all you have to do is put software in a thing and you can sue anyone for making parts for it" (DMCA 1201)

- Extending criminal copyright liability to filesharers (NET Act)

- Granting more copyright term extensions to old music recordings that weren't federally copyrighted until the 70s (CLASSICS Act/MMA)

The last thing I would ever want is to hear Congress's intent on any of these, as I would imagine it would sound something like "Fuck you, pay me". Australia, the EU, and the UK get a lot more shit these days for overbroad copyright laws, but this is mainly because doing so lets them rein in foreign tech companies. The US doesn't do that anymore because tech companies gained enough clout here to stop even more misguided copyright nonsense like SOPA/PIPA. However, with tech companies falling out of favor I wouldn't be surprised if Congress decides to start busting kneecaps again.


> Textualists are trying to ignore the fact that there's a difference between intent and implementation.

I would say that they are not so much trying to ignore the fact as acknowledging the fact but taking the position that it the court's role to interpret the implementation, not to guess at the intent.


And to complete their viewpoint, it is the legislature’s job to patch “exploits” by rewriting the code (laws).


Lower courts: "Wait, did you mean LESS THAN, or LESS THAN OR EQUAL?"

Supreme Court: "For now, we'll presume LESS THAN OR EQUAL."

Legislature: "Wait, we meant LESS THAN."

We need a decision NOW. The Supreme Court supplies a decision NOW. The Legislature can change it.

Interpreting the implementation demands guessing at the intent on the edge cases. It can't not. Even if your preference is to always pretend the language is absolute.


The legislature can't fix all bugs. Case Law exists for a very good reason.


Case law doesn't exist in a majority of the world and somehow these legal systems work nonetheless, in at least some instances even arguably better.

https://en.m.wikipedia.org/wiki/List_of_national_legal_syste...


> Textualists are trying to ignore the fact that there's a difference between intent and implementation.

It is actually the opposite. Textualists say that intent doesn't mean squat. Originalists will consider intent. Textualists say that intent is unknowable and therefore you must exclusively use the text of the law, regardless of how stupid that might seem.


> Textualists say that intent doesn't mean squat. Originalists will consider intent.

In practice, textualism and originalism aren’t all that different, because most of the same indicia that originalists will look to for signs of “original intent” textualists will look to for signs of what the words of the text mean in their original context (textualists are not, as a class, blind to context). While different observers will weight the individual indicia differently, the variation within the textualist and originalist camps on this is more significant than that between the camps. The camps really mostly differ in how they tend to frame arguments from the same facts to the same conclusions.


I blame Textualists for the existence of legalese.

Laws and contracts are so damn hard to read because they need to close every possible conceivable loophole. You get sentences that use multiple synonyms of the same verb because someone is going to come up with some strange incredibly-specific difference between them.

Imagine some parent telling their kid to not jump on the bed, and the kid says "I'm not jumping, I'm hopping!". That's a kid that's going to grow up being a Textualist.

> Textualists say that intent is unknowable

I think Textualists are claiming this in bad faith, knowing damn well that intent is very well knowable, but argue otherwise to advance their agenda.


Thomas's analysis pretty much starts from the conclusion that Google made billions off of Android, so therefore how could anything it be copied be fair use? He cloaks this analysis somewhat by arguing that the distinction between declaring and implementing code must be meaningless because Congress didn't lay it out explicitly in law, but for the person who actually broached the question of what other factors might influence fair use during oral arguments, it's pretty unintrospective about the analysis itself.


The argument from the text could go the other way: Congress didn't mention declarative code in the copyright act, so it's not included.


Thomas says the copyright act says any computer code called directly or indirectly. The Thomas argument is that this is an indirect use of code.


Thomas doesn't understand basic computer programming, so I wouldn't put much weight on that nuanced view.

"Indirect" here just means calling a function or jumping to some address, rather than directly inlining some statements.

For the purpose of copyright, the term "computer code" does not include the signature of that function, or the address you jump to, only the actual code statements at that destination.


Which, I would argue, is out of step with how that language was understood at the time the legislation was drafted.


He probably owns a bunch of Oracle stock


Justices routinely recuse themselves if they own stock in a company arguing before the court.


Thomas didn't recuse himself when ruling on court cases filed by the advocacy group his wife is a leader of. It's all voluntary, if a Supreme Court justice chooses not to recuse themselves there is no higher court to force them.


Note, a lot of these "x legislator owns y stock" stories actually turn out to mean "x legislator owns a whole market index fund".


Thomas aggressively refuses to recuse himself from cases that other justices consider an obvious conflict of interest.

But they have no authority to enforce their opinion, and Thomas absolutely doesn't care. He didn't become a judge to rule on things he has no opinion on. For him, conflicting interest makes it that much more important to keep his hands in.


If I were attributing bad faith to Thomas - and given that he ignores court norms on recusing himself, that doesn't seem like too much of a stretch - I would be more likely to ascribe to him a desire to see "liberal Silicon Valley" punished than anything else.

Thomas is an incredibly political beast, to the point that Scalia wrote him off as an unprincipled nutjob.


I'm normally with the textualists on the court on the question of how we interpret the law, but in the case of copyright, the concept of "fair use" is specifically intended as an "extension point" where the courts could do what seemed right in changing circumstances. I like strongly typed languages too, but there are legitimate uses for void*.


That's a very good summary. This is a case where there probably is no legally "correct" decision based on the law/precedent. It comes down to fair use and to what degree you can reasonably extend it to this case. For most people reading this, the decision is the "right" one. But I'm not sure to what degree one side or the other is better supported as a matter of law/precedent.


I strongly agree with the outcome but the cost in the other direction is good API design is a creative process. If you sit down and design a kick-ass API for a year, another person who re-implements is inheriting that design, and its benefits, for free. I do wonder if another case will wind its way up one day where the defendant lifted the API not for interoperability but because it was a clean or clever interface. (Seems a bit far fetched but would round out fair use further I think.)


The majority opinion cited precedent (Feist) that copyright is not intended to profit the creator. It's to advance the progress of arts and sciences. If someone copies your amazing API, that sucks for you, but it's not stopping the progress of arts and sciences.


Yes fair point I misread the OP that they were strictly talking about the legal tradeoffs. I was more thinking what was the actual cost to creators under this version of fair use.


They kind of intentionally danced around that question with 'are APIs copyrightable'.

Because here it's allowable for a product that isn't competing, and is being leveraged for interoperability/ease of users to adopt (rather than for how clean/clever it is).

What if someone had copied Stripe early on, though? Stripe's big claim at launch was "payment processing in 7 lines of Javascript" or similar. Obviously there were other barriers to entry, but what if someone else entered the market at that time with a similar (or even identical) interface? That question was left unanswered.


Even if that happens, we'll still get beautiful APIs made. Copyright is a means to an end. Fonts, for example, are not subject to copyright, but we still see beautiful typefaces made.


> the concept of "fair use" was specifically intended as an "extension point"

Yes, but to a textualist how the law was intended doesn't matter! (I'm mostly joking, I agree with what you meant to say here, I think.)


> Hackers and programmers tend to try and read the law like computer code to be "hacked" and exploited based on the letter of the law.

Speak for yourself. There are plenty of us that understand you can't take the human element out of this.


They said “tend to”...


I think you're reading a different argument. Thomas's argument is circular dreck. It basically says:

1. An important fair use test is market effects. 2. Amazon and others used to give Oracle huge gobs of money because they feared that APIs might be copyrightable and not covered by fair use. 3. After Google called Oracle on this, Amazon and others also started believing it was likely fair use and stopped paying Oracle tens of billions per year. 4. Therefore, Google copying the API was a major adverse market effect. 5. Therefore, copying wasn't fair use.

That's a shit argument. Watch me do a similar analysis in a more obvious way.

1. An important fair use test is market effects. 2. People used to pay gobs of money to watch the movie Transformers 2. 3. In a widely watched review of the film, I showed a 4 second clip of the movie where someone said "I am standing directly beneath the robot's testicles." 4. After this, nobody wanted to pay any money at all to watch Transformers 2. 5. Therefore, there was a major adverse market effect from my copying. 6. Therefore, copying wasn't fair use.


> It's a great example because this is a case where the majority is obviously the "right" decision to any true code hacker.

https://en.wikipedia.org/wiki/No_true_Scotsman

Have you spoken to any professional language or API designers about this case? Would all "true code hackers" agree that copyright shouldn't apply to software at all?


Obviously, I cannot say anything about "all" API designers, but I've read the opinions of a good few of them, including some who wrote the APIs in question here (i.e. the Java SE APIs), and they were unanimous that making APIs copyrightable would be a horrible idea.


There is a massive difference in interpreting law vs code. Code can be patched immediately. New laws or changes to an existing law can take months, even years or decades to pass.


Judge Thomas is terrible.

He simultaneously says that corporations have First Amendment rights to donate unlimited money to politicians, but have no First Amendment rights to moderate content on their social networks.

He's a hack that just does whatever is best for conservatives.


If your worldview is this simple, it is also probably very wrong.


Being concise isn't simplistic.

I explained very clearly what the contradiction in Thomas' rulings is which leads me to my conclusion.

You can have an opinion about whether that's right ... but its hardly simplistic.

Being simplistic would be having the view that he's a hack without any evidence.

I don't say he's a hack lightly. If you look at his decisions he uses one path of reasoning in one set of decisions and then uses the opposite path of reasoning to come to a different conclusion in a different set of decisions, depending on how the outcome needs to come out. And then he claims he's being textual. Its nonsensical.

Edit: TBF you're being very simplistic assuming my comment illustrates a worldview. What worldview is that? Look at my comment history. I'm generally free-market and maximal-corporate rights ... aligned with Thomas. I just think his reasoning is flawed.


"Following the letter of the law" means ignoring Congressional intent. It allows the judge to choose one of the many possible readings of a statute.

So in effect, "following the letter of the law" enlarges a judge's discretion. The opposite of what you would expect.


No, not generally. Congress is 545 different people, who definitely don't have a coherent collective intent. The only thing they did collectively was pass the text of the law.

So any coherent notion of "congressional intent" has to mean the intent a person reading the text would infer about a hypothetical coherent author. I don't know anything about this particular case, but it is not at all true in general that there are more ways for a reader to interpret the explicit meaning of the written words than there are ways for a reader to interpret the intent of the written words.


I think the intent is usually found in statements made by drafters of the legislative language. Intent is not packaged in the raw text of statute.


You can of course try to infer intent of individual drafters, or by looking at the transcripts of debates on the congressional floor, or by reading emails, or whatever. (I don't think this justified because these discussions aren't voted on, only the text of the law is, but I'm happy to put that aside as not everyone agrees with that perspective.) My point is that this needn't, and indeed generally isn't, a single coherent position, but rather is an incoherent mishmash of many competing interests. It will almost never be less ambiguous than the literal meaning of the words written on the paper, which is the claim I'm responding to. (You can certainly argue that it is better to follow this intent than the literal meaning, but that's different than the claim that the intent is less ambiguous.)


And to be clear: intent definitely can be in the raw text. If the whole text of a statute is trying to outlaw a certain kind of activity but one sentence undermines it all under a literal reading (e.g., by excluding all possible people it might apply to), that sentence will be re-interpretted to what it needs to mean for the law to be applied.


Which of Breyer's clerks drafted this? They clearly understand many tech issues and I hope they find their place on some Federal circuit to herald an era of logic in tech law.

"Google’s limited copying of the API is a transformative use. Google copied only what was needed to allow programmers to work in a different computing environment without discarding a portion of a familiar programming language. Google’s purpose was to create a different task-related system for a different computing environment (smartphones) and to create a platform—the Android platform—that would help achieve and popularize that objective. "

...

"Here the record showed that Google’s new smartphone platform is not a market substitute for Java SE."

...

"Google copied these lines not because of their creativity or beauty but because they would allow programmers to bring their skills to a new smartphone computing environment. "

...

"the Court concludes that Google’s copying of the API to reimplement a user interface, taking only what was needed to allow users to put their accrued talents to work in a new and transformative program, constituted a fair use of that material as a matter of law. "


"Held: Google’s copying of the Java SE API, which included only those lines of code that were needed to allow programmers to put their accrued talents to work in a new and transformative program, was a fair use of that material as a matter of law."

If the un-italicized is the new test, that's probably the most reasonable thing I'm going to read this month. And it's only the 5th.


They didn't establish a new test, they applied the existing 4 tests / factors and found that they indicated fair use. The first 2 or 3 pages contain a description of the 4 tests and how they were found to apply in this case.


Not entirely. Per my understanding, this is a fairly big shift:

"The fair use question is a mixed question of fact and law. Reviewing courts should appropriately defer to the jury’s findings of underlying facts, but the ultimate question whether those facts amount to a fair use is a legal question for judges to decide de novo. This approach does not violate the Seventh Amendment’s prohibition on courts reexamining facts tried by a jury, because the ultimate question here is one of law, not fact. The “right of trial by jury” does not include the right to have a jury resolve a fair use defense."

Or to put it another way, convincing a jury that something is or isn't fair use is very different than convincing precedent-bound judges, especially with this on the books as the controlling case.

In final impact, it seems like an incredibly good judgement for everyone: you can prove to a jury what was / wasn't copied, and then a judge will apply a standard fair use test over those facts, with a tendency towards allowing transformative use.

Legal protections against copying, room for progress, and (most importantly!) more certainty and standardization in how cases are decided.


That analysis is addressing an argument that the Supreme Court could not overturn the finding that it was not fair use. That argument was based on the Seventh Amendment's reexamination clause. The Supreme Court held that the reexamination clause did not prevent it from addressing this issue, because the question is a mixed question of law and fact, i.e., it's a legal conclusion based on evidentiary facts. The Supreme Court cannot re-examine the "underlying facts," but the Seventh Amendment does not preclude it from deciding, as a matter of law, whether those underlying facts constitute fair use.


It, or other reviewing courts. So the net effect will be to hopefully create more consistency around fair use defenses. Which is good for innovators.


That may be true, I remember there was quite a bit of surprise when the Court of Appeals overrode the fair use jury finding (not so much because they decided differently, but rather the fact that they set aside the jury's finding at all).


Well, it sounds like it's still the same test; it's just deciding that fair use cases must be decided by judges, not by juries. Which, as you say, seems like a good decision.


"Here the record showed that Google’s new smartphone platform is not a market substitute for Java SE."

Does this mean that companies copying the S3 API as a substitute for S3 are still untested territory?


Strictly speaking, yes - this decision, as many other SCOTUS decisions, is tailored to specific case and leaves the other situations to be argued on their own merits. But having definite precedent in the situation where API has been recognized as non-copyrightable both sends signal to the lower courts about where SCOTUS leans, and to the potential plaintiffs about their chances to ultimately prevail. It is not a definite solution for all cases, but it shifts the calculus to the side of "if you sue for copyright infringement about S3 API, it'd be an uphill battle for you and probability to lose is high".


And remember that Fair Use is a four-part balancing test. Thus, a single factor shifting will still have to be weighed against the rest. Also, for the S3 APIs, you're also talking about using even _less_ of Amazon's copyrighted code (e.g. a dozen function signatures compared to millions of LoC).


Theoretically, yes. But such companies would also have the ability to argue that their API was fully interoperable with S3, a factor counseling in favor of fair use. Google could have talked about interoperability in this case too, but for some reason didn't; see my other comment [1].

https://news.ycombinator.com/item?id=26701488


Another way to read that would be that the S3 API isn't a substitute for S3, and so another company using the S3 API could be fine so long as they don't copy the code for S3 itself?

My impression is that this is probably nuanced enough we need to read past the syllabus if we wanted to really unpack the reasoning. I can't tell which is the key part from which to make an analogy.


Breyer has actually been writing on these issues for quite some time; see for example his article "The Uneasy Case for Copyright: A Study of Copyright in Books, Photocopies, and Computer Programs" [0] -- published in the Harvard Law Review in 1970. His overall body of work demonstrates a pretty good understanding of the underlying technical issues, and he has been a reliable ally on the bench in this area.

[0]: https://www.jstor.org/stable/1339714?seq=1


"Here the record showed that Google’s new smartphone platform is not a market substitute for Java SE."

Well that nukes it. The courts took how long to identify this precedented principle? It seems like the rest of the opinion is just there to ward off more of this tomfoolery for people that don't get it.


The lower courts have been frankly awful about refusing to acknowledge the rulings that SCOTUS has been handing down about software and technology in general. For example Alice Corp v CLS Bank International basically put an end to the validity of "[generic idea or business method], but on a computer" patents and the lower courts have basically said "haha ok great but we're not doing it", continuing to rule on "on a computer" patents as if they were valid, and with the patent office continuing to issue such patents.

Obviously this is copyright vs patent law but it goes to establish that there's been a big problem with the lower courts on "computer laws". It's a nexus of the problem with jurisdiction-shopping (finding a lower court that wants to keep lots of cases coming in and is willing to pump out questionable decisions to do so) and just the legal system being about 30 years behind the times in general in terms of understanding computers and how innovative a particular idea may be.


> Which of Breyer's clerks drafted this? They clearly understand many tech issues and I hope they find their place on some Federal circuit to herald an era of logic in tech law.

Breyer also has a brother who was a District Court judge in the SF Bay Area who's undoubtedly had to deal with various tech cases. Not saying there's any kind of shared knowledge of tech within the Breyer family but just kind of interesting.


It is not publicized which of the Supreme Court clerks helped author an opinion, for definite reasons.

What you will likely see is in a couple years, one or two of the clerks start to appear as law professors or judges involved in such cases.


Why do you think Breyer and the other assenting justices wouldn't be able to come to this kind of decision without a clerk taking the lead?


Knowledge of how the justices work.

The way that the Court and every one of the justices work is that he/she will draft out with the clerks the broad principles and approach that he/she wishes the decision to be crafted around. Which cases influence the precedent, which regulations take what role in the decision, what issues to "turn" the case on, etc.

It's the job of the clerks then to go research, summarize, and create the bulk of justice's position based on knowledge of the details. They (justice + clerks) then review and talk about the evolving draft opinion several times over the course of months, circulating drafts to the other justices (and their clerks) as well. And note, most of the facts/issues already came up in the lower courts cases and rulings, so there has already been some fair surfacing of the details of the dispute (and what other judges believe the important issues to be) as it made its way through the system.

The justices have many opinions per term to do this for, and you can be very sure that while the "authoring" justice has been briefed on (and very well has tested the ideas with the clerks in detail), the summary of how APIs work and their legal status is not based on the justice him/herself wading through license agreements and "figuring out" the structure of the code or its legal status.

So, that is not to say that the justices are ignorant of the details (far from it), but the level of detail needed to form the groundwork of the opinion is heavily shouldered and created by the law clerks. But the main conclusions of the opinion are definitely of the justice him/herself (with input from the clerks).

-- By the way, the clerks (you may not realize) already have had a role in getting the case even to be heard before the Supreme Court, in briefing and summarizing the underlying appealed case on why it should be ripe for a decision, so they already many of the issues at stake and how to think about them.

Maybe think of it like a software engineering manager and the individual developer. The manager can lay out the principles by which a certain piece of code is to be written, and the capable developer will identify all the issues, test cases, etc., and they will review it together at various stages. You would not say that either could have done it without the other. It's kind of like that (when software engineering works like it should).


I believe the parent commenter was highlighting the particular wording of the opinion, rather than the actual decision itself.

One could imagine an opinion supporting the same decision with less clear or precise language. As I understand the process, the opinion was frequently reviewed and advised by Breyer, but actually written by one of the clerks.


Acknowledgement of the actual process of drafting opinions like this?


Thinly veiled ageism.


I think you might be surprised at how deftly Supreme Court justices are able to see through specific tech issues to identify the core dispute at hand and how decades-old laws and regulations should (or should not) apply.

If anything, they are even better with age at not getting confused by increasing technical detail of our API era, and making sure that the principles of law cut through that. (and how to structure a decision so it's clear to everyone)

If you relied on a tech-heavy decision to be made, this would not be a Supreme Court issue.


How much precedence does this carry for other cases or does each instance of "fair use" need to be evaluated by the Supreme Court before we know if it was legal?


Precedent works by analogy. What matters is not just the outcome of a particular case, but the reasoning. When similar legal questions come up in future cases, lower courts are required to cite this case and follow the same reasoning, to the extent the reasoning applies to the facts of that case. Of course, no two cases have exactly the same facts, and different facts may produce a different outcome. But if a future case is similar enough to this one, the lower court will be expected to compare the two cases and explain why the differences in facts justify a different outcome.

No legal question is resolved for sure until it reaches the Supreme Court, but most cases never make it there, instead being resolved by lower courts applying higher courts' precedents.


UPDATE: based on Wikipedia [1], the "API" was likely saved by one of these people (all likely in their mid-20s!):

Emily Barnet, 2020, Yale (2015)

Diana Li Kim, 2020, Yale (2017)

Arjun Ramamurti, 2020, Yale (2018)

Daniel Richardson, 2020, Virginia (2018)

Brittany Jones-Record, 2020, Stanford (2016)

David Scott Louk, 2020, Yale (2015)

Elizabeth B. Deutsch, 2021, Yale (2016)

Joel F. Wacks, 2021, Chicago (2018)

[1] https://en.wikipedia.org/wiki/List_of_law_clerks_of_the_Supr...


A supreme court clerkship is very impressive, but "saved by one of these people" is strong. My understanding is the justices have a conference, stake out their positions, and then the chief assigns cases based on who can attract a majority to their opinion. So Breyer presumably had a rationale that could get at least 4 concurrences in conference. It's possible for the other justices to later change their minds based on the actual opinion the chambers produce, but that doesn't seem to be the case here. It's also possible the case was just assigned based on workload, considering the 6-2 split, almost anyone could have written it.

In other words, the clerks do the work of researching and fleshing out the finished opinion, but I don't think they have much influence on the rationale used to decide the case. I've heard stories of clerks having to write opinions they personally disagreed with.


Breyer was a prominent copyright law scholar before he became a judge. Between that, and the fact that he hasn't gotten many opportunities to write majority opinions in his 27 years on the court, and the fact that he's likely about to retire in a few months, giving him the opinion was the obvious and collegial thing for Roberts to do.

I'm biased, but I don't think the technical elements of this case were challenging to an intelligent layman. I think most people smart enough to become judges can understand the concept of an interface that is independent from an implementation, which is all this case really required, along with quantitative estimates of the amount of code involved. So I doubt that he needed clerks to understand any of it.


While the Supreme Court justice authoring the opinion will have laid out the broad principles and legal framework upon which he/she wishes to make the decision, the law clerks have a central role in crafting the opinion and making sure that the arguments and reasoning are sound.

By the very nature of the court's operations, the justices cannot be writing the 30 page opinion and doing all the research on every case. The clerks are the ones who will be writing most of the summary, determining how certain cases influence the current case, and laying out the draft logic. They'll have many sessions with the justice to test the logic and find edge cases, implications, and make sure that a decision affecting millions of people is sound. Basically debate and draft/redraft the opinion (with other justices + clerks as well) based on what they're finding as the drafting continues.

I would say the clerks are indispensable to the creation of the opinion's outcome.


While Breyer wrote the piece, it was a single majority piece, which means all 6 justices agreed on it. The other 5 justices and their clerks were all effectively editors on the majority opinion.


"The doctrine of “fair use” is flexible and takes account of changes in technology. Computer programs differ to some extent from many other copyrightable works because computer programs always serve a functional purpose. Because of these differences, fair use has an important role to play for computer programs by providing a context-based check that keeps the copyright monopoly afforded to computer programs within its lawful bounds."

This is EXCELLENT news for anyone in software development. Yay for Fair Use.


> computer programs always serve a functional purpose

The Court is apparently not familiar with much of my code :)


From the dissent:

> The Copyright Act expressly protects computer code. It recognizes that a “computer program” is protected by copyright... And it defines “‘computer program’” as “a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result.” §101. That definition clearly covers declaring code—sets of statements that indirectly perform computer functions by triggering prewritten implementing code.

Thomas seems confused here. An API (declaring code) is not a computer program. A computer cannot execute declaring code - by definition - because it is missing the implementation.

Declaring code does not "indirectly perform computer functions". Declaring code does not perform anything. It provides a reference, nothing more, for a compiler to match one computer program (the API client) to another (the API implementation).


This argument is hard to swallow:

> declaring code would satisfy the general test for copyrightability.. they are expressed in “words, numbers, or other verbal or numerical symbols

It is common knowledge that mathematical formulae & equations, which are also expressed in words, numbers, and symbols, do not have copyright protection.

> Copyright protection is therefore not available for... mathematical principles; formulas or algorithms

https://www.copyright.gov/circs/circ31.pdf

> public static int MaxNum (int x, int y, int z)

This is literally a mathematical formula, hence does not have copyright protection.


   public static int MaxNum (int x, int y, int z)
This is not a mathematical formula. It is a declaration of intent to name some code that takes three ints and returns an int 'MaxNum'. It says nothing about what the code can, should or must do.

Now, if you've come up with some novel way to perform some computation on three integers and produce an integer:

- you might be able to patent that procedure.

- you might write some code that performs that procedure, and you would hold a copyright over that specific set of code

- you might, I suppose, name your algorithm 'MaxNum' and declare a trademark over it

But I don't think any of those could prevent someone from writing

public static int MaxNum (int x, int y, int z)

in another codebase.

- your patent protection might limit their ability to make a substantially similar implementation of such a function

- your copyright protection might prevent them from literally copying your implementation word for word

- your trademark protection might prevent them from passing off their implementation of MaxNum as if it were yours

But in no way does this have anything to do with the uncopyrightability of mathematics.


When you get down to it, copyright is a whole bunch of contradictory rules. Courts decide every time there is a new kind of work, whether it is copyrightable or not. Trying to divine whether something is copyrightable by analogy to other kinds of works is a hopeless endeavour.


That was the case with computer software when it first became interesting to copyright. After all, it's just a series of instructions which are often not considered copyrightable. But, in general, copyright has carried over fairly naturally from the printed word to new types of media as technology advanced.


That literally is not a mathematical formula.


This is not a persuasive argument because, by your logic, function implementations are also mathematical formulas and everyone agrees that they are copyrightable.


The copyrightable part of them is the creative decision making used to organize the workings of the function itself, not the formulas. Two functions could have identical algorithmic performance, but be stylistically and semantically different, have been written independently, and neither would infringe on the copyright of the other.


An API design is also a creative and highly stylistic work. Anyone who has ever designed a large API, or suffered a poorly designed one, can attest to that. A bad design can work just as well as a good design.

Also, you are distorting the argument by making it about one method signature instead of thousands of interconnected types and methods that work together to present an ergonomic interface for the developer.


Arguably API design is the most creative aspect of programming. The space of possible interfaces is infinite, whereas function implementations are heavily constrained by the interface and often there is only a handful of ways to write an implementation for a given interface.

Two equally good programmers may come up with radically different interfaces. Whereas if given an interface and instructed to implement it, they are likely to converge to a similar implementation.


The quality of good/bad or ergonomic is insufficient to meet the threshold for copyright protection.

A table of baseball batting averages or telephone numbers is not copyrightable, no matter how good or bad it is organized.


An API design is plenty creative. The bar for what is creative enough to get copyright protection is extremely low, basically zero. An alphabetized phone book is literally the example people have to use for something that isn't.

There's a reason the Supreme Court didn't adopt the argument you are pushing and instead ruled on fair use grounds: It's a bad argument because a large API is clearly a creative work.


Function implementations are definitely not mathematical formulas. To see what I mean, check out any HN discussions on TLA+ syntax.

It’s when you see an actual mathematical syntax that you realize how different programming really is.

Not try to be tedious here, just pointing out that actually programming is different than math, even for a language like Haskell.


No, definitely not. Computer code is not a formula.

A formula is an idea. It describes the nature of something computable. It does not explain how to compute.

For example: https://en.wikipedia.org/wiki/Euclidean_algorithm

The programmer must understand the formula in order to write computer code that implements it. The result is a creative/expressive work which is copyrightable.


Consider the following:

gcd(X, Y) = X if X == Y or gcd(X - Y, Y) if Y < X or gcd(X, Y - X) otherwhise.

Is this a formula? Should this be copyright-able?


Of course not, this is math; it is not copyrightable.

It would have made perfect sense to Euclid.

Some computers can understand this and execute it as if it were computer code. That's amazing! Kudos to those compute language designers and compiler authors. But their ingenuity does not suddenly grant copyright protection to anything their clever compilers can now understand.


Any computable function can be written the way I wrote the function that is equivalent to Euclid's algorithm. Does it means no computable function is copyright-able or not copyright-able if written that way?


The law says nothing about computability (nice straw man) but it does say ideas and math are not protected whereas code is. My point is the API declarations at the heart of this case are not protected by law because they are examples of the former. Like a formula, they are ideas that describe what to do, but not exactly how to do it.

If you code GCD in a low-level computer programming language then of course you can claim a copyright on that code, but nobody owns the idea of the Euclidean algorithm.


Exactly. That argument would never fly in a court. I’m always amused when software people think they have some legal checkmate like “any digital work is somewhere in the infinite digits of pi therefore cannot be copyrighted.” That’s not how law works.


Yes, but neither is an API signature a formula. I was assuming the logic of the person I was responding to, to show that it could not be right.


Thomas may have phrased it badly, but his underlying point that declaring code in a program satisfies the 17 USC 101 definition of "computer program" seems sound.

Declaring code in statement based languages is (1) a set of statements, is (2) used directly or indirectly in a computer, and it is used (3) to bring about a certain result. That hits all the points listed in 17 USC 101.

This is trivial to prove. Take a program that works and remove the declaring code. The program no longer works. That shows that the declaring code is indeed being used by the computer, and it is being used to bring about a certain result.

That the declaring code is not directly used in actually calling the API is irrelevant. The "certain result" the declaring code is used to bring about is the compiler producing output that works with the API.


Declaring statements are pure data. "int add(int, int);" is a piece of data, not a series of instructions. It may as well be a 4-tuple: (int, "add", int, int). You could convert each class declaration to a series of 4-tuples and put it in a CSV file. Database rights are much weaker than copyright.

> Take a program that works and remove the declaring code.

Actually, it will work just fine, because you the implementation necessarily has declarations in them, and you can generate declarations from the implementation.


I think this is a poor argument. I could make this "data" argument about any computer program, or even any copyrighted work. E.g. every statement is an n-tuple that could be stored in a database.


I also took issue with that argument. I suppose you could argue that the declarations are statements for the compiler or JVM. But even then, there is a layer of translation that is problematic, in my opinion. If you were to say that

public int max(int x, int y);

Is a program that tells a compiler or VM to add an entry to its public symbol table that allows it to compile or execute third-party code utilizing this function, and that the declaration, by itself, then qualified as a computer program and could be copyrighted, where would you draw a limit? Would two different programs that produce identical assembly instructions infringe on each other's copyright?

What about system calls for an OS? For example, Linux system calls have names, but they also have numeric identifiers. If someone copied Linux system call names in a new BSD-licensed OS, would they violate the GPL? What if they only copied the numbers?

It's interesting to think about. I'm glad this was the minority opinion.


> Thomas seems confused here. An API (declaring code) is not a computer program. A computer cannot execute declaring code - by definition - because it is missing the implementation.

This standard doesn't really make sense, and the legal standard says nothing about executability. What about programs with external dependencies, or a code snippet? Those won't necessarily be executable in a self-contained sandbox, but I'd certainly consider them computer programs.

Also, per Thomas's dissent:

> The majority also belittles declaring code by suggesting it is simply away to organize implementing code. Not so. Declaring code defines subprograms of implementing code, including by controlling what inputs they can process. Similarly, the majority is wrong to suggest that the purpose of declaring code is to connect pre-existing method calls to implementing code. Declaring code creates the method calls.

He clearly has a much better understanding of APIs than some software engineers I've worked with.


> Declaring code defines subprograms

Absolutely not. No points awarded.

Declaring code declares subprograms. They are defined by the implementation.

> A declaration provides basic attributes of a symbol: its type and its name. A definition provides all of the details of that symbol--if it's a function, what it does; if it's a class, what fields and methods it has; if it's a variable, where that variable is stored.

https://www.cprogramming.com/declare_vs_define.html

> the purpose of declaring code is to connect pre-existing method calls to implementing code

That sounds mostly right to me. Without declarations, the compiler cannot connect the function call to the implementation. Thomas ignores a crucial idea that decoupling definition & declaration enables multiple implementations for the same declaration.

> Declaring code creates the method calls.

That's nonsense. I have no idea what this means.


"Declaring code" is a specific term of art used in this case. For an example of what they consider declaring code vs. implementation code, see page 38 of the decision which has a handy diagram and example.

> That's nonsense. I have no idea what this means.

He's referring to how the workflow for an API generally involves gathering requirements, writing the "defining code", and then finally implementing the functionality promised by the interface. From that perspective, the defining code determines what implementation code is created, rather than linking up already existing implementation code.


Agreed. In another part the dissent says: "The Copyright Act protects code that operates “in a computer in order to bring about a certain result” both “directly” (implementing code) and “indirectly” (declaring code)."

But a program that only declares functions never brings about a result.

Declaring code is just the recipe for how to invoke implementing code.


Even if it were computer code, I think the Majority argued that use of 0.4 percent of the code can be considered Fair Use. In films, textbooks, etc., I think (though I'm not certain) there's precedent that up to 5% of the product can be reproduced (copied) under Fair Use, for criticism, academic analysis, etc.


> Thomas seems confused here. An API (declaring code) is not a computer program. A computer cannot execute declaring code - by definition - because it is missing the implementation.

Yup, for all intents and purposes an API is just a data exchange contract between different software.


The court overall seems confused, but whatever, at least they didn't rule wrongly in favor of Oracle, so I'm happy our long national nightmare is over.

Specifically I'm less motivated to read more of the PDF when the opening says "The copied lines are part of a tool called an Application Programming Interface (API)." I don't think any programmer would ever describe an API as a tool. A program implementing an API, or talking to an API, sure, but the API itself, is not itself a tool or program.


>A computer cannot execute declaring code - by definition - because it is missing the implementation.

If you allow null pointer references to a declared variable, then it certainly can.

>Declaring code does not "indirectly perform computer functions". Declaring code does not perform anything. It provides a reference, nothing more, for a compiler to match one computer program (the API client) to another (the API implementation).

I strongly disagree. We understand the obvious difference between declaration and instantiation, as declaration brings a variable into existence while instantiation specifies the variable's value. Declaring a variable is ultimately based upon available language primitives.

Whether or not he realized it, Thomas draws out a deep philosophical element of computing. Consider the creation of a self-hosting compiler. Once created, this compiler has an identity. However, creating this compiler required the usage of other software tools, each of which have distinct identities. Once the compiler operates, its creating tools become unnecessary to it, as the compiler operates independently (though the broader system may not). His phrase "triggering prewritten implementing code" has full-stack implications, whereas the majority opinion considers scope.

To connect to hierarchical processing model of programming, the majority opinion says a top-level processing block is special, whereas Thomas says no processing block differs from one another.

From a business perspective, I agree with the majority. From a philosophical perspective, I agree with Thomas.


This case is about declaration of functions/methods, not variables.


It's generally about acceptable usage of "top-level" programming objects, of which an API is one.

A related concept which comes to mind is killing in self-defense. We may say killing is killing is killing, yet society acknowledges a limited set of circumstances where it becomes permissible. In both self-defense and this court case, the difference in permissibility is context within a broader system.


By the quoted logic, any data file (say, an image) would be considered a computer program.


Agreed. I read the dissent, but not all of the majority. Do they address this point?


This appears to be the "money quote":

We reach the conclusion that in this case, where Google reimplemented a user interface, taking only what was needed to allow users to put their accrued talents to work in a new and transformative program, Google’s copying of the Sun Java API was a fair use of that material as a matter of law.

Also, while I hate to just repeat things that have already been said, I feel compelled to say

"What a relief!"

because this would have been a complete disaster if they had gotten this decision wrong. In fact, I'm not sure "complete disaster" is a strong enough phrase to reflect what it would have meant for the software industry if this had come down the other way. So getting this looming disaster out of the way is a tremendous relief.


I'm glad for the verdict but this is such bullshit.

Google implemented exactly enough to create the illusion of letting people use their Java talents then dragged their feet with a half broken out-of-date language environment.

And they did all this to save money, not some sort of noble rebellion or clever hack.

> Sun offered a licensing deal of between US$30 and 50 million. Schmidt said Google would have paid for that license, but they were concerned that Sun had also requested some shared control of Android along with the fee.

A pittance for Google but that vague "some control" sounds really bad right? Well fortunately there's a history here and we know from past licensing deals (J++) this control is enforcing interoperability with other Java implementation. And of course Oracle spells that out pretty easily:

> Oracle states that Sun refused because Google’s intention was essentially to fork Java to a Google version of the language, and to prevent it being inter-operable with other versions, an idea which was “anathema” to the “write once run anywhere” basis of the language.

Google got a cheap license and the only stipulation was "don't fuck up the Java ecosystem by having your OS run Java-but-not-really" but that was too much for them and exactly what they ended up doing!

I don't know why people are acting like this is some victory of open source. Maybe a victory for open source, but championed by a greedy corporation that fragmented the Java ecosystem for years.

I wish Oracle could have taken another angle here, they deserved damages from Google for this. Google literally pulled a J++ and got away with it.


I don't know why people are acting like this is some victory of open source

I don't know that anybody is saying that Google did anything specifically Good or Just or Noble or anything. The celebratory aspect is more based on all the Bad Things that would have happened in the future if this decision had come down in favor of Oracle.


What bad things would have happened? This ruling specifically says that it was fair use, not that APIs are copyrightable - which seems to be the buggy man. As it currently stands, APIs absolutely fall under copyright laws.


Once you use someone's API, then they dictate where and when your program works, unless you rewrite your program to not use that API.

Given the countless and fundamental APIs that are typically used in any program, do you not think that is a Bad Thing?

Given that most programmers have assumed that to not be the case, it would be very bad for existing code at the very least.


Well, if you are looking at an API which’s license explicitly forbids copying, I would stay away from copying it. While this case do give a precedent, it is much more about this specific case being a fair use according to the supreme court, than on whether APIs itself are copyrightable.

Also, given most programmers’ assumptions, I would not base much on that alone :D But IANAL, so do ask one, to be safe.


>As it currently stands, APIs absolutely fall under copyright laws.

This opinion doesn't say so.

"We shall assume, but purely for argument’s sake, that the entire Sun Java API falls within the definition of that which can be copy-righted. We shall ask instead whether Google’s use of part of that API was a “fair use."


It would be dumb to declare true the opponent’s case in the argument, wouldn’t it?


No, it is a sidestep. Even if the code is copyrightable, it doesn't matter. The majority decided it was better to make a case for fair use than for the uncopyrightability of APIs. That's all.


My understanding is that the original problem was that there is nothing in law that makes a difference between actual implementation code and API. Otherwise it would have been a trivial case.

And even in this, they rather go with the easier fair use claim that is case-by-case.


If Android Java was illegal, it seems likely that GNU, Wine, OpenStack, the Mastodon client API, LibreOffice Calc, ... this ruling is limited enough that some or all of those might still be illegal, but at least the open source clone of `windows.h` that winelib distributes is probably safe.


What bad things would have happened?

It would have become MUCH more dangerous to provide an alternate implementation of someone else's library or interface, which I believe would have have a profoundly negative effect on the entire software industry.

As it currently stands, APIs absolutely fall under copyright laws.

Yes, but now there is a very strong precedent establishing the idea that copying those copyrighted API's is OK anyway (under Fair Use) under at least some circumstances. And based off the way the SCOTUS decision was worded, it strikes me (admittedly, IANAL) that the set of circumstances that are captured by this are pretty large.


IANAL, but it was always true that fair use made code exempt from copyright. Wine is alive specifically because of that.


This case would have changed that has the rolling differed.


That's literally the next sentence that you intentionally omitted.

And I've seen plenty of people paint Oracle as some evil boogeyman like this is some good vs evil struggle.

Oracle wasn't trying to make Bad Things happen. They were seeking damages from a damaging situation, and if bad things had happened... I'd blame the patent trolls and judges that enable them.

Their insanity continues regardless of the verdict after all, and there are plenty of otherwise reasonable takes ruined by their existence.


Oracle wasn't trying to make Bad Things happen.

I didn't say they were.

They were seeking damages from a damaging situation, and if bad things had happened... I'd blame the patent trolls and judges that enable them.

The issue at hand is about copyright not patents.

And note that I'm not saying that nothing bad can, or will, ever happen again. I'm just saying that the consequences of this decision coming down the other way would have been Very Bad, which makes the current decision a Very Good Thing in general.


Are you familiar with Oracle's business practices? They are indeed evil.

Google started out with the stated intent to not be evil but now they're allowing that possibly and are making good progress.


> I've seen plenty of people paint Oracle as some evil boogeyman

“Don't anthropomorphize the lawnmower.”


That's exactly it, except here I would say someone stuck their hand in the lawnmower and got away with it.

But people were upset the lawnmower tried to take the hand at all


That's a thorough miss-understanding and misrepresentation of the situation. It also has nothing to do with open source specifically.

Google never promoted Dalvik as being a licensed Java VM implementation and never claimed it was a compatible Java runtime. The license was for logos and trademarks. As long as they didn't use those logos and trademarks, there's no violation of the license for those things. The API case is based on copyright, not trademarks or licenses so is a separate issue.

This is why Microsoft could lose their dispute with Sun over the MSJVM which was a non-compliant JVM implementation, but still come out with J# which was an implementation of the Java language running on .NET.

Microsoft licenses the Java trademarks and claimed the MSJVM was an implementation of the Java runtime, while breaking compatibility requirements for the license. Therefore they were in violation of the license. The .NET platform was never claimed to be anything to do with Java, so having Java code run on it in the form of J# was fine. The situation with Google using the Java language running on Dalvik is exactly analogous.


This sounds like you read Jonathan Schwartz's testimony and almost misinterpreted it.

The license included using Java's name and trademark and that was for Sun's benefit, not Google. Google wasn't asking to call it a Java phone. That's why part of the testimony is actually Sun saying they'd pay for that

And the rest of your comment is completely missing the mark here.

You're saying MS was in the wrong with J++ because they licensed Java.

I'm saying MS was in the wrong because saying you're using language X then randomly not supporting parts of that language is a shitty thing to do when you have a large presence because then you start to fragment the language's user base.

Copyright be damned. (Which is exactly why I said I wish they could have taken a different angle)

-

Logo or no logo, for years Google said you program Android in Java.

Their "Java" did not track the language everyone else knows, using a strange smattering of features from 6 and 7 in this weird hybrid that hobbled along.

As a result there was plenty of confusion among developers about what worked on Android. As someone who has mostly held day jobs that involved Android for a decade or so now, I can confidently say it was problematic and Android dragging its feet while being such a large platform caused people to avoid using language features.

When Lambdas first landed for example, I remember multiple projects refusing to use them since there was no official way to support them on Android (retrolambda which was written by a former coworker of mine addressed this)

This is so simple, Android should have licensed Java, created a compatible implementation, and kept it up to date. Would it have been hard? Yes. Would it have been better for Android developers who ended up using wonky work arounds, people learning Java and dealing with two sets of rules, and the Java ecosystem as a whole? Also yes.


If Android's "Java" is so different, then how does Google benefit? The whole point of reusing an existing language is to jump-start the app ecosystem by allowing developers to make use of their existing experience.


It's just different enough to be damaging?

Like in Java 7 days Android didn't support NIO, randomly didn't support certain forms of exception handling, had random holes in library support (core Java libraries mind you, not the sun stuff)

The odds you could take a random XML parsing library for example and use it in an Android project were low. Random namespaces would be missing, cryptic errors tied to missing language support, the works.

Like you realize the idea of having a kinda-almost-the-same language being damaging is already known. J++ was not the same set of circumstances, but it shows that yes, you can make a language similar enough to benefit and at the same time be different enough to damage.

I mean literally QNX had better support through some vendor we were using at the time, but somehow Google couldn't do better?


Can you be more specific about the differences your talking about? As far as I'm aware, Google never added their own features to the language itself. Granted, they were a bit slow to support new versions like Java 8. They also chose not to support libraries like awt, but I wouldn't consider those part of the Java language; rather they're part of Java SE.


I already mentioned multiple above.


No, you mentioned things Google didn't implement. That's not the same as making it incompatible. In this case that would be Google adding things to Java, not skipping some.


I 100% agree that this is the right outcome. Any other outcome would be a nightmare for software developers and would inhibit the development of products.

But the dissent raises an interesting point. I think it shows how the crafting of legislation by people who are wholly ignorant of technology can create problems. While programmers recognize the difference between an API and it's implementation, Thomas makes the interesting point that the relevant legislation does not (page 4 of the dissent):

> Copyright law generally protects works of authorship. Patent law generally protects inventions or discoveries. A library of code straddles these two categories. It is highly functional like an invention; yet as a writing, it is also a work of authorship. Faced with something that could fit in either space, Congress chose copyright, and it included declaring code in that protection.

> The Copyright Act expressly protects computer code. It recognizes that a “computer program” is protected by copyright. See 17 U. S. C. §§109(b), 117, 506(a). And it defines “‘computer program’” as “a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result.” §101. That definition clearly covers declaring code—sets of statements that indirectly perform computer functions by triggering prewritten implementing code.

While it clearly is in the Court's prerogative to interpret law, there seems to be a pretty good case that the court didn't provide an interpretation for a gap in the law, it instead fixed a law that didn't make sense.


Indirect is there to protect code that uses an API, not the API.

Since it's API's all the way down, this is needed to protect any application on top of the BIOS/OS/HAL.

Otherwise, very little would be protected by copyright.

However, it's entirely possible that "indirect" is a word with a definition that is different to our understanding in legal documents.


The court made no holding on whether APIs can be copyrighted.

"We shall assume, but purely for argument’s sake, that the entire Sun Java API falls within the definition of that which can be copy-righted. "


Yes, a good point, it does. Breyer's opinion does say the court is arguing that the API is copy-righted, but used under fair use (as opposed to not copy-righted, in which case fair use doesn't make sense). But my point about what seems to be the main distinction making it copy-right-but-fair-use is the declaration vs. implementation concern, a distinction that logically exists (so I think the outcome is correct!), but does not seem to legally exist.


>the court is arguing that the API is copy-righted

No they specifically omitted saying this.


The gap in the law they've clarified is what fair use looks like for software.

When the API definition is a small portion of a work, it is fair use to reimplement the api


I am very glad to see this. Having a “you can abuse copyright to have proprietary control over an API” precedent on the books had a chilling effect for programmers.

Let me give you one example as an electronic musician. Once upon a time, Steinberg created an API for connecting programs which simulate musical instruments and musical effects (think reverb, echo, flanger, etc.) called VST. This API was always proprietary but everyone ending up using it, including the open source Audacity program which uses an open source re-implementation of the VST API, allowing it to use professional effects when editing tracks.

Well, Steinberg decided that VST2 — the one everyone has been using — was out of date and removed all downloads to the VST2 API, since they wanted users to upgrade to VST3. While a lot of professional music making tools have updated to VST3, others have not, and a lot of tools will never be updated. Steinberg no longer has a copy of the VST2 SDK available for download; they’re really trying to get everyone to update to VST3.

Now, with this horrible “Google vs. Oracle” precedent looming over everyone’s head that a company was allowed to copyright an API, Steinberg could had, in theory, said “VST2 is copyrighted, and Audacity is not allowed to use their own independent implementation of that API” (they didn’t in practice because they know it’s bad business; indeed VST3 is dual licensed, where GPL3 is one of the license options).

With this precedent, the Audacity team can more easily retain their independent implementation of VST2 knowing the legal precedent saying re-implementing an API is fair use.


> I am very glad to see this. Having a “you can abuse copyright to have proprietary control over an API” precedent on the books was a chilling effect for programmers.

It was always possible to release APIs as open-source. There's as much chilling effect about proprietary software as there ever was being careful about using licensed work, and that was never a problem.

On the other hand, the hunting season on companies providing software is now open. You're a startup providing a new database, or a well-thought library? Shit, you better take the VC money before someone else does and puts you out of business. And when a company like Amazon comes with an offer, you better not be in a bargaining mood.


"On the other hand, Google’s copying helped Google makea vast amount of money from its Android platform. And enforcement of the Sun Java API copyright might give Oracle a significant share of these funds. It is important, how-ever, to consider why and how Oracle might have become entitled to this money. When a new interface, like an API or a spreadsheet program, first comes on the market, it may attract new users because of its expressive qualities, such as a better visual screen or because of its superior functionality. As time passes, however, it may be valuable for a different reason, namely, because users, including programmers, are just used to it. They have already learned how to work with it. See Lotus Development Corp., 49 F. 3d, at 821 "

Interesting to see SCOTUS citing Lotus v Borland, which was originally deadlocked at 4-4 (although Breyer seems to have voted in favour of Lotus back then). Does this elevate the precedential value of Lotus?


This is one of the most important legal decisions in the history of software. The US Supreme Court has basically just saved the whole software industry (and FOSS projects) from being wrecked by patent trolls.


s/patent trolls/copyright trolls/

This case involved copyright, not patents. Copyrights are separate from patents.


I agree with the parent. Patent trolls aren't tied to patents because of some love for patents specifically, but because the legal structure allows for the most misuse. They would gladly add another tool to their belt given the chance, as we saw from this case with most of the bad copyright opinions coming from the CAFC, ie. the patent appeals court that's currently stuffed with IP maximalists.


Oracle sued Google for copyright and patent infringement. Today's decision has to do with the fair use defence in the copyright portion of the lawsuit.

https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_....


I understand that. I'm saying that the same people that are patent trolls would add misuse of copyright to their set of tools if it became that became a viable option available to them. Today's patent trolls would just be called IP trolls, but they'd be the same set of people.


Copyright is already misused to perform DCMA takedowns of fair use and is a well known option available to all comers. I think the classic example was the Prenda lawsuit firm.

Prenda made its money by suing people who allegedly downloaded pornographic films online. Its targets frequently agreed to settlements worth a few thousand dollars rather than facing a courtroom process. These copyright trolling tactics netted the company more than $6 million between 2010 and 2013.

https://arstechnica.com/tech-policy/2019/07/prenda-law-porn-...


I mean, that article is about how the Prenda saga ended with the lawyer disbarred and in prison.

If his strategies had ended up a valid, legal option we would absolutely see trolls expanding into this. John Steele was testing the waters and got eaten by the deep acting as a warning for how not to go about this.

There's some DMCA takedowns and such still, but they aren't quite lucrative enough to show up on patent trolls' radars. Aquila non capit muscas and what have you. A several billion dollar copyright claim like Oracle's passing SCOTUS muster absolutely would have shown up on their radar though.


> the same people that are patent trolls would add misuse of copyright to their set of tools

Prenda is an example of how misuse of copyright is already in the trolls' toolbox.

Since you think about this stuff you might find the latest on the Santa Cruz Operation interesting:

https://arstechnica.com/gadgets/2021/04/xinuos-finishes-pick...

Xinuos is the company that purchased the remnants of the SCO Group in 2011. The SCO Group, in turn, is a company most famous not for its actual products but for its litigation against IBM and Linux. That litigation began in 2003—partially funded by a very different Microsoft, only five years after the leak of the Halloween documents in which Microsoft acknowledged the "long-term viability" of open source software and discussed strategies to choke it out of the market.


I looked back at SCO v IBM on Groklaw. SCO wanted to claim copyright infringement over IBM's use of code from Project Monterrey, but they tried to add it too late, and the judge wouldn't let them amend the case yet again. Well, this Xinuos nonsense looks the the copyright version of that exact claim.


And that's probably not going to go anywhere either. Yes, there's the occasional attempt, but it's a set of fringe actions that don't turn out great for the agressor rather than a well trodden playbook that will probably earn you many millions like patent trolls can expect.


To be pedantic, this part of the case is about copyright law, not patent.

https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_....

The first phase of the case lasted from 2010 to 2015. Oracle successfully established that APIs are copyrightable, but their claims of patent infringement were rejected. Google petitioned the Supreme Court in October 2014 to review the case, but this was denied. A second petition by Google in January 2019 included the judgement that APIs are copyrightable. The Supreme Court agreed to review this part of the judgment in November 2019.

To the degree that SCOTUS has found that an API can be copyrighted, there is still room for copyright trolls to operate.


At least in the US


US copyright law and interpretation tends to get exported through trade deals and other forms of political and economic pressure.


While true, APIs have specifically not been copyrightable in the EU for some time, I'm not sure about the cad else in other countries and regions.


That's always just a treaty away from changing.


There is a tendency, but it's not deterministic. When it does happem, it's more often for the broad strokes than this kind of detail, see eg sw patents.


Which, for now, is the global hegemon in software and tech at large. Any US court decision is extremely important to the whole industry.


Did Oracle also sue Google in other countries outside of the US? To my knowledge we didn't need any saving in this respect in my country.


Doesn't matter, as GDPR showed having something that's troublesome to sell or distribute in certain (critical) markets is a huge, massive roadblock for most companies. Software patents are worth s*t in the EU, but still we had to endure year of hassle when installing MP3s and such on Linux due to most distros having to also comply with the US market.


It is going to open a big door for people who reimplement APIs.

In particular, social-media aggregators (one app to display your Twitter, FB, Instagram, etc.) may have new protections.


I don't know about that. The issue at hand there isn't implementation of APIs, it's using an existing API (run on existing infrastructure) in a way that the social media company does not approve of. Isn't that more an issue of unauthorized access than of copyright?


I assume this means that Amazon can ignore the Elastic and Mongo licenses when building compatible implementations?


So can other vendors with S3's api.


Now it's legally possible to SaaS MinIO and sell S3 storage to customers.


I’d make the case that it instead saved closed source coding.

Open source code is still usually copyrighted. Nobody would trust closed languages and APIs unless they paid a fortune for them while open source with a grant would be safe to use.


It also saved open source software which reimplements proprietary API:s


Why? It wasn’t about whether APIs are under copyright (they are), but whether this particular case constitutes fair use. I think the effect of this decision was way overblown.


> whether this particular case constitutes fair use

The English common law system relies heavily upon judicial precedent. A ruling in this particular case that the copying of an API constitutes fair use will inform decisions in future cases of similar copying.


Justice Thomas clarifies why this case has wide-reaching impact in his dissent.

"Congress rejected categorical distinctions between declaring and implementing code. But the majority creates just such a distinction. The result of this distorting analysis is an opinion that makes it difficult to imagine any circumstance in which declaring code will remain protected by copyright."

I concur with Thomas (not in the connotation - he thinks this is a bad thing, I do not - but in the denotation). This ruling is such strong precedent that almost any API cannot be bound by copyright that no company is going to be willing to spend the money to raise the question.


I think Thomas makes a mistake in disregarding the reason for introducing the distinction between declaring and implementing code. The law (as I understand it - IANAL) doesn't exhaustively enumerate what does and does not constitute fair use. Therefore, any specific instance of fair use is bound to introduce new distinctions that are not specifically mentioned in the law itself.

In this particular case, Google's copying of interfaces was ruled to be fair use because its purpose was to allow Java developers to reuse their skills. This reasoning only holds for the declaring parts of the copyrighted work though. And that's why the distinction becomes necessary even if Congress rejects it as a primary distinction between copyrightable and non-copyrightable work.

That's also why I think the ruling is perhaps not quite as broadly applicable as some (including Thomas) are thinking right now. It may not cover code that isn't used by a significant number of developers. I haven't read the entire ruling, so I'm not sure whether it covers non-public interfaces that are nevertheless useful for interoperability. Such interfaces were at the center of past disputes (I think Microsoft's SMB protocol was one such case).


It definitely sends a message. And the stakes were so high that the message is know very loud and clear, too.


If this wasn't fair use, nothing of any substantial value could be considered fair use.


Wine would be a much better example of fair use. It is explicitly made to allow users of linux to run programs written against win APIs. It is not so clear in the Oracle vs Google case, because it is questionable whether Google’s case was really fair use (google pretty much didn’t want to pay Sun for the mobile license and the whole thing was done as cost saving) - hence the very long timeline of the case.


Well, regardless of your opinion, this ruling means that Google's copying of the Java SE API is a perfect example of fair use.


I didn’t say that it wasn’t fair use, but it would have ended much sooner if it would have been trivially fair use.


The dissent explains how Android fails three of the four fair use tests. I'm not sure what the majority was smoking when they wrote this, but far better examples of fair use exist, especially uses that are noncommercial and especially are noncompetitive with the original.

Java was a mobile OS before Android literally obliterated the market after copying Java. Arguably, if Android was fair use, everything is fair use and all software copyright is fundamentally defeated by this ruling.


The dissent is a bunch of garbage written by someone who clearly doesn't understand anything about what he's talking about.

He complains about the names of functions being "expressive content". Yeah, "max" and "toIndex" are real expressive.

Also, what the hell is this logic?

https://twitter.com/KardOnIce/status/1379080086880665606/pho...


Good, now can we get a ruling that prevents Google, RedHat, Microsoft and others from wrecking FLOSS projects with their stifling influence?

Or prevent them from eradicating competing or even original projects by doing hostile rewrites or forks?


Should we also get rid of all of GNU's hostile rewrites?


People seem to frequently forget that GNU was largely a GPL reimplementation of proprietary software.


Why would you prevent someone from writing whatever code they want, as long as it is FOSS? That's hypocritical, considering that doing whatever you want with the code is one of GNU's main tenets ("free as in freedom")


> Or prevent them from eradicating competing or even original projects by doing hostile rewrites or forks?

Wouldn't this directly contravene the findings in this case?


I found this section (pp. 33-34) particularly interesting:

...enforcement of the Sun Java API copyright might give Oracle a significant share of these funds. It is important, however, to consider why and how Oracle might have become entitled to this money. When a new interface, like an API or a spreadsheet program, first comes on the market, it may attract new users because of its expressive qualities, such as a better visual screen or because of its superior functionality. As time passes, however, it may be valuable for a different reason, namely, because users, including programmers, are just used to it. They have already learned how to work with it. [...]

This source of Android’s profitability has much to do with third parties’ (say, programmers’) investment in Sun Java programs. It has correspondingly less to do with Sun’s investment in creating the Sun Java API. We have no reason to believe that the Copyright Act seeks to protect third parties’ investment in learning how to operate a created work. [...]

Finally, given programmers’ investment in learning the Sun Java API, to allow enforcement of Oracle’s copyright here would risk harm to the public.

If one were to apply the above logic to anti-trust instead of copyright fair use, one might wonder if the Court could find harm to the public in certain behaviors of e.g. a monopoly email provider or monopoly social networking site.

(A big argument against anti-trust enforcement against Google and others is that the Sherman Act is designed to protect consumers, not competitors.)


The HN discussion from 2016 (Jury finds for Google): https://news.ycombinator.com/item?id=11781053

From 2018 (Oracle revives matter via appeal): https://news.ycombinator.com/item?id=16688521

Edit: Fixed, had written "Jury finds for Oracle", which was NOT what happened in 2016. Argh.


As both that thread title and the Supreme Court opinion say, the jury found in favour of Google.

They were then overruled by the Federal Court, which has now in turn been overruled by the Supremes.


Edit: Heh, yep. I was blind to it, fixed, thank you!


You misunderstand.

It is a change in decision from the appeals court, not a change from the jury's decision.


I think you maybe typoed your comment then, it says the jury found for Oracle.


Federal Circuit, not Federal Court, just to clarify.


I'm unfamiliar with the legal system (judicial system?). I had thought that the jury's findings were final. Am I understanding correctly that the case still went to the Supreme Court of the US, and now that court finds in favor of Google.

What happens after this, more appeals or is this like a proper static const readonly final?


In the US, the Supreme Court is the static const readonly final. It's over. There is literally no route of appeal or any way Oracle can keep this case going without a whole new lawsuit. The Supreme Court can elect to make a ruling and then send it back to a smaller court _if they choose_ for final assessment, but they did not do that here, making this ruling definitive.


Oracle (or some other company) can bring another case. It has to be different enough that it isn't immediately struck down based on precedent, but similar enough that a ruling would require appealing to the Supreme Court and force them to overturn or invalidate the Oracle v Google precedent. The chance of this happening is negligible, but this is basically the conservative plan for getting the Supreme Court to overturn the Roe v Wade precedent.


Sometimes SCOTUS explicitly suggests in an opinion that it's time to overrule precedent but they don't want to do so in that case.

Most recently (that I'm aware of) is South Dakota v Wayfair. SCOTUS previously held that states couldn't impose sales tax on out-of-state companies. Subsequently, many states imposed "use taxes" which are essentially sales taxes paid by consumers on purchases they didn't pay sales tax already to get around this. Colorado passed a law which required out-of-state companies to essentially provide sales tax computation information to Colorado (but not sales tax itself), and Kennedy noted in his concurrence that maybe it was time to revisit the sales tax precedent. So South Dakota went ahead and passed a sales tax on out-of-state companies in direct violation of previous precedent, and SCOTUS promptly overturned that precedent when it heard the case.


Well, more precisely: they definitively ruled that (a) a judge can decide whether a use is fair use and (b that this is fair use. Then they remanded the case to lower courts to decide what that means in terms of what happens next in this case.


> In the US, the Supreme Court is the static const readonly final

This made me laugh out loud. Thanks


You understand correctly. The jury's decision isn't final (and I thought this was ruled on by a judge directly, instead of a jury, but I could be wrong). You can appeal pretty much any case to a higher court. I don't know the order, but it's not uncommon for cases to appeal to a higher court several times. I.e. a verdict is rendered in a county court; you don't like it, so you appeal to the state court. State court still doesn't give the decision you want, so you appeal to the Supreme Court.

It's worth noting that the higher court can reject your appeal. You're not entitled to be seen by the higher court, and if you can't come up with good grounds for why the lower court was wrong, the appeal will be rejected. The Supreme Court rejects a fair number of appeals (I think the majority of cases).

This is final though. There is no higher court than the Supreme Court to appeal to. At this point, the only reason it would change is if the laws change, or the Supreme Court reverses their decision later. It's extremely rare that they whole-hog reverse a precedent that they set, though.


> The jury's decision isn't final (and I thought this was ruled on by a judge directly, instead of a jury, but I could be wrong).

The idealized rule is that the jury is the final arbitrator of matters of fact, while judges (and appeal courts) decide matters of law. Ideals don't match reality cleanly, especially on matters like fair use which is "mixed fact and law." But additionally, you can sometimes appeal matters of fact by arguing that no reasonable jury could have reached the facts as it did (these are very rare, as I understand it, except in situations where mixed fact/law comes into play).

Some other points you're missing. First, you have to appeal on particular failures of law; you can't just appeal that you don't like the decision. In particular, if you try to appeal past the appeal court to a higher court, you can only make arguments that you made to the appeal court.

Another important thing is that appeal courts can push the case back down to the lower court to redecide based on clarifying law. That's what happened here, essentially. Google won on the trial, Oracle appealed saying that the judge incorrectly ruled that the API wasn't copyrightable (and the appeal court agreed with Oracle), which told the lower court to try it again with the correct ruling on API copyrightable. Google tried to appeal SCOTUS, who refused to hear it. Lower court had another jury trial, which found Google had fair use. Oracle appealed again to appeals court, which found that the jury couldn't have thought it fair use. Google appealed to SCOTUS, which just now disagreed with the appeal court.


This does not match my understanding of the situation (though note: I am not a lawyer; take everything that follows with a grain of salt).

My understanding is that a jury's primary task of deciding on the facts is final. The facts in a case like this seem to me to be things like deciding whether Oracle in fact holds the copyright, and whether Google's copy of the API is sufficiently similar for that copyright to apply to Google's copy.

Now as far as appeals go, you can appeal whether the trial was done properly, such that the jury was able to do its fact-finding job correctly. You can appeal what was then decided based on those facts (e.g. sentencing). You can appeal meta-questions, like whether a particular decision is a "finding of fact" or not to start with.

The question of whether "fair use" is the sort of thing that is decided by judge or jury is apparently somewhat contentious in this case; I just found https://www.law.uw.edu/wlr/print-edition/print-edition/vol-9... describing some of the issues there. Today's decision refers to this as well: it's (c) under "Held":

> (c) The fair use question is a mixed question of fact and law. Re- viewing courts should appropriately defer to the jury’s findings of un- derlying facts, but the ultimate question whether those facts amount to a fair use is a legal question for judges to decide de novo. This ap- proach does not violate the Seventh Amendment’s prohibition on courts reexamining facts tried by a jury, because the ultimate question here is one of law, not fact. The “right of trial by jury” does not include the right to have a jury resolve a fair use defense. Pp. 18–21.

which sure sounds like the Supreme Court effectively decided that the final determination of whether a use is "fair use" or not should be made by a judge, not a jury. Then they proceed to make that determination in this case in holding (d).


I didn't understand that either, but I found a good explanation on page 2:

"The fair use question is a mixed question of fact and law. Reviewing courts should appropriately defer to the jury’s findings of underlying facts, but the ultimate question whether those facts amount to a fair use is a legal question for judges to decide de novo. This approach does not violate the Seventh Amendment’s prohibition on courts reexamining facts tried by a jury, because the ultimate question here is one of law, not fact. The “right of trial by jury” does not include the right to have a jury resolve a fair use defense."


A jury's findings are final only in determining the facts of the case. The actual legal implications of those facts can still be appealed, reviewed, and modified.


I think the question about overturning the jury is directly addressed in the linked PDF, whose Syllabus is surprisingly easy to read:

> Re- viewing courts should appropriately defer to the jury’s findings of un- derlying facts, but the ultimate question whether those facts amount to a fair use is a legal question for judges to decide de novo. This approach does not violate the Seventh Amendment’s prohibition on courts reexamining facts tried by a jury, because the ultimate question here is one of law, not fact. The “right of trial by jury” does not include the right to have a jury resolve a fair use defense.

I'm not a lawyer so I don't know exactly what this means, other than the SCOTUS saying that it can override the jury decision.


The latter. Once the Supreme Court rules, that is the law of the land, unless Congress/President pass a new law substantially changing things, which could then have challenges go back through the judicial process.


As others has said elsewhere, the jury rules on facts and judges rules on law. SCOTUS are judges. Under one interpretation of law, the most recent jury findings of fact held that Google infringed.

SCOTUS altered the interpretation of the law, thus removing the legal justification for why the jury found infringement. Since they did not alter any findings of fact (they did not need to) this ruling is legally fine.

A jury can say you definitely did X, that court's judge can say X is illegal, and SCOTUS can then declare X is legal so it doesn't matter anymore if you did X.


Generally, the Supreme Court finds narrowly on a specific point of friction in the case of a lesser court, answers the question, and kicks it back to that court, as a final answer for that very specific thing.

The point in this case was, can Oracle overturn the "phone books cannot be Copyrighted" concept baked into tech law by the IBM v Compaq BIOS case. Seems the Supreme Court finally told Oracle the collection of method signatures from the Java base API are, indeed, a phone book.


You are just totally wrong, the majority did not issue a ruling on copyrightability. It just said that even if the API is copyrightable Google's actions were "fair use," which is a legal doctrine allowing some use of copyrighted works without a license.


The jury is final on questions of fact. On questions of law the appellate and supreme courts can overrule the trial court.


They could file a new lawsuit but this specific complaint is effectively over.

Considering that the votes were not close, I don’t think Oracle would try again. Likely they will pursue a substantially different strategy to try and extort Google.


Realistically, both Google and Oracle are 800lb gorillas and the battle will continue via lobbying legistlators, if not court appeals. It's very hard to believe Oracle would just keel over and give up.


Congress can't make retroactive laws, this case is basically done and Google won't have to pay for their use of Java that occured/occurs prior to the passing of a new law. Oracle doesn't have a vested interest in ruining copyright for everyone in the future if they can't get past damages out of it. That would hurt themselves as much as it would hurt everyone else.

I'm pretty confident that Oracle rolls over on this issue permanently.


IANAL, but I believe what the US Supreme Court says is final. There isn't any appellate court for the highest court in the land.


Judge William Alsup learned to code for this case, and was therefore able to avoid a lot of the BS being peddled around the significance of some of the code:

> The argument centered on a function called rangeCheck. ... It was in Oracle’s interest to play up the significance of rangeCheck as much as possible, and David Boies, Oracle’s lawyer, began to argue that Google had copied rangeCheck so that it could take Android to market more quickly. Judge Alsup was not buying it.

> “I couldn't have told you the first thing about Java before this trial,” said the judge. “But, I have done and still do a lot of programming myself in other languages. I have written blocks of code like rangeCheck a hundred times or more. I could do it. You could do it. It is so simple.”

https://www.theverge.com/2017/10/19/16503076/oracle-vs-googl...


Judge William Alsup learned to code for this case

He learned Java for the case, but he was already an accomplished developer: https://www.theverge.com/2017/10/19/16503076/oracle-vs-googl...


I just took a look at the rangeCheck:

https://majadhondt.wordpress.com/2012/05/16/googles-9-lines/

Is this example correct? Can someone explain to me how this: if (toIndex > arrayLen)

is correct?

If the array length is say 5, and toIndex is 5, that should still throw an index out of bounds exception, right? But it would be acceptable here.


The example is correct. toIndex is exclusive.

Here is Dijkstra's opinion on why:

https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/E...


Aside from the questionable inequalities, there's a missing closing parenthesis after the arguments on the first line, too.

EDIT: as has been pointed out, the inequalities are correct. The original code can e.g. be found here, including doc comments showing the intended meaning of the arguments: http://www.groklaw.net/pdf3/OraGoogletrialexhibits/2012-04-2... (all the way at the end)


Thanks this makes sense. So the toIndex is literally defined as "the index after the last element in the range".


The upper bound of the range is intended to be exclusive, while the lower bound is inclusive - basically, the same s array indexing convention. It allows the case where fromIndex == toIndex to represent the empty range (note that this check does permit fromIndex to equal toIndex, but never to exceed it), and the number of entries in a given range is always defined by toIndex - fromIndex.


This is correct for a half-closed interval https://mathworld.wolfram.com/Half-ClosedInterval.html


toIndex is defined to be the index after the last element of the range (a half-closed interval).


That judge had no part of this decision though.


This stuff is very nuanced, especially when the stakes are high.

SCOTUS rules on the legal and fundamental matter, not the subject. So if the attorneys for one side or the other are able to manipulate the judge into making a weak ruling (even one not in their favor), the appeals courts rulings will be impacted. In this case, the trial judge went above and beyond to avoid that kind of bullshit.


>David Boies

That David Boies? I guess law firms will represent whoever will pay, but it seems somewhat funny that he also represented The SCO Group in their litigation against IBM...


I would imagine if the ruling went the other way, IBM might want to talk to all the BIOS companies. Luckily, that didn't happen.


IBM would probably want to talk to 99% of computing companies out there, not just BIOS companies :-)


Including Oracle, since their copying of IBM's SQL API is what the whole company is based on.


And Oracle is now copying AWS's API to try to enter the cloud market. (This was explicitly brought up in one of the amici briefs).


Are you referring to the S3 API? I believe the S3 API is explicitly licensed under Apache.

Disclaimer: I was previously employed by Amazon and currently Google. Opinions are my own, I'm not a lawyer, etc.


And OpenJDK is GPLv2 with a classpath exception. So why is Google unable to use Java's API here while Oracle able to use Amazon's API?


Google used the Apache Harmony version as the basis for Android (Until Nougat).

Some of the argument was over whether the Apache licence inherited by Google from Harmony was valid, or whether Harmony itself was in breach of copyright (and therefore had no valid licence Google could use).

Once the courts decided APIs are copyrightable the argument switched to whether Google's was Fair-Use, with a jury saying it was, federal appeals court saying no, and thus it ended up at the Supreme court.

Here's a Groklaw [0] copy of an early (April 2012) Oracle argument asking for Jury instructions around the licence topic that explains it well:

  "As made clear by Apache itself, Apache never had a license from Sun or Oracle for Harmony.  Apache had no rights to Java technology that it could give to Google"
[0] http://groklaw.net/pdf3/OraGoogle-959.pdf


IIRC (this case has been going on for way to long) they didn't cope the GPLed version of the code (oracle/sun had another proprietary version).


So the original case had claims against copying more of the original Sun JVM code than just the API--the entire furor over "rangeCheck" was a key part of the original case. By the first appeal, this was reduced to a de minimis claim of copyright and Oracle no longer pursued claims of copyright on anything but the API.

My understanding is that all of the APIs in question are shared between the (now-Oracle) JVM and the OpenJDK implementation. (Indeed, I think the actual implementation of the Java code in question is the same between the closed and open source versions, it's only the JVM itself that differs.)


Because it wasn’t GPLv2 at the time, and Sun explicitly disallowed mobile use?


I thought this case is from back when Android was using Apache Harmony?


IIRC the API is probably licensed under the Apache license (by virtue of client libraries being licensed, not intentionally) but Oracle isn't complying with the requirements of the license, so that would have been more or less irrelevant.


and Amazon could talk to Oracle who "borrwed" the S3 API for their cloud storage.


S3 explicitly changed their license to allow copying the S3 API. I forget the year, ~2010? I was working an S3 at the time and it was a strongly debated decision.

Google’s initial launch of their cloud storage copied not just the S3 API, but also the error codes.


I think the point is that if this case had gone the other way this kind of open licensing would happen a lot less. Companies would be obliged to enforce API copyright to protect themselves from loss of copyright (share holder value)


For better or worse, the same arguments ( "API is copyrightable" ) is what was used in the past to prevent 98's Microsoft from doing embrace-extend-extinguish to Java with their "JavaVM with P/Invoke'd Win32 API".

The idea in that case was that when you try to implement something identical to the Java language and standard library, it doesn't matter if you call it Java or "Visual J++"; you are still implementing Java and thus in order to be able to do that you need to agree to Sun's terms (in that time, it was that your implementation needed to pass a testsuite and among other things needed to be "write once run everywhere", something the MS one definitely didn't as it was offering lots of non-portable extensions).

Now to my understanding the opinion here is that literally Sun was trying to do the same to Google (forcing them to ensure their implementation was compatible with Sun's, including being able to run Android software under Sun's JVM), which would have quite put a setback to Android at least as it was at that point (could you imagine Android forced to go with Swing?).

If I try to be fair, I find that in fact Android did succesfully pull the embrace-extend-extinguish strategy that MS was prevented to by legal reasons, and as a consequence basically killed Java on the mobile space (though Oracle has a lot of blame to share here). Perhaps the tides turned and now Google is seen as the lesser evil when compared to Oracle, while in the past Sun was seen as the lesser evil compared to MS. But is there any objective reason why the two rulings should have gone differently?

I am actually completely undecided about how I would have liked this ruling to go. I can see some of the repercussions of being able to copyright "header files" way too dangerous to ignore, but on the other side I have already seen the consequences of not being able to, and they are also bad.

Alien vs predator...


I seem to remember that the 98 case was a trademark violation. Microsoft used the Java brand even though their implementation wasn't compliant (it was a derivative) - which was a big issue for Sun since one of the main point of Java is compatibility ("Write once, run everywhere").

Google however made sure to always be clear about "the Java Programming Language" or such safe phrase that makes clear that they're not the official thing.


Correct. Microsoft could make J++ or whatever; they just couldn't call it Java.

The particular issue was that Microsoft was extending some of the Java language (and maybe com.sun?) classes. If you used any of their extensions, then you had code that could only be compiled with Microsoft's compilers, and you were locked in. (The "extend" phase, which is then leveraged for the "extinguish" phase.)


I think the difference here would be that the "point" of Google copying the API was not to make Oracle's Java be irrelevant, but rather to get a pool of developers that already knew the platform. Whether Oracle's Java stayed as popular or even got bigger was irrelevant for their purposes. The "point" of Microsoft's copying of the API was to make it so that eventually, people would only use their version, like they did with MS-DOS. The Supreme Court was considering the "point" when they were applying a test on "what kind of economic impact does the copying have on the original" and "does this act as a substitute for the original", which is on pages 32 and 33, where they're saying "Oracle / Sun tried to get into the smartphone space but couldn't hack it, Google entering that space didn't meaningfully affect them".

On the flip side, if Microsoft had been judged by the same standard, they might determine that Microsoft's reimplementation of an incompatible Java would have too much of an economic impact on the original to be fair use.


I'm not sure the "API is copyrightable" argument was relevant in the Microsoft-Sun case. Keep in mind that case was settled privately. Since it was never decided in court, it's hard to say what the most relevant claims were, but I don't see Sun making much of the copyright claim. They had a licensing claim because they claimed Microsoft had licensed the Java trademark but was not implementing it fully according to the spec. That seems rather different than this case.


Good points. Though I thought the J++ naming was precisely to avoid the Java TM.


The different case results had nothing to do with the relative size of Google vs Microsoft vs Sun.

Microsoft lost because Microsoft had signed a contract with Sun, and was found to have broken the terms of the contract.

Google never signed a contract with Sun, so was free to act in ways that Microsoft was not.


I led the development of a large GUI app using J++ in the late 90s. This fear you describe is unwarranted.

It's worth pointing out that the list of examples of "Embrace, Extend, Extinguish" on the wikipedia page of that name [1] contains zero actual successful examples of it working. Perhaps you have noticed that you aren't reading this page in an ActiveX control.

This is a boogeyman. Don't be afraid of it.

[1]: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...


> It's worth pointing out that the list of examples of "Embrace, Extend, Extinguish" on the wikipedia page of that name [1] contains zero actual successful examples of it working.

Looks like the successful examples were successful enough for everybody to forget about the originals. There is basically no other YP/Kerberos/SMB implementation in use that didn't follow from the MS copy. Netscape was successfully lead to bankruptcy. All the EEE days platform independent dev-tools were successfully lead to bankruptcy. All the EEE days competing office suites were successfully lead to bankruptcy...


SMB seems alive and well? I don't see an "Extinguish" there.

You seem to be conflating "beat in the marketplace" with EEE. Netscape didn't fail because of ActiveX. They failed because web browsers and web servers became free.

Competing office suites struggle not because Microsoft extended some underlying protocol. Like it or not (and I personally don't), Office delivers an incredible amount of business value to its users.

Platform independent dev-tools were, and are, still around. But like the browser, it's tough to make a living selling dev tools when they are generally free.

Microsoft has been a very successful company for many reasons. It's not clear that "Embrace, Extend, Extinguish" is one of them.


As a contractor I have been a victim of _all_ the examples in that website (yes, even Interix. A company I used to work for immediately tried porting their software to Interix the moment it was released for free (I think XP?), and I still have nightmares to this day. God bless that guy who used to have a website with more recent GNU utilities for Interix). They only really succeeded in some of them (e.g. MSN, browser, email) but they definitely tried. Sometimes it was legal reasons that stopped them (e.g. Java) and not just their incompetence.


Their failure to take control over those markets is not the same as a failure to cause damage. They slowed down development of web standards by many many years, as one example.


> the wikipedia page of that name [1] contains zero actual successful examples of it working.

I will also point out that this page does not contain the letters "Novell" anywhere within it.


I don't want to speculate but Microsoft's embrace of Linux and Github has been frightening to me.


If I recall correctly, Microsoft licensed java and Sun sued them for violating the terms of the license. Google never had a license; they were sued for violating copyright. Neither lawsuit determined that embrace/extend/extinguish is illegal/unethical/immoral; they were concerned with the means, not the ends.


The issue is that what Sun was trying to do to Microsoft was equally wrong, but people didn't care as much because Microsoft was more obviously the villain.

The real answer is that copyright is the wrong tool to go after what Microsoft did and the correct tool for that is antitrust. EEE is anti-competitive even if copying an API is fair use.


I immediately thought of Microsoft Visual J++ as well. I will add that the Android Runtime/Dalvik did not really add such extensions to the Java language, only an additional library, so it isn't quite the same embrace/extend/extinguish approach, but the change in opinion is curious, and perhaps more a sign of the times than anything else.

I wonder if Microsoft's actions could have been ruled at the time as violating antitrust laws instead, if the copyright interpretation had fallen flat? Perhaps upcoming antitrust investigations into Google will look at their re-implementation of Java interfaces in the same light?


There's a huge difference. Microsoft was already a monopoly on desktops (and was relying on that dominance to EEE) when that happened, while in Google's case the smartphone industry was nascent.


The 1990s Microsoft issues were antitrust. They tried "embrace-extend-extinguish" because they were in a monopolistic position, and this tactic was viewed as anticompetitive.

But Google (at least with respect to phone OS) was in the position of the startup, and Sun was the big market player. Now, Google had with ridiculous resources at its disposal, of course, but at the time not using a monopoly position to twist arms of carriers, for example. It's not anti-competitive to spend a lot of money to win.

Of course, things change....


Microsoft extended the JDK with VisualJ++, by introducing their COM based version of JNI. They claimed that the result was the same thing; now Google reimplemented the JDK while keeping the same API. that makes a subtle difference. I wonder what would have happened if Microsoft were to have sold VisualJ++ as 'Microsoft JDK'.


The problem was, code written for J++ wouldn't run on "regular" Java outside of Windows, effectively killing the cross-platform aspect of Java and turning it into another Visual Basic.


that's what i meant: by naming it a windows jdk they would not imply to be cross platform. they could then argue that they implemented the same sdk for their platform only. (interesting if Oracle tried to argue that the same logic should apply in this case too).


To be fair, Java isn't and arguable was never a true cross-platform language that the media used to portray it as.

Any non-trivial app always needed a lot of platform-specific code and API calls to get that native look and feel.


You say the alternative is bad but stop short of evaluating how bad. There's clearly a difference here and you don't seem to shy away from giving an opinion yet you also claim to be undecided for a court case that had lasted 10 years.

I'm sorry, but this smells like a bad faith argument.


Had the ruling gone in Oracle's favor I can imagine some greedy company trying to procedurally-generate every API and copyright them all similar to this project which tried to copyright all musical melodies:

https://www.independent.co.uk/life-style/gadgets-and-tech/ne...

In the case of the music project, it was for the protection of the community, but I can imagine such a system being used selfishly for software APIs.


> Had the ruling gone in Oracle's favor I can imagine some greedy company trying to procedurally-generate every API and copyright them all

It would have officially mean businesses and the US governments are locked by vendors and have no right to copy API in order to provide compatibility towards other systems.

Making « VendorLocking » legally valid in favor of the vendor.

Not gonna lie I was scared by the outcome of that judgement and the catastrophic defense of Google.

I’m now relieved !


Independent copyright when a work was independently created is a thing in most jurisdictions, as copyright covers copying and is not like patents in that regard.

However, that would indeed require a ton more work to prove that you did not copy any of the generated work and truly did create yours by yourself.


Can you copyright generated things? You probably could copyright the way you're generating it, but I doubt you have a legal standing about the generated text or melody itself.


I am not a lawyer, but I don't see why not.

Have you ever used code generation as part of software you have built?

Is there any reason why generated code could not be copyrighted as part of a larger system?

For example, suppose I define a data model for a public-facing API and then generate SDKs in various popular programming languages to interact with the public-facing API.

If I were a major corporation that owned such a public-facing API, then I would expect that the generated SDKs would carry the major corporation's copyright.

edit: Another example of generated code would be the code generated by lexer analyzer generator and parser generator tools such as lex (https://en.wikipedia.org/wiki/Lex_(software)), flex (https://en.wikipedia.org/wiki/Flex_(lexical_analyser_generat...), YACC (https://en.wikipedia.org/wiki/Berkeley_Yacc), and bison (https://en.wikipedia.org/wiki/GNU_Bison).

If you create commercial software that includes YACC-generated code, wouldn't the generated code be copyrightable?


> I am not a lawyer, but I don't see why not.

The involvement of actual human creativity is required for a work to be copyrightable.


In my code generated-SDK example, a human defined the data model and a human created the code generation algorithm, but an algorithm generated the SDK code itself.

So human creativity is involved, but is not the direct creator of the SDKs. Does that count? I am not really sure.

I bring up the generated SDK example because I have used just such a system when I worked at a major corporation: I created a data model in Web Services Description Language (https://en.wikipedia.org/wiki/Web_Services_Description_Langu...) and used a company-owned tool to generate SDKs in various programming languages. All of the generated SDKs had the company's copyright notice in the generated code.


IANAL, but:

The code generated SDK is a derivative work of the human-defined data model - just like the binary for any piece of software is derivative of the source code. (Otherwise where'd the copyright for the binary come from?)

The generator's copyright (or the compiler's) doesn't directly flow in. (But if the generator/compiler incorporates pieces of itself, like a support library, that does. Also, the generator/compiler might have terms of use...)

If you write a generator that just generates random APIs, those are basically machine generated garbage and wouldn't be copyrightable. The human input to the generator is missing.

[FWIW, I had to research this due to an "ill-behaved" community member on an open source project a few years back; I'm not completely making this up out of thin air. That still doesn't make me a lawyer though ;)]


My understanding is that the copyrightability of binaries was something of a gray area for a time even after the copyrightability of source code was established. Apple v. Franklin is probably the most relevant court case.


The generator has been run by someone.


We already do this, binary is generated and copyrighted.


A more obvious example is that, if you write a program that generates music based on some algorithm, that work is presumably copyrightable.


> as part of a larger system

I think this is the key statement that will make a difference. If you want to copyright a larger system, generated code is not a problem. If you want to copyright an individual, generated piece of code, I doubt you'll get copyright for that. But IANAL either.


My understanding is no. Copyright requires human authorship (the case of the monkey selfie found it to be public domain because a monkey did it, e.g.), and code written by a machine is likely to follow similar precedent and be uncopyrightable.



All of the appeals courts that heard appeals in that situation agreed that animals could not hold copyright, and there are no appeals still pending since then. That's pretty settled--there's no courts with binding precedent arguing for animals being able to hold copyright.

(Appeals courts can still settle case law, even if SCOTUS doesn't hear the case. There are several precedents that are set by appeals courts and not SCOTUS itself.)


Since compiled binaries are copyrighted, and this has already been tested in court, I believe the matter of generated code being copyrighted should be pretty clear: yes, generated code is copyrighted.


Well if it's your monkey (or program) that generated it (music or art or whatever) and the monkey can't talk, what's to prevent you from copyrighting it?


You can certainly try to copyright it, but if the person who slavishly copies the case can demonstrate that you didn't write it yourself, you lose the copyright protection because you're not the author. There are copyright cases which turn heavily on who the actual author of the work in question is--the Happy Birthday song being perhaps the most famous.


This whole thread could be true wrt the Monkey Selfies, but I am someone else's paid monkey and they can definitely copyright the work I do at work.

So does this case really boil down to the Monkey being free and not owned in that you can't take their copyright away, but you could if you owned the monkey?

I feel like the structure of our civilization is not stable, the focus and balance of capital power, the law and the ecological direction we are headed. I saw this play once and I didn't understand a bit of it.


> This whole thread could be true wrt the Monkey Selfies, but I am someone else's paid monkey and they can definitely copyright the work I do at work.

That is "work for hire." You are the creative author of the code, but since your creativity is being applied at the direction of another, it is that person who owns the copyright instead of you. The Copyright Office has a document to explain how to decide whether or not your work is a "work for hire."

As applied to monkey selfies, it's possible that the human photographer who set the situation up owns the copyright instead, but this wasn't argued in court.


Yeah, have an AI do the work and just say nothing about it.


Sometimes I fantasize about generating methods for creating copyrights, such that you can copyright the process of creating the copyright - for the commmunity, obviously. However, they explicitly forbid that, unfortunately. If only it worked, you could file a claim for anyone that created a copyright to your disliking, given that you probably make strong stance.

While I'm at it, in a similar vein though entirely unrelated, i sometimes think of ways to create jurisprudence in your favor: You try to emulate a situation to your disliking - e.g. aggresive data hoarding - and file suit to yourself, try to argue the arguments that your target would probably file, but just crappy enough that you actually lose. Do this often and stealthy enough and voila, you might have generated enough jurisprudence to actually file your final claim based on your previous "lost" lawsuits. I do think that this actually does happen at times, though.


You can't copyright a procedure or process, but you can copyright the text of the instructions for the procedure. That doesn't stop someone writing an original text of instructions for doing the same thing though. That's how come there are clones of Monopoly.

https://boardgamegeek.com/boardgame/20311/horse-opoly


Board games are protected with patents. For example, with Khet ( https://boardgamegeek.com/boardgame/16991/khet-laser-game ) there is https://patents.google.com/patent/US7264242 which was upheld - https://www.generalpatent.com/professor-s-company-wins-1-6-m...

The patent for Monopoly is https://patents.google.com/patent/US2026082A/en which expired in '52

There is also issues of trademark on the '-opoly' games... which was settled in '83 with https://www.americanbar.org/groups/intellectual_property_law...

> Finally, in 1983, the Supreme Court let stand an appeals court ruling that the word “Monopoly” had become generic, because purchasers associated the name with the product rather than with the source.7 Specifically, evidence showed that purchasers of Monopoly were motivated by their knowledge of the game, and not by its association with Parker Brothers. Directly as a result of this case, Congress amended § 14(c) of the Lanham Act, which addresses cancellation of a registered mark, later that year. Congress added language clarifying that a mark becomes generic only if its “primary significance . . . to the relevant public” is as the generic description of the particular goods or services, and that purchaser motivation is not used as the test.

---

There are clones of Monopoly because the patent expired long ago and the trademark was lost in 83. ... Which is also why McDonalds did its Monopoly game in '87.


> Which is also why McDonalds did its Monopoly game in '87.

Are you saying McDonald's needed to wait for the trademark to expire? Or that they had to wait for a new trademark to be established? Wasn't the promotion collaborative?

Looking at McDonald's Monopoly commercials from 87 [1] and 88 [2], there's a Parker Brothers TM in both years.

[1] https://youtu.be/F737BVBKMCE?t=4

[2] https://youtu.be/KmV5O06McZk?t=14


The Parker Brother's trademark they had to license... probably to get specific imagery. However, the suffix "-opoly" as it refers to games was lost.

McD's probably waited until the trademark on Monopoly was sufficiently weakened for them to go out, license the other parts of it (as it was Parker Brothers(TM).

https://tmsearch.uspto.gov/bin/showfield?f=toc&state=4803%3A...

In particular - https://tmsearch.uspto.gov/bin/showfield?f=doc&state=4803:qp... is likely the one that they're referring to which covers the trademark on the board and game pieces - which is different than the game name.

Also note that many of those (now dead) trademarks were all filed in '85 - '87... after they lost the trademark in '83.


Humans create works, not copyrights. Copyrights spring into existence from nothing every time an original work is created.

And IANAL, but I think that strategy could fall under https://en.wikipedia.org/wiki/Frivolous_litigation.


For video and photography, there has to be a human element involved.

A fixed, CCTV feed of a beach with a daily sunset is not copyrightable, nor is a non-human using a photo camera.


But a photographer who travels to the beach and sets out a camera on a tripod to capture a timelapse of the sunset DOES have copyright over those photos.

What's the difference if they leave the camera there for longer? They still chose the placement and the angle and the lens. In either case, the camera's electronics are deciding the minutiae of the image acquisition.


Intent. It is non-permanent and done by the photographer, not a third party.


The human still made the decision to place the camera just so. You're not travelling through enough layers of intentionality.


Which human?

The installer or the owner of the equipment?


Look through the contract. Guarantee the installer assigns all IP rights to the client if theres anything else softwarewise going on with the feed, and if not, litigation would probably clear it up.


>Can you copyright generated things? You probably could copyright the way you're generating it, but I doubt you have a legal standing about the generated text or melody itself.

What would be the difference between a "generated text or melody" you present to copyright, to one you've written yourself?

What would be the mark of "automatic generation" that would be used to identify them as such and disqualify them?


> What would be the mark of "automatic generation" that would be used to identify them as such and disqualify them?

None, but you wouldn't get copyright, much like you can present the works of others as your own but won't actually get the copyright if you're not the creator.


Huh? For one, nothing stops you from saying you are the creator, and nobody would have any way to say you're not.

Second, even if you have used a generator tool, regardless of if you wrote it or just run it, you're the creator of the works it produced, and you can trivially get copyright for it, unless somebody else copyrighted the same work.

Half of Brian Eno's output is generated works, where he sets some rules on a music synthesis system, and lets it create a work. Never had any issue copyrighting them...


> Huh? For one, nothing stops you from saying you are the creator, and nobody would have any way to say you're not.

Sure, just as nothing is stopping you from walking into a store, taking something, and walking out without paying. It's when you get caught doing so that the trouble beings. If you get caught, not only do you not get the copyright, but you've likely committed fraud.

Proving that you're not the creator is another issue, which would probably make for an interesting case.

> Half of Brian Eno's output is generated works, where he sets some rules on a music synthesis system, and lets it create a work. Never had any issue copyrighting them...

That's somewhat different though. Setting rules makes it a predictable process, and you have a one-way system: you set the rules and you always get the same result. A generator that would generate all possible results isn't the same.

If you sifted through all those randomly generated things, found one that you like, and published it, things get fuzzy, I guess. Maybe the curation would qualify as the creative input.


>Sure, just as nothing is stopping you from walking into a store, taking something, and walking out without paying.

Well, there is. If you get caught you get to jail.

Whereas if you get "caught" saying this generated melody is your melody, nothing happens. It's a totally valid thing to copyright. (And even if it wasn't, unlike the store theft case, there's no way for anybody to tell and prove it's not yours anyway).

But in any case, you appear confused as to this.

Whatever tool you can use to create a melody, the melody is still yours to copyright (unless somebody else came with it first and copyrighted it). You don't have to "think" of the melody or write it on the piano, or something.

In fact tons of melodies nowadays are written partially or wholly by compositional tools.

People using those tools have the regular claim to the output melodies, regardless of whether the tool is some DAW utility or "random melody" button (all of which exist), a music synthesis algorithm with some params and seed, or even an exhaustive, minimally creative tool to iterate over all possible melodies.

(Actually some musicians/coders did exactly the latter: https://www.vice.com/en/article/wxepzw/musicians-algorithmic... )

There's no rule "you can't copyright a generated melody".


> There's no rule "you can't copyright a generated melody".

If that was so, then no more melodies can be copyrighted after that group that was also mentioned somewhere else in the threads generated (essentially) all melodies, claimed copyright and then released them into the public domain. Alas, there is, even with people claiming copyright on individual generated melodies!

Again, I think the curation is relevant. You can certainly copyright a book, even though "it's somewhere in Pi". If you endlessly calculate fractions of Pi and check them for something interesting, I'm sure you can copyright whatever poem you find.


>If that was so, then no more melodies can be copyrighted after that group that was also mentioned somewhere else in the threads generated (essentially) all melodies, claimed copyright and then released them into the public domain.

Well, that's true.

But

(a) nobody is going to cross-check their melodies against a new copyright claim,

(b) they are not going to claim infrigement against anyone,

So there's that. And even if they did, they'd be thrown out as a joke-submission (the content being "all possible melodies" etc).

But you can submit hundreds of generated melodies, copyright them, and succesfully sue people for infringing of them. The fact that they were generated doesn't change anything.


"The record also showed that Java SE’s copyright holder would benefit from the reimplementation of its interface into a different market....the jury also heard evidence that Sun foresaw a benefit from the broader use of the Java programming language in a new platform like Android, as it would further expand the network of Java-trained programmers...and because there are two markets at issue, programmers learning the Java language to work in one market (smartphones) are then able to bring those talents to the other market (laptops)."

The benefits of reimplementing APIs always flow both ways. I'm glad SCOTUS recognised this point.


Except that Android is a fkup of “Java” that is so old that repositories have to create an android and a normal version. Kotlin spread into android development pretty much because android java is so bad.

That is exactly what was the “damage” Oracle sued for.


I kinda doubt Oracle sued for 9 billions damages because Google tarnished Oracle's image with their bad Java implementation.


I found this description of an API surprisingly good compared to earlier courts. It's not quite literally true, but it makes sense.

> The copied lines of code are part of a “user interface” that provides a way for programmers to access prewritten computer code through the use of simple commands. As a result, this code is different from many other types of code, such as the code that actually instructs the computer to execute a task

> As part of an interface, the copied lines are inherently bound together with uncopyrightable ideas (the overall organization of the API) and the creation of new creative expression (the code independently written by Google). Unlike many other computer programs, the value of the copied lines is in significant part derived from the investment of users (here computer programmers) who have learned the API’s system.


Oracle's response[1]:

"The Google platform just got bigger and market power greater — the barriers to entry higher and the ability to compete lower. They stole Java and spent a decade litigating as only a monopolist can. This behavior is exactly why regulatory authorities around the world and in the United States are examining Google's business practices."

- Dorian Daley, Executive Vice President and General Counsel, Oracle

[1]https://www.prnewswire.com/news-releases/oracle-statement-re...


Here, Oracle, let me break out the world's smallest violin...


The irony is that what they claim happened is instead what would have happened only if the case was resolved in the opposite direction. Everybody having to pay for API licenses for absolutely everything would be disastrous. The gridlock would be insane.


"Only a monopolist would have the resources to fend off our blatant shakedown attempt."


Oracle is very clearly banking on their political ties with the GOP to save the company. Regulatory capture in its most disgusting form.


The alternative would have been not using Java at all. That would have made attracting programmers more difficult at the beginning of the Android platform, but then, Java would have disappeared on mobiles, at least. I do not discuss why Oracle thinks is entitled to have of big chunk of the revenues of Android and the work of Google.


Oh, I forgot this little apocalypse was hanging over our heads. It's good to see some sanity.


And it's kinda nice to see it come to an end. I wonder if both google and oracle are looking at the bills from their lawyers and thinking about it like the destruction at the somme.

It's great for software, it'll be an interesting documentary someday. And congratulations to all the lawyers for making a ton of money.


I doubt that it's a lot of money for these companies.


This made me wonder what gender 'apocalypse' has in French (feminine, it seems - la petit apocalypse),


I’m just grateful this decision didn’t come out 4 months ago. It would’ve gone the way of 2020, somehow.


This seems to change part of the debate on "Extracting the abstract syntax tree from GCC" that happened here recently:

https://news.ycombinator.com/item?id=26590524

Specifically, this thread about copying the readline API: https://news.ycombinator.com/item?id=26606328

Stallman's contention that a judge would look unfavorably on cloning the API signature because it could be viewed as subterfuge...seems very weakened here, if copying an API is fair use.

I suppose this also gives companies like Amazon a green light for clones of GPL software exposing an API that's identical.


Yeah, but even Stallman's opinion and understanding on the matter has changed over time (that was one of the first GPL enforcement actions). IIRC, FSF was one of the amicus briefs in favor of Google's position. They want to be able to replace proprietary software with compatible, open source clones piece by piece.

In fact a good chunk of the case law cited today hadn't even hit the courts yet at the time Stallman made that statement.


Oh my God. What a relief.


Yep. This case was an existential threat to multitudes of industries and the assumptions they were built on.

The weird thing is it would of hurt Oracle as much as anyone. I have no clue how anyone w/any technical merit didn't understand that this was a footgun of the largest possible magnitude for them.


I had the opportunity once to talk to an IP lawyer for Oracle and brought this up. I specifically brought up the S3 compatibility of their cloud storage among other instances.

His reply was “without admitting anything specific, how do you know we haven’t purchased private licenses for anything you just mentioned?”


It's still silly. Imagine if you needed to purchase a license for the shape of plug that fits inside a standard plug socket - to build any appliance.


Plenty of good, cheap DACs built in China (e.g. Topping) have an HDMI-shaped plug (IIS) that supports PCM-over-not-HDMI which happens to be compatible with HDMI sources, but don't dare mention HDMI because they don't want to pull in an interlocking, price-gouging nonsense from the US entertainment industry.

So you don't quite need a license for the shape of the plug, but you do need to pretend it's not something that it is.


Oh yeah he and I still fundamentally disagreed, but it gave me some insight into Oracle’s position.


Imagine if you had to pay a software developer 300K a year to design that API that you think it’s cool to steal.


Someone had to design plug sockets too.


Isn’t S3 under the Apache license?


In my own mind, when CentOS died Oracle was saying you should move to "Oracle Unbreakable Linux"... which is a downstream clone of RHEL, just like CentOS was. Just one example of the hypocrisy.


It is uncontested that Oracle cloning RHEL is allowed by the license that RHEL is released under. They don't need a fair use ruling from the Supreme Court because they literally have a license that allows exactly what they did. The same could not be said for Google's actions in this case.


Even more egregiously, Oracle's whole existence is based off of copying the SQL API from IBM.


I'd really like it if we could kill Oracle somehow. They are easily the worst player in the technology industry.


Based on what?


I love how the Us supreme court judgements are written using low level terminology that most anyone can understand with little prior knowledge. Some countries use legal and complicated jargon that its hard to follow.


Based on my conversations with my wife, who is a lawyer, that plain language can be a little bit deceptive. While lawyers love their jargon and latin phrases, there's also a lot of very specific terms of art that sound like regular language. Terms like "reasonable" carry a lot of connotations and context in a legal decision that you don't get from the word alone. But yeah, I agree that these legal decisions are really easy for a layman to understand, even if I might miss some of the nuances.


Supreme Court decisions are the next-best thing to black-letter law. It is important to clarify what the law has been decided to be, once and for all. Lower-court rulings have no shortage of legal jargon and terms of art with meanings that conflict with everyday meanings of those same words, because they're just part of the sausage making that is drafting and interpretation of the law. SCOTUS rulings can have these too, as the other responder indicated, but there's just fewer of them (and more clarifying language where necessary) because again, a SCOTUS ruling is a proclamation to the people, once and for all, of what the law has been settled to be.


> It is important to clarify what the law has been decided to be, once and for all.

> because again, a SCOTUS ruling is a proclamation to the people, once and for all, of what the law has been settled to be.

That is not how our common-law legal system works. Even setting decisions that the court has later explicitly overruled aside, when the court announces a new rule, that rule is not totally complete and set in stone. Later decisions frequently flesh out, revise, or reinterpret prior decisions.


We're getting pretty far off topic, but I love this article: https://loweringthebar.net/2017/02/octopoid-embrace.html


From the dissent: "In the 1990s, Oracle created a programming language called Java..."

Sun Microsystems was acquired in 2010... I guess I should give Thomas the benefit of the doubt that he intended the statement to apply to Oracle's owned IP & not be a historical account of the language's creation and creators, but this rubbed me the wrong way.


He addresses this in footnote 1 on the same page, though. "A different company, Sun, created the library. But because Oracle later purchased Sun, for simplicity I refer to both companies as Oracle."


Thanks for pointing that out -- I skipped over that first footnote. On my screen, it's on the previous page from the quote I posted (for what it's worth).


Also from the first page of the dissent: "A different company, Sun, created the library. But because Oracle later purchased Sun, for simplicity I refer to both companies as Oracle."


I mean, Android was acquired by Google as well.


Not surprised at all the Thomas and Alito are in that dissent..


I was under the impression that a dissent has to be written, even if they all agree in the majority opinion/ruling?


No; in order to write a dissent, you have to disagree with the result.

If you write a separate opinion while voting with the majority, that's a "concurrence", not a dissent, and those aren't mandatory either.


You also forget that a justice might feel more comfortable with ruling in opposition so that he/she can write the dissent, but if his/her vote was a swing vote, the justice might have second thoughts about that. It's easy to vote in opposition when you know it doesn't matter - and then, hey, you get to write the position for the losing side.


> You also forget that a justice might feel more comfortable with ruling in opposition so that he/she can write the dissent, but if his/her vote was a swing vote, the justice might have second thoughts about that.

This doesn't make any sense. Justices vote in the majority while disagreeing with part or all of the majority opinion all the time. The mechanism for complaining about the majority reasoning is the same in either case: you write a separate opinion detailing your personal analysis of the case. That opinion is called a "dissent" if you voted against the majority and a "concurrence" if you voted with the majority.

There is no concept of "the dissent". Any dissenting justice is free to write one; it is routine for one case to have multiple dissents.


No, a dissent means that one or more of the judges disagreed with the majority ruling.


Why is it that you aren't surprised?


Because they tend to take extreme or simplistic positions in opposition to any sort of nuanced or interpretive view of the law.

In this case it's "Hey, it's Oracle's code, end of story."


Is intellectual surprise caused by anything other than bias?

I noticed this when I started rereading the dissent with a s/Oracle/Sun Microsystems/g. I felt a bit more swayed when I started to recollect all my fond Sun memories: blogs, hobbyist customer experience, etc. and stopped thinking about my glowing hatred of Oracle.

The dissent does seem nuanced to me even though I am quick to dismiss it based on the premise and my superior technical knowledge and maybe a bit of my own biases that I can't quite completely ignore.


Was following this on slashdot. Kids grew up in the meantime.


From a quick scan, the majority opinion here seems reasonable. I suspect it is what almost everyone working in programming would have considered the "right" answer.

The dissent is worrying, though. For a pivotal case that would have had a profound adverse effect on the future of software development had it been decided the other way, there seemed to be a disturbing lack of appreciation of the fundamental issues in play, particularly the practical reasons that programmers separate interface and implementation and the implications of this for interoperability.


For me, the problem here is that there is no logically consistent way to rule in favor of Google without undermining the concept of software copyright itself. APIs are creative expression: at a basic level, it is possible to change the names, the order, and to some extent the type of parameters and achieve the same result. It is also possible to change the structure of the API itself at a large scale in such a way that the programmer still can do what the API purports to provide, in a completely different way. Therefore, if one were to call APIs merely functional "declaring code" that cannot be copyrighted, then that would put all software code at risk of being called such. The idea that, say, a certain algorithm can be expressed in many different ways lies at the heart of how we justify making such expressions copyrightable.

With this ruling, either software will be found to be entirely (or mostly) uncopyrightable, which is unlikely, or software copyright will turn into an even bigger legal morass that requires a team of top-tier lawyers just to understand which parts of your software are effectively copyrightable (or potentially infringing) and which aren't.

The Supreme Court should have found in favor of Oracle, and told Google to bring their case before Congress if they're so worried that API copyrightability would destroy the industry.


The bits where they emphasise that the copying was "transformative" as part of the "Purpose and Character of the Use" analysis are interesting:

« Google’s limited copying of the API is a transformative use. Google copied only what was needed to allow programmers to work in a different computing environment without discarding a portion of a familiar programming language. Google’s purpose was to create a different task-related system for a different computing environment (smartphones) and to create a platform — the Android platform — that would help achieve and popularize that objective. »

« Here Google’s use of the Sun Java API seeks to create new products. It seeks to expand the use and usefulness of Android-based smartphones. Its new product offers programmers a highly creative and innovative tool for a smartphone environment. To the extent that Google used parts of the Sun Java API to create a new platform that could be readily used by programmers, its use was consistent with that creative “progress” that is the basic constitutional objective of copyright itself. »

This suggests to me that someone who copies a set of function declarations for the purposes of, say, creating a free-software clone of an existing product might not be able to rely on this decision.


> This suggests to me that someone who copies a set of function declarations for the purposes of, say, creating a free-software clone of an existing product might not be able to rely on this decision.

They wouldn't need to rely on this decision.

The courts tend to frown on using IP law as a weapon against interoperability or legitimate competition outside the scope of what the IP law covers. If you get sued for copying Yoyodyne's API in order to develop an otherwise original piece of software whose purpose is to interact with other software that expects Yoyodyne's program, the appeals court is likely to smack the suit down citing Sega v. Accolade and Sony v. Connectix, and the SCOTUS (assuming it gets that far) is likely to agree.

One of Oracle's major arguments was that Android was not interoperable with regular Java, and in Oracle's position the fact that Google copied Java's declaring code just to screw Oracle over put Android outside the bounds of interoperability fair-use protection.


Now Google, Microsoft and Oracle can go ahead and copy little startup's APIs, or even Stripe?

Using Stripe?

You're literally one-click away from our new Google Payments?

Just change this URL, and you're good?

I'm not as keen about the outcome as others.

It's good for open source in a way but I'm wary of big cos just wiping out smaller one's.

Also - does anyone with insight have something to say about open source APIs being copied, to get around copyleft?

Could GPL'd software now be 're-implemented' without concern?


Page 44 has Thomas’s dissent with Alito concurring. Worth a read as well, even just to see the opposing arguments.


Designing an API is a creative work not unlike that of an architect, I see the merit in the dissent pointing out, e.g "there may have been only one way for Google to copy the lines of declaring code, but there were innumerable ways for Oracle to write them. Certainly, Apple and Microsoft managed to create their own declaring code."


I'm not sure what Thomas was referring to. What does "create their own declaring code" mean? Did they do some kind of white room implementation where they typed in the contents of a javadoc web site? Did they modify the name of parameters?


Swift and C#?


Although I applaud the effect of this decision, I can't help but agree with Clarence Thomas that the reasoning behind it is not sound. It waffles back and forth between arguments for fair use and arguments that APIs are not (or at least should not be) copyrightable in the first place. You can't have it both ways. If APIs are copyrightable (and a plain reading of the text of the law appears to indicate that they are) then Google's copying was clearly not fair use. The purpose was clearly commercial, not educational or a parody. The API was not merely a fact or an idea, it was a specific embodiment that required effort to produce. And the copying clearly had a negative impact on the value of the original.

What really happened here is that the Supreme Court did an end-run around the law to paper over a major fuckup by Congress. On the one hand, I'm glad that they fixed the problem. But the way that they did it fills me with dread for the future because it undermines the rule of law.

For the record, I absolutely despise Clarence Thomas and everything that he stands for. But in this case I think he has a valid point.


>You can't have it both ways. If APIs are copyrightable ... then Google's copying was clearly not fair use.

You seem to have misunderstood the idea of fair use. Fair use is a specific doctrine covering the acceptable ("fair") use of copyrighted works. Fair use of a non-copyrightable work would be, technically speaking, a contradiction in terms.

See, for example, the US copyright office's explanation: https://www.copyright.gov/fair-use/more-info.html The first sentence is "Fair use is a legal doctrine that promotes freedom of expression by permitting the unlicensed use of copyright-protected works in certain circumstances."

Furthermore, there is no requirement that fair use be non-commercial. It is more likely that the courts will find that non-commercial use is fair, but that is not a hard and fast rule. An easy example here is book reviews quoting passages from the text.


The point of much of Thomas' dissent, as I understood it, was precisely that the court is muddying the rules by taking concerns that properly belong in copyrightability into fair use. They've carved out a subset of copyrights---copyrights on "declaring code"---and made them difficult or impossible to practically enforce. But they did so under one vague fair use factor, not the rules about copyrightability. Because, as Thomas sees it, there's no dignified argument for exclusion or second-class status under the copyrightability rules, most of which come from statute, rather than the courts.


The purpose was clearly commercial, not educational or a parody.

This is addressed in the decision on page 27. The Court wrote:

The text of §107 includes various noncommercial uses, such as teaching and scholarship, as paradigmatic examples of privileged copying. There is no doubt that a finding that copying was not commercial in nature tips the scales in favor of fair use. But the inverse is not necessarily true, as many common fair uses are indisputably commercial. For instance, the text of §107 includes examples like “news reporting,” which is often done for commercial profit. So even though Google’s use was a commercial endeavor—a fact no party disputed, see 886 F. 3d, at 1197—that is not dispositive of the first factor, particularly in light of the inherently transformative role that the reimplementation played in the new Android system.


> news reporting

Sure, but what that means is that I can do (say) movie reviews for profit and include clips from the film. It does not mean that I can re-broadcast the CBS Evening News with my own commercials.


IANAL, but there is definitely such a thing as commercial fair use. The music industry is rife with "they stole my riff" cases that hinge on whether the copying was transformative and the amount that was copied. I wouldn't go so far as to say this undermines the rule of law (rather, the Court's precedent-setting power is part of the rule of law. It may undermine rule by Congress, but nothing about the US system makes Congress a king, and if they want to take back their power on this topic, they need only craft a clearer law addressing these issues directly).

I think reasonable people can agree with Justice Thomas on this (sidebar: this is why I love reading SCOTUS rulings - they're generally wise people and both the majority and dissent sides are usually reasonable takes). The tests of "is it transformative" and "how much was taken" are probably the most subjective tests in the copyright precedent.


> It waffles back and forth between arguments for fair use and arguments that APIs are not (or at least should not be) copyrightable in the first place.

The precedential parts are unambiguous: Google's actions were fair use, as a matter of law (this is code to lower courts to not fuck around). The majority opinion did not answer whether APIs are copyrightable in the first place because it was unnecessary to settle the dispute.

The rest of it is obiter dicta. Thomas's objection, as is usually the case, is irrelevant.

IANAL, TINLA.


> The majority opinion did not answer whether APIs are copyrightable in the first place because it was unnecessary to settle the dispute.

They didn't answer it. They assumed it. They couldn't reach the fair uses analysis any other way. No copyright, no infringement, no need to assert affirmative defenses like fair use.

> In reviewing that [lower court] decision, we assume, for argument's sake, that the material was copyrightable.

> We shall assume, but purely for argument's sake, that the entire Sun Java API falls within the definition of that which can be copyrighted. We shall ask instead whether Google's use of part of that API was a "fair use."

You can call all dissents irrelevant if you like. But Thomas' dissent addressed the issue of the case, and arguably more directly than the majority's. The Federal Circuit decision on copyrightability, for which the Supreme Court denied cert, still stands. Its importance, not its rule, is called into question today.


> They didn't answer it. They assumed it.

Which is another way of saying: they didn't answer it. Because it wasn't necessary for the dispute in hand.

> But Thomas' dissent addressed the issue of the case, and arguably more directly than the majority's.

Thomas invented what he thinks Congress intended, through the usual the-law-is-only-what's-written-except-when-I-don't-like-it of American conservative jurisprudence. The copyright act was unclear on this question and that's why it came to court. The majority dealt with the actual dispute.

It should be noted that I prefer strict Dixonian legalism as a jurisprudential style. Thomas doesn't really do that. He cosplays.


Does anyone have a good estimate of what this case cost Oracle and Google, especially in terms of legal fees, and where that money went ultimately?


I don't know, but it was money well spent and we should thank them for causing this important point of law to be clarified.


It was money well spent for Google. For Oracle, it was money thrown away for nothing but bad PR.


The money goes into lawyers fees.

Because of the way this decision went, I’m sure Google considers it a worthy investment and Oracle considers it a temporary setback as it pursues other extortion schemes using Sun’s Patents. I wouldn’t be surprised if they have a specific division of lawyers dedicated to finding novel ways of extorting wealth using Patents; this would likely just be one of the cases they were working on.

Come to think of it, from Oracles perspective it was definitely worth a shot, to throw a few millions (if that?) with a chance of winning billions.


> worth a shot, to throw a few millions (if that?)

Teams of high end lawyers over about a decade? Probably at least 10s of millions.


> as it pursues other extortion schemes using Sun’s Patents.

They bought Sun 12 years ago...not much time left to pursue that...


It was definitely more than a few millions. Still might have been worth it but lawyers are expensive.


This has impact beyond APIs. The Supreme Court says copying User Interface is fair use.

Excerpts:

The nature of the work at issue favors fair use. The copied lines of code are part of a “user interface” that provides a way for programmers to access prewritten computer code through the use of simple commands. As a result, this code is different from many other types of code, such as the code that actually instructs the computer to execute a task. As part of an interface, the copied lines are inherently bound together with uncopyrightable ideas (the overall organization of the API) and the creation of new creative expression (the code independently written by Google). Unlike many other computer programs, the value of the copied lines is in significant part derived from the investment of users (here computer programmers) who have learned the API’s system. Given these differences, application of fair use here is unlikely to undermine the general copyright protection that Congress provided for computer programs.


You're reading too much into that. The user in this case is the programmer using the API, or even the code that uses the API. It's doesn't generalize to end user interfaces.


The same principle applies, and for the same reasons mentioned in the portions I excerpted above.


Hopefully this is a crack in the armor of the x86 monopoly - after all what is an instruction set but an "API for processors"? The novelty is in how you implement the instruction set, not the actual API that says "this instruction takes A and adds it to B", that is purely a matter of compatibility.


Who would willingly make a new x86 design these days?

I would think this would crack ARM's control over their instruction set though. I can't imagine it'd be worth re-implementing literally the entire thing from scratch though when ARM will willingly sell you IP blocks, as opposed to Intel or ARM which will certainly not.


Zhaoxin Semiconductor, for one. Hygon licensed AMD's architecture as a starting point for their own stuff for another.

You're not going to find a lot in the west due to the patent issues (why follow that path when you're doomed to be sued into the ground), but there clearly is a desire to pursue x86 as an ISA (as opposed to going with ARM).


That's fair, but on the other hand, why would they have cared about American copyright in the first place? Worst that could happen to them is they're banned from being imported into the west, which they probably didn't see as a realistic market anyway.


Does anybody claim copyright for ISA though? I think it is just patent minefield.


Well worth a read. "We reach the conclusion that in this case, where Google reimplemented a user interface, taking only what was needed to allow users to put their accrued talents to work in a new and transformative program, Google’s copying of the Sun Java API was a fair use of that material as a matter of law."


First of all, very good news. Second of all, what does this mean for Fuchsia, Dart, and related projects? I always assumed they were a hedge against Google having to pay exorbitant licensing fees to Oracle. Now that the threat has disappeared, will those projects be sunsetted too?


Given the investment going into Flutter for cross-platform mobile (and now desktop and web) development, I would be very surprised to see Dart get Google Readered.


To be honest, the investment into Flutter pales in comparison to Android (mobile, TV, ChromeOS, etc.). Flutter has always been a side project.


Agreed, very good news though I'm left with the same question. It doesn't inspire that much confidence, but the recent embrace of Flutter from Canonical leaves me hopeful even if Google did drop from active lang / framework development, it wouldn't be left to dry.


"(e) The fact that computer programs are primarily functional makes it difficult to apply traditional copyright concepts in that technological world."

So the opinion effectively preserves the status quo in the software industry while sidestepping the question of API copyrightability.


True, but it's such a strong precedent in favor of copying API's being "fair use" that it at least partly moots the more general question of "are API's copyrightable in the first place." I think this was a good decision all in all. AIUI, the SCOTUS try to limit the scope of their decisions as much as possible, to avoid over-generalization.


I don’t think it moots the point at all.

* Google’s API copying can’t be fair use if they weren’t copyrightable in the first place.

* If you do copy an API because of it’s beauty and not for either interoperability with software or interoperability with developers then it seems that you would run afoul of copyright.


If you do copy an API because of it’s beauty and not for either interoperability with software or interoperability with developers then it seems that you would run afoul of copyright.

That's why I said it partly moots the issue, not completely. Yes, you could conceivably still run afoul of copyright in some cases, but at first blush, this seems like a precedent that will make it very unlikely that that would happen. I guess time will tell, but that's my initial perception. IANAL, of course.


> If you do copy an API because of it’s beauty and not for either interoperability with developers then it seems that you would run afoul of copyright.

So don't do that?

Why would you copy an API save to be inoperable?

If it's just to duplicate someone else's design, I think I'm okay with that potentially being a copyright violation.

What downside am I missing?


Of course fair use is moot if API cannot be copyrighted in the first place. But the court seems to say that this case would be fair use even if API is copyrighted.

"We shall assume, but purely for argument’s sake, that the entire Sun Java API falls within the definition of that which can be copy-righted. We shall ask instead whether Google’s use of part of that API was a “fair use.” Unlike the Federal Circuit, we conclude that it was"


That... somehow seems fair? If what you are copying is the artistic expression and not the functionality, that seems like exactly the sort of thing copyright is supposed to be about.


Was the question of API copyrightability even raised before the court? I'd guess Google didn't think it was in their interest to go that far.


It was, but SCOTUS declined to rule on it.


> In this way, the declaring code’s shortcut function is similar to a gas pedal in a car that tells the car to move faster or the QWERTY keyboard on a typewriter that calls up a certain letter when you press a particular key. As those analogies demonstrate, one can think of the declaring code as part of an interface between human beings and a machine.

I love this analogy, and I'm going to use it to describe this case from now on. If I have a great idea for a new keyboard, maybe great new clicky keys or something, I have to make it QWERTY. I can't just come up with some random key ordering. And it has nothing to do with how good or bad QWERTY is as an idea. It's just that QWERTY happens to be what people have skills in.


Actually, I find this a bit underpowered. The whole idea is that the invention (in this case the API design or QWERTY in your example) is so powerful that it becomes a 'utility' - so Java's implementation was so powerful it really should have been 'patented' not copyrighted. Then after 20 years, you can take the true 'utility' of the API design from Java to the commons.

And yes, if ease of use will be a differentiator why people like Apple (whether it's right or wrong), then so is the ability to learn is an attribute to be protected from theft.

I say all this seeing exactly where Swift is heading, and probably why Apple created the language that will run their unified APIs... because there's no other way to join except through their Swift gates.


> The whole idea is that the invention (in this case the API design or QWERTY in your example) is so powerful that it becomes a 'utility' - so Java's implementation was so powerful it really should have been 'patented' not copyrighted.

The majority's argument was that utility is not imbued by the maker (Oracle), but by 3rd parties (programmers) adopting it. Patenting an API is a good way of scaring people away from using it - good luck with that.


The comments on this case always seem a bit confused to me.

APIs have been copyrightable (in the US) since 2014(or 15, not sure). This ruling only affects the fair use judgement, and makes no further statement on the question of copyright; meaning APIs are still subject to copyright.


The copyrightability of APIs goes back to the "structure, sequence, and organization" being copyrightable decision back in (checks Wikipedia) 1986. The application since then has been inconsistent. Essentially, there's a concept called "thin copyright" which recognizes that some copyrightable things only receive minimal protection. The canonical example here is a phone books--phone books are copyrightable, but they mostly contain non-copyrightable information (lists of phone numbers), so most copying will essentially be fair use or free.

Breyer's decision explicitly avoids deciding whether or not the SSO being copyrightable is good law, but it does essentially provide that it provides only thin copyright.


Does anyone have any insight into how the justices are educated about a case like this? I guess this applies to many cases, involving a variety of industries, but it's especially clear here that making a decision requires a technical understanding of the stakes. How are the justices made to understand what the different concepts meant? from reading the ruling it's clear that they have a very good understanding, and it's impressive for non-programmers, most of whom are older and did not grow up with technology.


I am not a lawyer. Is it finished ? Has Oracle completely lost ? I really do not like very much Oracle.


Just exhaled the biggest sigh of relief I've ever had when reading the title. Holy cow. Thank fucking god.


Thinking out of box.

Am I right that this may essentially end Dart project at Google?

As far as I understand Dart was an attempt to have another Java in case that Oracle/Google conflict will not go anywhere.

As soon as Google will be able to use Java on dart platforms there will be no need for Dart.

Just guessing.


From the dissent:

"Instead of creating its own declaring code—as Apple and Microsoft chose to do— Google copied verbatim 11,500 lines of Oracle’s declaring code and arranged that code exactly as Oracle had done."

I didn't read the whole opinion, but what is Google's excuse for this? If there's one way to do it, I don't think copyright should apply. But when there's more than one way, why should copyright not provide some protection? I guess just because it's tiny and contains little expression?

Regardless, it seems like very poor judgement to not do a cleanroom implementation here.


The 11,500 lines is the API interface, so just the function/class signatures.

They _did_ do a cleanroom implementation, that's the whole issue that makes it an interesting case: are APIs fair use?


Why did it have to be a verbatim copy rather than just a very similar API spec?


Because you wouldn’t be able to run your existing Java code on their VM?

The whole point was interoperability


That’s the API? You can’t clean room that without having a different API.


I am glad Oracle didn't win. It seems to me that they bought Sun just to sue Google. I'm still bitter over for how they destroyed Sun... it's a shame that they didn't have a better steward.


Sun drove themself into the ground. And at least in the Java world they have been excellent stewards. The platform is moving forward again.


Oracle is making a lot of innovation in openjdk and graalvm. They have much better engineers than if e.g Google had bought sun.


Ah yes. The company that forbids people from benchmarking their database must be a bastion of good engineering.


This does not generalize to the openjdk team. Google team characteristics tends to generalize more.


A good ruling.

Re-implementing an API is how we got clone PC's when Compaq cloned the IBM BIOS interface and associated ISA bus logic which made Intel based DOS home computers cheaper and affordable for ordinary people.


Is this a final judgement? Is it over now?


Yes. There is no appellate court above the Supreme Court. The only way things could change now is if Congress/President passed a new law, and I don’t think API copyrights are near the top of the list.


> There is no appellate court above the Supreme Court.

That is true.

> The only way things could change now is if Congress/President passed a new law

That isn't true at all; the Supreme Court is free to change the law by itself. Someone could sue over the same question and get a different result overruling this one.


They are free to change their mind, but are very reticent to do so. What compelling reason would there be to revisit this that could possibly change the outcome?


Suing over the same question wouldn't get very far. The best approach would be suing over a closely related question. See coomoo728's analogy to Roe v. Wade: https://news.ycombinator.com/item?id=26699621


And this has happened hundreds of times already

https://en.wikipedia.org/wiki/List_of_overruled_United_State...


Time for Oracle to pull out the Sun patent portfolio and start over.


IIRC, they lost on the patent portfolio at the very beginning. That's how the case went to CAFC instead of the Ninth Circuit--there was a patent argument in the original appeal, which was dropped several years ago. And having already lost on the patent question in the past, any future case can point back to that decision and say "can't relitigate this point."


Yeah, before it expires.


I hate analogies... but will use one here... 'copying' an API, to me is a bit like copying the look&feel of a product. There used to be similar lawsuits alleging 'look and feel' violations awhile back between Microsoft and whomever (I don't recall anymore), most if not all of these bombed. If Google had lost this one, then the next step would be copyrighting a typedef-ed struct with "proprietary" Google data in it...

I am not a huge fan of Google's antics in general, but in this case, I am glad they won.


Regardless of how you feel about the legal question, if you read the whole thing, it’s interesting to see how much the justices differ with regards to their respective grasps of the technical and business issues. In particular Thomas’s dissent includes many very relevant business and technical facts that Breyer’s opinion doesn’t even mention. For example Java SE vs Java Micro Edition, advertising business model vs licensing model, the inherent creativity of designing an API, Apple and Microsoft’s competing products, etc.


Does this mean Fuchsia/Zircon are effectively dead? I got the impression Google was keeping them as a backup in case this lawsuit went badly for them.


Android has already switched to GPLed OpenJDK for the Java classes in question. This was about the Android versions from before that switch over.


I feel conflicted about this decision. I've added some analysis here:

https://frequal.com/java/SupremeCourtOracleVsGoogleRuling202...

focusing on two areas: * Google had the ability to make their own language and APIs for Android * The chilling effect on future language/API innovation


Not a programmer.

If I find a service that provides and API and I want the existing developers (customers) who use the service to be able to use a competitive service and the original API is re-created in order to provide compatibility with the second service. Is this OK?

The original API is part of a commercial service, the re-created API will be a commercial service, but not the entire service just a compatibility layer.

Thoughts?


"The fourth statutory factor focuses upon the “effect” of the copying in the “market for or value of the copyrighted work.” §107(4). Here the record showed that Google’s new smartphone platform is not a market substitute for Java SE. The record also showed that Java SE’s copyright holder would benefit from the reimplementation of its interface into a different market. "


Why would Google do this in the first place? The reason is that they did not have time to figure out what capabilities might be needed in their own solution. So copy the API from someone's other competing product and then later, put code behind those API calls. Is it theft or cheating? Kind of, I suppose. It saved them time from having to engineer the API surface.


Yeah, it really just gave them a shape that devs were familiar with and they could evolve the underlying mechanisms over time


Now while I eat my hat, I am waiting to see what will be the next excuse for not updating Android Java to latest versions.


How about promoting Kotlin to spite Oracle? That's what I'd do in their shoes, if I were feeling salty, with a longer-term goal of making Java the COBOL of the 21st century.


Oracle's newer VM patents.


Cleverly forgetting those from IBM, Intel, Microsoft, Amazon, Azul, SAP, Alibaba and everyone else that works on Java?


No, because the core patents behind the features you're asking about are very much in Oracle's possession, as those class library improvements were overwhelmingly written by Sun/Oracle engineers. Those other actors you're talking about absolutely contribute, but not in as nearly a fundamental to the implementation of the library and runtime definitions kind of way.


Are you now asserting that Sun/Oracle has pattents regarding Azul's GC implementation, PTC real time threading and AOT compiler, Aicas hard real time GC, IBM mainframe implementations of their own JVM and WebSphere Real Time VM?


No, I'm asserting that those (while being extremely valuable additions to the field) have nothing to do with a newer version of Java which is what you were asking about.

> the next excuse for not updating Android Java to latest versions.


So let's back to that.

The only two companies that ever had issues with Java owners were Microsoft thanks to J++ and Google with its Android Java.

Lots of companies have produced their own Java version, without any issue.

Sad that things have gone this way and Google isn't being hardly punished for what they did to Java ecosystem with their special flavoured Java and by giving Sun's fatal blow.

Thankfully they never thought of buying Sun to own Java, as it would have been yet another project on their graveyard, looking to how they handle it on Android.

But yeah lets not get distracted and join the Oracle hate mob.


> The only two companies that ever had issues with Java owners were Microsoft thanks to J++ and Google with its Android Java.

While the Apache project is not a company, it definitely had issues with Sun over Apache Harmony's Java certification (I'm not confirming or denying that this was part of IBM's proxy wars with Sun).

Incidentally, Apache Harmony is what Google used to jumpstart not-officially-Java compatibility with Android.

> Sad that things have gone this way and Google isn't being hardly punished for what they did to Java ecosystem with their special flavoured Java and by giving Sun's fatal blow.

Speaking of "special flavoured Java" - what Google did with Android was an improvement over the fragmented mess that was Java ME. Good God, I remember Sun-approved, vendor-specific extension, so Samsung/Nokia/Sony-Ericsson each had its own API for the same functionality - e.g. checking for connectivity. Additionally, the API could be subtly different for each phone model from the same vendor. You either had to create different build pipelines (1 per vendor, with overlays/facades), or do an ungodly amount of reflection in your runtime logic. So much for "Write Once". Sun was never interested in licensing Java SE on mobile, I don't see how Google could have killed them when they weren't even competing on "your phone as a full-blown computer"

I loved Sun Microsystems; they were idealistic, geeky, and made very cool, albeit expensive gear. I suspect their idealism made them hop onto the open source bandwagon without due consideration for long-term sustainability. They open-sourced the OS (OpenSolaris), open sourced the application stack (Java, perhaps reluctantly), while their server hardware was being disrupted by x86; how were they going to make money? They were not long of this world - Linux, commodity x86 and open source Java Application Servers killed Sun. IBM was in a similar place at the time, and they shifted focus to consulting.

> But yeah lets not get distracted and join the Oracle hate mob.

I've been part of that mob for a long time, fuck Oracle for how they treated Gosling, how they handled the JCP, and mishandled OpenOffice (until it blew up in their face). I didn't care for MySQL, but it seems to have been ok so far.


I love how Google apologists sell Android fragmentation and OEM modifications to AOSP as an improvement over J2ME.

Now excuse me while I will compile some stuff in Java 16 with the SIMD preview API.


If you had the displeasure of coding a moderately complex J2ME app - you'd know this it's not mere apologia. While Android fragmentation is terrible (and was worse in the android 1 era), J2ME was at least 10x worse - I haven't met a single person who disagrees with the idea that Android was a massive improvement over J2ME - I noticed not even you are making that argument, you're only chiding me for bringing it up.

Sun could have fixed it by availing Java SE on mobile devices and forcing vendors to implement the same APIs in the same java.smartphone.* packages - (they already had a Java TCK!), but they were not prepared for the smartphone era, sadly. Look at the CLDC[1] classes and tell me how one could write apps that could possibly compete with the iPhone apps in 2007.

1. Sadly - but predictably, Oracle nuked java.net which had documentation on CLDC 2.x/MIDP, I managed to find CLDC 1.1 documentation, the classes are surprisingly sparse, so J2ME was probably worse than I remember. https://docs.oracle.com/javame/config/cldc/ref-impl/cldc1.1/...


So what does this mean for the future of Java, now that Oracle won't be able to milk Google with licensing fees?


That's good for practical purposes, but they still didn't rule on APIs being copyrightable or not to begin with? It's a bit weird to say "it's fair use" but not say "it's not copyrightable in the first place".


So not only a good decision, but one that was decided 6-2, with the younger judges (left and right) among those 6. It looks like it could be a solid majority on the side of sanity on this particular issue for a long time (knock on wood).


I'm so relieved. This could have forced such dramatic changes in how we develop software. And any other decision would have been a crippling blow to FLOS software.

Now if we only could get the SC to invalidate software patents in general.


This is a large scale defeat of the GPL and dual licensing, so I'm not sure how this could be anything but a sad day for sustainable open source development.

If you're big enough and have enough lawyers, there's no reason to license software you want to build on.


How does this ruling interact with GPL?



That's a different situation though. You're then distributing something intended to link with readline -- not just implementing its API yourself but using its entire original implementation.

What you could perhaps do is create your own implementation of the readline API distributed under a different license and then claim your program is intended to link against that, but how would you claim that if no such implementation exists? Whereas if you have to write your own readline implementation in order to use it then you still end up with a large incentive to avoid that by releasing your work under the GPL instead.


> This is a large scale defeat of the GPL and dual licensing

Can you elaborate on that? What does this have to do with those thing?


Google had the option to use the OpenJDK and make Android a GPL-based platform. They did not want to. They could've, and tried to, negotiate a separate license, but simply decided to copy what they wanted instead, relying on their legal team to protect them.


I'm confused how not using the GPL version makes this relevant to the GPL.


Dual licensing is a common reason to GPL your code: Letting people have and use the source under restricted terms, and paying for an enterprise license otherwise.

If Google can steal the code from the GPL version and then just not obey the license or pay for an enterprise license, dual licensing is dead and no business will open source their code under a dual licensing model.


Google did not steal code. Dual licensing is not a reason but a practice. Unlicensed use of code is still unlicensed and punishable by the terms of the license. Dual licensing still exists and will continue existing.

Please.


Google has been using OpenJDK since Android 7.


On the other hand, it's the sort of ruling that could make companies less skittish about using GPL software.


Solely because the GPL may now be so weak nobody is worried about enforcement. If Google can so blatantly create a monopoly scale business by ripping off something instead of complying with the license or licensing it separately, there is no teeth to the GPL at all, and releasing your business' code under GPL is an existential risk.

They might use the GPL software, but feel no compunction to either open source their own modifications nor pay for an enterprise license.


Except that Google only copied the API, so how does that apply to anyone doing more than that?

For that matter, how does that have anything to do with the GPL at all? If you distribute your software under a proprietary license instead, how does that affect whether anyone can reimplement your API? If somebody wants your implementation then they get it under your license. If all they want is their own implementation of your API then your license doesn't matter, does it?


From a statutory standpoint, there is no difference between the API and the code in general, which the dissenting opinion highlights. So if fair use is granted for theft of copylefted code in a non-copyleft manner, it doesn't matter heavily whether that was "declaring code" or "implementing code".

This ruling doesn't change that APIs are copyrightable code.


The dissenting opinion is stupid. Thomas may be a bad justice, but he has even less of a clue about software devolopment. Of course there is a difference between an API and the code in general.

This decision sidestepped the question of whether APIs are copyrightable or not by declaring that this particular instance was fair use.

Reimplementing interfaces has always been fair-use, they are definitions. Re-Implementation of these interfaces has been a cornerstone of FOSS since its very beginning.

> So if fair use is granted for theft of copylefted code in a non-copyleft manner, it doesn't matter heavily whether that was "declaring code" or "implementing code".

I don't think these words mean what you think they mean. There was no theft and of course there is a difference between declaring code and implementing code.

Shesh...


> This decision sidestepped the question of whether APIs are copyrightable or not by declaring that this particular instance was fair use.

This is incorrect, before fair use was tested, copyrightability was established, which is why the fair use defense, which is an exemption for copyright violation, was then determined. If you followed the various appeals and rulings this case entailed, you'd have to be aware of this.

APIs are copyrightable, as this case has determined, but now the Supreme Court has also thrown out any reasonable definition of what is and isn't fair use.


It's convoluted.

Ninth Circuit courts held APIs weren't copyrightable. The Federal Circuit (which only had jurisdiction because of the thrown out patent claims) held that they were copyrightable. The majority of SCOTUS here explicitly said they weren't deciding copyright of APIs. Instead they looked at both cases and said: "either it isn't copyrightable, but even if it is copyrightable, that this is fair use." Either way, Oracle loses. Arguing in the alternative is a common legal pattern, as is ruling on the narrowest possible ground.

Generally when a circuit court makes a ruling, it's only "binding" precedent on subsidiary courts within that same circuit. The federal circuit is weird though, as it doesn't have a geographical jurisdiction, instead it has a subject matter jurisdiction. If a case has patent claims (or a few other things), an appeal gets routed there.

So, effectively, APIs are copyrightable if there is a linked patent claim in the same lawsuit.

Courts can certainly use the Federal Circuit ruling as "persuasive" precedent, and rule the same way, but it's not binding, and it's not settled law.


> So, effectively, APIs are copyrightable if there is a linked patent claim in the same lawsuit.

I suspect the Supreme Court would not be happy if a pattern develops where companies include spurious patent claims in order to get their copyright case heard by the Federal Circuit instead of one of the other circuits. They won't want another mess like this case, and if the Federal Circuit again rules in favor of API copyright and against fair use, I would expect the Supreme Court to rule on the API copyright question directly rather than merely clarify the bounds of fair use as in this case.


> APIs are copyrightable, as this case has determined

The supreme court explicitly refused to rule on whether code was copyrightable or not.

The lower courts made conflicting rulings on that question. But the supreme court itself only assumed, for the safe of argument, that code was copyrightable, and did not rule on that question itself.


GNU/Linux owes its very existence to the practice of reimplementing interfaces that this ruling now codifies.


This ruling has nothing to do what so ever with the GPL.


I don't see how this case has anything to do with GPL.


How so?


Can you explain?


I love this outcome. But what are people's thoughts on the analogy between a software platform and a "factory floor"? That seems wrong to me; the "factory" is more like the IDE, not the platform.


I had forgotten about this for quite awhile, given the pace at which these cases operate at.

The great sigh of relief I was unexpectedly gifted this morning upon seeing this at #1 was a nice surprise. Very important precedent, good job.


Great line:

> Unlike many other computer programs, the value of the copied lines is in significant part derived from the in- vestment of users (here computer programmers) who have learned the API’s system.


After experiencing 'good' and 'bad' API design, I'm really hoping that people who invest in creating great APIs get to benefit from their hard work even after this.

This decision doesn't appear to speak to why the 11,500 lines were actually important, other than to 'steal' developers away from Java - which in effect is poaching without the hard paper trail and paystubs.

So in the end, I find this setting us all up for the real battle... the utility of APIs and languages, which will bring us back to settle squarely what is a 'utility' & 'design' patent, and what is a copyrighted material.

I'm curious to know who will take it up -- I doubt anyone of consequence will be copying APIs after this.


Let's assume Google was in the wrong here - for the sake of argument.

How would it been possible for Google to do this without just taking the API definitions.

Could they have just use compiler errors?


Pay for the at the time not open license?


It's interesting to me that they ruled that APIs are copyrightable, but that copying them is a fair use.

In what circumstances would non-fair-use copyright then apply?


They didn't actually say whether APIs are copyrightable, just that they would assume it for sake of argument and test to see if the fair use test was sufficient. They found the fair use test sufficient so they didn't investigate whether it was copyrightable or not.


> In 2014, a federal appeals court ruled that the APIs could be subject to copyright in a controversial decision overturning a ruling by Judge William Alsup. (The Supreme Court declined to hear Google’s appeal the following year, letting the appellate ruling stand.)

- https://www.theverge.com/2021/4/5/22367851/google-oracle-sup...


I have a workaround. I was thinking that an adapter socket can be patented. And use by others cannot be made declared under fair use.

So what if APIs were also patented?


Does oracle have any moves left to counter this decision? Or are we finally clear of this litigation that has been hanging over us for so long?


The Supreme Court is the court of last resort. They'd have to start over with some new argument, and if they had a better one I imagine they would've pulled it out by now.


Thanks, makes sense and is good to hear.


This is not a Constitutional issue. This is a purely legal decision based on a federal statute passed by Congress.

Constitutional issues are somewhat of a mix of the political and legal. SCOTUS tries to be apolitical, but by its nature it can override Congress on Constitutional matters, and therefore it's at least somewhat political.

But cases like this are legal. Political credit and blame for this decision should go to Congress, not SCOTUS.

Of course, those interested in the legal process itself may give credit or blame to the justices for their legal positions.


Every time I see a big thread I smile knowing dang is going to have to write some comment about how they're working on things


A summary for those who don't want to read the entire thing:

This case was originally granted back in 2019. It was scheduled for oral argument in March 2020, but was postponed at the last moment until October because of the pandemic. Being postponed at the last moment, it was fully briefed well over a year ago, and the justices likely knew how they would rule in the case for a long time. (It's unclear how much of an impact oral argument actually has on influencing the decisions). That it took so long for a decision to come out--this is the last October hearing to get an opinion--strongly suggested to me that this would be a messy case with several overlapping concurring and dissenting briefs.

It is not. It is a simple 6-2 decision, with a single majority opinion and a single dissenting opinion. I'm reading between the lines here, but it seems pretty clear that Breyer (the majority opinion author) does not believe that APIs are copyrightable in the first place, but doesn't argue that point as he probably does not have enough other votes to agree with him. It's plausible that Breyer had a lengthy section on why APIs weren't copyrightable but that was pulled due to the other justices in the majority rejecting it. We can't know what the voting would break down as, but a 3-3-2 breakdown of "API is uncopyrightable; API is copyrightable, but this is fair use; API is copyrightable, this is not fair use" does not strike me as implausible. (There's not much in favor of this breakdown, note: that I lay it out like this is as much wishful thinking as anything else).

Thomas's dissent--I'll focus on that first--essentially makes two main arguments. The first is that API is copyrightable in its own right (Breyer's opinion assumes that it is for the fair use analysis but doesn't say that it is). The second argument is that Google's copying of the API cannot be fair use. A lot of that argument appears back-reasoned from "Google copied so much of the API and they made so much money off of it, how can it possibly be fair." In a broader sense, however, it's a different mode of fair use analysis than Breyer argues for. Thomas essentially views copyright as a property interest, and fair use is a narrow limitation on property interest. The API is an entity in and of itself here, so even though the API is a tiny fraction of both the original and reimplementing code, you need to look at the amount of the API itself that is being copied to judge how substantial a portion it is. Although when he turns to consider the impact that an independent implementation has on the market for the original, it's not the market of the API itself that matters but the market of the entire implementation.

Now going back to Breyer's opinion, he treats fair use rather differently. First, Breyer essentially invokes the idea that different kinds of copyrighted material deserve different amounts of protection. He draws a distinction between declaring and implementing code, and notes that since only declaring code is being copied, it pushes the factor analysis much more towards being fair use than otherwise. In contrast to Thomas, Breyer notes that commercial use isn't automatically non-fair use, and lists a few examples of where commercial use can indeed be fair use. Also, Breyer pushes hard against the idea of copyright being about property interests, noting that the Constitution expressly provides that copyright is for the progress of science and arts. Whereas Thomas places primacy on the importance of the effect of the market, Breyer instead contends that it's the least important factor here.

All the way back at oral argument, Thomas surprised me with the most insightful question: the fair use factors in the law are very explicitly a nonexhaustive list, so what other factors might exist to sway fair use analysis? At opinion time, Thomas is instead the one to declare that none other exist, while it's Breyer who rather strenuously comments that fair use analysis is not exhaustive, although he does not include any other factors in his analysis.

What's the overall impact, then? APIs may or may not be copyrightable--SCOTUS does not decide. But Breyer essentially suggests that APIs have at best "thin copyright"--a lot of their use may be inherently fair use (the same analysis Breyer does here can reasonably be copy-pasted for a lot of API reimplementation cases). What's more radical is the effect it has on fair use analysis. Breyer states that appeal courts have to reconsider fair use on appeals if juries find a use to be fair or not (that's an easy part of the opinion to miss). Breyer upends the traditional notion of how to balance fair use factors yet again. Essentially, he suggests that the analysis of fair use is dependent in large part on what kind of work is being copied, and the balancing is dependent on the kind of work. He also rejects a lot of the traditional emphasis on market or potential market analysis for fair use. This is somewhat disclaimed for wider application to non-code cases, but you can bet there is now going to be a lot of appeals surrounding fair use over the next few years.


This is a pretty good summary of the philosophical difference between Thomas's and Breyer's view of copyright.

I'll add that Thomas points out that if Breyer wants to talk about "thin" copyright, he should have discussed it within the copyrightability context, not skirting and discussing it in the "fair use" segment. If Breyer does so, Thomas argues, Breyer would find that "thin" copyright is still copyright, and Google will have no argument left to support fair use. All the remaining facts (such as competition, loss royalty, etc.) would support non-fair use.


This will be great for developing nations.


I’m super conflicted because I think I side with Oracle here and I never seem to. Java had an established API. It had a license. Google could have licensed it and the end result would have been the same: Java apps on Android. Weren’t there even Google brass worried about this in emails? It seems to me Oracle is due license fees but SCOTUS ruled otherwise and I guess that’s overall better for the industry.


Copyright protection is not an automatic right that you're entitled to for anything you put effort into creating and want to make money off of. There are more specific requirements for what you need to do to secure copyright protection or patent protection, and there are limits on the exclusive rights those get you. "They worked hard on it and want to charge money for it" is not a sound argument.


Edit: I’m dumb. I need to read all of the ruling and then research what fair-use really means.

Again I’m not a lawyer and I know there’s nuance and precedent in the law I just am having a hard time with the seemingly obvious-ness of this case.

Some examples to share how I am thinking of this:

1. Procuring land, paying contractors, buying materials, etc., doesn’t entitle you to rents in perpetuity on say an apartment you build?

Or 2. if I produce music — until that music ages out and becomes a public good — and I own the masters and all the rights to it having put in the work and the time and the money etc., am I not entitled to all the fees from licensing it to be played and consumed?

I am having a hard time seeing how it’s not a sound argument given that it seems very clear that Sun Microsystems put in a lot of work and effort and time and money to get Java off the ground and here Google comes and copies it even when there was an easy way to get a license.


I cannot tell you how happy I am to hear this. My heart sank when things seemed to not go well for Google.


I hope Oracle is ordered to cover Google's legal expenses for all of the lawsuits (related to this).


So does this ruling actually mean anything or can Oracle challenge this too somewhere else?


It's the Supreme Court of the United States; there's no higher court for this case to go to -- it's final.

Oracle could launch a new case but it would have to rely on entirely different merits. If Oracle did have such other grounds for a suit, they would have included them in this case.


Sanity prevails. This is incredibly important for _literally every programming language_!


Google's an LLC?


After a restructuring, Google is an LLC owned by Alphabet Inc. (the publicly listed organization).


Great! This could open a very dangerous precedent.

Time to end this one now: https://news.ycombinator.com/item?id=26692575


So Oracle's reason to buy Sun failed? I am happy.


Ok, so what is Oracle's next move then?


This is the end of the road, unless they can get Congress to change the law, of course. But they have 0% chance of that.


I'm sooo relieved that this is over!


How who Apple react if some company copied, then implemented their iOS API on their mobile device, so they could run Apples hundreds of thousands apps?


Guess thats it for Fuchsia and Flutter


> Those 11,500 lines, however, are only 0.4 percent of the entire API at issue, which consists of 2.86 million total lines

This marks jurisprudence


Yay!


All thanks be to God


Thank goodness.


Thank God.


this is a matter of opinions, and the jurors voted based on their own flawed understanding


The interesting question is how broad this fair use ruling is. According to the Supreme Court's other fair use cases, fair use is highly fact-specific and therefore case-specific.

What kinds of actions and motivations by Google could have led to a determination that the use was not fair?

Or is Embrace/Extend/Extinguish as practiced by the big tech companies now always protected by fair use?


That's exactly the question.

We see the majority trying to preserve flexibility in fair use throughout, even going so far as to head off arguments that this decision affects others:

> We do not say that these questions are always relevant to the application of fair use, not even in the world of computer programs. Nor do we say that these questions are the only questions a court might ask.

> The fact that computer programs are primarily functional makes it difficult to apply traditional copyright concepts in that technological world. ... In doing so here, we have not changed the nature of those concepts. We do not overturn or modify our earlier cases involving fair use. ... Rather, we here recognize that applications of a copyright doctrine such as fair use has long proved a cooperative effort of Legislatures and courts, and that Congress, in our view, intended that it so continue.

We see Thomas leading this question in dissent:

> Because the majority's reasoning would undermine copyright protection for so many products long understood to be protected, I understand the majority's holding as a good-for-declaring-code-only precedent.

Fair use is a mishmash of vague, impressionistic factors and a long list of cases from which to argue by analogy. It's not sharp-lines law. It's finger painting.

Which is why lawyers so rarely recommend that people rely on fair use in any really meaningful way, outside areas where there have been a lot of court decisions, or where strong industry norms have evolved between repeat players.


The centerpoint of the analysis is recognizing that declaring code is different from implementing code. From this key distinction, it pretty much follows that most copying of declaring code that does not also copy implementing code is inevitably fair use, so it can effectively be argued that copying APIs is inherently fair use. Kind of like how we say that commentary or parody is inherently fair use--it's always case-specific, but there are broad categories where you're almost always going to agree that it's fair use.


I wonder if Google will continue to move away from Java even after winning this ruling.

What will Java look like at Google in 2030?


Does that mean that we can use portions of copyright code/text with no repercussions?


thanks for the downvote you spineless user;)


Really interesting!


Now can they please use a modern jdk on Android? It's about time


They are using a modern JDK on Android. The standard library is literally OpenJDK, and the runtime is the excellent ART JVM, which has super-fast GC and tons of mobile-specific optimizations (like zygote space support and switching to a different GC when the app goes into the background). IMHO, you really don't want HotSpot on mobile. ART is good work.


I think he's just referring to a modern version of Java the language, not ART vs HotSpot. I don't think anyone really cares which runtime is running.


The runtime prevent the support for modern JVM features such as value types (see my comment above). Google might duplicate all that work (but how much late they will be before it divide the Java world? Switching to a unified jvm and improving it through collaboration is the way to go.


But as the person I replied to, HotSpot doesn't perform as well for the use cases ART covers.


I am talking about C2 JIT support and other sota GCs. ART has an increasingly growing technical debt. No support for constant dynamic so no support for the upcoming pattern matching. No support for sub 1ms GC No support for the already available Vector API. No support for value types. No support for generic specialization. No support for Loom. ART is NIH and support with Java and Kotlin will explode into two worlds, the Android obscolete world and the modern, feature complete and optimized world. ART has custom improvments? Fine that's good, now let's gradually port them to openjdk (or a light openjdk fork). No custom improvement is gonna outweight the need of interoperability (and the order of magnitude performance improvement from the above features) ART is an AOT so I wonder if the android team has considered switching to GraalVM instead of hotspot, the transition might be easier. Please Google, it's time to show technical excellence.


If you think ART is an AOT system, you might want to refresh your understanding of the system. ART has had a JIT for a long time now. Sure, HotSpot might have some features ART lacks, but ART has features that HotSpot lacks, so it's a wash. (And ART already has sub-millisecond GC pause times.) It's good and healthy for a language to have multiple implementations and there's no obligation whatsoever on the part of the Android people to switch to Oracle's JVM.


Hotspot has sub-millisecond GC pause times.

"But as long as your system isn’t heavily over-provisioned, you can expect to see average GC pause times of around 0.05ms (50µs) and max pause times of around 0.5ms (500µs)." https://malloc.se/blog/zgc-jdk16


Sure, HotSpot might have some features ART lacks, but ART has features that HotSpot lacks, so it's a wash.

The ART features are not exposed to the language design. The JVM features in addition to the order of magnitude performance impact it will have (cf previous comment) needs to be supported in order to maintain interop with future JVM languages versions. (cf previous comment)

It's good and healthy for a language to have multiple implementations no it's much healthier to have one that reap most of the benefits through collaboration. Hence why Android try to merge its patchset in the Linux kernel instead of duplicating it's million commits.

Sure, HotSpot might have some features ART lacks, but ART has features that HotSpot lacks, so it's a wash. Technical excellence unfortunately isn't an obligation. Or at least until the system becomes unsustainable (Cf interop) but then when it comes it is too late.


[flagged]


Upvoted because you shouldn't be downvoted into oblivion just for having an opinion contrary to the HN hivemind. It's okay to think Oracle should have won here. I disagree, but there are reasonable people on both sides.


The GP post seemed to start with some interesting information but then instead of adding enough substance to become a good comment, it petered out—and then it went straight to flamebait. It's correct to downvote flamebait.

Contrary opinions are welcome but need to come with substantive information. Contrarian comments that just go "nyah nyah nyah" at the majority end up having the same effects as outright trolling. It's tempting to do that, because it's frustrating to be surrounded by opponents (which is what holding a minority view on the internet feels like). It's part of maturing as a commenter to resist the urge to lash out in such situations—which is in your interests not to do, since it only discredits the minority truth even further.

Past explanations about this:

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...


In thought Oracle should have won this case as well and the opinion basically affirmed the reasoning but went the other way. The basis for Oracle winning was that copying the Java API for interoperability with developers rather than for existing software was copying for Java’s beauty rather than being purely functional.

Whenever this case came up on HN people outright refused to acknowledge that one’s intentions even mattered when copying an API.


> copying for Java’s beauty rather than being purely functional

How would "beauty" be defined here. In the context of copyright, it would seem to apply to aesthetic beauty, but I'm not sure that applies to code (despite all sorts of engineers using the metaphor for theirs or others work).


I would imagine it would hinge on the simplicity/elegance of the organized structure of the APIs? We tend to prescribe the term beauty to language features that are easier to use and implement in a novel way compared to the languages that came before.


I'm not sure that is the same use of the word "beauty" as used in copyrighted materials like books and art, since APIs are machine blueprints, whose primary and fundamental purpose is functional, not aesthetic.

Similarly, though a mechanical engineer might describe a particular gearbox design as beautiful doesn't make it copyrightable, since it's fundamental purpose is also not aesthetic.


The QWERTY layout isn't the best but everyone makes their keyboards the same layout. QWERTY isn't beautiful nor the most effective, it's functional and familiar.


Gjb


6-2 majority decision, which is pretty one-sided and really good news for open source.

It's worth noting - the two dissenting justices were Clarence and Alito, who are both baby boomers over the age of 70, both old school conservatives. Of other two conservative justices, Kavanaugh and Gorsuch (who are also on the early end of Gen X), both sided with Google.[1] I was not expecting that. I thought they would have aggressive views with respect to the possibility of copyright infringement.

Funny moment during the case - Clarence compared Google copying Oracle to a football team stealing an opponent's playbook. That's a really bad analogy and demonstrates a lack of understanding in open source software.

Oh, and before I forget - f*ck you, Larry Ellison.

[1] Justice Barrett came in too late to participate in the decision, I wonder where she would have sided.


Thomas and Alito dissented - these two are always on the wrong side of history.


Makes me wonder how much Goldstein & Russell get paid to win a case like this. Worth every cent, I assume.


Can I copy one line from the Beatles catalog “she loves you yeah yeah”. I represents such a small % of their overall lyrics.


Does this mean that frameworks like WINE are now illegal if Microsoft so desires?

How about special-cased ad blocker integrations that stub ad vendor APIs? I feel like that would also run afoul of these increased copyright protections.


I don't understand why people uses such stupid font style -_-


uBlock origin has a convenient font blocker, for what is worth. Saves many kilobytes, and readability.


It's not going to do much for a PDF :)


Oh, shout. xD

Actually, I've seen uBlock Origin's font blocker actually break font rendering on PDFs in Firefox in the past (maybe still today?).


So does this mean one can already interface with a GPL program/library and ignore it's license? Is this the end of the GPL dual-license business model?

https://github.com/JoshCheek/clisp/blob/master/doc/Why-CLISP...


No, only if you write your own implementation. Google rewrote the Java API from scratch* except for using the same method signatures.

* Some small functions were directly copied, but nothing major


I don't quite know how to say this but, is it possible to be happy about the outcome but have a feeling that it was probably legally not quite straightforward. I mean everyone (or most) on here is probably pleased with the outcome, but extremely biased?

Also if Sun was still around would people be rooting for them instead of Google? Oracle isn't exactly easy to love.

I'm not looking for pound keyboard replies from people that disagree, I'm just curious if there are others that have the same feeling.


The SCOTUS decision on API Fair Use is the correct one. Students of intellectual property law and computer programs will find the briefing for the Supreme Court fascinating. I find it hard to see how the Circuit Panel that overturned the original pro-Google decision to Oracle's favor in the light of the arguments and evidence provided. The briefing for the Cert, particularly the amici, is worth reading. Oracle tried to move the argument into the public square by encouraging "experts" to write damning op-ed articles for news outlets and for the semi-technical press about the evils that Google did. Often their articles misplayed a shallow understanding of the issues and history of the Oracle/Google dispute.

The SCOTUS decision cuts through the cruft and reaches the right finding in this case. It shows that the Supremes can can pay attention and do the right thing.


> Computer programs differ to some extent from many other copyrightable works because computer programs always serve a functional purpose.

So a computer program instructs processors to do things while books do not necessarily instruct neurons to do things. This seems like a leap. I could write a book with NOP for every word or I could write a program with NOP loops. Are these really instruction to do things? Like so, books do instruct people (aka knowledge).


Yes a NOP is an instruction to do something. It tells the cpu to not change state for a period of time equal to how long it takes to execute the NOP.


How about in a higher level language? C program that is all semicolons vs. a book of all semicolons? Neither computer nor human is any more knowledgeable after reading it.


I haven't compiled a C program in years so I'm honestly not sure what an all ; program would do. But assuming it would just do nothing, well that is still an instruction to the computer. Delays are very meaningful. Serial communication is a great example.


Honestly this stands contrary to almost every principle of fair use (transformative work of different character for the purpose of comment, parody etc.).

Google took tons of APIs from a platform and implemented them into... a platform.

If you think designing thousands of classes is not substantial that's a very different argument, different from fair use.

Fair use means yes, APIs are copyrightable, but this is transformative use. And, to anyone with a clue in software dev... no it's not.

It's basically like taking someone else's script as-is and shooting a movie from it, and the court deeming this use of a script "fair use".


Is a restaurant menu copyrightable?


Recipes and menu listings are not. The artistic layout of the menu is.

Disclaimer: IANAL


Artistic layout... The formatting?


I like the outcome from a public policy perspective. The policy the court has imposed is good for the industry. But let's make no mistake -- this is legislating from the bench.

The wholesale expropriation of an API is not the same thing as taking a small snippet of a copyrighted work for analysis, commentary, criticism, or scholarship. It is core the value of the work.

Indeed, it's the most important part, because it defines the functionality of the product. It is what the customer sees and interacts with. It is the means by which the customer gets value. You can completely swap out the backend behind the API and the customer will still get value. Change the API and the value goes away.

From a legal perspective, this decision is 100% wrong. The plain language of the law makes that clear.

What should have happened here is that Congress should have passed an amendment to copyright law allowing for fair use of an API. They should have done so after a free and full debate, with due consideration to all economic consequences.

It is not for our black-robed, un-elected overlords to make this decision.


Let's take the 'on a computer' portion out of it.

If I specify that my company takes orders that only have certain header columns and must have specific format in certain fields on the bill of goods, is that /specification/ (not the full text I wrote, but the facts of the specification itself) copyrightable? Why? I don't see that the abstract facts of a specification of interoperability should receive any kind of copyright.


As a matter of public policy, I agree that the specification should not receive protection, but under the law as written by Congress, it does. Thomas's dissent is correct.

My comment is about process, not policy.


Under the law, they do not receive protection.

See Baker v. Selden, which despite it's age is still good law.

https://en.wikipedia.org/wiki/Baker_v._Selden


No. Baker v. Selden does not settle the question of APIs and fair use. That is why the Google v Oracle case made it to the Supreme Court.


It does say that the facts of a traditional print formatting specification (ie. the specific subtopic we're talking about) is not granted copyright protections.




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

Search: