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.
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.
What about removing Oracle's devs contributions from Linux kernel?
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 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.
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.
Which is kind of ironic, hate them, but then willing accepting whatever comes from them, 'cause hey it is free.
What is schizophrenic is having a community that hates big corporations, but happily takes anything they decide to offer,
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.
I only see that among FOSS folks, seldom among other kinds of activism.
I honestly don't get the Oracle hate from HN people, even if I do understand it from the Slashdot folks.
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.
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!’
And so what anyway? Google is also good at supporting things not sales driven means that Oracle isn’t?
There's plenty of lab research going on.
Isn't Oracle a legal driven company  :)
I personally think stripclubs arre a waste of money, but I know femenists that would take exception to either of those above.
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.
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.
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.
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.
Hopefully as things continue to the cloud with private options
and their loss of the JEDI contract puts them right out of business.
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.
"James Gosling Triangulation's Interview on Google vs. Sun"
Google should face the same penalty as Microsoft did, plain and simple.
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.
> 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.
> 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.
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.
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.
Java 7 byte code was a big mistake. People complained but Oracle didn’t listen. As always.
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.
They forked the shit out of it too with tons of base functionality being in org.dvb. and javax.tv.
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.
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).
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.
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.
API compatibility doesn’t have any stylistic choices in it.
Silly example of course, can't think of any better. Feel free to substitute your own.
If a tree infringes in the woods and the silicon manufacturer doesn't hear it...
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?
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...
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.
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.
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.
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.
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.
Java: public String concat(String str)
Python: def __add__(self, *args, **kwargs)
C++: function <string> std::operator+ (string)
(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).
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.
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.
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?
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.
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.
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.
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’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 firstname.lastname@example.org: 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.
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.
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.
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.
Is there a list of top HN quotes, because I would like to add this one!
No idea of the quality of Bitcoinomics as a source though.
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.
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".
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.
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.
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.
Nobody deserves to be ripped off. This comment is absurd and you need to evaluate your morals.
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.
You're begging the question. This Supreme Court fight is over whether a clean room reimplementation lets them do that legally.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
There was a time when software didn’t have copyright protection. Somebody had to make the first move.
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.
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.
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.
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.
But I also think that it is better for the world with much less copyright protection in general.
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.
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.
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.
What you're describing is "how it should be", not the current state of the world.
> 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.
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.
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.
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.
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.
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.
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.
Since you obviously aren't interested in a good faith discussion that doesn't involve you adding strawmen, I shall bid you good day.
The lack of copyright protection for algorithms was never in question here until you started bringing it up.
I said good day.
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.
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?
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.
Send a GET request to some_website.com/some_protocol to get back a jpg of a cat
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.
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.
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.
> 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.
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).
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.
Rooting for Google itself, who is simply pursuing the most effective solution for their own business (and brand)? That’s something entirely different.
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.
Turns out, inventing a whole language every time you need to write a new library is an enormous pain in the ass.
(I'm all for crapping on Oracle, I guess the lesson is to weave that into any post on this topic).
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).
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.
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.
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.
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.
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.
I think that underscores the point? That even legitimate JVM versions were not substitutable for each other.
No, sir, I don't like it.
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.
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.
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.
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.
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.
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 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.