Why Making APIs Copyrightable Is Bad News For Innovation
from the this-is-a-big-problem dept
Following last week's terrible ruling from the appeals court of the Federal Circuit (CAFC), a lot of people have been trying to dig into what this would mean if it stands. As we mentioned, this is far from the end of the line. Google can (and will) seek a reversal, either from the entire CAFC or the Supreme Court. And even if that is rejected or fails, the case still goes back to the district court level to determine the fair use question (which will then see its own series of appeals). In short, this is not even close to being settled yet -- which means many, many, many millions of dollars in legal fees are going to be tossed around before this is settled. That, alone, is a mess for innovators and entrepreneurs who are in a state of flux given the situation.But, rest assured, if this ruling holds, it will be bad news for innovators. Over a year ago, Sacha Labourey had a good explanation of what's at stake here:
APIs exist for a reason: They act as the communication channel, the lingua franca, the boundary, between the provider of the implementation and users of that implementation — developers. Of course they require an investment to create. Deep expertise — and even taste — is required to create effective APIs. But, companies and individuals make those investments because they want developers to use an implementation that is exposed through the API. That implementation might give people an incentive to buy your hardware, software or services. Who knows, maybe it gives you a more effective way to sell ads.In other words, properly recognizing that APIs shouldn't be covered by copyright benefits everyone, as it makes people programming on your platform more valuable since they have more options and more flexibility. The big companies who don't like this are being short-sighted. They're trying to lock in developers, by forcing them to only develop for their platform, but in doing so, are inherently making their own platform less valuable. If innovators can easily write for multiple platforms, the network effects apply across all of those platforms.
You make some bets when you create an API, but they’re not about monetizing the API. They’re about monetizing the things the API unlocks access to. You’ll find APIs documented and used in many books, blogs and open-source projects. Adoption is probably the key measure of success of an API. But then if you encourage developers to use your APIs, why can you prevent them from implementing “the other side” of them? When Captain Picard orders a “Tea, Earl Grey, Hot,” at the Oracle replicator, he’s using a kind of API: “Object. [Qualifiers...]”. Google or anyone else should be able to create their own replicator without Oracle insisting they use some other syntax.
Oracle lost in their attempt to protect their position using patents. They lost in their attempt to claim Google copied anything but a few lines of code. If they succeed in claiming you need their permission to use the Java APIs that they pushed as a community standard, software developers and innovation will be the losers. Learning the Java language is relatively simple, but mastering its APIs is a major investment you make as a Java developer. What Android did for Java developers is to allow them to make use of their individual career and professional investment to engage in a mobile marketplace that Sun failed to properly engage in.
The folks over at EFF properly note that this kind of freedom is truly important for innovation:
What kind of litigation and what kind of mess are we talking about? Tim Lee, over at Vox, has some ideas:The implications of this decision are significant, and dangerous. As we and others tried to explain to the court, the freedom to reimplement and extend existing APIs has been the key to competition and progress in both hardware and software development. It made possible the emergence and success of many robust industries we now take for granted—for mainframes, PCs, workstations/servers, and so on—by ensuring that competitors could challenge established players and advance the state of the art. In other words, excluding APIs from copyright protection has been essential to the development of modern computers and the Internet.
When programmers can freely reimplement or reverse engineer an API without the need to negotiate a costly license or risk a lawsuit, they can create compatible software that the interface’s original creator might never have envisioned or had the resources to create. Moreover, compatible APIs enable people to switch platforms and services freely, and to find software that meets their needs regardless of what browser or operating system they use. The freedom to reimplement APIs also helps rescue “orphan” software or data—systems whose creators have either gone out of business or abandoned their product in the marketplace.
Today's decision puts all of that at risk, potentially handing Oracle and others veto power over any developer who wants to create a compatible program. What is worse, if today's decision is taken as a green light to API litigation, large and small software tech companies are going to have to divert more and more resources away from development, and toward litigation. That will be good for the legal profession—but not so good for everyone else.
One good example is the open source project Samba. It was created to allow users of open source operating systems such as Linux share files with Windows users. To do that, the Samba programmers reverse-engineered and then duplicated the functionality of the Windows file-sharing system. They didn't copy any Microsoft software; they simply duplicated the sequence of commands needed to transfer files, read the contents of folders, and perform other functions in the Windows file-sharing system.Meanwhile, over at the Disruptive Competition Project blog, Jonathan Band, delves into the many, many ways that the CAFC appears to have totally misread the historical precedents that bind the court. But, even worse, he notes that many innovators and programmers have relied on those precedents for years -- and now all of that work is thrown into doubt:
Samba has become hugely popular. Not only did Apple incorporate Samba into some versions of Mac OS X to allow Macs and PCs to communicate, many third-party companies also used Samba to build stand-alone file servers.
The legality of projects like Samba has been widely accepted for more than two decades. But under the Federal Circuit's logic, Microsoft might be able to sue a Samba for copyright infringement. If the Federal Circuit's precedent isn't overturned, companies could become more reluctant to reverse-engineer competitors' products in order to make them compatible.
Grimmelmann also warns that the vague language of the decision could open the door to frivolous litigation. For example, the decision could make it easier for a company to sue a former employee if he goes to a new employer and writes software similar to the code he wrote at his old job. Even if the programmer writes the new code from scratch, courts could find that it's similar enough to the old code to trigger copyright liability.
For the past 20 years, since decisions such as Sega v. Accolade, Computer Associates v. Altai, and Lotus v. Borland, computer programmers in the United States have understood that copyright does not protect program elements necessary for interoperability. Based on this understanding, programmers have freely copied these elements, which has encouraged enormous creativity, innovation, and competition in the digital environment. Judge O’Malley’s decision casts doubt on this understanding. By ruling that interoperability is relevant only to fair use, and not to protectability, Judge O’Malley would require every developer to perform a fair use analysis before developing an interoperable product. This would place U.S. programmers at a competitive disadvantage to developers in other jurisdictions that recognized that copyright does not protect program elements necessary for interoperability. The Court of Justice of the European Union, for example, in the 2012 decision in SAS Institute v. World Programming Ltd., ruled that program functionality, programming languages, and data formats were not protectable under copyright.While for non-programmers, all of this may seem like a minor, technical issue over whether some small bit of "software" is copyrightable, the practical implications of declaring APIs copyrightable will have vast and far-reaching implications for all kinds of innovation. This isn't just a bad ruling, it's a ruling that will create massive problems for today's innovators.
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: apis, copyright, innovation
Companies: google, oracle
Reader Comments
Subscribe: RSS
View by: Time | Thread
[ link to this | view in chronology ]
Why is this even a thing?
Baker v. Selden, 101 U.S. 99 (1879).
[ link to this | view in chronology ]
Re: Why is this even a thing?
In that discussion, though, the CAFC appears to have missed one important point made by Mr Justic Bradley:
(Emphasis added.)
“Given therewith” seems to imply that the modern 102(b) factors must be considered as pertaining at the time of publication.
The CAFC panel wrote:
Focusing on the time immediately before creation, though, seems to neglect the idea the necessary incidents to the art are “given therewith.”
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
Because essentially, C is the historic predecessor of Java, and there are tons of functions in Java which have the same names as the ones in C and behave exactly the same way.
[ link to this | view in chronology ]
Re: Re:
“To give to the author of the book an exclusive property in the art described therein when no examination of its novelty has ever been officially made would be a surprise and a fraud upon the public. That is the province of letters patent, not of copyright.”
——Mr Justice Bradley, Baker v Selden (1879)
[ link to this | view in chronology ]
No copyright doesn't help Open Source
If Andriod was Java compatible the "fair use", "interoperability" argument would stand muster. But instead they just knowingly made an incompatible competitor to Java without paying a cent.
If I wanted to use a Adobe API to make a new Photoshop filter that worked within the original Photoshop program without paying for a licence then that should be "fair use" of the copyright API, because the derivative work based on the API actually complements and extends the original creation. But companies using API of say a open source GPL licensed communication messaging system to reduce the development time on their own Proprietary Software without releasing their code back under the GPL is simply stealing the hard work somebody else has done for their own financial gain.
Reducing and removing copyright does not advance the cause of Open Source software. The GPL and related licences only work when their copyright is legally recognised.
[ link to this | view in chronology ]
Re: No copyright doesn't help Open Source
Feist (1991) firmly rejected the “sweat of the brow” doctrine.
Along a parallel track, even in his CONTU concurrence, Commissioner Nimmer expressed “doubts and concerns” about letting copyright devolve into a “general misappropriation law”.
[ link to this | view in chronology ]
Re: No copyright doesn't help Open Source
second, GPL only exists to counter copyright as it applies to software, without software copyright the gpl isn't needed.
you may as well point out all the wonderful medicine that wouldn't exist without illnesses or injury
[ link to this | view in chronology ]
Re: No copyright doesn't help Open Source
"If Andriod was Java compatible the "fair use", "interoperability" argument would stand muster. But instead they just knowingly made an incompatible competitor to Java without paying a cent. "
So what? Why does a competitor need to pay its competitors to make a competing product? The Java API wasn't suitable for what Google needed so they may have borrowed from it and made some changes. Java, itself, borrows heavily from C and C++ (I used to be familiar with C and C++ but was never really that familiar with Java, though I tinkered around with it a bit, but I hear it's very similar).
and different programming languages don't necessarily compete so much as they just have different uses. Some are more suitable for some things (like heavy duty math) while others are more suitable for others (like general applications). So Google made an API suitable for their specific needs and it happens to bear some similarity to Java (and they may have borrowed from Java as well where it makes sense).
and what does Android being Java compatible have to do with being 'fair use'. If anything fair use would be taking a portion of one piece of work and using it within another piece of work to criticize it or to make a point of free speech, it wouldn't be making an exact copy. But none of that even applies here. But it's not like fair use is well defined in law anyways and certainly your unsourced (and mostly anonymous) opinion means nothing.
"But companies using API of say a open source GPL licensed communication messaging system to reduce the development time on their own Proprietary Software without releasing their code back under the GPL is simply stealing the hard work somebody else has done for their own financial gain."
Well, a specific implementation of Java is released under the GPL (most of it). Others may make different implementations.
If someone makes something that can interpret Java code from scratch but they don't release it under the GPL, for instance, that's fine because their software is not a derivative of the implementation that was released under the GPL.
If someone makes a new API that may have similarities to the Java API and they don't release their specific implementation their new implementation is also a new work, so long as they wrote the implementation from scratch and didn't just copy the GPL code and make some tweaks to it and then closed sourced it and sold that implementation to the public for a profit.
but for people to develop on the Android API what needs to be released is the API functions. There maybe many different ways to implement those same API functions (different people may write different programs that essentially do the same thing and the same API functions maybe implemented differently on different hardware) but the API, itself, is open for everyone to use.
"If I wanted to use a Adobe API to make a new Photoshop filter that worked within the original Photoshop program without paying for a licence then that should be "fair use" of the copyright API, because the derivative work based on the API actually complements and extends the original creation."
Fair use is very poorly defined and you don't just get to make up your own definitions from scratch.
"But companies using API of say a open source GPL licensed communication messaging system to reduce the development time on their own Proprietary Software without releasing their code back under the GPL is simply stealing the hard work somebody else has done for their own financial gain."
From my understanding Oracle is not suing because the API implementation hasn't been released under the GPL. They're trying to claim the API itself is copyrightable. The API itself is not something that has source code to release. You can invent an API and have many people write different implementations for it using the same hardware or under different hardware conditions. But you don't really seem to understand the issue well enough to discuss it (both legally, with your poor understanding of fair use, and from a programming point of view). and the court that made the poor decision also seems to poorly understand the issue as well.
"Reducing and removing copyright does not advance the cause of Open Source software. The GPL and related licences only work when their copyright is legally recognised."
The GPL is partly a workaround to copyright. Granted, it does require the source code of derivative released works to also be open source as well and that is something that requires copyright law but I'm perfectly fine with copyright lengths being substantially reduced to something reasonable even if it means that the source code of many works would never be released if they are derivatives of public domain GPL works.
[ link to this | view in chronology ]
Re: Re: No copyright doesn't help Open Source
by Horse With Stripes (577) on Saturday May 10, @10:16AM (#41579)
"This is ridiculous. Just think about it ... what if you write a small API that works for your (or your company's) custom applications. That API happens to have a function name that is similar to someone else's. If it's a relatively simple or limited function it could also use similar variable names and/or a data structures. And that's all it takes to violate someone else's copyright?
This doesn't have to be a big corporation like Oracle. The people who have copyrighted their API could be a small little software trolling company that then hires some cheap labor to download and analyze code from other companies. WTF? This could create a brand new category of copyright trolls who rush to copyright rather generic API calls and then lie in wait for any somewhat successful startup.
Is the USCO going to publish a directory of copyrighted function names and their definitions so everyone else can avoid using the same names, structures, etc? Of course not.
Let's hope this plays out all the way to SCOTUS. Then maybe we can get some rulings on this issue as well as software patents."
http://soylentnews.org/~Horse+With+Stripes/
Basically, an example of an API would be something like
If the programmer types in "Print "Hello World"" the text "hello world" would appear on the screen.
If the programmer types "Scan y" whatever is typed into the keyboard would be inserted into the variable y.
If the programmer types in "y = y + 3" three would be added to the variable y.
If the programmer types "Print y" whatever the user typed plus three would be displayed on the screen.
Bob and Jill can write two different compilers that basically take this source code compile it into something the machine can use. Both compilers would, ideally, take the same source code and compile them into similar programs that do essentially the same exact thing. The API is basically this concept of "Print "Hello world"" (something that's been around long before Java) should cause the text "hello world" to be released. There is no 'source code' to release for that basic concept, it has to be known to anyone developing under the API or else they can't develop under it (ie: the Android API).
[ link to this | view in chronology ]
Re: Re: Re: No copyright doesn't help Open Source
http://soylentnews.org/comments.pl?sid=1765&cid=41579
[ link to this | view in chronology ]
Re: Re: Re: No copyright doesn't help Open Source
[ link to this | view in chronology ]
Re: their own platform that was not comparable with Java
Since when does copyright infringement depend on copying too little, instead of too much?
[ link to this | view in chronology ]
Re: No copyright doesn't help Open Source
You can rewrite Shakespeare, in you own words, and it's NOT Shakespeare any more, indeed, it has legally nothing to do with it, and you get a copyright on it.
Or you can copy Shakespeare, word-for-word, and it remains Shakespeare (and as it happens, public domain), and you get no copyright on it. Even if you did retype everything by hand, and even if it was a tremendous amount of work.
[ link to this | view in chronology ]
Re: No copyright doesn't help Open Source
Rob, I suggest some study in the field of computer science might be beneficial because you apparently lack some background and history.
[ link to this | view in chronology ]
Re: No copyright doesn't help Open Source
1.) Google should have bought a license. In retrospect this would have been an insignificant cost and would have benefited both Java and Android.
2.) They copied the API for use completely outside of a Java context (their own completely incompatible VM). That is a copyright violation pure and simple. There is considerable effort into designing an API. There was considerable 'value' in the existing knowledge of Java devlopers that Google wanted to exploit ... for free.
The argument for API usage being stymied because APIs can now be copyrighted is bogus. APIs are meant to provide access. Those that want the public to have full access and innovate will simply make their API available with a license that explicitly states all reuse options.
[ link to this | view in chronology ]
Re: Re: No copyright doesn't help Open Source
And thus all of these developers, with their existing knowledge, are now mentally contaminated (*).
(*) You are not expected to understand this.
[ link to this | view in chronology ]
Re: Re: No copyright doesn't help Open Source
Why would doing this even occur to them? Before this decision, there was never a hint that such a thing was necessary. It goes against the standard practice of the entire industry.
"They copied the API for use completely outside of a Java context (their own completely incompatible VM). That is a copyright violation pure and simple."
Well, I guess it is now, but that's a new development -- and one that should not be. It goes against everything that has come before now, and is harmful to all concerned. Also, in my opinion, an API is not copyrightable material at all.
"The argument for API usage being stymied because APIs can now be copyrighted is bogus."
It's not bogus at all. This ruling means that using an API you did not develop is now risky. Licensing does not mitigate this risk by that much. Should the company you're licensing with decide to not adhere to the license, you're pretty much screwed unless you have a lot of money for lawyers.
Even if you do have a warchest, you're probably still screwed. You're likely to come out of such a lawsuit poorer for it even if you win.
[ link to this | view in chronology ]
Re: No copyright doesn't help Open Source
See also the first IP release with utilities and the IP stack.
It's not actual interoperability per se that's very important it's about weather the bit you copy is aimed at interoperation.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
17 U.S.C. § 101 — Definitions
(I realize this bare definition is not, by any stretch, a complete answer to your question. This comment is not intended to be such a final answer.)
[ link to this | view in chronology ]
It's Oracle we should be criticising
The people we should be ripping apart here are ORACLE! They're the idiots who don't understand that their own products implement published APIs. Specific example: Oracle sell WebLogic - a web application server (let's not get into the merits, or otherwise, of the technical capabilities of the product). This HAS to respect the 2.5 or 3.0 web application API (or specification, if you prefer), otherwise no developer is going to use the tool to deploy their applications.
To the best of my knowledge, Oracle don't own the web application API, but do they really want to license the use of the spec from those that do?
This is, of course, just one example. Oracle's products also implement JDBC and ODBC APIs, and many others in the course of implementing various interfaces. Most fundamentally of all, they use APIs to talk to the OS and disk systems upon which the Oracle DB must run.
Oracle are the BIGGEST idiots here. This WILL come back and bite them in the proverbial. And it won't take long, either.
It's not the courts who need to see sense, it's Oracle that need to grow some balls and get over themselves.
[ link to this | view in chronology ]
Begging the question
Tim Lee misrepresents Samba as duplicating the Windows file-sharing system, ignoring that SMB was developed mainly by IBM with some assistance from Microsoft, Intel, and 3com. An attempt by Microsoft to sue the Samba project would have likely led to anti-trust charges (and indeed Microsoft was forced to provide documentation and licensing to Samba because of anti-trust litigation). He is also mistaken in suggesting that copyright liability might occur for "new code from scratch", should it happen to be similar enough. Copyright does not work that way; independent development which might result in identical works is never infringing.
Jonathan Band is mistaken about the case precendents (the U.S. cases, anyway) examined by the CAFC in that those cases involved Fair Use defenses, and did not address whether APIs obtained copyright protection in the first instance. An issue that was never tried shouldn't qualify as precedent in later litigation.
The CAFC ruled very narrowly on Judge Posner's decision that the Java APIs did not qualify -- as a matter of law -- for copyright protection. It was entirely appropriate for them not to rule on the factors of Fair Use and copyright abuse, which are yet to be decided.
[ link to this | view in chronology ]
Re: Begging the question
Jonathan Band -- the same guy who literally wrote *the book* about the copyrightability of APIs -- is mistaken? Really?
http://mitpress.mit.edu/books/interfaces-trial-20
You sure you want to make that argument?
The CAFC ruled very narrowly on Judge Posner's decision that the Java APIs did not qualify -- as a matter of law -- for copyright protection.
Judge Posner had nothing to do with this case.
[ link to this | view in chronology ]
Re: Re: Begging the question
The copyright issue in Sega v Accolade concerned whether the copying performed during reverse engineering should be considered Fair Use. In Oracle v Google, Google did not reverse engineer Java but instead worked from the prodigious documentation available.
In CA v Altai, the court's analysis first removed the elements of the copied program that were either in the public domain, or dictated by external factors such as operating system calls, and then deciding there was no organizational left afterward worth protection. (When designing a programming language from scratch, as in the case of Java, there are far fewer external factors to dictate the structure required to accomplish a particular task.)
Lotus v Borland was admittedly about copyrightability of an interface and might apply, but it took place in the 1st District and not binding to a 9th Circuit appeal*.
There are many reasons why one may decide that Google did not misappropriate Java's "structure, sequence, and organization" -- without resorting to the conclusion that there is no such SS&O original to the APIs at issue, or to APIs in general.
Personally I think that everyone involved in this case has made mistakes and/or misbehaved. Sun should have more precisely defined what they felt was protected, Google should have GPLed their code (once OpenJDK was announced), Oracle should have sought cooperation rather than litigation (there actions have fairly well torpedoed Java's future), and the lawyers have been arguing all the wrong issues.
The biggest culprits, though, are the legislators in Congress who have enacted such an untenable copyright regime that it provides no certainty as to what acts are permitted or prohibited, leaves well-intentioned businesses and people at risk of suffering debilitating penalties, and is doomed to waste further billions of dollars in litigation, clogging up the courts, with no sign of any attempt at correcting it.
"Judge Posner had nothing to do with this case."
You are correct. I misspoke. I should have said Judge Alsup. And to be precise, in his decision Judge Alsup did not rule that APIs were generally not copyrightable, merely that the Java APIs at issue in this case were not.
* Though tried by the CAFC, they were compelled to judge the case as though it'd been appealed to the 9th Circuit Court of Appeals.
[ link to this | view in chronology ]
Re: Re: Re: Begging the question
That's exactly what they did. Their implementation is a "clean room" implementation.
In CA v Altai, the court's analysis first removed the elements of the copied program that were either in the public domain, or dictated by external factors such as operating system calls
I haven't read it (yet), but when you're making an operating system call, you are making a call to the operating system's API. If an API is copyrightable, then so are those system calls. That works against your argument, if I understand it correctly.
Google should have GPLed their code
Their code is available under the Apache 2.0 license, including the Dalvik virtual machine.
The biggest culprits, though, are the legislators in Congress who have enacted such an untenable copyright regime that it provides no certainty as to what acts are permitted or prohibited, leaves well-intentioned businesses and people at risk of suffering debilitating penalties, and is doomed to waste further billions of dollars in litigation, clogging up the courts, with no sign of any attempt at correcting it.
On that, we certainly agree.
[ link to this | view in chronology ]
Re: Re: Re: Re: Begging the question
Long about 2004, 2005, somewhere in there, I put up on the web a nice list of signicant copyright cases—with special emphasis on software copyright. That was just before Google rolled out “Scholar”. It's kind of a shame that site's been dead for a few years now.
[ link to this | view in chronology ]
Re: Re: Re: Re: Begging the question
I would not say that by the mere fact of an interface being an "operating system call", it does not obtain copyright protection; it would depend upon whether that interface is to things that were original, creative choices made by the operating system programmers.
For example, if displaying the letter "A" on the screen is achieved by moving the number "65" to memory location 0x4e00 then the system call is derived from the non-copyrighted hardware. However, if the OS call comprises passing a complex specified data structure to be inserted into another data structure and manipulating a third data structure for scheduling a particular operation upon the passed data, then the definition and organization of all of those various elements were not dictated by the need to interface with non-copyrighted hardware, but by the desire to avail oneself of the copyrightable creative choices of the OS designer.
Note that I am not saying that one should not be able to make such calls, but this is not owing to the lack of copyrightability of the API. Most commonly one is licensed to make such calls but even if they are not, there is still a strong case to be made for Fair Use.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Begging the question
Setting aside, for the moment, the CAFC opinion under discussion, is it your opinion that the law in the Ninth Circuit denies application of the useful articles doctrine beyond pictorial, graphic, or sculptural works?
That is, in the Ninth Circuit, can a literary work possess utilitarian aspects? If so, does the Copyright Act grant exclusive rights to reproduction etc. of those utilitarian aspects?
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Begging the question
The API is nothing other than the specification of those system calls. The "things that were original, creative choices" in your case would be the implementation of the API. That is the "thing" that responds "to" those API calls. And that "thing" was implemented from scratch by Google.
For example, a system call will not do anything without an operating system that accepts those calls. And nobody is arguing that the operating system, itself, is not copyrightable.
The argument that Oracle made - and that the Court accepted - was that the names of the system calls can be copyrighted independently of any system that implements it.
So, for example, if the Windows system accepts a system call named "clearScreen," then any other operating system (Linux, OSX, whatever) that also accepts a system call named "clearScreen" would be infringing on Microsoft's copyright. Even if the operating systems themselves share no common code whatsoever.
A literary analogy: software that implements system calls would be akin to a novel written in the English language. An API would be akin to the grammar rules of the English language.
This probably doesn't come across in the Court's ruling, because the Court doesn't seem to understand what an API actually is.
If you're curious, the entire API for the C++ standard template library can be found here:
http://www.cplusplus.com/reference/
Note that there is no software available on the site at all. But, if this Court's ruling stands, that wouldn't matter. If Bjarne Stroustrup held a copyright on the API for the standard template library, that website would be infringing upon his copyright.
[ link to this | view in chronology ]
Re: Re: Re: Begging the question
Computer Associates v Altai (2d Cir. 1992) concerned itself with application programs at the top of the stack.
The Altai court had no need to consider libraries intentionally designed for use higher up the stack. The Altai court was not confronted with a situation where the designers' own intentional choices created external interfaces.
[ link to this | view in chronology ]
Re: Begging the question
An API is not a product.
Warning - Car analogy:
This is like claiming a steering wheel is a car.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
As noted in Mike's article, Samba doesn't use any of Microsoft's software code in Samba. Samba is written from the ground up using completely different software code. The only thing Samba and Microsoft's Network File Sharing have in common, is the API calls. Which allows the two incompatible operating systems to communicate with each other across networks.
Oracle basically doesn't want any interoperability between software or hardware components, so they can 'maximize profits' through vendor lock-in caused by incompatibility issues.
Oracle doesn't care about the far reaching damage this causes to the software and hardware industries. Damage such as fragmentation and constant code rewrites due to nothing being compatible, interoperable, or standardized.
Copyrightable APIs will harm the US economy as a whole, and retard innovation because nothing will be compatible, interoperable, or standardized. The future of the tech sector will look very similar to the fragmentation developers face with all the different versions of Android. Gingerbread, Ice Cream Sandwich, Jelly Bean... only much, much worse.
I think that probably sums up CACF's ruling. They not only turned the tech sector a giant Android fragmentation mess. They actually made the US tech sector much worse than Android's fragmentation problem.
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
future vision
[ link to this | view in chronology ]
Re: future vision
[ link to this | view in chronology ]
Re: Re: future vision
This is not entirely correct. The hardware manufacturers spend a great deal of time and effort (well - some of them do) developing drivers for their hardware. Their drivers are made to be compatible (sort of) with existing operating systems. A driver is not an Application Programming Interface, it may utilize an API like structure allowing ease of use - lol.
[ link to this | view in chronology ]
Re: Re: Re: future vision
[ link to this | view in chronology ]
Re: Re: Re: Re: future vision
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: future vision
Typically, each OEM hardware type requires its own unique driver. Iterations of that hardware from that manufacturer will usually be accompanied by an update that driver. For example, a driver for an HBA from IBM will not work on a SCSI adapter from IBM.
[ link to this | view in chronology ]
Logic
Satava, it should be noted, was not a computer code case.
[ link to this | view in chronology ]
API value
[ link to this | view in chronology ]
Now, if only Oracle had filed patents....
[ link to this | view in chronology ]
[ link to this | view in chronology ]
ORACLE wins then ORACLE loses - the culture is all based on Ellison's own way of doing things
As the years went by, I tried the same basic SQL code in V7, V8 and V9. The same problem occurred in each version.
When making recommendations of what sort of DBMS to build various systems, I ensured that my clients knew that ORACLE had a difficulties with certain kinds of problems. I actually don't have much confidence in ORACLE being capable of enhancing their systems in basic ways. They certainly jump on the latest band-wagons and they do give reasonable lunches for their seminars when discussing the latest band-wagons.
It is one of the reasons that I have moved to PostgreSQL as my DBMS of choice.
Lastly, JAVA (along with C++) is the latest incarnation of COBOL which means that businesses will stick with it for a long time yet. It is up to the developers to shift from this to more tolerable languages like ....APL, K, Basic, CLU, Scheme, LISP, assembler, etc.
[ link to this | view in chronology ]
Re: ORACLE wins then ORACLE loses - the culture is all based on Ellison's own way of doing things
My opinion of them is not because of this API bullshit -- that's completely in character with how they've been for nearly their entire existence. They are awful, and eager to burn the landscape down so they can keep themselves warm for a night.
[ link to this | view in chronology ]