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.

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.

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 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!’

There's plenty of lab research going on.

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

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

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.

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.

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

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.

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

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

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

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.

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.

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

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.

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.

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.

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.

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)

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

    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?

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

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.

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.

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

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

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.

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.

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

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.

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

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.

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?

    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.

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.

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.

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 think that underscores the point? That even legitimate JVM versions were not substitutable for each other.

No, sir, I don't like it.

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.