14 ms·
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, an
by staticassertion 7y ago
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.
- joshuamorton 7y agoIt goes both ways. WINE is a free implementation of windows apis. After an oracle win, widows could sue to stop development of wine.
- staticassertion 7y agoBut it has always gone both ways with software licensing.
- takeda 7y agoCopyrighting 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.
- staticassertion 7y ago> 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.
- nitrogen 7y agoWe 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.
- ChrisLomont 7y agoThose 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.
- raverbashing 7y agoBecause 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.
- BurningFrog 7y ago> 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!
- staticassertion 7y agoLibraries 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.
- jl6 7y agoIsn’t that a bit like saying cars don’t drive unless a driver gets in them?
- staticassertion 7y agoI 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. 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.
- yaitsyaboi 7y agoHow 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.
- salawat 7y agoFunnily 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.
- wahern 7y ago
- int_19h 7y agoAPIs 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.
- boublepop 7y agoBooks are protected even if they are not innovative, programs are protected even if they are not innovative. Why should interfaces not be?
- dbtx 7y agoReferring 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 https://news.ycombinator.com/item?id=22002272
- jayd16 7y agoIf 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.
- paulddraper 7y ago> Unless you think things are a disaster now Reread the comment, like "I see a far more daunting problem."
- terminaljunkid 7y ago> 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.
- Chris_Newton 7y agoA 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.