The Electronic Frontier Foundation (EFF) filed a brief with the Supreme Court of the United States today, arguing on behalf of 77 computer scientists that the justices should review a disastrous appellate court decision finding that application programming interfaces (APIs) are copyrightable. That decision, handed down by the U.S. Court of Appeals for the Federal Circuit in May, up-ended decades of settled legal precedent and industry practice.
Signatories to the brief include five Turing Award winners, four National Medal of Technology winners, and numerous fellows of the Association for Computing Machinery, IEEE, and the American Academy of Arts and Sciences. The list also includes designers of computer systems and programming languages such as AppleScript, AWK, C++, Haskell, IBM S/360, Java, JavaScript, Lotus 1-2-3, MS-DOS, Python, Scala, SmallTalk, TCP/IP, Unix, and Wiki.
You can always count on the EFF to do the right thing.
Agreed, you can’t to wrong with the EFF. I donate to them every year.
I’m not sure I agree so much. Overly broad software patents are one thing, but an API is another. To explain what I mean, let’s say I create a new platform with a robust API that developers like, so they start developing for it, which attracts a lot of users to the platform. And then some other company starts up a competing platform, and instead of having to design their own API, they leech off of my design, so that they are 100% compatible with mine, or very close to it. As a result, I lose a substantial amount of business to this other company.
I suppose a good argument could be made that this sort of thing is good for competition, but it’s a HUGE kick in the balls for those who spent the money and took the time to design the API in the first place. You can’t say ‘well, it’s good for end users’ when it sucks ass for the creators.
An API isn’t really just some implementation specification, it is the very heart and soul behind a platform. It is what makes the whole thing unique. And you just expect people to give that away? If you’re going to rip someone else off wholesale like that against their wishes, you should at LEAST be paying them for the privilege. If you ask me, it smacks of this entitlement generation we live in that expects to have everybody else’s shit for nothing.
Copyright is mostly about copying “things” (and not about copying ideas/inventions). If you have a document or book describing an API, then that document or book should be covered by copyright. If you have source code for a piece of software that implements an API, then that source code should also be covered by copyright.
Patents cover ideas/inventions (and not things). You should not be able to patent documents, books or source code because they are things and not ideas/inventions.
An API itself is an idea/invention and not a thing. You should not be able to copyright it. You should be able to patent it (if it’s new and not obvious).
However, normally you’re accessing “potentially not obvious” algorithms via. a very obvious API. In fact the API is often an extremely obvious list of inputs and outputs needed by the “potentially not obvious” algorithms. This means that while an API should be patentable in theory, an API should almost never be patentable in practice.
Wrong. It’s the algorithms that you access via. the API that are the heart and soul behind the platform.
– Brendan
Really? So if algorithms are the things that really matter and the APIs are obvious and inconsequential to the success and uniqueness of a platform, why not just make your own API then, instead of trying to leech somebody else’s? Obviously, 77 different computer scientists think specific API implementations are kind of important, and I don’t happen to think something so important should be forcefully taken away from the original implementer and given to every Tom, Dick, and Harry that wants to use it in their own stuff.
Note: I’m NOT saying that there shouldn’t be standards, just that somebody who wants to keep an API to themselves, that they themselves created (or bought from someone else) should have that right.
Edited 2014-11-09 02:11 UTC
APIs are important for interoperability (e.g. allowing fair competition between competing implementations).
If someone creates a competing implementation without violating the original author’s copyright and without violating the original inventor/designer’s patents; then neither the original author nor the original inventor/designer has the right to prevent competition.
Please note that the copyright system and the patent system are both designed to benefit consumers – e.g. increasing the number of different books, pieces of software, etc. that consumers can buy (by encouraging authors to write new things, by ensuring authors can make profit from writing new things), and increasing the number and new inventions consumers can buy (by encouraging inventors to invent new/innovative things by ensuring they can make profit from them).
Neither copyrights nor patents are intended to benefit companies. Any benefit to companies is just an “accidental” side-effect of the desire to benefit consumers.
If you ask me, attempting to abuse the copyright system to prevent fair competition (e.g. by allowing APIs to be copyrighted) smacks of this entitlement generation of companies that expects to have a monolopy for nothing.
– Brendan
Sorry fella, but are You for real?
Judging merits for the looks?
Copyright is about protecting CREATIVE works.
That is USA/EU stance at least.
Its not about copying.
API is not creative. Its public domain. Like phone numbers.
Correct.
“image.isCat” is an API.
The algorithm to work out if an image has a cat in it is the implementation and is not something easy to copy at all.
It’s nonsense to think that an API reveals the inner workings of the implementation.
Or you can tell things this way :
Imagine two stores, both selling basically the same things. Or not. Yet both of them have rectangular shaped doors that opens automatically when someone come close.
Would store one sue store two for having the same door shape that grant access to the store’s furnitures ?
Kochise
Boy, I wish I had read this before I replied so I could upvote you. Best explanation, hands down.
You must be new here:
http://appleinsider.com/articles/14/07/10/apple-store-design-and-la…
Wonderful news. What’s the next step then, Apple patenting being gay and their “back door” as an API ?
Seriously…
Kochise
Unless, of course, you’re a terrible programmer, something of which there seems to be no shortage.
An API is nothing more than an abstraction for the implementation. Some APIs have a higher level abstraction that allows multiple possible implementations, while others are tightly fit for a specific one. Either way, they both put very specific limitations to how an implementation could work.
Take the C++ std::vector<T> as an example. While it doesn’t directly state how the memory is stored, there is really only one sensible way of doing so: as a single allocation. Everyone that uses vector assumes this is how it is implemented. In C++11 they even took the consequence of it and added a data() function that can give you the pointer to the data.
Are you saying it was a terrible programmer that designed the C++ vector class?
Edited 2014-11-09 15:14 UTC
The problem with the std::vector example is that it’s clearly designed to be a runtime safe version of dynamically allocated arrays. That is not so much an API as it is a fundamental building block of programming. It is a thin wrapper over a raw array. Even though it has the syntax of an API, it is not actually much more of an API than a raw array with an accompanying length variable is.
Also, it is not an assumption that a vector is allocated singley. It is a requirement by the standard that it is a contiguous area of memory with constant access and linear insert, copy and erase, but that could just as well describe a memory pool, if the allocator uses one. So you can’t even assume that it uses the freestore unless you guarantee it uses the standard allocator.
Now with std::*set/map, those are less transparent about how they work internally. They could be implemented as trees or lists or arrays.
Yes, it is designed to fit a specific purpose, like any API. Just like half the classes that Google grabbed from Java.
Yes, but the constraints effectively binds the implementation to only a few realistic choices. All APIs suffer from the law of leaky abstractions and while I chose a rather low level example the thing really applies to any type of API. It is why it is impossible to create a cross platform API that doesn’t succumb to the lowest common denominator.
Also keep in mind that actual chosen implementation matters. That is why there is both a vector and a list, because you really do want to make a specific choice in those situations. The same thing applies to higher level APIs, like where a vertex buffer is actually allocated in OpenGL, or what the flushing guarantees are in a file API.
And the leaky abstraction of that choice means you can’t know how your program reacts in high-performance situations if you constantly build a map from scratch.
I think it is wrong to state that APIs are only ideas or that APIs and implementations are completely distinct. They are almost always designed together, even when expressing higher level abstractions than the vector example. The intended/assumed implementations do leak into the API design.
Personally I think it is best to compare APIs to file formats. Both require a lot of work to do right and neither should be copyrightable because doing so would create too many unreasonable barriers.
I’m completely at a loss at what you’re trying to argue. Do you think I’m arguing FOR copyrighted APIs or AGAINST copyrighted APIs?
Actually, as far as I know, you should not be able to patent API’s either. Abstract ideas cannot be patented, only implementations of them, which, in the software industry, is basically the same as copyright. Except patents are broader and don’t even need to be “copied” to be infringed, which is what makes them so dangerous.
No one “designs” API’s though. The API is an expression of the underlying functionality. The actual design is the functionality.
As you’re posting this on the internet you’re using software which uses some form of sockets implementation which in turn implements a BSD Sockets API, by the way.
So the APIs just happen to appear out of thin air?
Let me repeat: the API is an expression of the underlying functionality.
Edited 2014-11-09 02:26 UTC
WorknMan,
I disagree. Competing can be tough, but it’s a necessary element of a healthy free market. All too often when companies rely on vendor-lock and/or natural/artificial monopolies, their focus shifts from producing genuinely competitive products to designing restrictive products to block competition. We’ve seen this time and time again where big software companies add restricts to intentionally cripple the free market.
Copyrighted APIs, to the extent that they would ever have serious enforcement, just encourages more of the bad business models based on vendor-locking.
Consider how we allow unauthorized vendors to supply 3rd party car parts, vacuum cleaner bags, camera batteries, etc. If a brand name company starts significantly overcharging consumers, then the free market will kick in. We can and will choose alternatives. This is *good* because it helps keep companies honest and it encourages them to invest improving their products. Usually companies can still charge a premium anyways just for having “authentic” brnading, but if the competition is taking away a company’s market share, then maybe the company needs to work on being more competitive.
Edited 2014-11-09 02:25 UTC
Everyone wants a free market and competition….until they’re not the small underdog anymore.
Soulbender,
That’s a great point. It may be true in all industries. However I think our policies should lean on the side of free market competitiveness. It should never be the government’s responsibility to favor corporate “top dogs”, their influence should not be disproportionately amplified. This being said, government representation here in the US is hugely skewed.
Edited 2014-11-09 16:05 UTC
Short answer: don’t make programming tools your cash cow by using lock-in. It’s evil. Making APIs non copyrightable is exactly what’s needed to make such scenarios less likely.
Not everything you do can be copyrightable. For example, song titles on a music album. I really like the interoperability argument against copyrighting APIs, but there’s another one: simplicity. APIs are usually extreme obvious words.
If APIs were copyrightable, what would happen to the following example of an API?
File.open()
File.close()
Se what a mess it would quickly become?
I was thinking of IBM, myself; they could sue pretty much the whole world for infringing on their BIOS APIs. That’d be pretty much an instant death-sentence for all of computing in the U.S.
Except the courts had already ruled very much in favour of Compaq at the time and the concept of clean room reverse engineering. That’s the precedent that is set, which is one of the strengths of precedence in English Law.
* Yes, technically, precedence is not set in stone even in English Law, but it has huge weight.
What You describe already happened.
You wont see Amazon/Google/MS fighting each other in courts over same APIs.
Its that silly.
APIs serve as a mechanism to enable software inter-op. You have to have software that does something in order to have a product that people want to develop for. I’m not saying an elegant API isn’t a valuable feature, it is, but in and of itself it has no independent value to you – it is the product or service you offer that has value.
You say someone creating a work-alike to your product (i.e. same API) causes you to lose a “substantial amount of business” to them. Why? The API is exactly the same – so why would anyone leave you?
The answer obviously is that some other aspect of said product is either done better by your competitor or they have simply marginalized you on price. But that has nothing at all to do with the API being the same – all that did was make it possible for them to compete with you on equal footing.
And that is important… Your right, a good API attracts developers. But they put time and energy into writing software for it. It’s their software, not yours – you should not be able to hold their work hostage by virtue of a copyright that artificially ties the value of their work to yours.
If you offer a good product/service, support your developers properly, and price things fairly, it doesn’t matter if someone copies your API… It would only matter if you are failing to do those things. Sure, it creates opportunity for competition, but that is the point – your supposed to compete.
In short, being able to copyright APIs is a protectionist concept that has no logical foundation. It essentially only protects poorly performing products (otherwise the protection offered is meaningless) and it devalues the work of others – there is no upside to it at all.
It’s not a question of ‘leaving’, but if somebody comes out with a product that uses the exact same API as mine, if devs can port their code over with very little work, why wouldn’t they? You could make an argument that this is ultimately good for competition, but the end result is that the original creator is taking it up the ass, which is not necessarily good for innovation. Not only is it a dis-incentive to create something new when your competitors can just piggyback off your design, but if everybody copies each other, it’s just same old, same old.
Does it make it harder for your competition to get a leg in the door if they can’t copy your API wholesale? Maybe, but that’s kind of the point, isn’t it? Is that a bad thing? Well, depends on how you look at it …
I remember in the 90’s and early 00’s, there was a lot of whining – ‘OMFG, Windows is too big… we can’t compete with that. M$ needs to be split up!’ So in that instance, what do you do? Instead of taking on Microsoft head on, you do what Apple did by creating something that nobody has ever seen before, and you sneak in the back door. It kind of forces people to think outside of the box more, instead of just copying something that somebody else has done. Think about this for a minute… if MS had been split up and the desktop market was wide open, it is entirely possible that neither iOS or Android would exist today.
I guess what I’m saying is I’d rather see new platforms succeed by being innovators instead of, ‘well, they use the same API as this other guy, so I might as well port my shit over….’, and then you have a bunch of ‘me too’ products.
WorkMan,
Why shouldn’t they? Instead of speaking theoretically, why don’t we ask this in terms of concrete examples:
ReactOS uses the same win32 APIs as Windows, yet Windows is still extremely popular because it turns out that implementing the API is non trivial and MS still has tons of competitive advantages despite the fact that ReactOS uses the same API. Using a compatible API helps break down barriers to entry, but it doesn’t automatically translate to market share. MS still holds many advantages and ReactOS still has a lot of work to pose a significant threat to MS.
Android’s success is due to the demand for smart phones rather than the demand for Java. I think a Sun/Oracle authorized JVM could have been successful as well, but here’s the thing, neither Sun nor Oracle were filling that market void. At best, third parties were releasing J2ME feature phones. Apple and Android came in with their own modern smartphone implementations and took control of the market. Android didn’t have to use the Java language, I’m not sure which other languages were candidates? But if a company wants to implement their own toolchains for a language, then I think it’s reasonable for them to do so.
Say I’m building a new managed code OS for which there is no JVM, yet I want to be able to compile existing C# and Java applications to it. Asserting that there’s no merit to this is plainly wrong, yet I might never get explicit permission from MS and Oracle to build my own implementation. Reality is compatibility plays an extremely important role in breaking down barriers to entry. With no users, developers won’t be interested, and with no apps, users won’t be interested. By implementing the same languages and class libraries that are already popular, that gives us a way to break into the market. It’s still not easy of course, but it gives us a chance to overcome market barriers and compete. But even once we do that, we still have to have a plan to actually attract mindshare.
Edited 2014-11-09 17:20 UTC
Well, imagine is POSIX was not a standardized API. Because POSIX is nothing much than that, and Linux couldn’t have been successful by preventing it from porting applications to it. Even though Linux (or Minix) are NOT Unix, they do have some sort of compatibility.
Opening a file, seeking a pointer and closing the handle should be patented ? I can understand the FAT might be, even though it’s just a way to lay files onto a disk, but frankly, there are things that deserves being patented, not APIs. Really.
Imagine if all car makers have to put the gear, brakes, pedals at other places so that drivers couldn’t switch brand. That would be a real mess, just like we had in computers during the 90’s where hardly nothing was standardized. Not even the HTML with IE.
Please reconsider your weak position about APIs.
Kochise
Well, if it used the exact same API, there would be no porting involved I would think – their software would “just work”…
So the question should be would users of said software use your service or the other service? And the answer is obvious, they would use the one they found to be better/cheaper/faster/whatever – their choice would have nothing at all to do with the API because it is the same…
No, the original creator is not “taking it up the ass”. All the original creator has to do is compete – which is the whole entire point of free markets. If you create a wonderful API for your service, good for you – now it is your job to develop a good reputation with your users and developers so that you can leverage that first to market advantage and position yourself as a company worth sticking with. THAT is how you suppress competition, by competing.
But your competitor is not piggybacking off your design. Your competitor doesn’t have your design – your design is your actual implementation. Your API is just how the world interacts with it.
You are conflating two entirely different things. Software and books are quite different, but a good analogy of an API to books is printing words on paper, or EPUB format, or PDF, etc. etc. Those things are the “APIs” of books.
The difference with software is that every implementation of a “thing” generally needs a unique API to have the world deal with it logically. If two “things” do roughly the same thing, it is possible for them to share an API, but when they are inherently different they can’t.
If I want to compete with you (do the same “thing”) why should I be forced to fragment the market of said thing just to protect your business? Competition is between things, not between ways to talk to things…
That’s ridiculous. Most things we call standards now started out life as some company or another’s API for some “thing” long ago. BIOS, Posix, ANSI, ASCII, etc. etc. Are you seriously saying that because markets formed around them and they became standards that innovation was hurt? Really??
Read my other post. The problem with this is it ignores that you are affecting other people’s products too. The world doesn’t revolve around your company – if you make an API you are by definition inviting the world to take part in it – they have rights too.
ps. Thank you for posting a alternate viewpoint. Even though I do not agree with you at all, if everyone agreed about things this forum would be very boring
The problem with your argument is that the API itself does nothing.
What makes it unique is what happens behind the API, not the API itself.
If you ask me, it sounds like you don’t now much about software design and development.
Nonsense, it is by it’s very definition just an interface to functionality, and the specific implementation of said functionality is what can be copyrighted since it is actually the ‘heart and soul’.
What you are trying to claim is that you could copyright the idea of ‘a novel where a detective solves crimes committed with hunting knives’, which of course you can’t, it doesn’t matter how creative you think that is or how much ‘hard work’ you spent in coming up with it.
You can however copyright the actual story you write about a detective who solves crimes commited with hunting knives.
definitions like:
strcpy(destination, source)
is not and should not be copyrightable, which is what Microsoft and Oracle is now trying have them be, all in order to extort money and further vendor lock-in strategies.
Not really, it’s more like copyrighting a specific story. For example, let’s say I write a book about a killer named The Sporksmith that disembowels people with a wooden cooking spoon. And then you come around and write a book that is the exact same story with the exact same character names, but you just rewrote it in your own words instead of copying mine verbatim.
No, that would be the actual implementation. API is, as others have said, the general idea and the actual contents, ie. the code that the function actually does or the actual words in a book, is the implementation.
An API is more than just a ‘general idea’. It is a very *specific* set of function names with parameters and data types that the functions except, under a *specific* set of assemblies. That is why I mentioned copying specific character names and plot points without copying the words, instead of just copying the general story idea.
Let’s say I wanted to rewrite the book ‘The Wizard of Oz’ under a different name, and I used a character named Dorthy, who walks down the yellow brick road, where she meets the Scarecrow, Tin Man, etc. But instead of copying the exact words of the book, I wrote my own. In other words, I copied the design, not the implementation. Should I be able to do this? And if not, why not?
Edited 2014-11-09 16:57 UTC
Yes, you should.
It depends, Werecatf. If the plot is too similar, or the characters are too similar, it will infringe even if the words are different. As far as US law is concerned, the classic statement is Learned Hand’s ruling in Nichols v Universal Pictures Corp. The key paragraph:
Here’s a link to the decision:
http://law.justia.com/cases/federal/appellate-courts/F2/45/119/1489…
Actually, the API would look more like this:
print_title(title as string, format as format)
character_introduce(story as string, character as character)
place(whole bunch of other properties…)
meet(character1 as character, character2 as character, story as string)
..and of course the related API’s for string, format, character, etc.
And the API wouldn’t be in a specific order and you wouldn’t have the original story. You would just have a whole bunch of building blocks that you know someone used to build a great story
(Example of an API: https://docs.oracle.com/javase/8/docs/api/)
No, it would be closer to you writing a novel split into 20 chapters, and you publish your book with a Table of Contents that lists the chapter numbers, names, and page numbers.
Then someone comes along and writes a different book, with different characters, a different title, a different setting, but using the same Table of Contents.
Completely different books (implementations), but same ToC (API). Should be completely legal (and it’s how most Harlequin romance novels are written).
It’s not the API design that is bringing you in the money but your ability to deliver working functionality.
Courts have long held that APIs are not copyrightable – that you can’t copyright declarations (C/C++ headers), only functionality (C/C++ implementation files).
That is the crux here; and the industry has long relied upon that.
In fact, your exact description is how Microsoft took on the existing DOS vendors in the 1980’s – they made APIs that were close enough to be passable for other versions of DOS so that things ran on their version of DOS, then later introduced subtle differences after they captured enough market share to force people into supporting only their version in the EEE ways.
APIs are just the interface definitions. They do not provide any functionality; so no – they are not the “heart and soul behind a platform”; and they do not make any “whole unique thing” – if they did, they’d be providing functionality, not APIs.
So what you really have is you have APIs and API implementations. APIs are not copyrightable, but API implementations are, and the courts have long differentiated between the two.
The courts have also held, btw, that a network-based API – e.g. network communications – are not copyrightable either as they are just ‘interfaces’.
An API is nothing more than a Table of Contents that lists what a platform can do, but without actually listing *how* it’s done.. It’s just plain facts, and plain facts aren’t copyrightable.
Anyone can take a Table of Contents from a book, and write their own book using that as a template, without infringing on anyone’s copyrights. The ToC isn’t what’s important … it’s the content of the individual chapters that’s important.
Similar to recipes. You can’t copyright a recipe, as it’s nothing but a list of ingredients and a list of steps (bare facts) for cooking a dish. You can copyright a cook book, though, with all the images, and stories about the recipes, and embellishments to the steps (using fancy cooking terms). But the bare recipe isn’t copyrightable.
An API is nothing more than a list of function names, parameters, and return values. It’s a list of bare facts, nothing more. It shouldn’t be copyrightable.
The actual code that implements each of those functions, that’s copyrightable. And any publication that lists those APIs along with information on how to use them (aka a programming manual) is copyrightable. But the actual list of functions? Nope. Nothing more than a list of ingredients for cooking a program.
I think we can meaningfully decompose this: an API consists of a conceptual design of the software, and also the specific names/identifiers chosen.
The former is (kinda) the realm of patents, and the latter is (kinda) the realm of copyright.
If we allow the second component to be protected by copyright law, but disallow patent protection of the former component, then a trivial wrapper or preprocessor is all that separates the original API and the rip-off one. It would therefore be rather pointless.
Personally I think it would be overstepping things to allow patenting of a software conceptualisation.
I might be committing the slippery slope fallacy, but: another issue is how you’d draw the line. Would Trolltech get a patent on the signals/slots idea? If so, would they own the ‘observer pattern’, which is essentially the same core idea?
Allowing APIs to be copyrighted could mean LGPLed APIs would become the only safe way to use an API, since you are guaranteed that you are allowed to use the API under the terms you were given and you are not allowed to prevent others from using the API.
LOL.
APIs are public domain or equivalent.
EVERYWHERE.
Adding any restrictions is just that, adding restrictions in place where non where before.
Code can not be left in public domain. Cause there are some countries that have no such notion.
With API? Up until now, nobody cared. Like in, nobody thought to hire layer for such case. There was no “case” at all.
Not if the courts’ ruling says otherwise. It’s very much up in the air now, after we all thought it ended with Judge Alsup, the only person who seemed to understand what APIs actually are.
kwan_e,
Good point, most judges don’t understand the first thing about software development, yet they are never the less in the privileged position to hand down decisions that impact us all.
As is often the case, european governments have ruled differently than US counterparts:
http://www.zdnet.com/blog/btl/e-u-court-rules-programming-languages…
The SAS case is covered here as well:
http://www.out-law.com/en/articles/2013/january/computer-programmin…
I’d like to better understand the underlying cause of these differences; Is the EU less susceptible to corporate corruption? Is there broader representation? Is it simply a difference of culture? My impression is that these differences do not stem from the software developers themselves, so what prompted such a wide divergence in terms of government policy?
Edited 2014-11-10 05:23 UTC
If I understand correctly, Google only copied the function names. The underlying implementation was rewritten (different code). They can rename them but it it would break compatibility with existing software.
Developers will have to port their applications to the new APIs which isn’t impossible but it appears Google is trying to keep things familiar and attracting Android developers.. This makes me feel that Oracle is not really being protective of their API names but they are trying to damage Android development.
If what Google is doing here is illegal, then Wine and ReactOS are also illegal since it uses non-Microsoft code to provide APIs with the original names Microsoft used to allow Windows applications to run.
Edited 2014-11-09 09:45 UTC
Oracle is just annoyed that Android took over the market so manufacturers no longer have to license Java ME for embedding into phones.
So yes, it did have a direct impact on Sun/Oracle. But (unfortunately for Oracle) is was blessed by Sun (court case had public quotes from Schwartz essentially blessing it via his corporate blog which was listed in their SEC filings; Oracle tried to counter with Scott McNealy saying that the blog wasn’t official company stance, but McNealy was not in charge, and the blob was noted as being so in their SEC filings). So Oracle is fighting for real money, but they’ll likely lose in the end – too much industry reliance on the existing rules on such a fundamental thing for the industry that the May 2014 ruling likely won’t stand.
If you look at the parties filing with Oracle, you’ll be able to figure out a clear motive too.
What Wine/ReactOS does may actually be considered illegal; but then, that’s why the core dev team (AFAIK) is out of Russia. 😉
This is why the US will lose it’s technological edge in the long run: overprotectiveness in the name of profit maximization.
APIs aren’t that special. I contribute to an open source reimplementation of a commercial OS, and although a lot of the APIs are badly designed, we copy them anyway for the sake of compatibility. I.e. it’s all about interoperability, not appropriating someone’s “brilliant API design”.
For those of you arguing that the API is the substance of software, i challenge you:
I give you a list of APIs that my program uses, you describe what my program does.
I guarantee most of you won’t have a clue.
That says more about your ability (or lack thereof) as a software developer than it does about the merits of copyrighting APIs.
I think people here are taking too extreme a stance and advocating for a dangerous precedent.
While the pedants here will point out that APIs are a concretion of an abstract concept, there is still a very real degree of creativity that goes into the structure, sequence, and organization.
API design is a thing, and programmers who interface with cruddy APIs understand this all too well. I’ve read too many crummy vendor manuals at work to know that not all APIs are made the same.
Creating a concise, flexible, and intuitive API is not easy and certainly not something that yoyu divine purely as a result of the functionality of the program.
Now, some of you might argue from a “greater good” standpoint, and that makes sense — but in my opinion there needs to be a balance.
I’m sorry, but the dangerous precedent was the decision of the appellate court… This has been settled law for decades. The idea that you can copyright an API was considered ridiculous prior to this case, because everyone knew you couldn’t. From the EFF brief:
Don’t pretend that APIs being exempt from copyright protection is a “dangerous precendent” – it is how it always has been.
I think that is debatable, but whatever – personally I don’t thing the argument hinges on them not being creative. Just because something is creative does not mean it automatically deserves copyright.
Typefaces can not be copyrighted in and of themselves, and they are creative works. Until 1992 they couldn’t be copyrighted at all. An exception was made for digital fonts in 92, allowing them to be copyrighted in effect as software works, but the font itself (its design) is still not eligible for copyright independently.
Why? It is summarized quite simply on Wikipedia:
API = Same thing. They are utilitarian in nature and serve a function that is more important than the rights of the author. The API’s users have rights too that need to be considered. That is the exact argument the EFF will make, as well as the multitude of prominent and respected professionals in the field who are backing them in this.
There already is a balance, that is what frustrates me about this whole thing. By virtue of having created it in the first place, a company has an absolutely huge advantage over their competitors. And there is that something behind the API called software that is copyrightable, usually something quite complex. At some point companies need to stop looking to the government to protect them and just f–king deal with reality – first to market gets you a huge head start, but its up to you to keep it.
Eventually if you do a shitty enough job someone is going to think they can do it better. They should be able to try without having to make everyone else start over from scratch too.
ps. A while back I told you this decision would end up in front of the Supreme Court, well here is how it starts. I said a lot of industry people would not settle for this, and here they are. I’d bet money they will hear this case, and this decision will be overturned. Wanna wager?
Edited 2014-11-10 13:46 UTC
galvanash,
+1 from me, very well said. I didn’t know about the typeface history. It’s pretty obvious to me that the dangerous precedent is the new one in the appellate court overturning decades worth of practice.
You are more confident than I am, we have a sue happy culture, overruling the appellate court would put a damper on things. /sarcasm
Oracle is not thinking very far ahead on this matter.
First, Java is designed to overload APIs, which is pretty much copying the API and using it. So how can they now claim copying the API is illegal?
Oracle makes most of their money from their database software which implements SQL, owned by IBM. Are they really arguing that they are stealing from IBM?