Hacker News Reader

Comment by staticassertion | Hacker News Reader

I am somewhat ignorant, so I would love it if someone could fill me in on what I'm missing.

* APIs are just as novel as implementations. API design is hard, and interesting, and it's code just as much as a library is code.

* While in this case it would be nice for Google to win because it's a case of a Proprietary software being used for Open Source, I see a far more daunting problem. I see massive companies like AWS reimplementing open source projects' APIs with proprietary solutions, and I'm not sure if copyleft licensing would be able to protect them if Google wins. That sounds far more dangerous to me than a company being able to copyright its API.

* People say this would be a disaster. Is it not the case that, if this happened, that new and novel APIs could be copyrighted? Why is that bad? The difference between a free/proprietary API is that you can't use a drop-in replacement, but we already avoid proprietary software, or overly restrictive software, all the time. So wouldn't we just continue doing so?

edit: From another of my posts, to put it this way:

To me, if I write a program under license X, it is strange to me that someone can reimplement my program's API under an incompatible license Y. To me, that violates my license, and software licenses are enforced via copyright protection.

View on HN

APIs are interfaces. If an interface is truly innovative in some important way, the proper way to protect it is with a patent, not with copyright. Of course, then you'll have to actually prove that it's sufficiently innovative - and, conversely, somebody could challenge your patent and strike it down by e.g. providing examples of prior art.

If all APIs are copyrighted, then interoperability goes out of the window. How far do you think would F/OSS have gone if it couldn't re-implement Unix enough to be reasonably compatible? The story of Linux vs Hurd tells volumes right there.

Books are protected even if they are not innovative, programs are protected even if they are not innovative. Why should interfaces not be?

Referring to the article in [0], facts are not copyrightable.

If you're going to write some code, then you usually choose to base your work on a particular language, which means you copy a lot of the design decisions and original work that went into it, and that is hopefully what everyone wanted ITFP. You (or O'Reilly) copyright a thorough description of the language's syntax, not the syntax itself. An API's function signatures are a more specific and elaborate kind of syntax, but all are just facts about the world now that someone published the thing. edit: I mean that the uncopyrightable fact is that "if you are going to use this thing, here is exactly the way it must be done".

This goes much further than 'imitation is the sincerest form of flattery'. The reason e.g. Microsoft published the reference for MFC is because they wanted people to be able to use it, and actually use it. My shallow opinion is that interfaces are like that. You want people to build on top of it rather than making up a new and utterly foreign thing every time, so you want people to copy the exact things about it that make this possible, correctly.

You could argue that Oracle didn't own any of the code that different bits of Android were interfacing with, so they didn't have any incentive there. But that only means Oracle forgot or doesn't care about that thing called 'mindshare'. People learning and using identical interfaces "should" have been something that Oracle wanted.

(I don't mean to imply any notable similarity in the two cases, but people knowing when and where the trains were running-- so they could use those and keep on deciding to use those-- "should" be something that MTA wanted.)

On the side, obsessing over protection is precisely what I've said is distasteful about the GPL.

$0.02

[0] https://news.ycombinator.com/item?id=22002272

"If you're going to write some code, then you usually choose to base your work on a particular language, which means you copy a lot of the design decisions and original work that went into it, and that is hopefully what everyone wanted ITFP. You (or O'Reilly) copyright a thorough description of the language's syntax, not the syntax itself."

Yes, exactly like APIs.

"An API's function signatures are a more specific and elaborate kind of syntax, but all are just facts about the world now that someone published the thing. "

This is just plainly not true.

Nobody on this thread has given a reasonable argument as to why APIs are not more or less like code.

In fact, almost everyone's attempt to demonstrated that 'API s are different that code' have done the opposite, and highlighted how similar they are.

I believe HNers just don't like copyright, and don't like Oracle.

> This is just plainly not true.

This is DH3. [0] I need some more red meat. :)

> Nobody on this thread has given a reasonable argument as to why APIs are not more or less like code.

I think they did, though. An API is designed and written, and then it is "a design". (OK "an interface" but that's jargon, the design and formal requirements and patterns are what matters) Code is designed and written, then it is "an implementation". If there's anything special about your design so that you want to control how and whether people are legally allowed to implement it, you get a patent, not a copyright. Then (IINM which seems probable because IANAL) the separate (perhaps royalty-paying) patent licensee can still copyright their own implementation. Don't get me wrong-- I don't want even more patents around software, I just hope people will call things what they are. I have to admit that I could merely be mincing words, if only because that's what I want to accuse someone else of doing. I don't envy the court.

[0] http://www.paulgraham.com/disagree.html

Yes, that's actually a good attempt at making the case, along the lines of some some of the amicus brief filings. (Most of the arguments on this thread are missing the point).

So here is where people are crossing streams I think:

'The interface' to something is not copyrightable as the law says today - fair enough.

But the description of said interfaces may in fact be.

In many cases, probably most, the API is literally part of the code - which is copyrighted already.

So it might be possible that the articulation of an interface is a creative work like anything else, but the implementation is not.

So you can release an implementation of some copyrighted platform - that does the exact same thing with the exact same interface, but the description of said interface in some descriptive language is copyrighted.

The paradox of the fact that the API is often part of the copyrighted code ... is hard to get past.

This part is pretty settled, I think - an .h file is copyrightable, for example, because it is code (that happens to define an API). That's fine, well-established, and people have worked around it for a long time now - e.g. MinGW uses their own <windows.h> for this exact reason, even though it describes the same API as the one that comes with MSVC.

The question at stake is whether the API itself is copyrightable, and that workaround is therefore not sufficient.

It has been conflated in this particular case, because IIRC there were some infringement claims around the literal contents of the .java files, and others over the "structure, sequence, and organization" (i.e. the API proper). But then for that first part, Google pointed out that in Java, there is usually only one way to describe one particular API; and if you use the standard coding style, then even independent definitions will end up looking the same verbatim.

Yes, thanks. As I see it, that 'conflation' to me is a not just some odd mangling of issues, it's a material to the nature of what's being created.

> MinGW uses their own <windows.h> for this exact reason, even though it describes the same API as the one that comes with MSVC.

I thought they provide their own because they don’t want to assume that MSVC is installed too.

If it weren't copyrighted, they could have just copied it as is, instead of rewriting it from scratch.

The file may be copyrighted, but the discussion here is whether the API is or not.

In this subthread, we were discussing "the interface something is not copyrightable as the law says today, but the description of said interfaces may in fact be". The header file was an example of how this is already generally assumed to be the status quo - the API is not copyrighted, but the particular description of that API, in form of <windows.h> that ships with MSVC, is copyrighted. So MinGW could do this for Win32 API, so long as they rolled their own header.

You Seem to Assume that the language in question and the API’s must have identical license requirements. Sure, if someone write a novel in English they can get a copyright on the book but not the language. But If I invent a different language and publish it in a book, why should I lose the rights to it simply because of what the language is or how people would use it. You can’t copyright the European history because it’s facts, but you definitely can hold a copyright to the Written. history of Westeros.

Also, just to note. Even authors of completely proprietary languages want people to use them. Only they also want to make money when people use term. The intention that people should use your product does not give anyone rights to copy outside of license allowances or to break copyright where that applies.

> You Seem to Assume that the language in question and the API’s must have identical license requirements.

Maybe. I seem to be saying that with both languages and APIs, licensing-related restrictions are worse than useless. Anyone can go write a compiler that translates a pre-existing language into object code, right? If you can insist on being the only one who can compile your language, good luck getting people to write in it.

> But If I invent a different language and publish it in a book, why should I lose the rights to it simply because of what the language is or how people would use it.

Which rights? Isn't that the original question, the one of what rights are implied as 'granted' when you publish a thing, such as 'the right to read and understand it'? (No I didn't purchase your book, I found it at a library.) You don't "lose the rights" to it, that sounds a bit like false dichotomy. You merely would not have had all the rights you had hoped, from the beginning.

---

I can almost see it Oracle's way: they own all the results of a great deal of work that Sun('s employees) did, and later on Google managed to avoid a chunk of that work and so help their own bottom line. Google also takes advantage of the industry's pre-existing familiarity with it. I still think Oracle is on the wrong side of common sense because Google was also helping Oracle's thing stay popular by increasing the motivation for anyone to gain familiarity with it, and I would call it a fair trade. But that's me, and my business sense is rather like a phantom limb.

> ou want people to build on top of it rather than making up a new and utterly foreign thing every time, so you want people to copy the exact things about it that make this possible, correctly.

As the copyright holder you are free to grant that right to anyone. In fact, if Google wins, you just won't have a choice in the matter. If Oracle wins it's far more inline with how licensing currently works - the developer chooses who and how their code is used.

Ironically enough, Oracle winning gives developers more power over their code. Google winning will allow any large company to replace open source software with proprietary software with no ability for devs to protect themselves.

> if Google wins, you just won't have a choice in the matter.

> Google winning will allow any large company to replace open source software with proprietary software with no ability for devs to protect themselves.

Can you back this up? What should I be reading if I wanted to convince myself that this is true? What if I'm not releasing a FOSS library (and necessarily publishing the API) which I hope people will use if only to justify the time I spent designing and implementing it?

> Can you back this up?

This is just the way licensing works today. So just take the existing rules for a software license and apply them to an API.

> What if I'm not releasing a FOSS library (and necessarily publishing the API) which I hope people will use if only to justify the time I spent designing and implementing it?

If Oracle wins you are the copyright holder of that code, including the API. So feel free to let anyone use it if you would like.

Oracle winning means you get more control over your code. Google winning means you have no control over the API.

> This is just the way licensing works today.

I remain unconvinced.

> If Oracle wins you are the copyright holder of that code, including the API.

I said "what if I'm NOT", as in, "how will this ruin everything for me in the most common case, that of being only a user?"

But I am planning a library and it is meant to be free-as-in-sunlight if it ever gets there. I'm not worried, I just find it easier to agree with those who are saying the opposite. They seem to think Oracle winning will be precedent for an incredible amount of control to be exercised by software publishers, especially regarding operating systems... this would basically throw a bucket of sand into the proverbial gearbox, for everyone, down to the last user.

Not everyone wants more control. On the flip side, not everyone wants more users just for the sake of proving they made a more useful thing.

IIUC Google winning means I have to be mentally prepared for someone to someday take advantage of my work, which is what I wanted from the very beginning. Whether or not that feels "fair" depends entirely on my definition of "fair", not the court's. Anyone who decides to do that will have paid me a compliment, unless of course someone reuses my work to do something specific that I happen to really dislike. But people are very different from me, so that's almost inevitable, and I might not even learn about any of it, and anyway I accept the possibility.

If Google wins it basically re-establishes the status quo. Unless you think things are a disaster now I don't really understand your conclusion.

>The difference between a free/proprietary API is that you can't use a drop-in replacement, but we already avoid proprietary software, or overly restrictive software, all the time. So wouldn't we just continue doing so?

Right now we can drop in implementations as we see fit. Oracle's win would mean all proprietary APIs become vendor lock in. This would be a massive sea change that would shake the industry (possibly many industries?) to its foundation.

>it's code just as much as a library is code

APIs enforce a representation. We are free to re implement the functionality of other software without copying it verbatim. Any implementation of an API will produce an exact copy of code at the API boundary. This is inescapable and we should not treat this as copyright infringement.

> Unless you think things are a disaster now

Reread the comment, like "I see a far more daunting problem."

A good analogy might be the special provisions in copyright law for the design of typefaces.

In the US, as I understand it, copyright does not apply to those designs, although it can apply to a specific description of the design such as a font file on a computer.

This is not because typeface design isn’t a creative activity; clearly it is, and as such the usual arguments for the copyright incentive would apply. However, that must be balanced against the public benefit of being able to communicate unfettered. In the case of typeface designs, the view was taken that the public benefit was more important.

It seems to me that a directly analogous argument can be made for APIs in software. While making a good API is certainly skilled creative work, allowing the API to be restricted by copyright would be a huge barrier to interoperability and competition.

It goes both ways. WINE is a free implementation of windows apis. After an oracle win, widows could sue to stop development of wine.

But it has always gone both ways with software licensing.

Copyrighting API means there no longer is operability allowed, not only between proprietary and open source software, but also between incompatible open source software. For example ruling in Oracle's favor means no ZFS on Linux.

Your concern about Amazon implementing proprietary solutions using open source API I believe is not an issue. I actually can't see it being one. It's like a proprietary service using TCP/IP. I don't think it would be easier to write an open source client, if there was a proprietary stack that copyright would prevent you from implementing anything compatible with it.

> also between incompatible open source software. For example ruling in Oracle's favor means no ZFS on Linux.

Can you please elaborate here? I don't understand what you mean.

It is already the case that you can not relicense software under and incompatible license.

> I actually can't see it being one.

Let's say I write an amazing database. It's open source, and my license dictates that any modifications to the source code get contributed back.

Someone else clones the repo, guys everything except the APIs, and reimplements what's inside. They then release this under an incompatible, proprietary license.

Why is that ok? It seems like a clear violation of the intent of my copyright. And it's already what we see AWS doing, so this is obviously a lever that large companies are willing to pull.

We wouldn't have Linux, BSDs, or MacOS, or any of our modern web infrastructure, if AT&T had been able to maintain a monopoly on the UNIX API design.

Those came out to scratch an itch. If AT&T had maintained a monopoly on UNIX API, someone else would have scratched the itch. Maybe someone would have designed an interface and explicitly granted public reproduction rights, as many products have done before UNIX and after.

So even with this change, we'd still likely have most of not all of the same overall solutions, derived from other places.

Because the API is not code. It's that simple

It is implemented through code, but it isn't.

> Let's say I write an amazing database. It's open source... Someone else clones the repo, guys everything except the APIs, and reimplements what's inside

It's fine to copy the essential parts to maintain interoperability, so that's fine. But then again, API is not code so "guts everything besides the API" is almost moot.

You can say an API isn't code but it doesn't make it true. Even if it somehow were true, code is hardly the only thing copyrightable, even in software.

> Can you please elaborate here? I don't understand what you mean. It is already the case that you can not relicense software under and incompatible license.

According to some groups (Canonical, Nvidia, VMware etc.) you can use proprietary/incompatible licenses with (not in) the Linux kernel by using a shim. This shim construction or other compatibility layers relies on the argument that you don't have to relicense at all, but that just using/implementing the API is fine.

The Oracle case has the possibility of changing this logic completely, making all shims/compatibility layers illegal and possibly making all software GPL.

> Why is that ok? It seems like a clear violation of the intent of my copyright. And it's already what we see AWS doing, so this is obviously a lever that large companies are willing to pull.

Why does it seem this way?

> Someone else clones the repo, guys everything except the APIs, and reimplements what's inside. They then release this under an incompatible, proprietary license.

So you mean, they don't even use your source code? For all you know they used 0% of your source code (for example the source of your amazing database was in C++, and they implemented theirs in Rust). Why should Amazon's completely different amazing database that shares zero implementation details of yours be contributed back?

Another bad side effect of things like this is that potentially things like `Shape` and `sort` become copyrightable APIs. If oracle has copyright on Java APIs, that prevents other people from implementing better/other versions of the Java sort function (maybe it's faster, but unstable), you can't implement that.

Why does it seem what way? Like a violation? For the same reason that it would be a violation of my license if they copy/pasted the code and just made some modifications to the implementation, then released it under a proprietary license.

> So you mean, they don't even use your source code?

They delete the implementation but keep the API. But sure, let's say they deleted 100% of the code just for argument's sake.

> that shares zero implementation details of yours be contributed back?

My opinion is that APIs are implementation details. I completely fail to see why some people are insisting that APIs are not code.

> Another bad side effect of things like this is that potentially things like `Shape` and `sort` become copyrightable APIs.

Doubtful. For one thing, they exist across tons of languages - you can't copyright the work of others.

> If oracle has copyright on Java APIs, that prevents other people from implementing better/other versions of the Java sort function (maybe it's faster, but unstable), you can't implement that.

Not true. Oracle's copyright would not extend outside of their enterprise / separately licensed APIs. If people choose to use those APIs they are accepting Oracle's copyright, which is an obvious mistake that they should avoid.

Copyright is not there to protect you from making a bad technical decision If Java's APIs were all copyrighted the obvious choice would be to not use Java.

Same reason why companies ban using libraries that are AGPL3.

> Why does it seem what way? Like a violation? For the same reason that it would be a violation of my license if they copy/pasted the code and just made some modifications to the implementation, then released it under a proprietary license.

Copyright, historically has only extended to the concrete work in question. Other protections, like patents or trademarks are for concepts. Steamboat Willie is protected by copyright, but generic depictions of Mickey Mouse are trademark protected.

If as you claim, someone can delete all the code but still maintain copyright, that's a fundamental change to how copyright works: it now extends to ideas and concepts, not just things. This has deep impacts due to how copyright works vs. those other things.

Let's talk about some of the weird outcomes:

> I completely fail to see why some people are insisting that APIs are not code.

Well, in Haskell, APIs are built from fundamental mathematical properties. Is `sort :: [a] -> [a]` copyrightable? We don't consider mathematical constructs to be covered by patent, so while a specific sorting algorithm might be patentable, the API wouldn't be. But now the API is copyrightable. So the mathematical construct can be copyright protected. That's weird.

> Doubtful. For one thing, they exist across tons of languages - you can't copyright the work of others.

This fails the Rule Utilitarian test: If we rewound time to the mid 1950s, and set intellectual property law to what you're proposing, someone could have copyrighted `sort`, and `sprintf`, and `malloc` and `cat`. GNU could never have appeared because the APIs that GNU copied would have been copyright protected by the Unix authors.

So that's a big issue. What else?

> If Java's APIs were all copyrighted the obvious choice would be to not use Java.

This is easier said that done, I believe your proposal actually breaks the GPL, because I can fork and add a new API surface to a GPL-licensed piece of software, and then use API-copyright to prevent others from making further changes. So currently GPL software would need to be relicensed under a hypothetical GPLv4 that fixes this loophole.

> Copyright, historically has only extended to the concrete work in question.

APIs are concrete work.

> it now extends to ideas and concepts, not just things.

APIs are things as much as code is.

> Well, in Haskell, APIs are built from fundamental mathematical properties. Is `sort :: [a] -> [a]` copyrightable?

No. sort as an API is both fundamental and preexisting.

> If we rewound time to the mid 1950s, and set intellectual property law to what you're proposing, someone could have copyrighted `sort`, and `sprintf`, and `malloc` and `cat`.

Maybe. But that's fine. Someone would have just written their own APIs and licensed in a way that allowed others to use them - the way all software development has gone for decades.

I'm sure there were many proprietary 'malloc' APIs that ended up going nowhere, and one one cares today. The ability for developers to license the code was in fact a major deciding factor in APIs surviving - I'm sure we'd see many APIs today, given copyrightable APIs.

> GNU could never have appeared because the APIs that GNU copied would have been copyright protected by the Unix authors.

The Unix authors could have granted permission (not saying they would). Just because someone holds the copyright doesn't mean they restrict usage - hence the entire open source ecosystem having developers own their copyright, and how the vast majority release that copyright under a liberal license.

Or, as stated above, someone would have released their own APIs and granted their copyright via the license they chose, and those APIs would be what we have today

> This is easier said that done,

We do it all the time. Companies largely ban some licenses, such as AGPLv3. The same exact thing will happen with proprietary or overly restrictive licenses on APIs.

The fundamental question here is who owns the code. IF Oracle wins, the developer owns the code - this is much closer to how code copyright already exists, but extended to APIs. IF Google wins no one can own that code, developers lose control over their own work.

> because I can fork and add a new API surface to a GPL-licensed piece of software, and then use API-copyright to prevent others from making further changes.

I'm not sure that that's true, but even if it were that doesn't "violate" the GPL, it acts in accordance with the license.

The question here is if licenses we apply to our code should extend to our APIs. Again, developers have more power in a world where Oracle wins, and less power in a world where Google wins.

Further, I feel that things have changed quite a lot. Everyone has been burned by poorly licensed code that has gone stale, and can no longer be modified. Open source has won this fight already.

I am far more concerned about the future, as tech companies grow massive, and consolidate. We already see AWS implementing open source APIs with drop-in replacements. If Google wins you kill any ability for developers to protect themselves against that. If ORacle wins you give open source developers back their greatest weapon (Software licensing), and they can create licenses that restrict the ability for massive companies to reimplement their open source code as a proprietary service.

> APIs are concrete work.

So in the case of an API re-implemented without copying any code, what concrete work is taken? If not the code, then what thing?

> APIs are things as much as code is.

I can print out code and read it. I can't print out an API and read it. (I can print out documentation of an API, which is copyrightable, but I cannot print out the API itself).

> No. sort as an API is both fundamental and preexisting.

What makes sort fundamental but other things...not fundamental? Historically copyright has been pretty straightforward: if there's a physical thing (like a written work, in the case of code) you can copyright it. Now you're adding weird rules like "well some apis are obvious and fundamental but others aren't". Who dictates that?

> Maybe. But that's fine. Someone would have just written their own APIs and licensed in a way that allowed others to use them - the way all software development has gone for decades.

The problem here is that it means that people can, for example, api-squat. Which is terrible. Imagine the ML craze of recent years, but with Google or Facebook or whomever copyrighting the tensorflow API so that other libraries couldn't be tensorflow compatible without licensing to Google. Sure, companies could just not use Tensorflow, but it was like a half a decade ahead of the competition, and had the backing of basically the largest Machine Learning practitioner in the world. An Open Source version could maybe compete, but probably not.

> Again, developers have more power in a world where Oracle wins, and less power in a world where Google wins.

Some individual developers have more power, but the development community has less freedom.

> The fundamental question here is who owns the code.

No, the fundamental question here is if an API is copyrightable. Oracle very clearly owns the code. The question is if the concept of how to do something is a copyrightable work in the same way that actually doing a thing is. A map is not the same as a taxi, and you're saying that the protections we give taxis should also extend to maps all of a sudden.

> I am far more concerned about the future, as tech companies grow massive, and consolidate. We already see AWS implementing open source APIs with drop-in replacements.

But you don't seem to consider that Amazon probably already has an answer to API-licensing.

> they can create licenses that restrict the ability for massive companies to reimplement their open source code as a proprietary service.

No, what you're saying is that companies can restrict the ability for competitors in the same space by building arbitrary lock-in. Companies can already use licensing to prevent competitors from stealing their work, but what you're suggesting is that a competitor can prevent others from entering the space. Consider the opposite situation: Spanner and CockroachDB. If Google decided to license its API, cockroachDB couldn't exist, or at least couldn't compete. Your ideas cut both ways, they don't magically fix things for the little guy.

> Can you please elaborate here? I don't understand what you mean.

> It is already the case that you can not relicense software under and incompatible license.

Yes you can't, but currently in case for example Linux and ZFS and even BSD and ZFS. Programmers were able to use ZFS (note, it is Open Source but under CDDL) by implementing so called shim, that was providing API that ZFS was expecting. Ruling in favor of Oracle will make this illegal.

Even within Open Source it could became a problem, for example FreeBSD implements Linux ABI (it's binary version of API) which allows it to run Linux binaries natively. Depending if the other side is hostile, this might no longer be allowed. Same thing with Wine. The law would prevent interoperability between all kinds of software, that's bad thing for all users, it's already difficult.

> Let's say I write an amazing database. It's open source, and my license dictates that any modifications to the source code get contributed back.

> Someone else clones the repo, guys everything except the APIs, and reimplements what's inside. They then release this under an incompatible, proprietary license.

> Why is that ok? It seems like a clear violation of the intent of my copyright. And it's already what we see AWS doing, so this is obviously a lever that large companies are willing to pull.

First of all, creating a good API is not trivial, but it is nothing compared to developing the actual product. If someone went the effort and create their own database from scratch that someone (especially if it is Amazon) would provide their own API, even today when it is legal to use someone else's.

They would be concerned that having to follow other API would limit them, also it would make it easy to replace their product with Open Source alternative.

You're saying that Amazon is already doing, I'm guessing you mean Aurora PostgreSQL and MySQL. In those instances they are using existing Open Source products and just replaced the storage layer with their proprietary. They can do this, because license permits them already. PostgreSQL license allows for commercial use without sharing code, MySQL is GPL but most likely they paid Oracle for the proprietary license. Ruling in Oracle's favor won't change anything there.

> Depending if the other side is hostile, this might no longer be allowed

It seems like it would be license compatible.

> The law would prevent interoperability between all kinds of software, that's bad thing for all users,

Only between incompatibly licensed interfaces.

> First of all, creating a good API is not trivial, but it is nothing compared to developing the actual product.

It could be, depending on the implementation.

I don't know what your next few sentences are saying.

> I'm guessing you mean Aurora PostgreSQL and MySQL

No. I mean their proprietary reimplementation of Rabbit, Cassandra, and MongoDB.

If your code is floss then amazon or whoever could just fork the code and just use it in their backend. If that is okay with you then why is complete reimplementing it not okay? In both cases customers are directed away from your wallet.

Let’s not go all draconian here. Copyrighting APIs just means you need approval from the original owning entity to do interoperability. Which again comes down to licensing. Why should the creator not own what they create and why should others not be forced to seek approval or license to use it? You might say “but the purpose of APIs is integration! How can they sue people for using it for integration?” But it seems obvious that they would be able to sue people using Oracle DB without license even if they are using it for its intended purpose.

> API design is hard, and interesting,

OK, fair enough.

But plenty of difficult and interesting things are not patentable.

> and it's code just as much as a library is code.

It doesn't execute, so it's not code!

Libraries don't execute either, unless someone wraps them in an implemented program.

And this is about copyright, not patents, right? Oracle has apparently already lost the patent case.

Isn’t that a bit like saying cars don’t drive unless a driver gets in them?

I don't know, is it? I don't like analogies.

This comes down to what is and is not copyrightable. 'Code', whatever that is, very obviously is copyrightable - hence licensing. 'APIs' are now being separated from code by Google to support their claim that they did not violate Oracle's copyright.

How can you own the interface to an implementation? Can someone copyright toString() or appendToKeyValueDataStore() in a given language?

Honestly, given that I literally write Java code for a living and think this case is mega confusing (granted, I've spent roughly 6 minutes reading about it), I am skeptical about the SC's ability to render a sensible verdict. But, meh, maybe it really can be abstracted out a legal principle.

> How can you own the interface to an implementation? Can someone copyright toString() or appendToKeyValueDataStore() in a given language?

How? The same exact way I own copyright to all of the code I write. It's the same exact system.

Yes, someone could copyright those if they weren't fundamental, obvious, and preexisting. The same way that if I write a novel new implementation of a String it is copyrighted under whatever license I choose. The same way that a new codec is copyrighted, etc.

I'm not a legal guy, so I don't know.

It just seems a bit funny that the example you give to point out how obvious this standard must be is an implementation, not an interface. It would be weird to me that if I created a different String implementation with the same interfaces as your, that is prohibited.

I guess that with Java it's a little bit more straightforward, because the interface is a file that you must have created. But what if I create EvenBetterInterface and convince people to swap it out in their dependency injection and use my implementation, which otherwise has the same interfaces as yours? I feel that the interfaces they are talking about are supposed to be more that classical type of interface (a definition/promise with NO implementation details but assurance of functionality), and not the straight up Java (jesus christ, im sorry) "implementation" of an interface.

If it's text it's code. The fact that it doesn't do anything doesn't enter the argument.

1. By that logic this post is code;

2. I just entered it into the argument!

All text is copyrightable including source code and the comment you just typed. In fact when you look at TOS for websites you'll notice that you give an indefinite copyright to works by yourself on their platform including images, posts, comments etc etc etc.

The fact that the code is never executed doesn't enter into the argument.

The argument is whether a clean room reimplementation violates their IP rights.

Java code doesn't execute either. It is compiled to a different representation, and then interpreted or compiled again by a different program. And that binary representation has a translation for `void foo(int a)` just as much as it does for `x = new Object()`.

Even if there were any technical merit to this idea that API definitions are not code, I still don't think it would mean anything. Copyright law applies to human expression, not to code specifcally.

> But plenty of difficult and interesting things are not patentable.

We're talking about copyright, not patents though.

Books, not mouse traps.

Plenty of difficult and interesting things are not copyrightable, too.

> I see massive companies like AWS reimplementing open source projects' APIs with proprietary solutions

This may feel wrong to some, but emulating the API of the famous thing is bread and butter of software interoperability.

Funnily enough, music of all industries is having their own similar "come to Jesus" moment with copyright along the same lines of the Oracle v. Google case.

All code (and music) is math, at it's core. It's a pipeline of transformation functions that end up getting a particular system to do a particular thing (or assortment of alternating musical notes and silence that make up an experience).

The problem comes in that when everyone converges to the same tools and ways of doing things, you end up running into copyright induced paralysis innovationwise. Over time, there is a trend toward "nothing new under the Sun". Once this point is reached, copyright poisons landscape for everyone. No one is free to innovate, because that innovation is dependent on some schmuck who won't just let their copyright die.

The entire bloody concept of copyright is one of the most intellectually destructive forces on the planet. The fact we've entertained this farce this long is testament to humankind's love of the long-period, delayed-activation foot-gun.

Also, to respond even more to your point, API's are meaningless in the end. The Binary is what runs, and all it takes is a pass by a code mangler to fundamentally change the character of code to make it a derivative work.

Will it be as warm, comfy, and human readable necessarily as the original? No. Will the binary generated from it run exactly the same? Yepper. You bet it will. It's part of what makes copyrighting any particular program on a Turing Machine farcical. You don't want me using yours? Fine. Give me a bit to rejigger and reimplement with a slightly different naming convention or approach to optimization.

Boom. Equivalent functionality, completely different source code. Almost as if computer code were some sort of mathematical construct.

We cannot afford to maintain this litigious stature when the means of production and innovation exist in everyone's hands. It's not a case of one company trying to get one over on another. It's a case of a handful of people stomping their feet and saying "How dare you put in the work to make me irrelevant! Someone force them to pay me!"

We need to cut the time of copyright, and leave enforcement of it alone, or we need to seriously weaken the enforcement severity if we're looking at fundamental technological building blocks getting locked away behind the threat of an angry legal department.

And no, in case anyone is wondering, anything I write for myself, I pretty much just implicitly release to the public domain. I don't want to have to solve the same problems over and over again, just slightly different and for a different boss this time; nor do I want anyone else to have to.

> The entire bloody concept of copyright is one of the most intellectually destructive forces on the planet.

What if somebody accidentally leaves their personal diary on a park bench. A finder quickly locates the author and returns the diary, but not before they make a copy, which they're about to publish to the world. Is that okay? Should the author not even have a right to control public disclosure--that is, a right of first publication?

Don't go leaving personal diaries on park benches. Especially when legal action has non-trivial chance of exposing the contents as a matter of public record anyway.

And regardless, that is a substantively far cry from how Oracle is trying to employ copyright. The Java API's are no mere diary left on a bench that the evil Google has taken to publish and profit from.

Think of the precedent this would set. You'd open the door to never being able to right the Pair<K.V> API in any form. Oracle owns it. Sorry. You weren't the first to write it.

You'd open up a gold rush scenario. Imagine someone writing a generator, or going and publishing micro-API's doing nothing but squatting on the most logical or attractive signatures, structures, and ergonomics that everyone would converge toward or independently rederive. It'd be like domain squatting, but absolute leagues worse. You'dactively degrade the ability to innovate and write easily readable code all because you wanted to treat an interface as something you should be allowed to lock the rest of the world out of.

That's insane, pure and simple, and makes a mockery of what copyright was intended to actually do.

To go back to your journal on a bench example; I'd be willing to accept a right to protest over the unintended publishing of a creative given the caveat that it not in any way be extended to anything that has to with source material for executable code, or anything that is broadly reducible to math. I even grant this reluctantly, because you're still enshrining the same artistic time bomb if you don't enforce strict, and shorter time limits to the copyright term, or the specific aspects protected by it.

Copyright was intended to incentivize creative work (I.e. the process of doing the creative work) not to create a framework whereby upon compiling a large enough basis of creative works as intellectual property an entity with a sufficiently funded legal department can shut down or render perilous the landscape of creative endeavor simply by virtue of everything having been seen/done in one shape or another before. The legal system, and corporate portfolio's in particular have created a situation where entire generations of people can come and go without being able to reintegrate and iterate on older experiences.

We communicate and perpetuate our understandings, mores, and common experiences in our time on earth through these activities; the risk and cost of freezing out our descendants ability to practice by stripping them of the very giant's shoulders on which we were ourselves placed upon our arrival into the world is real, and even today is fundamentally changing the shape of the field as we are now more than ever concerned with trying to wring as much as possible out of the smallest crumb of similarity.

I'm probably edging into rant territory at this point, but while I recognize valid interest in enforceable copyright your example represents, I cannot accept Oracle's assertion that their Ali's would constitute the same phenomena in kind, or that it is right to have any creative work locked away for a lifetime. The experience, takings away, and derivations of the audiences it influences should hold the same level of sanctity as the original work. Especially if redone independently or utilized in a novel way.

Reply on news.ycombinator.com