[jfasi]

I hate to say it, but I’m not optimistic about Google’s case here. From a purely technical point of view, APIs being free to reuse is an awesome thing that makes for a more vibrant and competitive software ecosystem.

At the same time, Oracle’s characterization of their API as “original software” is not entirely off base, as anyone who has spent time and energy creating and API would know. The amount of design and work required to create an elegant and useful API is huge, and while it would irreparably harm software as a field to call it copyrightable, calling it anything other than an “original” work is a weak position.

Personally, I’m dreading the outcome of this case.

[danShumway]

We have precedent that game mechanics can't be copyrighted -- they get classified as "inventions" and have to be patented instead.

Obviously IANAL, but to me as a game designer, mechanics aren't any less creative work than narrative. In fact, I'm spending more of my creative energy on mechanics than I am on story. So the lines to me just seem incredibly arbitrary, or at least I don't understand the legal differences well enough to figure out intuitively where they lie. I am incredibly grateful that game mechanics can't be copyrighted, but game mechanics don't feel like inventions to me. A game mechanic is how I express an idea.

I tried to make a prediction about which way this would go, and I genuinely don't know -- not even that my prediction is uncertain, I don't feel like I know enough to even make a prediction at all.

It does make me nervous. I think it's important that the Supreme Court hear it, and I'm glad they agreed to, but it would be utterly disastrous if this got decided in Oracle's favor. My (perhaps incorrect) impression is that the Supreme Court is not particularly fond of the 9th, and have something of a history of slapping down attempts at copyright expansion. A ruling against Oracle would be fantastic, and would maybe even open the door for talking about blocking copyright on grounds of compatibility.

I guess I'm just nervous because it feels like the stakes are really high.

At this point, there's nothing really that people like me can do, right? It's just up to Oracle and Google's lawyers?

[roland00]

>the Supreme Court is not particularly fond of the 9th

Sorry but this is FUD you see going around. The most overturned court circuits are as follow.

6th Circuit - 87 percent; 11th Circuit - 85 percent; 9th Circuit - 79 percent; 3rd Circuit - 78 percent;

Furthermore the 9th Circuit does the most basis and almost all of their court cases are not taken up by the Supreme Court, that means less than 1% of Court Cases are overturned.

Source for numbers but other places have written about this.

https://www.politifact.com/punditfact/statements/2017/feb/10...

[danShumway]

I'm thinking specifically about copyright, not the 9th circuit's rulings overall. I don't know if that would make a difference from the overall stats you link to.

Although having just said that, the Blurred Lines, "these songs sound similar so that's good enough to say they're infringing" case didn't get overturned, and I think that's almost as dangerous a precedent as this. And a few other commenters are saying that it's actually more just patent-law expansion that the Supreme Court has been wary of.

So maybe it's entirely wishful thinking on my part.

I dunno. I just want someone to tell me it's all going to turn out OK :)

[girvo]

That blurred lines case has had big impacts on copyright in music, sadly. There’s more cases in the works right now based on it :(

[njharman]

I would definitely characterize more than 3/4 of appealed cases being overturned and within 10% of the most overturned court as "not particularly fond"!

[gpm]

You can't seriously say "more than 3/4 of appealed cases being overturned" and "within 10% of the most overturned court" as if they are both significant in the same sentence.

The supreme court (according to the same article) overturns 70% of all cases it takes. The 9th circuit (and 3/4) is within 10% of the average.

[twright]

> At this point, there's nothing really that people like me can do, right? It's just up to Oracle and Google's lawyers?

Yes, with regard to this case, there’s nothing we can do at this point.

In the longer term, it’s up to law makers on the state and federal level to address shortcomings and expansions of copyright law. So vote! (Or, I guess if you are particularly wealthy, lobby!)

[dragonwriter]

You, or an industry group you are part of, could file an amicus brief, but, yeah, there's not a lot.

[jcranmer]

You could also try to get your company to file an amicus brief as well.

[username90]

> Obviously IANAL, but to me as a game designer, mechanics aren't any less creative work than narrative.

I agree, to me it is a bit annoying seeing asset flips like Wargroove being hailed as new innovative games. They took the units from Advance wars straight offs. AA gun -> Wizard (fast good against infantry and air but weak against armor), Light-Tank -> Knight (fast, good against most targets and armored), Medium Tank -> Giant (slow heavy unit), Recon -> Dogs (very good against infantry, see invisible units), AA missile launcher -> Ballista (ranged unit that only attacks air), Bomber -> Dragon (strong flyer that only attacks ground) etc.

I don't think that anyone making an original game would have made those choices, like why can dragons only attack ground targets? Makes sense for bombers, not for dragons. Why are wizards so fast and weak against armored targets? Usually it is the other way around. Why can ballista only attack air? Historically they were used against ground targets, etc etc. The only original unit in wargroove not straight up taken from Advance wars is the Amphibian.

I wonder how much faster they got their game made thanks to just stealing the entire combat system from Advance wars...

[ShroudedNight]

> the Supreme Court is not particularly fond of the 9th

I thought the 9th wasn't involved here, and that the appellate ruling originated from the federal circuit?

[jcranmer]

You're right, this is CAFC, where all patent matters end up (the case originally involved a patent dispute, but that was dropped very early).

SCOTUS has not looked kindly on CAFC when it comes to patents, almost always overturning CAFC's decisions as being utter lunacy. I hope that same skepticism will transfer to copyright.

[dragonwriter]

The 9th is involved in spirit because the Federal Circuit was in principle bound to apply 9th Circuit law on the copyright claims (which, arguably, they did not do.)

But that's mostly immaterial at the Supreme Court, as the Supreme Court isn't deciding based on whether the CAFC correctly applied 9th Circuit precedent.

[wtallis]

The appellate ruling originated from the Federal Circuit, but only because Oracle's suit included a patent claim that didn't last long—the Federal Circuit is the appellate court for all patent-related stuff. For the non-patent stuff (ie. the copyright stuff), the Federal Circuit was supposed to follow precedent from the local circuit: the 9th. They didn't.

[monocasa]

Taking time and energy doesn't define copyright. There's tons of acts that take time and energy, and don't grant you a century long government backed monopoly on anything almost like it.

For instance, recipes, and tables of contents aren't copyrightable.

Going into case law, Sony v Bleem made it pretty clear that clean room reimplementations of APIs are on the table.

Going into US code, the otherwise crappy DMCA explicitly allows reverse engineering for interoperability. ie. interoperability even when the original vendor won't even tell you what the API is.

Going into practicalities, who owns SQL? Who owns POSIX?

The entire idea that APIs can have copyright is blatantly in contrast to decades of law, and is only happening because the CAFC is going off on it's own and ignoring 9th circuit precedent.

[tzs]

> Taking time and energy doesn't define copyright

For those who would like more detail on this, the major case on this in the US is Feist Publications, Inc., v. Rural Telephone Service Co., 499 U.S. 340 (1991) [1].

This is not necessarily the case in other countries. See [2].

[1] https://en.wikipedia.org/wiki/Feist_Publications,_Inc.,_v._R....

[2] https://en.wikipedia.org/wiki/Sweat_of_the_brow

[matheusmoreira]

> Going into case law, Sony v Bleem made it pretty clear that clean room reimplementations of APIs are on the table.

Sony sued Bleem because of screenshots. The legality of compatible products such as emulators was not evaluated by the court.

https://scholar.google.com/scholar_case?case=118372240780525...

> The legality of the emulator is not at issue in this lawsuit.

> The issue in this appeal is the validity of the method by which Bleem is advertising its product.

> In various advertising media, Bleem has included comparative "screen shots" of Sony PlayStation games.

> We conclude that it is a fair use for Bleem to advertise comparatively only between what PlayStation games actually look like on a television and what they actually look like on a computer when played with the emulator.

[monocasa]

There were several Sony v Bleem lawsuits.

[eqvinox]

> From a purely technical point of view,

The technical point of view needs to be combined with the legal one here, and —

> At the same time, Oracle’s characterization of their API as “original software” is not entirely off base, as anyone who has spent time and energy creating and API would know. The amount of design and work required to create an elegant and useful API is huge, and while it would irreparably harm software as a field to call it copyrightable, calling it anything other than an “original” work is a weak position.

just because something takes a lot of work, that doesn't automatically mean it is copyrightable.

An API doesn't implement anything, it describes a function. Even if it describes a lot of functions and they mesh together really well, there's a distinction between "what" a program does and "how" a program does something.

To compare with literature copyright, there are a ton of romance novels out there — pretty sure you can find a lot of common patterns on "what" story they tell. However, only the "how" is copyrighted, you can't prevent anyone from writing a story with the same outline as an existing one.

(For literature, the problem becomes really tricky since the crossing over from "what" to "how" is kinda fluid; e.g. you can't just swap out character names. Software is actually easier there.)

[wbillingsley]

> An API doesn't implement anything, it describes a function.

Unfortunately, that is also a definition for the whole of programming: describing functions. In Java, the method signature gives only a very incomplete definition, but that is a factor of the programming language itself.

For example, you might wish to imagine a hypothetical language that has a type system so refined that the behaviour of any function is completely described by its type (1). In such a case there would be no difference between its description and its implementation.

(1) We'll leave aside the question of whether this is strictly possible. It would be possible to have more powerful type systems than Java's, and program designs that use such small and clear function definitions, that if you have the type signatures then filling in the code for them is more straightforward than designing the function definitions was in the first place.

[incompatible]

The API description of a single function seems too trivial to be copyrightable. All the functions combined could perhaps be covered by a database copyright, but I believe those aren't recognised in the U.S. Thus phone books or listings of television programs are not copyrightable.

[jhanschoo]

What Oracle has won on is in the Structure, Sequence, and Organization in the API.

The analogy with phone books is if someone else published a competing phone book, with the same positions for adverts and paid listings, and same distinctions between adverts and paid listings. The courts would find that such a phone book infringes as well.

To make the analogy more accurate, many consumers have since come to be used to the layout of the old phone book, and do not want to switch because they have to retrain their habits to use the competitor book. Competitor book argues that the old phone book layout has merged with the idea of a phone book, or that the old layout is essential to the use of a phone book. The circuit court disagrees.

[zucker42]

I think the phone book analogy still falls short; two phone books can be organized different and have different adverts, styles, etc., but still fulfill the same function (allowing a reader to look up the phone number associated with a person or business). On the other hand, two APIs with different SSO do not fulfill the same purpose, since programs must be written to use one API or another.

It's much more similar to recipes. Recipes, like programs, are functional; they exist to produce useful output. Two different recipes calling for different ingredients/proportions can be used to bake similar cakes. However, the two cakes are fundamentally different, and copying the ingredients/proportions/steps of a recipe might be the only way to produce a cake quite as tasty as the one from the recipe.

Recipes themselves are not copyrightable because of the idea-expression divide. Authors can express the recipe using different words/formatting, and that expression is copyrightable. Likewise, an API, including the SSO, is merely an idea and so can't be copyrighted, while the implementation is the expression of that idea and so can be copyrighted.

I think if we take the phone book analogy to it's logic conclusion, it must be okay for Google to use the API only if they change it to make it sufficiently non-interoperable, which seems highly unintuitive.

[jhanschoo]

> On the other hand, two APIs with different SSO do not fulfill the same purpose, since programs must be written to use one API or another.

According to the 9th Circuit opinion, for the purpose of whether an API is copyrightable, interoperability (with client programs) does not factor in. Interoperability comes into play on a case-by-case basis when considering whether or not the use of a copyrighted work is fair use.

So, to use the telephone book example, if machines have been built to interoperate with the old telephone book layout and cannot accept the new telephone book layout, the competitor may have a fair use case, but the competitor cannot argue that the layout of the original could not be copyrighted; at the time of designing the layout, there were many avenues to lay out the pages, but the holder chose a particular layout.

Intuitively, this differs from trademark law where use in a generic manner dilutes the trademark. With copyright, there was copyrightable creative expression in the API's SSO when it was designed, and because others have come to rely on the SSO aspects doesn't mean that the copyright of the API's SSO has become diluted.

> Recipes themselves are not copyrightable because of the idea-expression divide. Authors can express the recipe using different words/formatting, and that expression is copyrightable. Likewise, an API, including the SSO, is merely an idea and so can't be copyrighted, while the implementation is the expression of that idea and so can be copyrighted.

At the time when the API is created, there is creative expression as to what the API should look like.

[zucker42]

> At the time when the API is created, there is creative expression as to what the API should look like.

At the time a recipe is created there is creative expression as to what ingredients will be in the recipe. Creativity/originality is a necessary but insufficient condition for copyright.

> According to the 9th Circuit opinion, for the purpose of whether an API is copyrightable, interoperability (with client programs) does not factor in.

I disagree with the 9th circuit here. To be clear, my argument is not that because copying is necessary for interoperability, APIs are not copyrightable. Rather, the argument is that because only one API (including SSO) fits any given purpose and because it is not functional in itself, the API is closer to an "idea", a "system", or a "method of operation" rather than a "literary work" under the Copyright Act section 102. A data structure with enqueue, dequeue, and size operations is an idea, not a concrete expression of that idea.

Plus I believe if the Supreme Court upsets 50 years of practice in the industry, they are essentially legislating.

[incompatible]

But we are talking about the source code representation of the API? Nobody cares about how its ordered or formatted: Google could change those aspects and programs would still link and run.

[marcoseliziario]

Exactly. An implementation of an API is copyrightable. Not the API itself. With a lot of goodwill, with some very generous interpretation, an API could be patentable, but copyrightable seems absurd to me.

[smadurange]

I don't think the comparison with literature makes sense.

API is what defines a software. For instance, if someone copies Microsoft suite full public interface (including the UI which is part of the interface it would be a problem even if the implementation was different).

API signature is the UI equivalent for a library/programming interface software. So, I agree with the original commentors concerns here. Oracle's got a point too.

[eqvinox]

> API signature is the UI equivalent for a library/programming interface software.

It isn't. "A main window with toolbars and an edit area." is the equivalent of the API signature. The layout, icons, ordering, etc. is artistic work of the "how" and copyrightable.

(FWIW by your logic, LibreOffice would be violating Microsoft's copyright already and we could only ever have one office suite in the world.)

[wbillingsley]

No, that's not a reasonable interpretation of his comment. Other OO VMs (e.g. dot NET) exist and do not have the Java API. Google's argument is that the API is required to maintain compatibility with Java programs, not bytecode-based VM programs in general.

[thesausageking]

Google's argument is that it falls under fair use to do a clean room implementation of the APIs. District Judge Alsup agreed with this legal idea:

"So long as the specific code used to implement a method is different, anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification of any methods used in the Java API. It does not matter that the declaration or method header lines are identical."

[tenebrisalietum]

The whole PC industry was deeply affected, in a positive manner for consumers, in a negative manner for IBM, by Compaq's reverse engineering of IBM's BIOS ROM API. Imagine if users of BIOS/UEFI API had to pay royalties to IBM (which derived it from CP/M).

[hollerith]

>Imagine if users of BIOS/UEFI API had to pay royalties

I always thought that every PC maker did have to pay royalties to Phoenix or one of the other BIOS vendors.

I know that open-source BIOSes, e.g., coreboot (formerly known as LinuxBIOS), exist, but I got the impression that even at this late stage in the BIOS game, only a minority of machines ship with them.

I always thought that Compaq created its clean-room implementation because IBM outright refused to license their BIOS (to Compaq or anyone else).

[pgeorgi]

> I know that open-source BIOSes, e.g., coreboot (formerly known as LinuxBIOS), exist, but I got the impression that even at this late stage in the BIOS game, only a minority of machines ship with them.

coreboot is not an open source BIOS, it's open source firmware. It can be combined with SeaBIOS, which is an actual PCBIOS implementation (that may or may not be in violation of IBM's APIs given this case) to provide a PCBIOS-alike boot environment.

It can also be combined with Tianocore, Intel's open sourced implementation of the high level APIs of UEFI, so that this approach would be less affected by the court case (since that's using code verbatim that was specifically published for that purpose). But who knows if the Oracle case wouldn't affect this approach as well?

coreboot can also be combined with other code for customized boot concepts, like on Chromebooks, which are probably the largest consumer deployment of coreboot, at ~6% of laptops and desktop in the US, apparently (The numbers on https://en.wikipedia.org/wiki/Usage_share_of_operating_syste... vary wildly depending on the detail each is covering)

> I always thought that Compaq created its clean-room implementation because IBM outright refused to license their BIOS (to Compaq or anyone else).

Apparently Google (or Android before they were bought? not sure) also tried to license Java for Android and that fell through. They didn't clean-room because there was the Harmony stuff to work from that nobody seemed to have a problem with. These days Android's Java is based on OpenJDK which gives it a whole new twist (it being licensed by Oracle under GPL terms).

[jpollock]

Let's rephrase...

Imagine a world where Compaq was unable to create a cleanroom implementation of IBM's BIOS because that involved re-implementing the copyrighted APIs.

[all2]

Where I work we have a line item for every computer we make for a BIOS royalty. So this happens at least sometimes.

[monocasa]

On the copyright of the actual software by Phoenix or Award or whoever, not an API licensing fee.

[simcop2387]

that's the difference though, theyrr free to make one or use any of the existing ones with the conditions of the authors. they're not forbidden to make their own or use a competitor's like the oracle ruling could otherwise mean.

[kiba]

I am told that this is a deliberate choice by IBM.

[flomo]

Antitrust decree. IBM also did come back and collect royalties from the PC industry.

[gpm]

Google has several arguments, I find most of them persuasive. The fair use one is sort of a fallback.

The more immediate argument is that APIs aren't copyrightable material, since there isn't more than one way to write them. You can't write the API differently and still let existing java programs run with your standard library.

[glofish]

They could design their own API and provide an "invisible shim" that transforms the calls to the original API into theirs.

[gpm]

To implement such an "invisible shim" you would still need to write the exact same API that oracle is claiming is copyrighted to let other programs build against it.

It's not the internals of the functions that this case is about, it's literally about "class ArrayList { void clear() { [this part excluded from case] } ... }"

[glofish]

not exactly.

there is a big difference between an API exposed to all other programmers in the world - versus one that is there for say compatibility.

Their entire API works the same way as Java system and you program it as Java - it would be very different if say Android was programmed in Go and they had a way to translate Java programs into Go.

[gpm]

I assume your first post was in response to my "you can't write the API differently" paragraph. If not we are talking past eachother, sorry. If so, your followup is that focusing on Google's actions is missing the point. If there is only one (or a small number) of ways to write it then it isn't copyrighted, so Google can do literally whatever it wants. If there are many ways to write it, the argument fails, and Google taking a more minimal approach to copying it wouldn't change that (it might change the fair use analysis, but that's a separate discussion).

It's more of a nitpick, but your reply also exaggerates the scope of the case. No one is arguing in this case that Google was not free to implement Android or an API in Java, they are arguing about re-implementing Java's standard library APIs. As far as this case goes I don't think there is any salient distinction between implementing android in Go, and implementing android in Java with a different standard library api.

[saghm]

That was only after the appeals court stuck down Alsup's previous ruling that APIs couldn't be copyrighted and sent the issue back down to him to determine whether it was fair use.

[jrochkind1]

In general, the amount of time/energy/cost invested in something is not a prime indicator of whether it is copyrightable, under the law. This is a misconception.

Facts are not copyrightable no matter how much time/energy/cost went into compiling them, and this is clearly established law.

Google's case is that an API specification or implementation is more like a set of facts. Which as a software engineer, seems pretty plausible to me, they do seem like a set of facts, a description of fact about how software works. On the other hand, unlike facts, they were not purely observed, but were indeed invented by humans -- but recipes aren't copyrightable either, even though they are not observed but invented too. Neither are the rules of a game. These are all considered more like 'facts' than creative works. Doesn't matter if eg you spent years and millions of dollars researching food chemistry to make your recipe.

I don't think its entirely clear who will win, but I don't think Google's case is as weak as you think, although i agree that Oracle's contention isn't entirely off base. . In particular, in general, how much time and energy went into making something is not generally one of the most significant factors in determining copyright or fair use. (Additionally, the well-established law around reverse engineering and creating clones -- that it is allowed -- is in Google's favor, as that analogy seems pretty strong too). Copyright law is -- has always been, or at least for 100 years -- about a bunch of competing factors balanced against each other.

And when it comes to technology advances, has always relied on analogies to previous technologies and industries, and who has the most persuasive analogy. And then we have the fact that the people deciding what analogy applies best may not entirely understand the technology as a social fact...

[zmmmmm]

I don't think it's actually about that.

APIs are facts, and facts are not copyrightable. How is an API a fact? You have a system, in the real world. It is a "thing". There are facts about this thing: if you send it particular bytes, it does X, if you send other bytes, it does Y. The fact that it does this is empirically derived. There are not two or more options for it, it's like gravity or electromagnetism. APIs are facts about the systems they apply to, so while there is creativity in designing them, there is no creativity in building a system that interacts with them. There is exactly one way derived from the empirical fact of how it works.

Where the case IS weak is that there IS creativity in how you document and organise the API. And I'm pretty sure Google's re-implementation was very similarly organised to the real Java. That will be the crack Oracle will be trying to exploit here. But its not actually about the original work being "original" or even "creative".

[jcranmer]

If you read the amici briefs, some of the people who actually wrote that API are explicitly disagreeing with Oracle's position.

[bondolo]

This would seem to call in to question their being "friends of the court" rather than associated with a particular litigant, especially in the cases where they chose to also work for Google and likely have an a interest in the outcome of this specific case. As opposed to legitimate amici who are generally more concerned with the precedent.

[zucker42]

If you're talking about the 78 programmer amici brief, only 12 have any connection at all to Google (only 5 are employees), and each of those are affected personally, beyond association with Google. This is addressed directly in the brief.

Also when the commenter said "wrote the API", he was referring to the Oracle/Sun Java API, not the Google Android API.

[wyldfire]

> From a purely technical point of view, APIs being free to reuse is an awesome thing that makes for a more vibrant and competitive software ecosystem

This is not merely a technical benefit, it's a practical one and represents the status quo. The fact that there's no precedent isn't because it's new, it's because no one ever thought it was infringing before.

[Spivak]

Nobody might believe that such a thing is infringing but there are plenty of people who are mad that a competitor just copies and pastes their API. Smartcar was such a case that made it to HN.

I really do think the determination for this case ought to be if you copy an API to facilitate interaction with existing software then you should be in the clear. If you do the same because it’s easier than coming up with your own then I think it should be infringement.

[bborud]

I don't agree with your argument.

I agree that designing good APIs requires a great deal of work, but Sun/Oracle were not alone in doing this work. In fact, they had considerable help from community, competitors and customers.

Java APIs are to a great degree a collaborative effort and it isn't right that Oracle should be the sole benefactor of this uncompensated work that has only made their product more valuable.

If this is true for these particular APIs isn't very relevant in my view. What is relevant is that the Java platform as a whole has gained much from its community. Without the Java platform the APIs would hardly have any relevance at all.

[alok-g]

What you are questioning then is not that whether APIs should be copyrightable or not, but rather whether Oracle solely should have a copyright over the Java APIs.

[bborud]

I am saying that if they want to claim ownership of something they can’t pretend the Java community didn’t contribute significantly to the development of the Java APIs.

If you are asking for my opinion: extorting those who use your API is always a poor long term business decision because it proves ill faith and undermines trust.

Oracle already has a problem with corporations making a conscious effort to move away from their database platforms.

[drallison]

The possibility that Oracle might prevail keeps me awake some nights.

Oracle's "original software" is not. It is derivative of other work, for example, Smalltalk and its libraries. The idea of including explicit interface declarations with each module was, I think, introduced by the programming language SUE designed by Rick Holt.

Copyright does not protect ideas; copyright can only protect the expression. And when the two are intrinsically combined, there cannot be copyright.

[abledon]

Wasn't there some judge a couple years back who , in order to understand a case properly, taught himself java ?

[gumby]

The very same judge, Alsup, whose ruling was overturned, hence this Hail Mary/saving throw to the Supreme Court.

[elygre]

I wonder how he deals with medical malpractice cases.

[burtonator]

If Oracle wins the Open Source community should adopt a new license to punitively punish companies like Oracle who abuse this system.

We can adapt our license to allow anyone to use the API except if they're using API licensing themselves, at which point they would be in violation.

[ocdtrekkie]

My understanding is that this case has produced emails inside Google about essentially how to avoid licensing Java. In the light of the incredible profit machine Google is, and how large a monopoly Android is, its hard to imagine any judge looking favorably on a plan to avoid paying licensing for something to build a multi-billion dollar industry.

That being said, I feel ruling against Oracle would be also very perilous for open software from for profit entities, as it would have a harmful chilling effect on companies trying to dual license or keep their technology open. Arguments Google had made in earlier stages used the GPL-licensed OpenJDK to justify using their non-GPL implementation.

[danShumway]

I don't get this perspective. The Open Source movement relies on adversarial operability far more than for-profit entities do.

Would WINE be legal if Oracle won? Would Oracle's OpenOffice be able to read and save Microsoft document formats? Replicating APIs has always been a huge part of the Open Source movement.

[gpm]

The Wine case is particularly amusing, because WSL (v1) would be equally infringing in the exact opposite direction.

[Spivak]

Assuming that the court rules in the way I would want then 100% yes.

WINE would be fair use because it’s purpose is to allow programs written for Windows to run on Linux.

Google’s use of the Java API would be infringement because Google’s use of the API is to provide a familiar environment for Java developers and it was easier to borrow the Java API than design a new one.

[wtallis]

By that logic, would WINE be fair use while winelib is infringement?

[marcoseliziario]

Wanting to avoid paying licenses by doing your own implementation is perfectly legal and moral. Let's say we lived in a world where there were no Open Source RDBMS, and you didn't want to pay Oracle's license. There would nothing shady on you deciding to develop your own RDBMS.

[Spivak]

Ignoring patents for a second you’re absolutely right. Where it gets hazy is if you copied Oracle’s query language because it was easier than designing your own.

To me the intention matters. If you copied it so that you could market that you work with existing software then I think you ought to be fine. If you copied it because designing a query language is hard then probably not.

[perl4ever]

But how could the reason be anything other than both of those things at the same time?

[monocasa]

The FSF has been very vocally for APIs to not be copyrightable. They've filed amicus briefs to that effect.

Edit: also why do those emails matter? The facts of the case aren't dependent on them. There's nothing wrong with a company looking to build a semi interoperable replacement to avoid license fees. That's why sun bought and continued development on OpenOffice; they figured out that was cheaper than the MS Office fees at their scale.

[lostmsu]

It is kinda interesting, that if Oracle wins this, then Google, and specifically Android will effectively become GPL-infringers.

[alok-g]

I believe there's more. Oracle had specific clauses in the licence terms to prevent usage of JVM on mobile. In other words, Google actually releasing Android under GPL is not enough for the case to be finished off.

[jgmjgm]

I'm really not sure about why this comment has been down-voted besides that people disagree with it. This comment and the one above that was heavily down-voted both inspired some relatively interesting responses. It's a shame because the HN that I used to appreciate had more tolerance for civil disagreements. (Maybe this is just a reddit norm leaking here.) So it goes.

[akersten]

You're seeing folks with a certain persuasion downvoted because frankly, there is a right answer here, and it's astounding that people would undermine their own profession.

If Oracle wins, software engineering will be seriously hampered. And that's not hyperbole. If you are on Oracle's side you directly jeopardize the livelihoods of most of the contributors of this board. So not only am I not surprised by the downvotes, I think they're appropriate.

[ocdtrekkie]

That is actually the very definition of hyperbole. No, software engineering isn't going to be seriously hampered because Google has to pay for what they knew they stole.

Some terms about API use would likely change in some software agreements. Google would fess up about 8 billion dollars. And not much else would happen.

Software engineering is a vital part of the world and the economy and it will not go away because the law got enforced.

[musicale]

Well I suppose an Oracle victory could be good news for AT&T if they own the copyright to the standard C library and the UNIX/POSIX API.

Then they could demand licenses for any C toolchain as well as any piece of code (libc, Linux) that included libc/UNIX compatible declarations.

This could be highly beneficial to software engineering since it would discourage the use of languages like C and Java, as well as UNIX-like systems. ;-)

[wtallis]

Specious arguments that provoke well-informed corrections may be better than obvious trolling, but overall they're still not beneficial to the level of discourse here.