2

Google’s copying of the Java SE API was fair use [pdf]

 2 years ago
source link: https://news.ycombinator.com/item?id=26699106
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Google’s copying of the Java SE API was fair use [pdf]
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.

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

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

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

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

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

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

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

s.gif
Wine was not really as much of an organized commercial endeavor so was not as much of a target
s.gif
You could sue wine to take a swing at everyone building on wine. Valve/Steam for example.
s.gif
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.

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

s.gif
IP lawyer here — @wtallis's summary is how I understand the impact of the Federal Circuit decision as well.
s.gif
> 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.

s.gif
> issues within its special jurisdiction

How are those issues defined?

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

s.gif
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?

s.gif
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.
s.gif
I completely forgot about DesqView. Never used it of saw it, but yes, that was another well-known one.
s.gif
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.

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

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

s.gif
Lotus 1-2-3 was on Windows so I think I am missing some context here around version differences?
s.gif
Timing, IIRC. Lotus was late to Windows, opening the door for Excel.
s.gif
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.
s.gif
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?
s.gif
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
s.gif
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.

s.gif
Windows Mobile/iOS? Arguably Office and Google Docs.
s.gif
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.

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

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

s.gif
Hell, AOL still runs Netscape as a discount ISP, same logo since 1999 and everything: https://isp.netscape.com
s.gif
God that's a beautiful website. Loads fast. Not too many graphics. Nothing moves unless I tell it to.
s.gif
> Netscape got bought out by AOL

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

s.gif
"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.
s.gif
Microsoft had FrontPage create pages that crashed Netscape.
s.gif
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.

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

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

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

s.gif
Netscape produced a browser that could be crashed by a malformed page.
s.gif
> Explorer crashed too, but not nearly as often.
s.gif
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.
s.gif
I worked on Netscape Enterprise Server it had JavaScript as the scripting language. Did you work on that? Before NodeJS....
s.gif
They absolutely did sell their browser to enterprises. It was only free for personal use.
s.gif
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.
s.gif
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.
s.gif
Yup, I can clearly remember Netscape crashing very very often. It was definitely the worse browser.
s.gif
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.

s.gif
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.
s.gif
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.
s.gif
Explorer also launched a lot faster than especially the late versions of netscape.
s.gif
Yep. Netscape crashed at least every 30 minutes.
s.gif
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.

s.gif
What about Microsoft J# or Microsoft J++? A directly relatable example.
s.gif
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.

s.gif
I wonder how this would effect things like Preact too, which for operability sake, uses the exact same API as React.
s.gif
In that specific example, I don't think it would really affect them, since both React and Preact are MIT licensed.
s.gif
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...

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

s.gif
Concern about the licensing was eventually sufficient that they resolved it a few years back.
s.gif
Not a lawyer, seems like this case will hold precedence then. The whole idea of copy righting an API is insane.
s.gif
Can any of those companies copying APIs in the past be sued now due to this precedent?
s.gif
DOS also copied APIs from CP/M (though that was before Microsoft bought it I assume)
s.gif
> 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.

s.gif
The dissent point out “non-competing” is a bit of a stretch as this affected contracts oracle had.
s.gif
How is J2ME not competing?
s.gif
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.

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

s.gif
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?

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

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

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

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

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

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

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

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

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

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

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

Yes, I agree.

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

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

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

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

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

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

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

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

s.gif
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?

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

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

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

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

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

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

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

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

s.gif
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
s.gif
Cipyright law needed reform for like 40 years. Thre is slow, and there is dysfunctional
s.gif
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.
s.gif
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.
s.gif
It doesnt matter what I want, it has not addressed the issues that need to be adressed, in either way.
s.gif
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.

s.gif
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.
s.gif
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!!
s.gif
The case was argued weeks before Barrett was confirmed to the court.
s.gif
That’s the perfect explanation!!! :) I’m dumb - thanks so much!!!!
s.gif
> 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.

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

s.gif
This is what the Supreme Court does in general. They decide on the narrowest of rulings possible.
s.gif
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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

s.gif
Thank you for the succinct answer.
s.gif
> 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.

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

s.gif
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?

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

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

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

s.gif
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.
s.gif
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.
s.gif
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.
s.gif
That is the order scotus considered it.
s.gif
Right, and that's why SCOTUS considered it in that order. Deciding API copyright was a much bigger decision than deciding fair use.
s.gif
A shame, because as test cases go that wouldn’t have been a terrible one.
s.gif
>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-...

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

s.gif
I suppose Supreme court decision over this matter sets precedence for any future cases.
s.gif
Making APIs copyrightable is a GOOD thing. It means they aren't patentable.
s.gif
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.

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

s.gif
Could you explain your line of thinking here a bit more?
s.gif
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.

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

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

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

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

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

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

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

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

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

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

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

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

s.gif
Fair enough. I had taken that to mean they were assuming a given to then prove the negative.
s.gif
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
s.gif
While true, it's not particularly relevant. When you acquire a company you're taking on its liabilities along with its assets.
s.gif
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.
s.gif
To their credit, they are explicit (in a footnote I believe) about equating Sun and Oracle.
s.gif
Yes, it is one of the first footnotes.
s.gif
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

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

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

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

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

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

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

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

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

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

s.gif
The judicial branch did decide this.
s.gif
Sigh, I made a mistake mixing up the order of judicial and legislative in the sentence.
s.gif
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.
s.gif
Thomas is almost always on the wrong side of history. If you want your API non copyrightable, don't make it public. Problem solved.
s.gif
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.

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

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

s.gif
The WINE and ReactOS guys must be cheering!
s.gif
It's a win for all open software. Torvalds and Stallman didn't ask Bell's permission before re-implementing Unix
s.gif
Why was this comment downvoted? Does GNU/Linux not largely reimplement proprietary Unix?
s.gif
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.

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

s.gif
Were there any Breyer counterfactuals?
s.gif
> 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.

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

s.gif
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.
s.gif
Thomas lives in a weird alternative universe where logic works differently. His dissents are always a trip.
s.gif
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.
s.gif
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.

s.gif
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.
s.gif
++ 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.
s.gif
Yeah. He's got a strange mind.
s.gif
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.
s.gif
What Amazon deal? Did Amazon pay Oracle to license the Java API?
s.gif
Yeah for the original Kindle. It's brought up in the court's decision.
s.gif
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.

s.gif
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.
s.gif
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.
s.gif
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 :-)

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

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

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

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

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

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

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

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

s.gif
Yes, reverse engineering for the purpose of interoperability is one of the things explicitly allowed by laws such as DMCA.
s.gif
The decision talks about "interoperability" as a general concept, but neither the DMCA nor reverse engineering is at all relevant to its legal reasoning.
s.gif
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.
s.gif
IANAL: Merger Doctrine is closest thing I'm aware of.
s.gif
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.

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

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

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

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

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

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

s.gif
Those are protected by patents, not copyrights.
s.gif
Wow, that's an insanely brilliant evil business plan. And plausible, too.

The copyrightability of APIs will have to be determined.

s.gif
Yeah it sounds like they were being sued over building a compatibility layer. That's nuts. Good thing the right decision was made :)
s.gif
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?
s.gif
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.

s.gif
Yes... Sanity prevailed, no thanks at all to SCOracle.
s.gif
It is fascinating that code is now being measured quantitatively. Number of "lines of code".
s.gif
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!"
s.gif
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.

s.gif
>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?

s.gif
It would be trademark infringement to use the names, it would be copyright infringement to use the meaningful content of the plot and story.
s.gif
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.

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

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

s.gif
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.
s.gif
Tell that to the Sir Arthur Conan Doyle estate :)

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

s.gif
Would it violate copyright to take a painting's colour palette and produce a different work with it?
s.gif
"Harry Potter and the methods of rationality" - affly known as HPMOR - https://www.hpmor.com/
s.gif
They do state, copy-write isn't the same in the programming world. Programming is always functional in nature, unlike a book.
s.gif
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.)

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

s.gif
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.'

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

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

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

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

s.gif
This Ballmer clip is the first thing I think about when I hear K-LOC.
s.gif
My first manager, when I was a young engineer at Raytheon would like a word.
s.gif
It's 2021 and I still come across managers that use this as a metric.
s.gif
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.

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

s.gif
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.
s.gif
How else do you determine what amount infringes? One of the four factors is "The Amount or Substantiality of the Portion Used".
s.gif
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.
s.gif
LoC is an old and classic software size metric. It's not perfect, but not completely useless either.
s.gif
Objective measures are better suited to uniform application of justice vs subjective ones.
s.gif
So if I copy the entire A volume of Encyclopedia Britannica, but leave B-Z alone, I'm good?
s.gif
No but it’s okay to copy all the entry names in the encyclopedia and fill in the content yourself
s.gif
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...

s.gif
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.
s.gif
This is an excellent metaphor but now I am curious, is it literally true?
s.gif
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.

s.gif
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.
s.gif
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.
s.gif
Yeah I was giving an analogy similar to what Google is doing, but I am not sure of the legality of the exact case
s.gif
are you clerking for Justice Thomas, perchance?
s.gif
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 “

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

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

s.gif
More like 10 million pages of books, Reading 10K pages does not mean one stole all the knowledge.
s.gif
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.

s.gif
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%.
s.gif
Who is this "Java" you're personifying?

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

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

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

s.gif
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.
s.gif
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.
s.gif
Do you feel like Wine, Linux, or any web browser is also "stealing a platform" from Windows, Unix, or Netscape?
s.gif
> 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.

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

s.gif
Bad analogy, architecture schematics are subject to copyright and you can't just take them and use them, either.
s.gif
People can and do steal architectural patterns all the time for reuse in their own structures. Are your getting it wrong on purpose?
s.gif
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.

s.gif
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.
s.gif
Please don't post in the flamewar style to HN.
s.gif
yes and most of the api is similar or copied from programming languages that came before java.
s.gif
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.

s.gif
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.
s.gif
I think you missed the rationale for fair use.
s.gifMore

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK