Hacker News new | past | comments | ask | show | jobs | submit login
Supreme Court to Hear Google-Oracle Copyright Fight (axios.com)
522 points by nwrk 21 days ago | hide | past | web | favorite | 444 comments



I'd say almost every software engineer should be rooting for Google here. The implications of being able to claim copyright infringement on anyone implementing an Application Programming Interface are staggering - it would impact every open source project that tried to interoperate with any company's services, for instance.

The world is not going to be better for extending the protections Oracle wants here.

Alsup's ruling is sane, shows his clear understanding of coding and the history of Java and how it was licensed out to the world under Sun, and is really very simple to understand: http://www.groklaw.net/articlebasic.php?story=20120531172522...

The appeals court fucked this up, hard. I would like to think Alsup's ruling will be upheld -- groklaw has fantastic quotes from him during the trial. At one point, he himself notes he had coded from the spec some of the functions Oracle complained about and disagreed with Oracle counsel statements. Refreshing from our judicial branch, to say the least.


Also, Oracle just sucks in general. Larry Ellison is a notorious jerk and philanderer. Oracle's entire business is based on the success of one expensive database product from the 70s, which is mostly still in use due to decades-long vendor lock-in of stagnant enterprise giants like SAP, IBM, most banks and a good chunk of the DoD.


Notorious jerk is an understatement. He’s literally a garbage human being and a liar.

My last company was entangled in the Oracle web of vendor lock in. Before renewing our contracts, Oracle wanted literal access to our proprietary code - much of which is older code that mixes business logic and logic that works directly with Oracles products. Many of the algorithms we had implemented were 100% proprietary and secrets - not something we want just anyone to see, especially a competitor. On top of that, this company had IT contractors that had built all kinds of functionality using one off features only available in Oracle - shit that didn’t scale with new and upcoming use cases but also just a huge pain in the ass to migrate off of.

People think AWS or Azure risk vendor lock in. Oh boy you do not know what true evil actually is - Oracle literally prays on this happening. It’s the foundation of their business model. Not features, not innovation, nothing else - but solely ensuring your customers have no alternative but to use your products at whatever cost you want or drown in litigation.


Did the company end up being forced to giving their code including the proprietary algorithms?


What's the point of this applause light? Surely it's obvious that none of this should be relevant to the court case.


Humans love to see the bad guy lose. Larry Ellison has built a business out of lock-in and lawsuits against his own customers. People hate to see that kind of antisocial behaviour rewarded.


Except in this case it's two bad guys fighting each-other... Google built a business on spying on people.


100% agree that Google should die in a fire, just after this case. They’re the good guys here.


They're the least bad guy in that case, but that doesn't make them the good guy by default.


No, them fighting on the side of what's good for the industry is what makes them the good guys in this case, not the fact that they're fighting Oracle. If the positions were switched, I would be biting my tongue and rooting for Oracle.


I don't believe jerks should lose in court because they're jerks, but I am happier to see jerks lose.


It doesn't matter for the court case, but this thread is a court of public opinion, not a legal one.


Agreed. Oracle sucks and needs to die off. The sooner the better.


Yeah, let me know when PostgreSQL does distributed transactions across database clusters, or provides a proper development environment for stored procedures.

What about removing Oracle's devs contributions from Linux kernel?


yawn There are other databases systems doing that, no need to depend on Oracle. For example: http://erlang.org/faq/mnesia.html which is also associated with a programming language known for its quality distributed computing.

Removing contributions to the Linux kernel? I don't think so. The kernel is free software and people contribute to it knowing that it is free software, so they cannot hold any code hostage. Once you release as free software, you give up that control.


I’ve never heard of anyone who actually uses mnesia for real or would consider it prime-time. I’m no Oracle fanboy but comparing their DB to mnesia is like comparing an oil rig driller to a fisher price screwdriver.


> never heard of anyone who actually uses mnesia for real

I didn't till I had to become one of them this year. Mnesia is real, it's prime time, but not in place of something like Oracle.

> comparing an oil rig driller to a fisher price screwdriver.

Better analogy would be Comparing SQL Server to Redis. Mnesia is, at it's heart, a(n optionally) Transactional K-V lookup that can be run distributed. It's use case it works VERY well, but I wouldn't consider it a substitute for Relational storage.


[flagged]


Basically, as soon as something is released as free software, you must have the 4 freedoms: use, study, share, improve. This means, that it is not important, who contributed the code and what else they did, in the context of using that code in any of the 4 freedoms ways. It frees the code from the control of the creator in that sense and the creator cannot take it back. Anyone who releases as free software will give up such control. Oracle once having provided something to free software (My guess: They only did it because the GPL forced them to.) does not mean, that we have to like Oracle. These two things are not connected.

I am not sure about the state of Mnesia, however, I wrote, that it is an example. If I had found a Wikipedia list of DDBMS, I would have posted that. However, I am sure knowledgeable people will be able to name a few more.


Are corporate open source contributions the new blood money?


Linux would hardly gotten where it is without the contributions from everyone getting paychecks from IBM, Intel, Oracle, NVidia, AMD, Apple, Sony, Google, Facebook, Microsoft, Huawei, Samsung among many others.

Which is kind of ironic, hate them, but then willing accepting whatever comes from them, 'cause hey it is free.


You could also say that Google wouldn't have gotten anywhere without Linux, as they really depended on lots of cheap hardware and software. Humans are connected, which is a great thing (that what makes us human).


Sure, I guess hating them today, and tomorrow gladly accepting whatever they release 'cause its gratis, is also human behaviour.


pjmlp: Bad People Can't Do Good Things Andy


They certainly can do good things and even change.

What is schizophrenic is having a community that hates big corporations, but happily takes anything they decide to offer,


There are many conflations in these statements of yours, but one of the more offensive is that corporations are responsible for an individual's open-source contributions because that individual draws a paycheck for something else. What's the corporate equivalent of a bootlicker? An NDA-licker?


What I don't get is how someone can hate companies like Oracle, wish that they would disapeer out of the face of the earth, and at the same time jump of joy when a couple of lines get added to the Linux kernel, by the corporation they want to nuke.


if they offer it under gpl, it's no poison chalice. why do i care who does the right thing? what's good is good.

i would be more worried when they propose that we all abandon this adequate gpl tool for this permissive licensed code they seriously didn't write, but here's ten fantastic contributions they made.


It is not about being a posion chalice, rather the attitude of wanting to nuke company X, while accepting whatever it gives as gratis contributions.

I only see that among FOSS folks, seldom among other kinds of activism.


Because of the nature of the GPL. You don't get those guarantees in most other forms of activism.


That's a good thing right? I mean, I'm not implying that Google is on the opposite side of this, but still, I'd wager most people on HN would love to be a Larry Ellison (riches aside), where you get start a product today, and still be relevant with that same product 40 years from now.

I honestly don't get the Oracle hate from HN people, even if I do understand it from the Slashdot folks.


I previously worked at Oracle for years in the dotcom era and I can tell you the company culture was horrid. It was completely sales driven, sales people would often lie to customers and promise the product had a feature which it either didn’t have or was not well supported and then have to fly in expensive consultants afterwards to fix the resulting shitshow.

I accompanied Sales Account managers with fellow female engineers to client meeting where they, and I’m not kidding, discussed which strip clubs they would go to after the meetings.

If Apple is a designer culture, and Google is an engineer culture, then I‘d say Oracle is driven by a hierarchy of sales culture.


> It was completely sales driven

Another perspective is that Oracle is one of just a few tech companies left that has a proper dedicated research lab that does long-term research without asking about profit. I worked on my research project there for six years and nobody once asked me how we were going to make money from it, let alone talked about sales. That’s pretty special these days.

Oracle even paid me a senior developer salary while I worked on my PhD. Hard to say that’s ‘completely sales driven!’


Isn’t that basically Microsoft Research?


Yes like MSR. I said ‘one of just a few’ so that doesn’t invalidate what I said. There aren’t many. IBM as well.


Google has this as well.


I don’t think Google has dedicated research labs do they? They’re very proud that they integrate research into (sales driven) product groups.

https://youtu.be/0wqc69oNbms

And so what anyway? Google is also good at supporting things not sales driven means that Oracle isn’t?


Google specifically has Google Research and a Research Scientist track.


Their video says that’s not separate, but people embedded in product groups.


https://ai.googleblog.com/2019/10/quantum-supremacy-using-pr...

There's plenty of lab research going on.


DeepMind, Google Brain, Google AI..


Project Zero could be counted as well


> I‘d say Oracle is driven by a hierarchy of sales culture.

Isn't Oracle a legal driven company [0] :)

[0]: https://bonkersworld.net/organizational-charts


Discussing strip clubs in front of your colleagues is bad. Isn't worse because they are female.


True but it’s even more tone deaf when the sales bros/Mad Men aren’t even woke enough to realize what they’re doing outside the lockerroom.


Yeah but saying it to me (a male) would still be tone deaf, right? There are no locker rooms even in locker rooms these days. All I'm saying is, it being in front of me is disgusting enough.


Why is that? Are you uncomfortable with men expressing their sexuality? Or perhaps you see strippers as abused and taken advantage of?

I personally think stripclubs arre a waste of money, but I know femenists that would take exception to either of those above.


I'm not afraid or uncomfortable with expressions of sexuality but a boardroom is hardly an appropriate place for it. I don't understand the argument that just because something is a normal part of life it somehow becomes ok to talk about it anywhere. Taking a shit is a normal part of life, that doesn't make it ok to discuss your weekly bowl movements in the board room. In different social settings there are different levels of comfort between people. You can be ok with strip clubs, there are perfectly valid opinions for and against them, but I come to a board room to discuss business, not your sexuality.


If it was the topic of the board meeting, definitely not appropriate, but otherwise it's just the conversation was not meant for you. Can you imagine the abuse I'd catch if I complained about overhearing women talk about their periods? Or, to make it more fair, planning some kind of hypersexualized bachelorette party.


It is bad, but also worse if they're female. Unless they were discussing male strip clubs?


Please explain to me how it's worse? I find it offensive because it's discussion of sexuality and a sexually charged topic in a massively inappropriate setting. If I was a female, why should I feel worse? Just because the performers there are female?


Yes. It's like saying if your colleagues are using the N-word and making racist statements, would African Americans in the room feel worse than the white people? Yes they would.

No matter how "woke" or allied you think you are, there's no way the lived experience of a white person reacts the same way to people reinforcing systemic racism than that of those who have to live under that experience.


It would be really good to have a product which is relevant after 40 years WITHOUT adopting business model of an organized crime syndicate. In other words: Having a product which is relevant after 40 years.


I'd wager that many people on HN are not interested in the startup and VC aspects at all. I come here for the news, the geekery and the expertise.


I've worked at Oracle in an engineering (not management) position, and I've seen the (tail end) of the way they interact with acquisitions. I tend to be somewhat guarded about talking about it -- I don't see a benefit to me badmouthing a former employer. But, I'll be open and honest for this comment.

The analogy I use to describe Oracle is that they're this kind of massive lumbering beast that just lays around and occasionally swallows other companies alive and whole. Then those companies run around inside, burning existing customer good will for a while until Oracle finishes digesting them or generating whatever news-reports or vendor lock-in they wanted in the first place. Then Oracle goes out to find another company to eat.

I saw a slow movement with my particular department away from developing useful software towards, "just keep on releasing things, just keep on trying to figure out what looks good at trade shows, just keep the department moving forward like a zombie while it gets eaten away and resources get shifted to new acquisitions and lawyers and salespeople." The software wasn't even a secondary concern, it was just a very minor part of the company that happened on the side. Writing code was a side-effect of the business, our real business was sales and grand promises and multi-year contracts that everyone was going to regret.

As a developer that wants to build products that actually help businesses and users, it felt really, really bad -- and my impression interacting with other parts of the business and other departments felt the same. Like they were just kind of lumbering on, that they existed because a few companies were locked in or were still buying them, and a few more dollars could be extracted before they starved to death or until their staff was fully absorbed into new projects.

I won't go into any more specific detail than that; for better or worse I feel like I have some responsibility to be a little vague. But by the time I left I was convinced that any company Oracle bought or any project it maintained was doomed as soon as they touched it. It's one of the reasons I won't work with Java -- I just don't want to tie myself to a technology that's owned by a company like that.

The current case with Sun is to me perfectly in character with the company. Oracle bought Sun, killed everything that made it Sun, and now their lawyers are out trying to extract every last penny they can get out of its mostly rotted corpse, all under the guise of 'protecting their investment' or whatever.

I'm very cynical on Oracle now, and I wasn't even at the company very long. Since moving on I've been able to work on industry-scale software that's actually being designed for customers and that actually cares about helping them accomplish business goals. It's a massive breath of fresh air that I'm still grateful for to this day. It makes a huge difference to be able to get up in the morning and feel like there's an actual reason you're going to work beyond buying Ellison a new yacht.


I once called EA a "sarlacc for good game studios". Sounds like Oracle is a sarlacc for business and infrastructure software companies.


It's one of the reasons I won't work with Java -- I just don't want to tie myself to a technology that's owned by a company like that.

Somewhat amusingly, Java becomes more dangerous to use if Oracle wins this case, because they would then be able to kill OpenJDK and any other implementations whenever they want.


Not everyone strives for a relevant product just because of vendor lock-in, I'd wager most of HN would rather make good, portable products that only stay relevant due to continued hard work and incremental feature upgrades.


I ... don't know about everyone else here, but personally I'd rather become a McAfee than an Ellison. At least John has this thing called sense of humor.


I don’t think his neighbor’s family would agree with you: https://www.google.com/amp/s/www.itpro.co.uk/security/33284/...


This article reads like something from theonion or babylon bee. Especially the last paragraph. Did you read it?

It's either an elaborate joke, or McAfee wrote it himself. Or both.

In any case, if I was an US citizen and had to choose between him and Trump, well, that would've been a very hard choice. They both deliver.


Exactly this. Oracle is nothing but a common patent troll here. They bought SUN for one and only one purpose..... to sue Google. I know someone involved in the preliminary investigations into this. It is not a secret at all. It would be awesome if Google would take the Cloudflare approach and try to crowdsource prior art for all of Oracle's patents. (Best case, 1M software patents go away on all sides)

Hopefully as things continue to the cloud with private options and their loss of the JEDI contract puts them right out of business.


Google had the option to buy SUN, too.


Why would they buy it if they weren't interested in the prospect of suing other people with it? In hindsight it would be a great defensive buy,but there's no way they could foresee this shit storm caused by this absurd lawsuit.


For the rights to the proprietary language around which they built their flagship mobile platform.


Honestly, they need to put it into layman's terms.

The exposed function calls of an API are meant to be implementation-blind.

Let's say car-company A builds the first ever car that's operated with a steering wheel, gas pedal, brake pedal, clutch pedal, and shifter.

Then, Company B comes along and - both to create a complete control system for the car AND to potentially benefit consumers who are already familiar with those controls - also uses a steering wheel, gas pedal, brake pedal, clutch pedal, and shifter.

The steering column and its inner workings are completely different. The gas pedal activates a V8 combustion engine instead of an I4. The clutch pedal triggers a dual clutch for faster shifting between gears. The brake pedal activates disc brakes instead of drum-brakes.

The appeals court is, in effect, saying that Company B has violated copyright because, when faced with the same problem, they came up with a solution that looks very similar on the outside. They turn a blind eye - willingly or unwillingly - to all the new engineering that went on to improve the product and create a new expression of an automobile.


The current state of Java support on Android proves that Google has achieved their own variant of J++, forcing Java library authors to write Android Java, if they wish to support the platform.

"James Gosling Triangulation's Interview on Google vs. Sun"

https://www.youtube.com/watch?v=ZYw3X4RZv6Y&feature=youtu.be...

Google should face the same penalty as Microsoft did, plain and simple.


About the only IP this trial hasn't covered is trademarks, so I'm not sure how the Microsoft decision applies.


The way to get there isn't the same, the impact on Java library authors it is.

Even Jake Wharton already complained about this publicly, and he is now working at Google, go figure.

> Happy Tuesday Android developers! Java 13 out today. Java 8 is now 5½ years old. Here's your bi-yearly reminder that Android is holding back the Java library and language ecosystem.

https://twitter.com/JakeWharton/status/1174020113466568704

> The Android platform is on the cusp of holding Kotlin back. New bytecodes not being available both in the Dalvik set but also on devices in the ecosystem means Kotlin is forced to target older Java bytecode versions which can hinder new language functionality.

https://twitter.com/JakeWharton/status/1017597264225857536

> Kotlin is great but there's no reason anyone should need to target Java 6 bytecode and APIs in 2019. IntelliJ platform switched to 8 in 2016.1 and 11 in 2019.1. Servers are mostly 8 trending towards 11.

https://twitter.com/JakeWharton/status/1174024747400777729

So we are just in the same position as if J++ would be kept being a product, any Java library author that wants to have market share on Android needs to constrain themselves to the Android's view of what means to be Java.

And I have to bow to Jake as he is doing a very good job adding support to R8 and D8, to at very least desugar modern Java features into Android Java.


> any Java library author that wants to have market share on Android

Had Google used a completely different language instead, this market wouldn't exist at all, and Java library authors wouldn't even have the option of choosing to target it.

I don't disagree that Google's handling of the language is bad, but that doesn't mean it should be illegal. Creating a bad legal precedent harms us all.


The same could be argued as defence for J++, but naturally Google gets free pass, because it isn't Microsoft.


Microsoft's actions weren't ruled illegal, they had to pay because they broke a contract.


But by that logic, any large organization using an old JVM version and requiring developers to target that version would be holding back the Java ecosystem.


Exactly, with the small detail that almost everyone else does provide support for more recent versions on their Java implementations.


> there's no reason anyone should need to target Java 6 bytecode and APIs in 2019

Java 7 byte code was a big mistake. People complained but Oracle didn’t listen. As always.

http://chrononsystems.com/blog/java-7-design-flaw-leads-to-h...


Yet everyone else on the Java world doesn't have an issue having up to date Java implementations.


IDE, debuggers, bytecode libraries, build systems, profilers, all of them had to deal with “up to date Java implementations”. Which hurts adoption.

Not just because of this issue, but because of tons of other mistakes made by Oracle: users shouted, Oracle ignored.

The net result is inertia is high, but Java is stable declining. Existing projects continue to be developed in Java, new projects often choose something else.


That's not true. BD-J is limited similarly for instance.

They forked the shit out of it too with tons of base functionality being in org.dvb. and javax.tv.


Microsoft signed an agreement with Sun and advertised the fact that they were Java compatible. "Forcing Java library authors to write multiple versions" was never a factor in either lawsuits.


why does matter? it's a serious question. it sounds like if they just renamed it Jawa instead of Java your complaint would disappear?


Only if they rewrite the world in Jawa and stop advertising compatibility with the Java eco-system, then they can use Jawa, Dart, Kotlin/Native, whatever they fell like.


I don't really get your argument. gcc has lots of non-standard extensions. Should gcc not be able to call itself a c++ compiler?


Android Java is a subset of cherry picked features of Java and its standard library, with support varying across Android version.

GCC is an ISO C++ and ISO C compliant compiler, plus a set of language extensions.

Any ISO C++ or ISO C code will compile under GCC.

Not every piece of standard compliant Java code will compile under Android Java.

Not only this produces a burden writting portable Java libraries, it creates a false perception to many developers that learned Java via Android and assume Android Java == Java.

The later point is usually used by Google when they sell how Kotlin fares against Java, because naturally if they would compare it against a proper up to date version, some of the plus points wouldn't uphold.


Issue exists with instruction sets as well. If Oracle wins everyone who has written a compiler for an instruction set they did not have explicit permission to write one for is in violation.


There's probably a better case for compilers being fair use than this (not that this doesn't have a great case).

I'd be more concerned about emulators and actual chips. People have been assuming that copyright doesn't apply to APIs for so long that I'm sure there's any number of cases of accidental "copyright infringement as defined by Oracle". I'm just not sure that compilers are a prime example (at least as relating to instruction sets).


"Probably". Hah. That just shows the ramifications of Oracle winning this case are fucking insane. We've been operating as if this stuff isn't copyrightable for the last 50 years. You may as well burn the whole industry to the ground if they have their way.


> You may as well burn the whole industry to the ground if they have their way.

At least in the United States. China, on the other hand, will laugh at us as they lay claim to everything American lawyers prevent us from doing.


In EU interoperability is a valid reason to break copyright in this manner.

It would matter here too though as we do also want to sell software to US.

But if one stays out of US markets then things are as they have always been.


The EU has similar cases occur. For example between Lego and Best-Lock over what features of lego are copyrightable versus which are functional (and their competitors' minifigures are also designed to "interoperate" with lego bricks)

https://thetmca.com/equitable-estoppel-defense-denies-lego-f...


Yeah. As can be seen in that case they are focusing on things that are mandatory (non copyrightable) and those that are just stylistic choices (copyrightable).

API compatibility doesn’t have any stylistic choices in it.


Could you de-copyright things in this manner? Say I make locks that only open when they hear music from Disney's lion king. Are you allowed to play that song to open the lock, even without opening it? Does it matter if it was disney or me that made the lock?

Silly example of course, can't think of any better. Feel free to substitute your own.


For anyone to care you'd have to be an adversary of the manufacturer who published the specification. Generally they publish these details in order to encourage people to port OSs and compilers.

If a tree infringes in the woods and the silicon manufacturer doesn't hear it...


Then you, for example, write a compiler for SPARC in 1990 and distribute it for twenty years, only to see Oracle buy Sun and then decide they'd rather sue you for twenty years of copyright infringement than maintain your cooperation in continuing to produce a compiler for a processor architecture they're planning to discontinue.


I think emulators and competing CPUs are a more direct analogue.


IBM should be warming up their lawyers to sue Oracle for SQL.


Nah, oracle’s sql is so different there’s hardly any overlap with standard sql.


Can you explain why you think "the appeals court fucked this up, hard."?

Isn't the way the law is written the real root cause here? Judges and courts don't write laws...

Basic questions pop up (hey look "pop" that's an API) in my mind like: is copyright on code a thing that should exist?


> Can you explain why you think "the appeals court fucked this up, hard."?

This reply I already wrote serves as a good answer to that question (though I'm not the person you asked): https://news.ycombinator.com/item?id=21550702

> Isn't the way the law is written the real root cause here? Judges and courts don't write laws...

This is a complicated question, but I would argue that the answer is no. Congress trying to anticipate every corner case ahead of time would be a nightmare, so instead the courts exist to take general laws and apply them to specific cases.

Even if congress tried to write a law with no unspecified edge cases, they would fail, because any law they pass has to be within the powers granted to them by the constitution, and those powers are vague. The relevant power here is literally "[the United States Congress shall have power] To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries". That's it, one sentence, it's vague and there is no fixing it. If congress tries to legislate something that falls a bit outside of it, or that violates any of the various rights and freedoms specified in equally vague sentences, the law, at least as applied such that is violates the constitution, doesn't exist.

It's also not quite true that judges and courts don't write law in our common law system. They do, that's what the "common" part is about. Statutory law takes precedence, common law fills in the gaps. Here's an example of a case where the Texas Supreme Court directly addresses that they are creating new exceptions to the law, and that they can do so because the relevant law in the first place was invented by the courts: https://www.casemine.com/judgement/us/59148e86add7b04934555a...


Yeah, fancy a scumbag using the legal system to hold people to ransom with their worthless and bogus claim.

Sounds a bit like what Peter Vessenes is doing to 25,000 creditors of MtGox, even after being offered an incredibly generous $10 million dollar kiss off.


Not copyrightable APIs is a fairly dangerous precedent.

1. Good APIs are hard.

2. Under Alsup's ruling, good luck competing with AWS sales org when they decide to offer your own APIs as a service.

3. Nothing prevents Google from inventing their own APIs, and licensing them under whatever terms they like.

As of Google vs. Oracle, it's pretty clear that Google appropriated Java to benefit from its penetration in the market place, instead of putting in the hard work to build their own. Apple has built their own ecosystem, ObjectiveC/Cocoa/Swift/SwiftUI. Microsoft has built their own ecosystem, C#/DotNet, or adopted and contributed to open standards, HTML5/Javascript/Typescript. Heck, even HP has built WebOS around open standards.


good luck competing with AWS sales org when they decide to offer your own APIs as a service

If the only advantage you have over AWS is that developers would have to change the function names in their code, you're dead anyway. And copyrightable APIs mean that you can't offer an API compatible with AWS as a way to get developers to try your platform in the first place.


Would this open the door for some schmucko to copyright push, pop, enqueue, dequeue, etc?


An even more problematic example:

https://docs.oracle.com/javase/6/docs/api/java/lang/String.h...

So...I guess this api signature for string concatenation is on the verge of being owned by oracle forever. Perhaps I can create a non-derived work by adding a few extra arguments.


I'd bet that isolated examples couldn't be copyrighted any more than a single sentence in a novel couldn't be copyrighted. Doesn't it have to do with the whole work?


The case is about APIs, not the whole work. By their very nature, all APIs are both:

1. Single sentence.

2. Usually obvious. In fact, just about every API definition in the above linked String method list is blatantly obvious, and many of the APIs look similar to ones in various other completely incompatible languages.

So even if you argue the copyrighted work is comprised of the whole set of APIs, it may be patent-able as an invention, but it does not seem reasonable to suggest it be protected by copyright.


Hopefully only the specific Java incantation. Other languages have different syntax, so arguably they are not Java.

    Java: public String concat(String str)

    Javascript: String.prototype.concat ( [ string1 [ , string2 [ , … ] ] ] )

    Python: def __add__(self, *args, **kwargs)

    C++: function <string> std::operator+ (string)


Use vararg for parameters to pass to iconv


Just rename it : Konkat. Easy /s


The better question is would this case mean someone already has the copyright on push, pop, enqueue, dequeue? Someone originally came up with all those APIs, and they (or the people they were working for or otherwise sold it to) would would own any copyright.

(The answer is probably no, I'm sure a half decent lawyer would manage to distinguish that from this case since it is so simple).


This case has the appeals court striking down de minimus claims as well. : /


I wonder how those idiot judges on the appeals court would feel if a bunch of programmers with Sharpies ran rampant through their law books, altering the long-established order of things with essentially no knowledge of what they were doing. It's a shame the universe doesn't provide for karmic retribution at this level.

Downvote if you like, but there's no other way to describe the absence of de minimis exceptions besides "idiocy." These judges are essentially monkeys in a machine shop.


Perhaps they are not idiots, they are just trying to apply laws written for books and music to software. That is not their fault, they don't get to make laws, only interpret them.

I think this is another case where the law makers have been rather slow to keep up. Copyright is not really working in this era.


> That is not their fault, they don't get to make laws, only interpret them.

Isn't that exactly what the parent of your post called:

> These judges are essentially monkeys in a machine shop.

Blindly trying to apply an unfitting law, because those are the instructions?


The absence of de minimis exceptions is not that important because API copyrights are a terrible idea all on their own.


Those are too abstract as described. Could you copyright an implementation of those? Yes. And if someone did you shouldn't infringe on theirs you should write your own. But that's not new, you can find tons of different basic data structure implementations out there, with a variety of licenses.


Eh, that's nitpicking. "class Stack<T> { void push(t: T); T pop(void); }" is not too abstract, and has been written down many times.


Yes and no, I guess if that's what they meant then yes I was nitpicking but I took it literally (lots of folks confuse concepts between patents, copyrights and trademarks. Less common on HN but still happens. )


Why does it matter? The API is as dead as the telegraph, everyone is just building garden walls higher instead.

I worked on and with lots of APIs back in the day. They are all gone. All of them. Eliminated for business reasons. The internet has become a tool for carving out fiefdoms of engagement to be monetized, it's not about connecting people or systems anymore.


[flagged]


You seem to be talking about Mt. Gox, based on https://bitcoinomics.net/if-youre-going-to-get-into-bitcoin-...

I am one of those fools who "lost their life savings": $11k, that my father worked diligently to gather for me over many years. It still haunts me today that I squandered years of a person's life with such a decision. And yes, I would be happy to recover some of the money -- I supposedly am owed 7.7 BTC if Mt. Gox pays out.

Now, all that said, I am really not happy to see your comment here. And since I paid $11 thousand dollars to be in a position to reply to you, I think I will: it wouldn't matter if he murdered someone. You can't just come up on a completely unrelated thread and be like "It makes me sick to see you here on HN."

Ultimately, we have all made our choices, and part of those choices involved taking risks. That's why it's called a risk. I theoretically would have gained some ~$100k from my risk, but instead I lost my father's hard work. But I consider myself much richer for the lesson: I can pass this knowledge on to my own children so that they will be better positioned not to make similar mistakes.

As someone who has spent countless nights agonizing over such things, my advice is this: make peace with yourself. Externalizing like this only makes everything worse. If Satan himself wanted to leave a thoughtful, relevant HN comment, Satan should be permitted to do so without being harassed. There are very few communities where such an important rule is the norm, and it's worth preserving that culture.


Hey sillysaurus, I've seen you around for years on here so I knew you're one of the people who lost a lot and I'm happy you're at peace with it. I'm someone who only lost a little so I'm not losing sleep over it.

That's not why I'm attacking Peter even while that's against my favorite forum's rules and I might get banned for it. I don't think Peter is comparable to Satan. Peter also hasn't murdered someone, he's not committed an act that stemmed out of emotion, or a great need, or that he regrets.

Peter is a human being that has made the decision to put his greed ahead of tens of thousands of people. At any moment could he say, "ok I'm sorry this was a bad idea" and stop and still gain millions of dollars. He doesn't. He is consciously hurting people for a possibility to make this absurd amount of money.

In my frame of ethics, I can't just let him go around unharassed. If he goes unharassed it means that I, or we as a community, are ok with people behaving in an unethical manner. I'm sorry you had to witness my comment, I know it hurts the thread, but I just can't not make it.


I think I speak for many people on here when I say, we don't care about your drama and don't want this forum to turn into another failed Reddit social justice crusade forum.

If the poster above has an informative post, I'll upvote it regardless of who he is.

It's about the content, not the people.


I usually don’t respond to comments like this because they tend to inflame the conversation; I can tell you care, so I’ll take a shot here at saying my perspective in hopes that it might help add some understanding.

I’m sorry you both lost money and had it locked off for years; many people in the world, including me have had the same experience. I’m not the cause of your loss, and I’m not in control of its return.

Some longer thoughts on the case below; if it expands your perspective all good.

What we have asked for in the six years since we sounded the warning on mt gox insolvency with our suit (a full year of public warning for everyone who used gox) is a fair trial. The trustee repeatedly slowed or stopped that process, including going to the extraordinary measure of helping get Tibanne into bankruptcy six weeks before our US trial so that the case would be stayed. Before then Mark avoided the suit so aggressively that we had to go through The Hague convention to even serve him papers.

That was many many years ago. We have never slowed a single court date or asked for a single extension. We just believe we are owed a fair adjudication of our contract and have proceeded both in confidence on the merits of our case and with the fundamental confidence that a party harmed by breach of a contract has the right to have damages determined.

The narrative that we are the hold up is absolutely not true. In fact, we have never even been offered a settlement from the trustee which we could accept or reject. The trustee cheerfully went to court in venues he thought he could win, even negotiating for a return of some of mutum sigillums seized funds in the US; he could have had a ruling years ago from a US proceeding if he had wanted it. He clearly did not want that.

We just want a ruling from an independent court on our 2012 contract, a contract made during an era of $10 bitcoin with a man who ended up committing US federal money laundering crimes, ‘lost’ 500k+ of the public’s bitcoin and has since been imprisoned.

Public tweets or essays speculating we want something else come from two places - either from those who have decided, a priori, that our contract must not have been valid and therefore doesn’t even deserve due process and ergo is just a form of petulant spoiling, or are funded by VERY large claim holders in a sort of PR based pressure process.

All that said, I would be very happy to continue to talk with you about this in person or on a live chat; my email is vessenes@gmail.com: feel free to reach out to me to continue this dialogue.

As to who has a right to be where online, I will say over the years I have left some of my own thoughts about my career here and benefited immensely from others doing the same. I’d like for there to be places like this that aren’t gate-kept even if people are fighting.

If you look back in my post history you will see one of my first posts/comments is about deciding not to go into business with Jed Mccaleb when he was running gox out of his bedroom in Costa Rica, long before either of us had heard of Mark Karpeles; I think that’s a cool bit of history!

I liked and appreciated the HN community 10 years ago, and hope to be appreciating it in another 10.


> We just believe we are owed a fair adjudication of our contract and have proceeded both in confidence on the merits of our case and with the fundamental confidence that a party harmed by breach of a contract has the right to have damages determined.

Yeah, only problem is your "we only want what's fair" narrative is sliiighly undermined by the fact that you started with a $75M claim, then went to $16B!!!! and now that the $16B claim got thoroughly rejected you changed it to $500M. You ran wild with the $16B claim because the assessment phase didn't require any court fees and you picked the biggest number you could think of, to block the process. Now for the appeal you actually need to pay court fees as a % of your claim and being well aware that the $16B figure is ridiculous, you changed it to a number that's still big enough ($500M) to block the process but you don't have to pay that much court fees.

Not to mention that your contract with Mark only stipulates $50M of liquidated damages and the rest of your claim is based on potential lost revenue if MtGox never went bankrupt. This is not a thing in Japan or anywhere in the world. You know that very well and your lawyers know it very well. The most you could hope for is the $50M and the rest of your claim is just there to block the process and extort the creditors. So, please, drop the "we only want what's fair" charade. You can only fool people not familiar with the case, which is probably what you're after.


It’s a pubic forum. If someone decides to be a shady scam artist, people have a right to point that out regardless of the thread context.

I’d sure agree that Satan is allowed to comment, but other commenters are certainly allowed to point out that the freaking devil showed up.


It’s a public forum with particular guidelines. Personal attacks that have nothing to do with the topic at hand are very explicitly against those guidelines.


Statements of fact about a person's previous behavior and actions are not personal attacks.

While the breach/fraud/mix of both/whatever happened was basically out of your control (though should've been considered as a risk; paper wallets have been around as a much more secure storage mechanism for a while), a similar scenario could've occurred if Bitcoin crashed and you sold low, or if it crashed and never recovered.

I don't understand why someone would put 100% of something into a highly volatile and risky investment. Even if this were the ordinary stock market and it was 100% of your savings invested into one or two companies, it'd seem just as absurd.


> And since I paid $11 thousand dollars to be in a position to reply to you, I think I will:

Is there a list of top HN quotes, because I would like to add this one!


I know people can do their own research but if you're posting about someone directly like this, maybe share a link so those of us who don't know can easily find out more about this case.


Taking my own advice, I found this:

https://bitcoinomics.net/if-youre-going-to-get-into-bitcoin-...

No idea of the quality of Bitcoinomics as a source though.


Here's an article that was accurate at the time:

https://news.bitcoin.com/mt-gox-restitution-process-frozen-d...

I'm part of the lawsuit that he's blocking, so you could take my word for it that that news article is correct. He has since lowered the claim amount to half a billion, which is still an insane amount that's too large for letting the bankruptcy just proceed.


>You should be ashamed of yourself, at least own it and make your comments under a pseudonym

I've found that this community will turn a blind eye to fraud and corruption, as long as it's done in the name of "disruption" and you're a "tech company".


Could it be changing? I used to be in that camp 10 years ago but in the past couple years my mind changed as these companies became much more nasty in their desperate quest for profitability; I'm sure I'm not the only one in this situation.


I've ovserved something very different. Lots of debate about the likes of Uber and AirBnB - with the bulk of comments leaning towards condemnation.


I don't think that has ever been true. What companies that are lauded in this community engage in fraud and corruption?

Some people side with the hotel's and the taxi drivers versus AirBnB and Uber, but I don't think circumventing rules and regulations to significantly improve these services is quite the same as fraud and corruption. Especially considering those industries are frequently associated with fraud and corruption themselves.

Not that I don't think Uber and AirBnB have manoeuvred themselves into positions of power that they are abusing or exploiting, but that just means they should be better regulated.


they didn't circumvent laws, they broke them with enough advertising that they got changed. the companies just ignore regulations and profit from it.


>at least own it and make your comments under a pseudonym.

Looks like he's owning it and making his comments under his real name.

Also if you invest your life savings on crypto you deserve whatever may happen to you.


I didn't do that, but I know many who did (like one commenter above) and they exposed their savings to a risk and they got hit. That could have been the end of it and it would have been a sad story, but maybe a good lesson.

That's irrelevant to Peter's unethical behavior though. If you trip because you didn't tie your laces running to the ice cream van, you don't "deserve" people kicking you while you're down. That doesn't make any sense.


> you deserve whatever may happen to you.

Nobody deserves to be ripped off. This comment is absurd and you need to evaluate your morals.


Did you read the content? Google did copy the private API’s. I am a legacy Java person and it is blatant theft. Not rooting for Oracle in any sense, but it was a total copy.


I think APIs cannot be patented. Not sure what is the situation with Google vs Oracle.

https://bbvaopen4u.com/en/actualidad/patents-apis-or-copyrig...


Are you mixing copyrights with patents?


Google screwed over Sun Microsystems. Let’s not forget that all this started before Oracle.

The original Java license mandates that mobile usage is differently licensed. Google basically writhed their own JVM just to bypass this - not for any other technical reasons.


If you don't want to enter into a particular licensing agreement, and a clean room reimplementation lets you do that legally, what's wrong with that?


> and a clean room reimplementation lets you do that legally

You're begging the question. This Supreme Court fight is over whether a clean room reimplementation lets them do that legally.


I understand that. I was specifically replying to the assertion that "Google screwed over Sun Microsystems". No, they did not. They decided on a path that they believed was legally defensible and would allow them to do their own thing with Java at lower cost. It might turn out that they're wrong, but no one tried to screw over anyone. It was purely an economic decision.

And if it turns out that Google loses this case, then all sorts of things that we take for granted for interoperability (like WINE, and, before the MS acquisition, Mono) are actually copyright infringement and shouldn't exist. I don't think we can claim with a straight face that WINE or Mono were created with malice intended toward MS, so we should give Google the same courtesy.


I don't think that's "begging the question". Google's corporate counsel determined current law allows for clean room reimplementation, so that's what they did. This was subsequently challenged, and that's where we are now. This isn't a case of Natural Law where the decision is commonsensical -- it's up to the courts to make an evaluation based on other established caselaw (in this case copyright), and there's certainly room for interpretation.


This is a fight over whether Oracle can get existing Supreme Court and Ninth Circuit precedent overturned to make clean room reimplementation no longer legal.


They could have used a different system (LLVM?) and Java would have become irrelevant on mobiles.


Sure, but instead they decided to capitalize on the existing market of J2ME and Symbian Java developers with tricks to sidestep Java licensing on mobile devices.

And nowadays Android holds hostage any Java developer that wants to target Android, because one needs to constrain ourselves to Android Java's view of the world.


But this case isn’t about consuming or interacting with an API, it’s about implementing an API. So less writing a compiler targeting a CPU instruction set and more building a CPU based on someone else’s instruction set.

I’ve always found it strange that other programmers are so dismissive of APIs as copyrightable work. They’re they hard part! Building APIs requires creativity and careful thought.

If you support the idea that APIs can’t be copyrighted, and ignoring the evilness of Oracle and Google, what’s your reasoning?


> If you support the idea that APIs can’t be copyrighted, and ignoring the evilness of Oracle and Google, what’s your reasoning?

Copyright is the thing that applies to works of authorship, like short stories and music. You can't copyright a fuel pump for a jet engine. You can't copyright function. That's patents, not copyright.

Software is somewhat unusual in that it's at the same time a work of authorship (code, copyrightable), and a set instructions for a machine to interpret (functional), and pure mathematics (facts about the universe, not subject to patent or copyright).

But an API is at the intersection of the functional part and the factual part. What distinguishes a literary work from a fact is that the literary work leaves room for creative expression. A copyright on an expression of a fact isn't a copyright on the fact itself, because someone else doesn't have to use your expression. They can create their own expression, so you having a copyright over your expression doesn't exclude them from using or conveying the same factual information.

When someone creates an implementation of an API, the API itself is a fact about how to interact with implementations of that API. There isn't any other way to interact with other implementations, so there is no room for creative expression in that aspect of a compatible implementation, so there is nothing there to copyright. You have to use the same API for entirely functional reasons or it's not compatible. And you can't copyright function.


But is that enough? Let's use a deliberately extreme example to test its limits: Skyrim mods.

Does the presence of third party Skyrim mods mean that everything they refer to is an API and therefore non-copyright? The game geometry, maps, characters and events are facts about Skyrim that those mods need to operate. Does this therefore imply that a hypothetical person could sell their own re-implementation of Skyrim on the grounds that all those things (characters, missions, events, geometry, models, etc) were function required for mods to continue to operate?

Or, to stretch it in a different direction, let's suppose I write some functions. If you write some functions that call them, presumably my API is therefore functionality and non-copyright? But what about if you don't call them, and only I happen to write calling code. It's still an API, it's still functionality required for other code to operate (my own), so is it still non-copyright?

What about whether I mark my code public? If I omit "public" from the same function definitions so they can't be called externally do the definitions become artistic and copyright? If so then is the artistry in the lack of a public keyword? If not then is any code structure copyright - it's all functionality that calling functions requires to operate.

Yes, that's deliberately playing logic games and taking things to extremes to see if there's a clear line in the sand. It's going to be interesting to see what the court determines, anyway, because it seems like a big question.


> Does this therefore imply that a hypothetical person could sell their own re-implementation of Skyrim on the grounds that all those things (characters, missions, events, geometry, models, etc) were function required for mods to continue to operate?

You're supposing that function being uncopyrightable narrows the copyright in the expression, but they're really just two completely different things.

Let's try an even more extreme example. Remember those anti-piracy book codes from a few decades ago? They'd sell a game with a printed manual and then to start the game you'd have to type in the third word of paragraph two on page seven of the manual.

We'll take the game copyright itself out of the equation by saying that the software is cheating by trying to restrict a copyright year 1800 work (expired copyright) using a copyright year 2000 book.

The book itself is clearly subject to copyright. It could be Harry Potter for all that matters. But the third word of paragraph two on page seven? That's a fact about the book. As is the fourth word of paragraph two on page seven, and so on.

If you collect every single fact about the book, you have all the information you need to reproduce a copy of the book. That neither means that facts are copyrightable nor that books are not. If you used all the facts to reproduce a printed copy of the book, that would clearly be copyright infringement. But if you collected and used all the facts only to solve the book code, not so much. Interoperability is solving the book code, not reproducing the book. Function, not expression.

And it has nothing to do with publication vs. secrecy because that's a copyright thing. Facts are facts whether you intended anybody else to know them or not.


I think the answer lies in compatibility and lock-in. Software and even hardware gets built against APIs. If APIs are protectable through copyright and a single entity can control who can and cannot implement that API as a provider, then everyone who has built software that consumes the API will be locked into doing business with a single company or its approved providers. As software engineers, most of us value the ability to compete and be interoperable and we recognized APIs becoming protected as enabling a new era of walled gardens and barriers to creating competing products.

We cheered for Compaq when they reverse engineered the IBM PC and started selling computers that could run software built for the IBM. We cheered Linux when it created a free alternative to the proprietary Unix interface. We cheered WINE when it made Windows APIs available under Linux. This kind of interoperability gives the rest of us the ability to reuse our own software without being beholden to the companies that created the original target platform.

Incidentally, there's a slight distinction in wording around API copyrights. I don't think there's a doubt that they can be copyrighted. Anything that is written down, recorded or filmed automatically receives copyright protection. The interesting question is whether there is a fair use exemption for interoperability. I think it would be obviously wrong if Google had taken Java and its APIs, renamed it Gava and then started pushing developers to write Gava software instead of Java. But they didn't, they just made Java be able to run on a new class of devices. If all you're doing is helping to ensure that existing code written by other developers can work with your product, that's a benefit for those developers too as well as the end users that buy and run the software.


> Anything that is written down, recorded or filmed automatically receives copyright protection.

This is factually untrue. Many things written down, recorded, and filmed do not receive copyright protection in the united states. A common example is recipes.

There is extremely good reason to think that APIs specifically fall into the set of things that can not be copyrighted. That's what the original ruling in this case was (overturned on appeal by the federal circuit). That's what a good portion of Google's brief argues.


Regarding the point in the first paragraph: In that case, that is a legislative issue. A judiciary is not empowered to be lenient in their judgment on copyright infringement because of compatibility and lock-in.


Case law strongly disagrees with you on this point.

Most relevant to this case is the merger doctrine. Ideas that can be expressed in only a small number of ways are not copyrightable.

Even more on point to your comment is the concept of copyright misuse. If you try to use your copyright (a government granted temporary monopoly on the reproduction of your work) to gain monopolies on other things you can not only lose the infringement case but in extreme cases even lose the copyright entirely.

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

https://en.wikipedia.org/wiki/Idea%E2%80%93expression_distin...


> Most relevant to this case is the merger doctrine. Ideas that can be expressed in only a small number of ways are not copyrightable.

The CC's opinion is of interest here:

> We further find that the district court erred in focusing its merger analysis on the options available to Google at the time of copying. It is well-established that copyrightability and the scope of protectable activity are to be evaluated at the time of creation, not at the time of infringement. See Apple Computer, Inc. v. Formula Int'l, Inc., 725 F.2d 521, 524 (9th Cir.1984) (quoting National Commission on New Technological Uses of Copyrighted Works, Final Report at 21 (1979) ("CONTU Report") (recognizing that the Copyright Act was designed "to protect all works of authorship from the moment of their fixation in any tangible medium of expression")). The focus is, therefore, on the options that were available to Sun/Oracle at the time it created the API packages. Of course, once Sun/Oracle created "java.lang.Math.max," programmers who want to use that particular package have to call it by that name. But, as the court acknowledged, nothing prevented Google from writing its own declaring code, along with its own implementing code, to achieve the same result. In such circumstances, the chosen expression simply does not merge with the idea being expressed.[7]

> copyright misuse

Inoperability with customers who have decided to use a service or product or lock-in due to said inoperability itself does not necessarily make the provider of the original service a monopoly.

Interoperability arguments have relevance in fair-use, but the courts have yet to determine if Google has a right to the APIs under fair use. Google and others may be entitled to the APIs under fair use, but the CC has determined that the SSO of APIs are copyrightable.

And fair use is yet another can of uncertainty, since usurpation of market share counts negatively to one's case for fair use.

====

In the case of APIs, a competing service can create a functionally identical competing API, but differently structured and organized and named, and then provide a competitor2us.sh script to help their customers migrate.


Note that copyright misuse is a separate doctrine from fair use, and unlike fair use it is not effected by any usurpation of market share.

That said, I think fair use is more likely to apply than copyright misuse in this case. I just brought it up as one way that the judiciary is empowered to be lenient in their judgment on copyright infringement because of compatibility and lock-in.


My bad; the court has already determined that Google did not have a right to fair use.


> you can not only lose the infringement case but in extreme cases even lose the copyright entirely.

Does the work become public domain or government royalty subject in that case? If the latter, it is worse since the government cannot be sued for copyright misuse, either.


Public domain or some state that approximates it (this is really not a well explored area of law and I'm not an expert).


I asked because government royalty subjects are something extremely (and I consider dangerously) commonplace in Europe.


Do you have any examples of that? I'm European and don't know what you mean.


Works of government that are copyrighted by the government are called government royalty subjects.


> If you support the idea that APIs can’t be copyrighted, and ignoring the evilness of Oracle and Google, what’s your reasoning?

The reasoning is quite simple and obvious: We have long-standing statutory and case law that defines specifically what is or isn't eligible for copyright protection, or patents, or trademarks. Your gut feelings about whether your API deserves protection because of how much effort you put into it are completely irrelevant to that legal framework.


Seems like circular reasoning to say that the things that can be copyrighted are the things that we have agreed can be copyrighted. Seems like if the courts decide that APIs are copyrightable then you would be fine with it since it would be part of that case law.

There was a time when software didn’t have copyright protection. Somebody had to make the first move.


It's not circular reasoning. The flow is clear: the Constitution gives Congress the power to make copyright law, Congress passed laws doing so, and the courts work out the details at the margins for stuff Congress didn't make explicit. Software is very much explicitly mentioned by the copyright laws that have been passed by Congress, so there's no reasonable doubt about the legal foundation there. API copyright isn't explicitly supported by statutory law, so for the courts to affirm API copyright on their own, they need to provide a convincing derivation of its existence as implicitly covered by existing statute. I doubt they can do so, and they obviously cannot do so without overturning a lot of previous precedent.

And all of the above is about the legal, technical questions about what the law is. The public policy question of what the law should be is a different matter entirely, and opinions about that generally should be addressed to Congress, not the Supreme Court.


APIs are functional, not artistic. They belong in the domain of patent law, not copyright.


> APIs are functional, not artistic. They belong in the domain of patent law, not copyright.

I think you're mixing up different types of intellectual property:

- Trademarks are intended to identify a source. Trademarks cannot be functional, they have to be descriptive.

- Copyright must express a creative idea. That idea can be artistic, or functional. Computer code and APIs can be copyrighted (as they most often are), but they can also be patented.

- Patents cover inventions with some utility. One can definitely patent a piece of art if it provides some utility.

It's not uncommon for companies to throw all three at whatever they are cooking up.


Copyright does not only cover artistic works. APIs are a form of contracts and contracts are copyrightable.


APIs aren't a type of contract in the legal sense.


>They’re they hard part

Are they though?

Implementors aren't piggybacking on APIs because they can't come up with anything better, they can ... easily. They are implementing those APIs because they want compiled Java programs to run on their runtime.


This case is more nuanced than that. Google is not copying the Java API for interoperability with existing Java programs — they’re copying the Java API to provide a familiar environment for Java developers. I agree the former ought to be fair use but the latter I’m less sure of.


Aren't you unfairly privileging the idea of a Java program over that of a Java library? A wholly-packaged Java program may not have interoperability with Android, but lots of libraries don't have that problem. There are plenty of copyrighted works written in Java that are fully compatible with Android.


If they happen to be lucky enough to use the cherry picked features from OpenJDK (cause they are now using it, but only the parts/packages they care about), not taking advantage of newer JVM bytecodes and ideally written in a Java 7 style.


I don’t disagree at all, but the question isn’t “are there pieces of existing software that run on both” but “is that the reason that Google copied the API or is it a side effect?”


I'd argue that that is the wrong question, motive doesn't come into play in this law (specifically: The merger doctrine). You should rather be asking the hypothetical version. If someone tried to make a second system that could run the software, would they have had to copy the API? If so the API is not copyrightable.


The existence of those works that run on both means you really need to start coughing up evidence for your repeated assertion that Google's motives were strictly about something else.


>they’re copying the Java API to provide a familiar environment for Java developers

Well, that's a difference without meaning. Familiarity with the syntax is important but we're not talking about copyrighting the language structure and syntax.

The other aspect is that of the wider ecosystem. Once you commit to Java, you have to reimplement the existing APIs because every Java library relies on those APIs. And it is that ecosystem that is the true value prop. The API itself isn't special itself (in fact, the Java one is frequently maligned for how bad it is), and devs adapt quickly to different ones when they move to another programming language. There would be no point in selecting the Java language without being able to partake in the ecosystem, no matter how brilliant the API design is. And if it was brilliant, they could have aped it in another language (Dart?) ... I'm making an assumption that presumably adapting the API to another language would be fine by you? Because if not, the mess you would cause in the industry would be immeasurable.


I agree. I don't think APIs should be copyrightable, but in a world where some little piece of a tune reminds of another tune and therefore is deemed infringing on copyright.. There is similar intellectual effort behind both. We will see what happens but I can see the argument why it should be copyrightable from a pure "intellectual property is property" standpoint.

But I also think that it is better for the world with much less copyright protection in general.


The short answer is: I think the law clearly supports the idea that copyright does not extend to APIs, and if copyright did extend to APIs it would be disastrous for the American software industry, and given America's large influence the world at large.

The long version of both of those is made much better than I could hope to make it in the various briefs. You can find them all here: https://www.supremecourt.gov/search.aspx?filename=/docket/do...

Google's brief probably provides the best version of the legal arguments, that being their job. Read the text under the heading "The Federal Circuit erred in holding that the Java API declarations were copyrightable." on pages 16 to 21 and the text under "This Court Should Grant Review To Decide Whether, As The Jury Found, Petitioner’s Use Of A Software Interface In The Context Of Creating A New Computer Program Constitutes Fair Use" on pages 21 to 29. I personally find the merger doctrine arguments particularly convincing, starting on page 17. Here's a direct link https://www.supremecourt.gov/DocketPDF/18/18-956/81532/20190...

As for why it would be disastrous for the software industry, I particularly like this amicus brief, and would suggest reading section 2. It was written by 78 particularly famous computer scientists, including Steve Wozniak, Guido van Rossum, Ken Thompson, Bjarne Stroustrup, Martin Odersky, Peter Norvig, Brian Kernighan, and Alan Kay. https://www.supremecourt.gov/DocketPDF/18/18-956/89487/20190...

Here's an except, where one of the programmers for Java says that while he was creating Java's standard libraries he copied APIs in the same way ("Amicus" in this context means one of the computer scientists who wrote this brief to help better inform the court)

> Sun reimplemented existing APIs for Java. Java reimplemented C’s math API,which includes methods for calculating a variety of mathematical functions. While at Sun, amicus Joshua Bloch oversaw Sun’s reimplementation of the Perl programming language’s regular expression API for Java, which allows sophisticated text searches and alterations. Oracle’s attempt to copyright Java’s API and hold Google liable for infringement of the resulting java.util.regex API ignores Java’s own history of API reimplementation.

Here's an excerpt about an API you are probably familiar with, which hopefully underlies just how bad a compatability nightmare this ruling will create

> In 1983, the Berkeley Systems Research Group released the Berkeley Systems Distribution (BSD) sockets API. Sockets control the endpoints for any communication over the Internet. Because the BSD sockets API was not copyrighted, it became widely adopted: Every major operating system reimplemented it to enable Internet communication. Thus, programmers can write standardized software compatible across computers to manage Internet connectivity.

But really, read the whole of section 2.


Designing APIs != Building APIs. Saying Oracle can copyright the Java APIs is like saying you can copyright the HTML5 specification, making it so the authors are the only ones who can implement HTML5.


> it would impact every open source project that tried to interoperate with any company's services, for instance.

This is categorically untrue. The discussion is not about anything called "API" but only certain kinds of APIs (code APIs, as opposed to protocols like REST "APIs"), and even then there is fair use.


What about the legal arguments made makes a distinction between "code" and "REST" APIs like you're doing? I've been reading the decisions and haven't seen anything like that.


Me neither and I even used ctrl-f. It seems the impact could taint anything loosly called an API. I make an API that is loosly linked to three competing API around then same data. Some of this leads to each of us suing the others.


Anyone can sue anyone over anything right now. The whole purpose of the court system is not to blindly apply any ruling to any other loosely coupled event, especially over the use of borrowed words, but to focus on the nuances and peculiarities of each case laid in front of it. That's what the courts are for, and why human judges and juries pass judgment rather than algorithms.


The legal arguments in any case pertain only to that case, but it is a necessary condition for a work to be covered by copyright is that it "fixed in a tangible medium of expression"[1], i.e. that there is some fixed text (or a picture, or an audio or video recording) that is the work (although once it exists, derivatives are also protected). This is true for a code API, but not for a protocol.

[1]: https://www.law.cornell.edu/wex/fixed_in_a_tangible_medium_o...


The moment your REST API includes any kind of validating schema, that will be the copyrightable "code API".


That schema could be copyrighted, but not equivalent ones, because the protocol isn't its schema. That's like saying that an algorithm can be "fixed" by writing a program that performs it, but if you do that, only the program (and its derivations) are protected, not the algorithm (the algorithms can be patented but not copyrighted). A program (including its code API) is a piece of text, and then its derivations are covered. A protocol, like an algorithm, is an idea that could be made into a piece of text, but the US copyright code explicitly states that that idea itself is not copyrighted.

For example, you and I could go to a sporting event and write down a description of it. Both of our descriptions are copyrighted, and any derivation of mine or yours are protected, but your description is not a violation of mine and vice versa, and neither is any other description by someone who saw the event but didn't derive her description from mine or yours.

Similarly for software, BTW. If you look at what a program does and then write a new program that does the same thing -- that's not copyright infringement, as you didn't derive your program from the fixed work of the original.


This whole case is about the "Structure, Sequence, and Organization" of the API. It's the abstract collection of API entry points, not any specific implementations. Yes, it's openly in conflict of previous definitions of copyright.


Yet again, I am not talking about whether code API is copyrighted or not; I'm just saying that regardless of the ruling, protocols aren't copyrighted. I said nothing about a particular implementation, but a code API, unlike a REST protocol, is a fixed expression. If that fixed expression is copyrighted, then what the copyright protects is a whole other discussion. Harry Potter is a fixed expression, but once applied, its copyright doesn't protect just a particular sequence of words, but various derivations of it as well (like translations). As to whether or not what this case is about is "in conflict with previous definitions of copyright," I have no opinion of the matter.


Yet again, the distinction you're making isn't one rooted in these rulings. The combo of striking down de minimus and entertaining that APIs can have copyright applies equally to REST, unless you can come up with a way for a server to not have the endpoint string literals in their code.

What you're describing is "how it should be", not the current state of the world.


Why would the distinction be rooted in the ruling? If there are, say, three conditions for copyrightability, and a work satisfies the first to but the third is unclear, then why would the ruling in that particular case even mention works that don't satisfy the first condition?

> applies equally to REST

Nope. This is a case about a verbatim copy of about two hundred pages of text (11,500 lines). There are interesting legal questions about whether or not the text is copyrighted (because software copyright is more limited than some other forms of copyright), but REST protocols aren't a fixed piece of text to begin with. They are just not works that copyright law deals with.

> unless you can come up with a way for a server to not have the endpoint string literals in their code.

There is no problem with string literals. None of the words in Harry Potter is copyrighted, and most books, or program with string literals, containing all of them don't infringe on Harry Potter's copyright.


How do you define, implement, or use a REST endpoint, without verbatim using the endpoint names?

And the length of the verbatim copying doesn't matter, because these same ruling are rejecting de minimus claims.

Like please look up the legal rulings here. They're using different tests than you normally see with copyright. You're spreading a lot of misinformation here.

https://en.wikipedia.org/wiki/Structure,_sequence_and_organi...


> How do you define, implement, or use a REST endpoint, without verbatim using the endpoint names?

You can use names verbatim. You can write a book with the names "Harry" and "Ron" and even "Dumbledore" without violating Harry Potter's copyright. In fact, if you take Harry Potter, translate it to French and change all the names so that not a single word is copied verbatim, that is a copyright violation. But regardless of what you copy, in order for a work to be protected by copyright at all, it must be some fixed piece of text (or an image, or an audio/video recording). REST protocols aren't.

> They're using different tests than you normally see with copyright. You're spreading a lot of misinformation here.

I'm not talking about this case, but about why this case doesn't apply -- whatever the result -- to REST protocols. What you linked to is about the following: Once a work is protected by copyright, what kind of derivations are disallowed? For example, Harry Potter is copyrighted, but I don't make a verbatim copy but a French translation. Is that protected or not? What about basic plot lines? But any such discussions are irrelevant to algorithms and protocols, which are not copyrightable works to begin with. There is also a question about code APIs, because there are other necessary conditions for copyright, but there's no question about protocols, as they don't satisfy the first condition -- there is no fixed work at all. Anyone who says this could affect protocols is spreading misinformation. Whether code APIs are copyrighted or not, protocols, like algorithms, aren't.


> You can use names verbatim.

If this ruling passes the Supreme Court, you can't anymore in the context of software. That's the whole point of what has people up in arms. These points of copyright are left to the courts, and they can change the rules if they see fit.

I really don't understand your outright refusal to read the ruling or even the damn wiki page.

I won't be responding to you anymore until you make a good faith effort.


> If this ruling passes the Supreme Court, you can't anymore in the context of software.

This is simply and totally untrue; it is nothing but uninformed panic. If you think otherwise, please point me to what makes you think that. In any event, a protocol is not a copyrightable work regardless of the result of this case, for reasons that have nothing at all to do with the discussion about the copyrightability of code APIs. Code APIs satisfy the basic necessary conditions for copyright, and there is debate over more nuanced ones. Protocols, like REST APIs, don't even satisfy the first requirement of copyright law -- they are not a work fixed in any tangible medium -- so they are completely irrelevant. Again, programs are copyrighted, algorithms are not -- even if the algorithms contain some fixed strings in them. If you don't understand that distinction, there is really no point in going further.

> I really don't understand your outright refusal to read the ruling or even the damn wiki page.

I have read pretty much everything written about this case, and the actual rulings. But understanding the basic tenets of copyright law is necessary in order to make sense of what you read.

The question of SSO is, once a work is copyrighted, is its SSO protected similarly to translation? For example, Harry Potter is copyrighted; if I copy the basic structure from Harry Potter is that an infringement? That's the subject of the discussion, which takes as a given that software is copyrighted. In the case of protocols -- like in the case of algorithms -- there is no work from the perspective of copyright law, so questions of what transformations of the work could constitute infringement are irrelevant.

I think that many people don't understand that copyright works like a two-stage process. First there needs to be a work satisfying some requirement to which copyright applies; second, once such a work exists, different kinds of deriving other works from it are determined to be infringing or not. This court case is about the second part, as it is recognized that software is a copyrighted work, and all discussions about the second step (like SSO) are under the assumption that the first step is OK. Protocols and algorithms don't even pass the first step, so any discusssion about the second does not concern them.


Example: I decide to to cleanroom reimplement Google's search REST API. Google hits me with a lawsuit for violating the SSO of the REST API as implemented by the Google Web Services executable and source.

Any protocol worth protecting will have a tangible expression they can point to whether it be code or documentation. The need for a tangible expression doesn't make a practical difference in the de facto copyright of the REST API.

You keep using literary examples even though SSO treats software differently. I will be ignoring any literary allusions from now on, please use actual case law about software.


> Google hits me with a lawsuit for violating the SSO of the REST API as implemented by the Google Web Services executable and source.

No, it doesn't work like that, just as if you implement an algorithm that's at the core of another program (without deriving your code from that other program) you don't infringe on the other program's copyright.

> Any protocol worth protecting will have a tangible expression they can point to whether it be code or documentation.

I don't know how to explain it any better than I have, so I'll mention yet again that your point applies to algorithms, and yet they are not copyrightable.

If you have a paper describing an algorithm, the paper is copyrighted, but the algorithm it describes is not. If you copy or translate the paper you may be in violation of its copyright; if you implement the algorithm described -- you are not. Same goes for recipe books, by the way. If you copy the recipe you could be in violation; if you implement it -- i.e. cook according to it -- you are not.

That the program is a fixed expression that manifests the algorithm or protocol is irrelevant. You are not allowed to infringe on the program's copyright, but the protocol or algorithm it describes are not copyrighted to begin with.

> please use actual case law about software.

Protocols are not software. SSO is irrelevant to them. Their relationship to software is the same as that of algorithms to software, and SSO doesn't apply to algorithms either, because they are not copyrighted works.

Any argument you'd like to make why this case has any bearing on protocols would also need to be compatible with the fact that programs are copyrighted while algorithms are not. If you make an argument that would also cover algorithms you can know you've made a wrong turn somewhere.


Neither my example nor the facts of Oracle v Google are dependent on copying of algorithms due to both being clean room reimplementations with the minimum verbatim copying needed for API compatibility.

Since you obviously aren't interested in a good faith discussion that doesn't involve you adding strawmen, I shall bid you good day.


I think you intentionally misunderstand my point or we're completely talking past each other. This case isn't about protocols just as much as it isn't about algorithms. The only relationship between this case and protocols is that in recent years some have taken to calling them APIs. No matter what the result of this case is, it will have no effect on protocols, just as it will have no effect on algorithms, or on bananas. From the perspective of copyright laws, these things are completely different categories, no matter what mental connections you can draw between them. I only bring up algorithm to help you understand that even though algorithms and programs have a similar relationship to that between protocols and code APIs, copyright law is not concerned with algorithms although it is with programs, so that same connection between protocols and code APIs is equally irrelevant to copyright law. But if you're not able to understand why programs are copyrighted but not algorithms, you won't be able to understand why code APIs could possibly be copyrighted but definitely not protocols.


> if you're not able to understand why programs are copyrighted but not algorithms, you won't be able to understand why code APIs could possibly be copyrighted but definitely not protocols.

The lack of copyright protection for algorithms was never in question here until you started bringing it up.

I said good day.


Protocols aren't copyrighted regardless of whether code APIs are for the same reason algorithms are not copyrighted even though programs are. Any argument you make that if APIs are copyrighted then so are protocols would also lead you to conclude that since programs are copyrighted, then so are algorithms. The latter is untrue, and so is the former.

For example, you said above that a program implementing a protocol becomes its fixed expression, and so every implementation of the protocol would violate that program's copyright. Well, that same argument can be applied to incorrectly conclude that algorithms are copyrighted as well. Same goes for an argument about certain fixed strings. I've explained directly why those arguments don't work, but if you don't understand the explanation, perhaps seeing that your argument would also apply for algorithms make you realize you've made a bad turn somewhere. To claim that this case affects protocols you'll need an argument that cannot be used to claim algorithms are copyrighted, too. If it can be -- it's a wrong argument.


> Same goes for an argument about certain fixed strings.

The fact that you don't see the difference between copying an abstract idea like an algorithm compared to literal copying of the names necessary for the structure, sequence, and organization of the API belies your ignorance wrt to copyright.

One involves no "this piece of the original is listed here in the reimplementation, verbatim" and the other does.

So far you've given no examples as to why you think that literal copying of SSO of a clean room code library reimplementation isn't equivalent to literal copying of SSO of a clean room REST server reimplementation.

Do you understand SSO arguments?


> The fact that you don't see the difference between copying an abstract idea like an algorithm compared to literal copying of the names

An algorithm can contain literal names and you're allowed to copy them. You need to understand that what you're allowed to copy or not is the second step after having established that the work under discussion is a fixed expression (and satisfies all other necessary conditions).

> necessary for the structure, sequence, and organization of the API belies your ignorance wrt to copyright.

SSO applies after it's established that a work is a copyrighted fixed expression -- it's the second step; it does not, and cannot, establish that things that are not works are. The SSO of a non-copyrightable thing, like an algorithm or a protocol is not protected.

> One involves no "this piece of the original is listed here in the reimplementation, verbatim" and the other does.

What you're allowed to copy or not of a copyrighted work is irrelevant to what you're allowed to copy, or not, of a non-copyrighted work. You are allowed to copy, verbatim, anything that's copyable from non-copyrighted works.

For example, if I tell you an original story at a bar, the story is not copyrighted. Therefore, you are clearly allowed to repeat it verbatim, write it down etc. It's not that copying verbatim, SSO, translations of anything is not allowed; it's that doing those things for copyrighted works might not be allowed. The action matters only after the work is determined to be copyrighted. Another example: distributing photos of copyrighted images might be an infringement. Your face, if you show it in public, isn't a copyrighted work. Do you think that "the SSO argument" states that the SSO of your face is protected?

> Do you understand SSO arguments?

Yeah, but clearly you don't. SSO, like translation, is one of the kinds of protected derivations of a copyrighted work. It is not used to define what is or isn't a work. Protocols are not copyrighted, and so their translation and SSO are not protected. Programs are copyrighted works, and so the argument goes that their SSO is protected.

Once more, two steps: first, is it a work that satisfies the necessary conditions for copyright (yes for programs, no for algorithms/protocols); second, if the first part holds, what kinds of copies and derivations are allowed (SSO, translation, verbatim copies of small parts etc)?

You don't need to concern yourself with SSO or verbatim copies until you've established that the work is copyrighted. If it's not -- like in the case of an algorithm or a protocol -- the argument is completely irrelevant.


I think you're confusing the "fixed text" requirement with the question of whether the Java language constrains the declaration of an API to a unique textual representation. The latter is more or less true, but the declaration that the compiler ingests isn't the only way to describe a Java API in writing.


The two things are completely separate, but having a fixed expression is a necessary requirement. If I go to a sporting event and describe it in an article, then my article is copyrighted, and derivations of it are protected (translations etc.). But there could also be other people who wrote different original articles describing the same event, each of them is copyrighted, but none a derivation of the other or of mine. But the fact that all of those articles are different descriptions of the same match doesn't mean they're not all copyrighted, and that their derivations aren't protected. Each of those articles is a fixed expression, but the game itself isn't.


There's obviously code implementing the REST protocol that's copywritten.


How is a rest api document any less tangible than a source code document?


What piece of text that is the REST protocol?


Here is a simple REST protocol:

    Send a GET request to some_website.com/some_protocol to get back a jpg of a cat
I wrote it down, and thus it was "fixed in a tangible medium of expression". As I understand that requirement of the law that is all that is required.

If I just told you that verbally, and we did not write it down, record what I was saying via a mic, or anything else, then it would not be fixed. No one does protocols like that though.


What you have here is a particular description of a REST protocol that is fixed, and indeed, if it fulfills the other requirements of copyrightability, it could be copyrighted, and I wouldn't be allowed to, say, sell T-shirts with that sentence printed on them. But if you developed a protocol and I asked you what is the work that you have produced, that work wouldn't be that sentence, but the algorithm it describes.

The same applies to algorithms, BTW. If I write and publish an algorithm, it is possible that my paper and even the particular pseudocode I used is copyrighted, but that's not "the work" (of the algorithm) nor is it a part of it. That is why even though the paper is copyrighted, the algorithm itself is not, although it could perhaps be patented. As confusing as it may sound, in the US the situation is: the paper describing the algorithm is copyrighted, a program implementing the algorithm is copyrighted, the algorithm itself cannot be, but it can be patented.

Whether or not code APIs can be copyrighted, they are different from protocols just as programs are different from algorithms, as a certain fixed piece of text is certainly an important part of the work. That may not be a sufficient condition for copyright, but it is a necessary one.


If Oracle is right, copyright protects the "[not relevant to the case] GET [not relevant to the case] <base_url>/some_protocol [not relevant to the case]" and it would be copyright infringement.

Well really I'd probably need to have a few more APIs involved, such that I have a tree structure similar to classes, but the point stands.

All that this subdiscussion was discussing was whether or not REST APIs are fixed in a medium as required, they are.


No, because the fixed portions are too small to be copyrighted, and they're also not creative. Being a fixed expression is just one of many necessary conditions, not a sufficient one. Also, not every copying of a copyrighted work is an infringement.

> they are.

They most certainly are not. If you think REST protocols are like code APIs, you should be able to explain why algorithms are not copyrightable but programs are. The law already makes a distinction between those two, so you'll need to explain why that distinction does not apply for protocols vs. APIs.


> Being a fixed expression is just one of many necessary conditions

And yet it is the only one you raised, and the only one I responded to in this thread. You are moving the goal posts. If these posts were legal briefs the judge would say you have waived the rest of your arguments and I would have won (Waiving arguments being the legal equivalent to moving goalposts).


Because it is the difference between protocols and APIs, and why, regardless of the status of code APIs, protocols cannot be copyrighted. This is also the difference between programs and algorithms.

But you seem to have interpreted the necessary condition that a work must be fixed in order to be eligible for copyright as "any fixed portion of a work is copyrightable." This is untrue both because being fixed is necessary but insufficient for copyright, and because tiny portions of a work aren't works in themselves. Also, I have not claimed that anything that might be called an API and is fixed is necessarily copyrightable. I only said what is definitely not copyrighted. So no goalposts have been moved, you just misunderstood the necessary condition and my point: Protocols (like algorithms), unlike code APIs (and programs), aren't fixed, and so cannot be copyrighted regardless of anything else that may or may not be. That some tiny portions of a protocol might be fixed does not change the status of the work.


They are the same thing. In time this should become apparent to you.


A story I tell you in a bar and a written story may seem like the same thing to you, but one of them is copyrighted and the other isn't. A feature that may seem incidental to you is an essential one to copyright law. To copyright law it matter a great deal exactly how some expression is made, and how it is fixed to some recording medium. In particular, it requires that there exists some particular piece of text that can be called the work. This just doesn't exist for a protocol (there are many original texts that could describe the protocol), but it does exist for a code API.


How is there a difference here between "code APIs" and "rest APIs"? Both are simply interfaces which allow two pieces of code to talk to each other, the only difference is the protocol used (HTTP vs the platform's ABI)


Because copyright law doesn't care just about the purpose of a creative work, but also about its precise form and medium of expression. Why? That's a whole other discussion.


Rooting for fair use? Yes. Rooting for a big company spending big money to pay for the precedent? Sure.

Rooting for Google itself, who is simply pursuing the most effective solution for their own business (and brand)? That’s something entirely different.


I don't love everything about Google, but the enemy of my enemy is my friend. If Oracle wins, that precedent will hurt everyone in the software industry, including me.

So yeah, I'm rooting for Google and I have no hesitation or shame rooting for Google -- because for better or worse, Google is the company fighting for my rights in this case, and I want to win.


If APIs aren't copyrightable, then that solution is open to you as well.

Turns out, inventing a whole language every time you need to write a new library is an enormous pain in the ass.


Not surprisingly but this comment / position gets downvoted and yet plenty of approval for "Also, Oracle just sucks in general. Larry Ellison is a notorious jerk and philanderer...."

(I'm all for crapping on Oracle, I guess the lesson is to weave that into any post on this topic).


On the contrary, I’m actually not 100% sure who’s side I should be in on...

Look at it this way, if oracle loses, then what’s the implications of the software licenses in general. The whole point is that they were protected by copyright. If that’s shot down, then what’s at stake?

Not saying I side one way or the other, simply that I don’t think it’s clear. Depending how the court rules one way or the other could have a huge impact (as you pointed out).


> Look at it this way, if oracle loses, then what’s the implications of the software licenses in general. The whole point is that they were protected by copyright. If that’s shot down, then what’s at stake?

An Oracle loss would not damage the legal framework that the software industry has been operating under. Oracle's loss would only confirm the non-existence of a new class of copyright that Oracle is trying to invent (one that appears to be patent protections with copyright duration, enforced in part by trademarks). An Oracle loss would not undermine the legal foundations of existing copyrights on code that implements an API.


Software licenses still work exactly the way we've always thought they do if the federal circuits ruling is shot down. Copyright still works exactly the way we've always thought it done.

No one has ever thought that you could stop people from copying APIs. If they did all sorts of things like Linux (hi Unix), Wine, Windows Subsystem For Linux, AMD x86 CPUs (ok, Intel might have licensed them to avoid anti trust issues), Intel x64 CPUs, and so on would not exist.


Also Intel licensed x64 from AMD...


Those were patent licenses, not copyright.


Oracle isn't complaining about their software copyright. They are complaining about their API copyright. They believe that they own the idea of a tool os where one tool is called "println" and another tool is called "math.sqrt". Their work was never copied, only their naming scheme.


Seriously people - read the comment before down-voting it. A flood of down-votes coming in in less time than it takes to read what I wrote implies that you aren't even considering the argument I'm presenting.

I hate to say it, but I'm with Oracle on this - but not for any reason that I've seen mentioned (so I guess I want neither party to win).

(Notwithstanding Sun's internal excitement at Google's use of Java prior to the Oracle acquisition.)

There is a justification on the grounds of obviousness for certain method headers to be uncopyrightable.

But for inobvious and complicated method headers I do not believe that the restriction should prevent the API from being subject to copyright, but rather to limit the applicability of the copyright for fair use purposes.

Specifically I believe the copyrights on such interfaces should not be applicable where interoperability is the justification for the reuse of the interface.

Google broke compatibility with Java. I do not believe that Google is using the API under fair use constraints.

I'm not sure how the law operates here - but I believe that the precedent set by a Google victory would be more damaging to my position. I'd like to see Google lose, and for someone later - operating with cross-compatibility in mind - to present and win a fair use case for reuse of an API.


Let's assume everything you said except the conclusion is right (I disagree with almost all of it, but for the purposes of this discussion I'll put that aside since it's better argued in the fine legal briefs).

Why does fair use for interoperability require perfect interoperability? That seems like a totally unreasonable bar. It would mean that making some fraction of an API ridiculously complex to implement a way from stopping anyone from implementing the rest of it.


I'm not talking perfect interoperability - I believe that substitutability should be the bar. Google produced something that is not substitutable in either direction, so what I perceive as the reasonable fair use argument cannot be used here.


What do you mean it's not substantial? People use the same java libraries on android and servers all the time, thanks to being able to use a shared standard library API (the supposedly copyrighted material in question in this case).


Substitutable, and no it isn't. Google deliberately broke compatibility with java, its language and its packaging.

From the UI perspective, there is actually a reasonable justification for limiting compatibility - but they went far further than what was reasonable.

They did this to prevent applications executable on any JVM from running on Android.


You seem to be arbitrarily setting the scope for substitutability to Java as a whole, but why? Why can't it be e.g. individual classes, or even methods on them? Two pieces of Java code pretty much never need the entirety of J2SE API to interact.


The JVM itself makes backwards incompatible changes. I have jars that work on earlier VMs, but don't anymore.


Sure, but I'm damned certain that's never happened with the destruction of interoperability being the goal in mind.


The destruction of interoperability wasn't the goal in mind with Android either. Java ME sucked, and SE is somehow even a worse fit for phones. The fundamental process model destroys battery life, hence the switch in Android to that model that'll shut the app down basically at any time and allow it to save state, so it can come back to where it was later. In addition to that, an IPC system was added (which basically doesn't exist in Java ME), and a bunch of support for devices that are only accessible in Java via 3rd party libraries anyway. Oh, and the lack of swing. But come on, even Eclipse doesn't use swing.


Having jars only work with specific oracle JVM versions is not at all unusual.


> Having jars only work with specific oracle JVM versions is not at all unusual.

I think that underscores the point? That even legitimate JVM versions were not substitutable for each other.


How is that supposed to be determined? By hiring more lawyers, no doubt.


I'll admit that I'm not sure how the law operates here myself. But I worry that because fair use is an affirmative defense, your formulation opens the door to something like a platform vendor analog to SLAPP suits. That is: it seems like if I, as the legally anointed steward of a platform, believe that your leveraging of my API is in line with my business model, I can decide not to sue you. If you try to compete with me (even in a venue that isn't using said API), I can decide to sue you just to make you incur the cost of defense. The particular burden of platform fragmentation and how it interacts with trademark law is a pretty subjective thing, so I suppose Oracle ultimately gets to make a prospective competitor relitigate Apple v. Franklin and Sega v. Accolade and Oracle v. Google Every. Single. Goddamned. Time. They. Want.

No, sir, I don't like it.


I don't disagree with you about that being a danger - but I don't think that the solution to bad faith operators in copyright is to bring the system down any more than I believe it to be the answer in patent law.

I think that the system desperately needs to more actively punish those who abuse the legal system.

If a case is found to be frivolous I belief that the plaintiff should have to pay both fines and damages. The plaintiff's lawyers should also be punished - warnings, fines and eventual disbarment.


What if the defendent doesn't have the funds to get all the way to the frivolous decision?


That's hard- maybe talk to the EFF (https://www.eff.org/pages/legal-assistance)?

I'd prefer it if it didn't to come to that, and they lack the budget to do all that needs to be done, the system simply lacks enough good operators to act as a counterpoint to those operating in bad faith.

I think when you need that counterpoint at all, it's the system as a whole that needs to change. But this is getting way off topic.


> Specifically I believe the copyrights on such interfaces should not be applicable where interoperability is the justification for the reuse of the interface. Google broke compatibility with Java.

You cannot make good law on this basis. Requiring compliance to a compatibility standard written by Oracle would give Oracle all the power, and render that kind of fair use exception effectively impossible to exercise. There's no good way to define what kind and degree of interoperability should qualify. The only regulatory option that doesn't trivially collapse into a complete win for Oracle is for API copyrights to not exist in the first place.


I think that you're making a bit of a leap here. There are a large number of JVMs - https://en.wikipedia.org/wiki/List_of_Java_virtual_machines.

Not all of which will be Oracle certified, I would argue that each and every one of them should be free to exist regardless of that fact, on the grounds of fair use.

The courts have never been black and white entities - and there has long existed the legal notions of best and reasonable efforts. Which I think should be the standard by which a competing implementations interoperability should be judged.

This also ties in to another part of another response that I had not addressed - the reasonable efforts standard would protect against being required to implement needlessly complex parts of API.


Postulating a "reasonable effort" legal standard does absolutely nothing to answer the more important questions about what kind and degree of compatibility should be considered the goal. Whether it's judged strictly or with some leeway, we still need to know who other than Oracle gets to decide how much compatibility with Java would be necessary for fair use to unquestionably apply.


The mistake you are making is assuming Oracle is, and will continue to operate in good faith, judging by their past history of rent extraction maximization, that is absolutely not the case.


I know full well that Oracle isn't operating in good faith, it never has it never will - I have made no statement regarding Oracle's intention or nature (which I generally find to be malignant).

In this instance, I believe both parties to be operating in bad faith.

My position is relatively simple, and despite the hate it seems to have inspired I stand by it: A complex API is a creative work that deserves the protections of copyright, fair use limitations should be applicable based upon a need for the existence of interoperable software.


If you allow it to "deserve the protections of copyright" then it absolutely will be abused to ensure that inter-operation, and thus not violating Oracles copyright, is impossible.


Both copyright and patent law is already abused to a significant degree - that does not mean that the protections provided provide no worth or are unjustified.

The problem is a system that rewards bad actors - and yes Oracle is one of those bad actors.

The solution is to improve the system to disincentivise bad actors while continuing to provide time limited protections to those operating in good faith.

As I've mentioned in other comments best and reasonable efforts are standards already used in the legal system - and there is no reason that those standards could not be applied to reimplementation efforts.

All of the arguments that I've seen against what I'm suggesting are based around abuse of the system by bad faith actors - I think that they can be disincentivised without tearing it all down.


The best way to disincentivise bad actors is to not give them a nuclear bomb to go threaten people with.

The legal system has largely failed in constraining copyright and patent abuse, and indeed has been key in massively expanding their reach (See "business process" patents and software patents, as well as stuff like the DMCA to shut down basically anything that involves interfacing with things).

API copyright is absolutely a _new_ concept invented whole cloth by the court, what advantage do you think it brings, vs the heavy tax on literally every piece of software ever created it imposes (after all CPU instruction sets are APIs).

You have repeatedly failed to present any actual advantage it provides beyond "it was hard work". What new APIs are going to exist because of this new law, that did not exist beforehand? What is the point of even trying to design a system where supposedly only "good faith" is rewarded? (good luck with that one)

Copyright is not about ownership because you created something, it is about benefit to society, that's why it expires and the public domain exists and also does not apply to all works.


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

Search: