Computer Scientists Ask Supreme Court to Rule APIs Can’t Be Copyrighted
eff.org
eff.org
1. Harold Abelson.*
2. Alfred V. Aho
3. Tom Ball.*
4. John Perry Barlow
5. Brian Behlendorf
6. Richard A. Belgard
7. Jon Bentley
8. Matthew Bishop
9. Joshua Bloch
10. Dan Boneh
11. Gilad Bracha.*
12. Eric Brewer.*
13. Frederick Brooks
14. Rick Cattell
15. Vinton G. Cerf.*
16. William Cook
17. Ward Cunningham
18. Mark Davis.*
19. Jeffrey Dean.*
20. L Peter Deutsch
21. David L. Dill
22. Les Earnest
23. Brendan Eich
24. Dave Farber
25. Stuart Feldman.*
26. Edward W. Felten
27. Jeremiah Flerchinger
28. Martin Fowler
29. Neal Gafter
30. John Gage
31. Allan Gottlieb
32. Miguel de Icaza
33. John Hennessy.*
34. Tom Jennings
35. Mitchell Kapor
36. Alan Kay
37. Brian Kernighan.*
38. David Klausner
39. Ray Kurzweil.*
40. Kin Lane
41. Ed Lazowska
42. Doug Lea
43. Sheng Liang
44. Barbara Liskov
45. Paul Menchini
46. James H. Morris
47. Peter Norvig.*
48. Martin Odersky
49. Tim Paterson
50. David Patterson.*
51. Alex Payne
52. Tim Peierls
53. Simon Phipps
54. Bill Pugh
55. Larry Roberts
56. Guido van Rossum
57. Avi Rubin
58. Bruce Schneier
59. Curtis Schroeder
60. Barbara Simons
61. Dave Snigier
62. Alfred Z. Spector.*
63. Bjarne Stroustrup
64. Gerald Jay Sussman
65. Brad Templeton
66. Ken Thompson.*
67. Michael Tiemann
68. Andrew Tridgell
69. Josh Triplett
70. Jeff Ullman.*
71. John Villasenor
72. Jan Vitek
73. Phillip Wadler
74. James H. “Jim” Waldo
75. Dan Wallach
76. Peter Weinberger.*
77. Frank Yellin.*
"presently Google employees, consultants, and/or directors. Those amici are signing this brief as individual computer scientists whose work in the field long preceded their affiliation with Google. They are not signing this brief on behalf of Google or at Google's request."
Although I can imagine the "letter from the companies that are competition from both Oracle and Google" would also at least have some impact in media.
Isn't it to "Promote the Progress of Science and the useful Arts?"
http://en.m.wikipedia.org/wiki/Copyright_Clause
In this case it would seem that in fast-moving industries, monopolies would retard, rather than promote, the progress. Especially seeing as how copyright can be extended to 100 years or more after the author's death, here the author being a corporation?
Which is, yes, a different thing than arguing about whether it's "a good idea" for society or innovation or whatever. The EFF summary focuses on the "good idea" thing, but the actual amicus brief addresses both -- although I bet you can find even more of the legal arguments in the first party brief.
From the amicus brief, take a look at the original brief, starting on numbered page 4, "I. The Federal Circuit’s Decision Has Disrupted Decades of Settled Expectations That APIs Are Not Copyrightable"
> That assumption was well-founded. It was based, in large part, on this Court’s own recognition, in 1996, that menu hierarchies that control functional capabilities are a method of operation, and thus uncopyrightable under 17 U.S.C. § 102(b). Lotus Dev. Corp. v. Borland Int’l, Inc., 49 F.3d 807, 815 (1st Cir. 1995), aff’d by an equally divided Court, 516 U.S. 233 (1996). Programmers and developers relied on that ruling for the proposition that APIs, like the menu hierarchy in Lotus, may not be copyrighted under § 102(b). Ninth Circuit law—which should have been controlling in this case—was the same: the “functional requirements for compatibility” between computer programs “are not protected by copyright.” Sega Enters., Ltd., v. Accolade, Inc., 977 F.2d 1510, 1522 (9th Cir. 1992); see alsoSony Computer Ent’mt, Inc. v. Connectix Corp., 203 F.3d 596, 599–600 (9th Cir. 2000) (describing Sony’s PlayStation BIOS as a “system interface procedure[]” that Connectix was entitled to reimplement under § 102(b)).
This was in regards to Accolade (game company) reverse engineering, and reimplementing the software side of the security procedure of the sega genesis for third-party game cartridges. Following the source leads nowhere to an explanation of the quote. Must be a pretty trivial notion.
Still interesting case, though. First of all, it's puzzling that they just talk about "functional" requirements and concepts. "Well, what isn't functional?", said the Haskeller.
>The TMSS initialization code is a functional feature of a <24 USPQ2d 1577> Genesis-compatible game and Accolade may not be barred from using it.
>Functional features of a product are features ‘which constitute the actual benefit that the consumer wishes to purchase, as distinguished from an assurance that a particular entity made, sponsored, or endorsed a product.’”
I don't, what? Are they basing copyright-eligability on consumers' ability to understand features that interact to form other features? How is the Trademark, that was shown as part of the security check (only on consoles newer than the games), precluded from that desire?
>Accolade did not seek to avoid paying a customarily charged fee for use of those procedures, nor did it simply copy Sega’s code; rather, it wrote its own procedures based on what it had learned through disassembly
Wait, did they pay a fee to use the procedures? What's the case about again? Then, reimplementation is based on the understanding derived from the translation of the object code. Translation is prohibited under copyright, except for fair use. The fair use here is interpretation of an idea and expression of the same idea in different semantics, translation for short. Never mind the irony, surely there wasn't any commercial gain involved, so it's still somewhat fair use. Apparently, a security check that can be broken isn't a commercial advantage, so, its defeat is no benefit. It's defeat is only lawful, because it isn't copyrightable in the first place.
This is so messed up, it just doesn't make sense.
The point is that it's in customer's interests for Sega to be able to e.g. only display the Sega logo for games that use Sega chips. That's a non-functional feature, so to speak, and there are good reasons for it (e.g. some low-quality third party chips could damage the console itself). The court is looking after customers' interests by distinguishing between that and a functional feature.
> Translation is prohibited under copyright, except for fair use.
Nope. Translations are derived works and may not be distributed without the copyright holder's permission, but there's no law against making a translation in-house and using it internally.
> surely there wasn't any commercial gain involved, so it's still somewhat fair use
That's not what fair use means.
Incorrect. The right to prepare (not merely distribute) derivative works, including translations, is one of the exclusive rights of creators included in copyright. [0]
[0] 17 USC Sec. 106.
Also, as others have mentioned, the whole "method of operation" argument is also a dangerous slope to be slipping down. What is all code anything other than a "method of operation" of the hardware it runs on?
I've said it before, but copyright is not really a good mechanism for IP protection of code. Software was shoehorned under copyright because 1) other mechanisms were not available and 2) there is sometimes creative expression involved in writing code. It's only the potential of creative expression what grants copyright protection to any written code. By that standard, APIs are no different from any other code.
I guess maybe that'd be the argument. To me, it seems pretty clear that API's are for "computer systems interoperating with each other". That's what an API is, an interface for one piece of software to interoperate with another. Seems to me and many others anyway. "Interface" kind of means "interoperation", an interface is the where and how of one component interoperating with another. I'm a bit surprised that any programmer would disagree actually, but I've been surprised before.
The scary thing is that non-technical judges will have to understand what an API is and what it's for here.
I do agree that software code does some weird things to copyright and starts to make the whole thing odd, and agree with you about "method of operation" thing -- the trick about code, different from former "creative expression fixed in a physical medium", is that code _does things_, in a way different from previous forms of creative expression fixed in a physical medium. Copyright is a weird edifice to begin with, and code makes it weirder, for sure.
> APIs are no different from any other code.
To me, API's are _not code_ at all, sot that's why they are different from "any other code." An API is a _description of code_, not code itself. Code implementing an API is surely copyrightable, but it seems to me clear that an API -- the description of classes, methods, and signatures -- is not code, it is a description of features of code. Google here lost by making code that _worked the same_ as Sun's, not because they copied Sun's Java source. And that's why it seems clear to me that it ought not, consistent with previous copyright law, to be copyrightable.
But clearly people will disagree, especially non technical people, which is why this is a case. I think most technical people tend to agree with me, but obviously not all.
In my mind, this difference is critical, because at a binary level (byte code, IR, assembly, what have you), the actual human-readable names don't matter. At the binary level, the interface essentially is nothing more than a bunch of bytes representing offsets into other byte arrays representing code, and yet more bytes arranged at other offsets representing arguments. Whether that code was generated from "File.open(fname)" or "new File(fname)" or "open(fname, O_RDONLY)" does not matter at all, because the final machine code (on x86) is essentially "mov al,0; mov ah,3dh; int 21h" (or the binary representation thereof).
As such, you could generate a binary that calls code represented by an API without using the API at all. But of course, nobody really does that because human-readable "new File(fname)" is so much more expressive (and more important, much more readable) than they bytecode for "new #3; dup; aload_1; invokespecial #4". There is very limited potential for creative expression in a sequence of bytes and offsets, which is why it differs so greatly from APIs from a copyright standpoint. However, it is the bytes and offsets that is actually makes computer systems interoperable, not the names and organization of the APIs. Unfortunately, the Sega/Sony caselaw seems to exempt the former from copyright law, but the latter is what Google copied wholesale. Now Google, EFF et al are trying to conflate the two. (Of course, the fact that Android is not binary compatible with Java either is another hole in Google's own defense.)
> ... APIs are not code at all...
One could make convincing arguments both for or against that, but it does not matter from a copyright perspective. From what I can tell, anything that is "written" and can have "creative expression" is protected by copyright. My point is simply that, unless some exception is carved out for it, APIs being copyrightable is currently completely consistent with what copyright is intended for.
So, given that an API is an arrangement of ideas, and that copyright apparently protects arrangements of ideas, why is copyright inapplicable here?
If the argument is that copyrights shouldn't apply to APIs, then I understand. It's probably more harmful than beneficial, and thus should be prevented. But if the argument is that copyright is incompatible with the domain of APIs, as if you were trying to copyright a taste like chocolate or copyright a smell, then I don't understand that at all. Would anyone mind clarifying?
For instance, if you write a recipe, the -exact text- of that recipe is copyrightable, but the actual recipe itself is not -- someone else can reword it in their own words, with the same basic ingredients combined using the same operations, and that is not protected by the recipe-writer's copyright. This is (or was?) established in U.S. law.
Similarly, in the U.S. _functionality_, behaviors or operations themselves, are not copyrightable (although it may be patent-able). You can copy a competitors functionality exactly, as long as you do it with your own original implementation -- the functionality is not protected by copyright. (This is why people do 'clean room' compatible implementations by developers who never saw the original code they are copying the functionality of). In general, the right reverse engineer and reproduce the functionality of a technical work without the permission of the copyright holder of the original work -- is (or has been?) legal and protected.
(I am not sure the judges involved realized the relationship between promoting the copyrightability of API, and what this does to the previously well-established right to reverse engineer and create compatible things).
So the belief, previous to this case, was that an API is more like functionality, or the steps in the recipe. An implementation of an API is copyrightable -- but the description of the API itself, the classes, methods and signatures, are more like functionality or statements of fact, more like the steps of a recipe or a description of behavior. Both of which are not copyrightable -- you can't prevent someone from "doing the same thing", only from copying your particular code or text), then they are like a creative work in fixed medium themselves (the exact text of a particular written recipe, or a particular code implementation. (Patent law lets you prevent others from 'doing the same thing', but that's a different law with different requirements for what is patentable vs what is copyrightable, different legal rules for determining if a violation occured and what the penalties are, etc.)
You are (or were?) allowed to copy an API in your own implementation by reverse engineering in order to create a compatible implementation, and it doesn't make a lot of sense if you lose this right because you can get the API from docs instead of reverse engineering it.
I'd imagine you can get more details from various briefs involved these cases, as far as cites to specific previous law. But to many, the fact that API's are not copyrightable is what's consistent with existing law over copyright, including the lack of copyright over the actual operations of a recipe themselves and the protected ability to reverse engineer someone elses thing to create your own compatible implementation. It seems to many that making API's copyrightable is inconsistent with much existing law.
You can run skittles, coke, or Viagra trough a mass-spec and get exactly what they are made off but it won't get you any closer to understanding how to make them. Pharmaceuticals patents as well as patents in other industries like cosmetics and the food industry are all about the "recipe".
As far as API goes it's slightly more tricky but it's also something that needs to be thought off as they allow your competition to replicate functionality and directly take business from you by being compatible to every business partner you currently have.
Take for example the S3 API there are 100's of "Cloud Management Solutions" now that take advantage of the S3 API, as well as 1000's of developers already familiar with it's syntax and function. Now you want to set up your own cloud computing provider so you replicate the API for your own systems, under the hood they might be completely different but as far as integration goes they are identical. While some might say well you can't copyright expressions and syntax others might say Amazon invested millions in developing their API, perfecting it's interoperability, investing money in partners and early adopters to get tools out there and get it to catch now you are coming and reaping all the benefits without investing anything whilst stealing potential costumers from Amazon.
API need to be open to survive, however as things go there should be a way for companies to control how and who implements them especially on the server side.
Nope.
http://www.copyright.gov/fls/fl122.html
http://paleomagazine.com/recipe-copyright/#protected
Those are on recipes. Clearly not copryightable in US law, really.
Pharmaceutical companies typically use patent, not copyright. The one place pharmaceutical companies try to use copyright is in "product information documents" (not the pharmaceuticals themselves), and even that is tenuous, as some courts have considered them statements of fact that are not copyrightable, and there was actually specific legislation about pharmaceutical product information sheets recently, which I don't know the details of well enough to speak on.
Your post seems to argue for patenting an API, not copyrighting it. I can't think of why an API can't be a patentable process. The claim tree might be rather complex.
The purpose of copyright is to encourage innovation and creativity. In a broader sense, the ultimate goal is to benefit society. I think the real question we you should be asking is "will society benefit more from copyrighted APIs or not?". I personally think the answer is that it would be a net negative for society but that's my own opinion.
There are many creative acts which are not covered by copyright, and the argument is that APIs are one of them, since they are a functional description (the "method of operation"/"functional requirements for compatibility" covered by ewillbefull). It's not saying that API design is an incidental and uninteresting byproduct of the design of software, it's saying that as a method of operating that code, they aren't copyrightable.
Incidentally, that may mean that these APIs could be covered by patents, but Oracle's patent argument in the original suit was extremely weak and so they dropped it, so it wouldn't be relevant to this case.
It would also generally be very difficult to get patents on APIs without the Federal Circuit working a whole lot more of their patent-expansion magic.
That's an argument I could never understand. And remember, even though the term API has been borrowed in the past few years to mean "protocol", API in the context of this case pertains only to its classical meaning. As such, a specific API is indeed a method of operating code, but also a very elaborate text -- including specific class names and method names (and a specific ordering of parameters). None of the names is essential for replicating the functionality of the code. For example, String.length() could have just as easily been named string.len() or Str.size(). Because Googles "JDK" isn't actually the JDK -- and therefore does not interoperate with any actual JDK classes -- but simply a copy of them, the names, organization, etc. are absolutely not necessary in order to operate Google's code. Google's code was never meant to interoperate with Java, but to replicate it (once they've disregarded Java's GPL license this may not matter, but they've also broken the JDK's license in other ways, namely, they've made a partial, incompatible implementation). How, then, is the API being "a method of operating code" relevant to the matter at hand?
"In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work."
The common belief is that an API meets this "system or method of operation" standard.
This isn't helpful: http://legal-dictionary.thefreedictionary.com/Method+of+oper...
I really don't understand how an API is a method of operation in any sense. It's an understanding between people about how to use a software library. The only sense that I could see it being a method of operation is literally "This is a description of how you operate the software library." In other words, an API is an instruction booklet for people, not computers. But in that case, why are instruction booklets copyrightable, but not software APIs?
for example...
Ninth Circuit law—which should have been controlling in this case—was the same: the “functional requirements for compatibility” between computer programs “are not protected by copyright.” Sega Enters., Ltd., v. Accolade, Inc.
Also, an API is much more than you think. An API might be Windows' system APIs which applications use to interact with the operating system -- put a license behind that and WINE is gone overnight. An API is also totally indistinguishable from a network protocol, in both a technical and legal sense.
But to be clear, instruction booklets are copyrightable, but the _instructions_ are not. (Or haven't been prior to this case? I think some worry that if the logic of this case if carried through, many things that were previously not protected by copyright will become so).
Let's say you figure out, say, a great new way to assemble some tool, and write down instructions for it (1. Get a ball of twine. 2. Get some chewing gum. 3. Affix the chewing gum to twine.)
Your instruction booklet itself is copyrightble -- nobody can photocopy it without your permission. But the steps you figured out are not copyrightable, someone else can write down those steps in their own words, hey, look what we can do with chewing gum and twine, and that is not protected by copyright. You can't stop someone from sharing those steps with others in their own words, and you can't stop someone from carrying out those steps. (Under copyright, that is. The steps may be patentable; that's a different law. But they are not copyrightable. Or... didn't used to be?).
That's the way copyright has been. It seems to many that the API itself, and the ability to make new software with the same API, is more like "following the steps yourself in your own words", than it is like the "instruction booklet." If someone writes docs for their API with lots of good narrative instructions and examples -- nobody else can just copy that documentation ("instruction booklet") wholesale, that's protected by their copyright, nobody disputes that. But the classes, methods, and signatures themselves, prior to this case, most everyone thought were more like "steps themselves" and not subject to copyright.
An "an understanding between people" has in fact never been copyrightable in itself, you can't stop someone else from sharing the same understanding, under copryight. You could stop someone else from copying particular text describing that understanding, but only the particular text.
The instructions themselves are not copyrightable only a specific presentation of those instructions.
So if I create a new recipe for a dish. You can include that recipe in your book but you can not include the specific presentation - so you should rewrite in your own words, not duplicate my layout, not copy my picture without permission, but you are free to recreate the recipe as it's a method of preparation rather than a form of presentation. Now arguably my layout of the dish could be copyright too so you may have to plate it differently.
void* foo(int bar);
The more dangerous question is "what is a computer program except a method of operation?"
If they're "doing the exact same things" then they're the same API. That's what an API is -- it's a formal declaration of the function(s) implemented by the implementation. Its purpose is literally to separate the part that can be implementation specific from the part that can't. The purpose of an API is to be the part that can't.
And yet somehow I can reliably differentiate the Java API from the C++ API from the Python API etc. etc. doing all the same things in their respective standard libraries. That is, each one expresses the same concepts in different ways. You seem to be conflating the concepts represented by an API with the specific expression of that API. This being a copyright case, the issue at hand is clearly the expressive aspect.
Let's try a specific example. Here's a function from the C library:
int tolower(int c);
int64_t tolower(int64_t c);
This specific case is not talking about copyrighting "java.io.File(String filename)" or "Character.toLowerCase(char c)" in isolation, but rather the overall collection of the whole API. It's all about covering the "structure, sequence and organization" of the API, and there's not much of that in a single function call.
But your point about linking relates to another point I made elsewhere (https://news.ycombinator.com/item?id=8581069): you can compile arbitrary textual code to binary code that links to the same symbol in the function table. That is, "new File(fname)" in Java and "open(fname, 'r')" in Jython can both point to the same symbol ("invokespecial #4" in Java bytecode). This is what I mean by "different API for same functionality". Google argues that they needed "binary compatibility" (by citing the Sega and Sony cases), but you do not need to copy the API wholesale for that! They could very well have defined their own new API (e.g. "android.fs.FileObject android.fs.FileSystem.openReadOnly(String fname);") that compiles down to the same bytecode, but then they wouldn't have been able to leverage the widespread pre-existing Java knowledge in the industry.
Just because a particular reading of copyright law might suggest that APIs could be copyrighted, doesn't mean that in the presence of a greater good ("...To promote the progress of science and useful arts..") the court might just decide that allowing the copyright of APIs would be incorrect.
Copyright is supposed to protect just the expression of an idea, not the underlying idea itself. With API copyrights, there isn't room left for others to express the same idea.
I'll sign it, too. - designer of the D programming language
The fact that feature "z" is located at "x,y" can't be copyrighted, but the data file that describes exactly that can be and is. (There are good reasons for this. It's not as simple as the straw man I set up there.)
The US is very fortunate to require all government-produced cartographic data is solidly in the public domain. This is not the case in most countries.
Now there are several public-domain global datasets, but not very long ago obtaining basic cartographic data for many parts of the world was fraught with copyright issues.
It's rather annoying to have made a map of your study area and then find out that:, "Oh, wait. You can't publish that. Our license for the river locations only allows us to use the data internally. We can't publish a figure with that data on it!"
You can make the argument that making these maps costs money, so those that benefit from the maps should actually pay the government for them - thus people who don't need these maps don't have to pay for them through their taxes.
I'm not entirely sure I subscribe to that - often having something publicly available like some kind of a utility is more beneficial to everybody than properly allotting the cost.
But I don't think it's clear cut in the case of maps, and in any case it's a reasonable argument to make.
I generally like open government, but I think this particular practice may come from a history where maps were more interesting and relevant to the integrity of the nation-state.
Five years ago, www.OpenStreetMap.com started getting comparable to commercial maps in many places. And we have not even entered the golden age of OSM, when all of these sensor-laden devices we carry will be automatically feeding the map updates and corrections.
Open data will be the best for nearly all applications on a 20-year timeframe. Google, TomTom, Russia, etc will not be able to make money on the actual map data.
For anyone who wants to look at some pretty maps: http://leaflet-extras.github.io/leaflet-providers/preview/
However, you would be in violation of trademark law.
That's an excellent point. If you run a service, you can use someone else's TOS and apply it to your customers. It is the outcome of intellectual work, for instance a lawyer's work, and it is under copyright. However, it is not clever to reuse someone else's contract anyway and you'd better use a lawyer to check its terms.
Therefore I don't think the wording of contracts, norms, standards and laws should fall under copyright/patent.
Think about a US law writer prosecuting Germany for "a law which proceeds the same way as one which was established in US" under patent infringement.
What does not (or has not before) are the _meanings_. You in fact, can't, under US law, take someone elses TOS and just plain copy it. I'm not sure if you meant to say "can't" instead of "can" in your comment -- but in fact, you pretty clearly can't just copy the text of the TOS.
What you can do is write your own TOS based on the exact same categories of allowed and unallowed behavior.
> Think about a US law writer prosecuting Germany for "a law which proceeds the same way as one which was established in US" under patent infringement.
Are you talking about patent or copyright? Two entirely different laws, which protect different things in different ways.
You could -- quite clearly and uncontroversially -- _not_ accuse someone else of "proceeding the same way" and thus violating your copyright. Copyright simply doesn't protect "ways of proceeding".
If you could get some government to issue you a patent on your law (which I don't _think_ you could, but who knows these days in the U.S. which seems happy to issue a patent on nearly anything), then you might be succesful in a patent infringement case. Patent and copyright are entirely different things.
If they copied the exact text of your law, then that might be a copyright violation. Copying the "proceeding the same way"? The sorts of things you want to regulate or prohibit and the nature of the penalties or whatever? Nope. Copryight simply does not go there.
(The fact that in the U.S., nothing created by the federal government is protected by copyright anyway -- is really a side-issue, something unique to U.S. law, and not really relevant to the present topic, although it is a thing).
This isn't necessarily bad (fire safety experts writing a model fire code, e.g.) but it does have the effect of putting the law under copyright.
I think what it comes down to is it's copyright, but there's an exception for compatibility. Like a 3rd party part in your car. You can't claim it's the other brand's product, but you can claim it's compatible with that brand. It happens all the time, in all industries. So why can't it be the same with software APIs? A copyright exception for "interfaces" sounds like a pretty safe approach.
Unless their's a patent involved preventing someone from recreating a certain process or method, or a trademark preventing confusion, the act of creativity itself cannot be bounded. Copyright gives rights to the creator for their own creation. It can't prevent someone else from trying to create the same thing with their own hands.
Normally, in a copyright case, the appeals court for a case heard in the 9th Circuit would be the Court of Appeals for the 9th Circuit. The ruling of that court would then be binding precedent for future 9th Circuit cases.
However, in this case the case in the district court was both a copyright case AND a patent case, and for patent cases the appeals court is the Court of Appeals for the Federal Circuit (they have exclusive subject matter jurisdiction over patent appeals). The CAFC only got the copyright case because it came along for the ride with the patent case.
How does precedent work when the CAFC gets something that would normally not go through them? Do they still set national precedent for that, or do they just set precedent for subsequent cases that are appealed to CAFC (e.g., subsequent copyright cases that hitch a ride on something the CAFC has exclusive subject matter jurisdiction over)?
Actually many years ago Sun has successfully sued Microsoft over Microsoft's incomplete JRE implementation, but I guess that was more about breach-of-contract and trademarks than it was about copyright.
What Sun has done is release (most of) their own JRE implementation with a GPL(+exception) license, which would of course imply a license to the API copyrights that Oracle is now speciously claiming... but Google is not using this implementation (because, as everyone knows, there are obvious legal risks to using GPL'd code); IIRC the class library implementation that Google uses comes mostly from Apache.
When Google Announced Android, CEO of Sun at the time welcomed the project and acknowledged it as a positive to Java Community.
http://ansuz.sooke.bc.ca/entry/23
(law vs. computer science perspective on information; go read if you haven't yet!)
Trademark law is primarily to protect customers - people who bought "Microsoft Java" (yes, it was more complicated than handing cash to MS and getting Microsoft Java, but the point stands) thought they were getting Java, and they weren't (the whole point of Java was "write once, run anywhere", but programs written under Microsoft Java often wouldn't run on Sun Java). Whereas there is no such confusion when people buy "Google Dalvik".
the cookbook in itself has copyright, but utilizing the instructions from it for your own food or business is not exactly the same as republishing the cookbook itself or redistributing it
imagine if someone could copyright the way we make grilled cheese sandwiches
We need a new legal system for arbitrating disputes in technical disciplines overseen by a panel of technical experts. Or perhaps a trial by jury where the selection criteria is employment in the relevant discipline for at least 10 years (academia or corporate).
Its not a tech matter, its a matter of the application of Copyright law. Its exactly what the Supreme Court exists to do.
> We need a new legal system for arbitrating disputes in technical disciplines overseen by a panel of technical experts.
Specialized trial or intermediate appellate courts of this type may make some sense (though such a specialized body --whose members are no doubt both drawn from and likely to leave to industry -- runs a particular risk of regulatory capture and becoming a body that reflects very well the interests of the bigger players in the industry), but I don't see any good reason for fragmentation at the top of the judicial branch just because technology, so I don't see any reason that ultimately such issues wouldn't end up with the Supreme Court.
> Or perhaps a trial by jury where the selection criteria is employment in the relevant discipline for at least 10 years (academia or corporate).
Specialized juries defeat the purpose of trial by jury -- and, anyway, then you just create a bunch of additional litigation over the boundaries of the "relevant discipline" for each case as each side tries to set the experience qualifications to suit the pool of jurors it thinks will be most favorable.
This could be egregiously abused without too much cleverness.
"Oh, you're self employed in software? No jury duty for you." "Oh, you don't work for GE, the only company approved by the 'What Counts As Corporate Software' board? No jury duty for you."
One must be very careful advocating for the creation of special courts. History is rife with examples of these being particularly corrupt and deplorable.
One can predict with high accuracy a SC Justice's vote on most cases based on the political party of the president who appointed him/her.
Having taken a number of law and judicial politics courses, I can say this has been studied and its not at all true. You can tell with some accuracy a SC Justice's vote on issues that had high political salience at the time the individual justice was appointed by the position of the appointing administration on those issues, but predicting votes by party identification fails rather drastically for most other issues. There's a few evergreen issues that have had both high political salience and fairly consistent partisan breakdown of positions over a long time (e.g., abortion, gun control), and so these issues tend to be pretty consistently predictable by party ID.
OTOH, most issues aren't like that (though issues that get lots of mainstream news coverage are disproportionately likely to be -- though even there many aren't), and issues like the particular one here (whether APIs are within the scope of copyright) haven't ever had high political salience.
Sometimes you can predict how a given Justice will act, based on how he feels about the specifics of similar cases.
Why is that a problem? It's certainly possible that the judge was an avid home computer enthusiast in the 1980s and knows about tech.
Old age doesn't automatically mean technological incompetence anymore.
Just curious as I turn 35 in a couple of years...
Edit: to the person who downvoted this, it's a joke in case you didn't notice
For example, Judge Alsup was born in 1945 and demonstrated a perfect understanding of the issues in his ruling. As I recall he even taught himself Java programming during the trial.
None of this is inconsistent, though, with it's being beneficial that there are additional very smart younger people, who may be more likely to be familiar with newer technologies just in case their perspective becomes relevant.
This is not a case where you're digging around in the weeds trying to figure out which function does what. You don't need to be a computer scientist to understand the legally-relevant concepts in a case like this. Especially at the appellate level, where you're working with high-level concepts, and where you have people with the relevant technological background submitting amicus briefs explaining the concepts. I don't think anyone on the panel read the amicus briefs in this case and simply failed to understand what an API is.[1]
The real issue in this case is that a judge, applying the copyright law, simply does not care about whether finding API's to be copyrightable hinders interoperability or cloning of software. It's simply not legally relevant. The lynchpin of copyright is originality and creativity. Are the Java API's original and creative? That's the only relevant question.[2]
[1] And I would posit that software is easier to understand for a lay-person than a complex reinsurance arrangement or financial instrument. How would Hacker News react to the proposition that we should have specialized courts to decide financial disputes, with judges required to have a minimum of 10 years experience in Wall Street?
[2] Having written internal API's for software products, I would say they definitely are! API design is hard work that requires a lot of careful thought. Making a beautiful API is as much a creative expression as writing a sonnet or a short story, and is no less deserving of copyright protection.
This is 100% false of course. My shopping lists are creative and original, but certainly not copyrightable.
You know it's not the only question, and not even the most relevant one (which is whether the structure, sequence, and organization part of an API is the copyrightable part, or whether the literal implementation only is protected).
"[2] Having written internal API's for software products, I would say they definitely are! API design is hard work that requires a lot of careful thought. Making a beautiful API is as much a creative expression as writing a sonnet or a short story, and is no less deserving of copyright protection."
1. API's are not expressions of anything. They are literally interfaces. An outline of a story in abstract terms is not copyrightable. The actual story is. Such should it be with API's. API's are not copyrightable, their implementations are.
2. The fact that it is hard work and requires careful thought is 100% irrelevant in united states copyright law, since we have no sweat of the brow doctrine.
To me, an "API" is just the "structure, sequence, and organization part," distinct from the implementation. I.e. you can't take a C header file and delete the parameter names, and replace all the types with typedef'ed names and get a different API. So the question is whether that (whatever you call it) is copyrightable. And under 17 USC 102, how you answer that question is to look at whether that is original and creative.
> 1. API's are not expressions of anything. They are literally interfaces. An outline of a story in abstract terms is not copyrightable. The actual story is. Such should it be with API's. API's are not copyrightable, their implementations are. 2. The fact that it is hard work and requires careful thought is 100% irrelevant in united states copyright law, since we have no sweat of the brow doctrine.
Of course, but something being hard work and requiring a lot of thought is indicative of whether it requires originality or creativity. Take, for example, the POSIX file API's. That specific combination of orthogonal function calls, the concept of passing around file descriptors as small integers, etc, is definitely a creative expression, distinct from the underlying functionality. And it's a distinct creative expression from, e.g., the Win32 file API's, which express similar functionality in a very different way.
Of course, if you did so, the fact that you ended up with the same API means you have removed any expressive portions, and are left with purely functional constructs and short names.
". And under 17 USC 102, how you answer that question is to look at whether that is original and creative."
Sorry, but no. The fact that something is original and creative does not, by itself, make something copyrightable in any way, shape, or form.
"Of course, but something being hard work and requiring a lot of thought is indicative of whether it requires originality or creativity."
It 100% is not indicative of this. It is hard work to compile address lists and phone numbers into the white pages. It requires a lot of thought to think through physics and math problems, and write down equations.
Neither is subject to copyright protection.
"the concept of passing around file descriptors as small integers, etc, is definitely a creative expression, distinct from the underlying functionality. "
However, as a concept, it is one completely and totally ineligible for copyright protection.
That presupposes that there is nothing expressive in the structure of the API itself, beyond the names. But the combination and structure of calls in an API is an expression in and of itself, as evidenced by the fact that the same functionality (e.g. file access) can be expressed in many different ways.
> Sorry, but no. The fact that something is original and creative does not, by itself, make something copyrightable in any way, shape, or form.
I didn't say it was the only requirement for copyrightability. There's obviously the exclusions in 17 USC 102(b). But in addition to the "work of authorship" and "fixation" requirements in 17 USC 102(a), which I assume aren't in dispute, originality is what matters.
> It 100% is not indicative of this. It is hard work to compile address lists and phone numbers into the white pages.
Ditch-digging requires a lot of work too, and I'm not asserting that is creative, but I do think API design is a creative process that requires a lot of careful thought.
> However, as a concept, it is one completely and totally ineligible for copyright protection.
Sure, the concept of passing around file descriptors as small integers is not protectable in the abstract. But it's an expressive choice that, when weaved into an API, takes it beyond purely functional into a creative expression.
By this argument, everything ever, including my shopping lists are creative expression and copyright eligible.
Copyright protection in software has never extended this far, and your argument is not particularly convincing (at least to me :P)
"Sure, the concept of passing around file descriptors as small integers is not protectable in the abstract. But it's an expressive choice that, when weaved into an API, takes it beyond purely functional into a creative expression."
We're going to have to agree to strongly disagree.
By your abstract arguing, almost everything can be found to be expressive as long as it's "an expressive choice". This would extend copyright far into the realm of methods and processes.
I'm not sure that necessarily follows, but if you do use creative expression in write your shopping list, why is it not copyright-eligible? Just because it's a "shopping list"? Where do you draw the line?
And what if you no creative expression is involved in writing some code... is it not covered by copyright?
Is a "Hello World" program copyright-eligible?
Is a FizzBuzz program copyright-eligible?
Is a library that implements atoi and itoa copyright-eligible?
Is a program simply implementing a detailed spec copyright-eligible?
Is a service implementing PageRank copyright-eligible?
> This would extend copyright far into the realm of methods and processes.
I'm sure you know this, but copyright expressly excludes protection for functionality (leaving that to the realm of patents), and isn't that what methods and processes are?
What would it mean to use creative expression to write a shopping list?
"And what if you no creative expression is involved in writing some code... is it not covered by copyright? " It is clearly not covered by copyright in that case.
I'd need to see specific code to answer the rest of your questions.
Copyright is not a binary thing. There is essentially a 'strength of protection' that goes along with it. For example, you can have copyrights on compilations of works. Your copyright does not extend to the underlying works. Anyone can copy them (assuming they otherwise have rights).
"I'm sure you know this, but copyright expressly excludes protection for functionality (leaving that to the realm of patents), and isn't that what methods and processes are?"
No.
Make it rhyme? Interject humor? Use archaic language? :-)
The question is, of course, why would you ever bother when it's only ever going to be you who reads the shopping list? But that's not the case with APIs! APIs are made primarily for other people to read, understand and compose other programs with. If I were to design an API that I wanted other people to use (and I have), I'd try my hardest to make it as attractive as possible.
> I'd need to see specific code to answer the rest of your questions.
I did give a list of examples, but your next paragraph answers my question, in a way. I guess "hello World" is probably not copyright-eligible, but more complex programs are. My question is, what if a complex program was just a mechanical implementation of a very detailed spec?
As to the methods and processes bit, I'm not quite clear what aspect of those you fear would be covered by copyright. If it's the actual implementation, it's just the code, which is already copyrightable. If it's the functionality or the "idea" behind the code, it is explicitly excluded.
This brings me back to my general belief that copyright is not appropriate for protecting code. (Good) code is supposed to be as boring as possible! The actual creative expression in programming goes into how problems are solved, i.e. the "idea" behind the code, and that is explicitly excluded by copyright.
"In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work."
I could easily see an API being an "idea" or "method of operation". I have no idea how this squares with precedent.
Do you know, off hand, what excludes mathematics from copyrightability?
I can copyright the text of my proof, but not the fact being proved.
If you pass the file descriptors because that looks pretty, because of the beauty of the form and not for any functional effect. And, if the same functional effect (if there is one) can be achieved in other obvious and equally functional ways, so the only reason to do it this way is aesthetic, then yes - the essential elements are creative.
Just because you can achieve the same technical outcome in a different way doesn't make this way specifically creative however.
If an obvious way to create a specific technical effect creates a specific art-like outcome too then it's probably not copyrightable. Tyre treads, say: if your tread is created to appear different and there's no other reason to make it that way then you're covered by copyright; but if they have a technical benefit and you don't have other IP protection (patent or design patent) then others are free to duplicate that design because they are allowed to generate that technical outcome and the visual "artistry" is subordinate to that it's emergent rather than being directed.
How is it not? Interoperability is functional. If you can't copyright function then you shouldn't be able to copyright anything necessary for interoperability.
> The lynchpin of copyright is originality and creativity. Are the Java API's original and creative? That's the only relevant question.
That obviously isn't the only question, otherwise you could copyright anything which is patentable and get 95 years of monopoly rather than 20.
That is exactly why a legal professional is the wrong person to decide the issue. I've written plenty of APIs myself, and when it comes to interoperability, anybody should be free to reimplement the same interfaces, no matter how creative my design. Anything else would destroy competition in the software industry and promote a virtual dystopia of vendor lock-in.
But that isn't a technical argument. If it had some empirical support it might be an economic one, but it's mostly just an ideological argument. One that, I might add, many software engineers would disagree with.
The courts have regarded interoperability as a fair use in the past. https://en.wikipedia.org/wiki/Sega_v._Accolade
The Supreme Court spends much of its time interpreting the patterns that are laid out in the constitution and laws passed by congress. Sometimes it synthesizes a new pattern, which will be interpreted for the next 10's or 100's of years.
For copyright, there is some value in recalling patterns from the last few decades. For example, the film industry thought that TV and later VHS would kill their business. Another is when the music industry thought that radio, cassette tapes, and MP3 files would kill their business.
The problem of employing experts as the final judge is their bias towards a particular pattern. The time spent going deep in a particular field would mean that they have less time to go broad across all fields. IMO, how to benefit US commerce is about as broad as it gets.
[0]arstechnica.com/tech-policy/2012/09/how-a-rogue-appeals-court-wrecked-the-patent-system/
What have we done recently?
Supreme court justices are (hopefully) legal experts, not technical experts. Having younger supreme court justices doesn't change that _at all_. I don't know of many lawyers that know what an API is.
Sarah Jeong has written thoughtfully on whether justices need be tech savvy: http://sarahjeong.net/2014/04/23/scotus-is-bad-at-computers-...
The good thing about non-technical courts is that they force the parties to explain what is at stake in terms that every intelligent person can understand. This process is very important because it can highlight things that are often assumed by people in the trade. It is the law equivalent of "rubber duck" debugging.
A specialised court notorious for blindly enforcing tighter interpretations of IP laws reversed the decision.
You might want to try drawing your examples from reality, not prejudice.
I don't think it's a good idea to turn off copyright protection of APIs, moving all of them to public domain. Some of them may be "public bad" instead of "public good" if they don't get managed using license agreements.
However code is code, be it a library, module, framework, API, program or anything else...
Is MOOPH module copyright protected?
Most likely yes. Because you gave it a specific implementation that is not required to make it work. The functionality - and any elements of the module that spring directly from that functionality - is not copyrightable.
If you gave a programmer pseudo code for your module and they created near enough the same module from it then the creative elements don't lie in the aesthetic art and so the copyright in it is very weak.
Urgh.
Judges aren't writing laws - they're doing their job to "act as interpreters of statutes and the constitution by elaborating and precisely defining the broad language"[1]. There's a difference between "Judicial activism" and Common Law working as intended.
[1] https://en.wikipedia.org/wiki/Common_law#States_of_the_Unite...
This is by design. Its checking the powers of the other branches of government so we don't end up with "tyranny of the majority." Without judicial review, legislators are free to pass any law they'd like without taking into consideration the constitution. No constitution or law can interpret or enforce itself. Without enforcement laws are just pieces of paper. Someone's gotta do it.
Judges have the hard issue of interpretation of laws. Someone is probably going to disagree no matter what they do since every layman has an opinion and laws can sometimes be unclear. Just because your interpretation is different than theirs that doesn't mean that they are nessesarly wrong or trying to legislate. They may even thought they were right at the time but then time proved them wrong and then there must be reinterpretation.
"Judicial activism" is, of course, entirely subjective.
The other thing is times change. One interpretation might have worked 100 years ago but not today. The ethos of a populace are subject to change. New technology comes along. Interpretation can change with it.
Sometimes legislatures go back and try to change the wording of laws after judicial review to make the meaning clearer or to come into compliance of the construction. Or even implement new laws for various reasons.
It is an imperfect system. People are imperfect. They are subject to bias and the accepted values of the time period. The constitution and laws can also be vague.
Some people even think the Constitution is deliberately vague in many area in order to allow it to be a "living document" so it evolves with the times, so to speak. Of course, like most things, this is controversial.
Congress has the power...
"To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries." Article 1, Section 8, Clause 8
This is so vague that it practically begs for judicial interpretation.
when the federal circuit originally ruled i read the ruling and walked away with a completely different understanding than the eff touts in their headlines
this whole farce hinges on fair use stead copyrights
in terms we understand :
checkFairUse(GOOG_USE){
FAIR_USE=[http://www.copyright.gov/fls/fl102.html]
for (rule in FAIR_USE)
for ( usage in GOOG_USE) )
if ( usage < rule )
use="fair"
else
use="unfair"
if ( use == "fair" )
return true
else
return false
}
GOOG_USE=[googSRC]
if ( API_COPY == "left" || checkFairUse(GOOG_USE) )
print("allow legal use")
else
print("penalise")
why does the eff consistently tout copyrightability of apis? this case has yet to rule on copyrights was alsup being clever attempting to end the suit quickly using the mature, uncontroversial fair use clause, or was it a spineless way to avoid making a ruling on the question that the tech community really wants: are apis copyrightable?
slightly off topic, this whole debacle just screams avoid java at all costs because if you write anything financially successful in the language oracle is going to drag you through courts