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.*
Asterisk:
"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."
I think it was a tactical mistake to include the folks affiliated with Google. Amicus briefs are supposed to be from parties who have an interest in the dispute, but not a personal stake in either party. Including so many people affiliated with Google will come across negatively.
Unfortunately, it's just a background fact that Google employs a lot of well-known computer science figures. So this was bound to happen unless they explicitly forbade them from signing this, which I also don't think is good.
I find "30. John Gage" interesting in that he was Chief Scientist at Sun. I always thought that Google's Dalvik was a hack around Sun's business model for Java, in bypassing the need to license JVM. The fact that John Gage signed the brief seems to imply that he considers Google's hack to be less ominous than Oracle's attempt to change the game.
The Java class/jar file formats are inherently slow and Dalvik's dex code fixes that problem. I don't think the licensing hack would have worked since you can't escape patents by making syntax changes.
It probably depends whether the people reading it know who the people signing it actually are. Vint Cerf, Ken Thompson and Ray Kurzweil now work for Google but that doesn't mean they aren't still Vint Cerf, Ken Thompson and Ray Kurzweil.
Like the earlier post said, amicus curiae briefs are filed on behalf of people who are not parties to a case. They may have an interest, but it can't be "we're suing/being sued in this particular case." Maybe it's different for employees of a firm, but Google is certainly a party to the case.
If you know any of the back story of those names you would have known that none of them would need to affiliate with any company. They are basically the deity of our age. Without them we would not have modern computers and the only handhelds we have are rocks.
So why do you believe Rod Canion is somebody expected to be in this list? It's a letter signed by the people who made some significant contribution to the "scientific" not to the "business" aspects of computers.
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.
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?
Many in this thread seem to be wondering about the legal argument itself -- that API's being copyrightable is inconsistent with existing pretty well-established law.
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)).
I don't think the cited case law for exemptions for interoperability in interfaces applies to this case. For instance, the Sega and Sony cases apply for, as far as I can tell, computer systems interoperating with each other. Lotus applies to humans operating software applications running on computer systems. APIs on the other hand, are mainly for humans to communicate with each other when building systems that interoperate. As such, APIs are primarily a means of expression between humans - from those who provide the interface, to those who use it. So from a copyright perspective, I don't see how binary interoperability between systems or the GUI layouts can compare to textual expression between humans.
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.
> APIs on the other hand, are mainly for humans to communicate with each other when building systems that interoperate.
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.
"Interface" is an overloaded word, which muddies the waters quite a bit. It's even more confounded by the fact that one type of interface (APIs) are used in code that often compiles down to another type of interface (protocols/ABIs).
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.
>>functional requirements for compatibility” between computer programs “are not protected by copyright
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.
> 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?
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
> 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.
Incorrect. The right to prepare (not merely distribute) derivative works, including translations, is one of the exclusive rights of creators included in copyright. [0]
Quick question: Why can't an API be copyrighted? My understanding is that the purpose of a copyright is to protect a specific arrangement of ideas. A piece of music, a book, a painting. All of those things are an arrangement, and the arrangement itself is what's protected by copyright, not the physical object that was created.
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?
> purpose of a copyright is to protect a specific arrangement of ideas
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.
One thing that many in the tech world get hung up on is the idea that this is arguing that designing APIs is not a creative endeavor. That's not what's being argued here.
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.
> it's saying that as a method of operating that code, they aren't copyrightable
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.
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?
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.
So, I think you are right that computer software problematisizes much of copyright law, and this is how we get to this confusing situation.
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.
>* But in that case, why are instruction booklets copyrightable, but not software APIs?* //
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.
That isn't really a problem. You can have two programs that do the same thing, e.g. BSD cat and GNU cat, but you're copyrighting the specific implementation rather than the method of operation. Each method of operation can have arbitrarily many different implementations.
By that logic, copyrighting APIs is not really a problem either: Each API can have arbitrarily different concepts, paradigms, organization, and naming and calling conventions. Hence even APIs for doing the exact same things can (and do) look completely different from each other. Compare, for examples, the Java APIs with those for C++, C#, Python, Ruby, Go, etc. etc.
> Each API can have arbitrarily different concepts, paradigms, organization, and naming and calling conventions. Hence even APIs for doing the exact same things can (and do) look completely different from each other.
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.
> If they're "doing the exact same things" then they're the same API.
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.
They aren't doing the same things. You can't copyright a bolt with specific dimensions and thereby prevent anyone else from making nuts compatible with your bolts or bolts compatible with your nuts because you can't copyright function. It is also true that you can't copyright the entire concept of a bolt, but how does that help you?
Let's try a specific example. Here's a function from the C library:
int tolower(int c);
The following is not the same function:
int64_t tolower(int64_t c);
Even though the concept of what the function does (convert a character to lowercase) may be the same, you still can't switch them around in the compiler's symbol table. You can't link a binary that calls one with a library that implements only the other. They are not functionally equivalent.
I don't see the relevance of that. Of course those are NOT the same function. But they would logically belong in the same overall API, where "API" as used in this particular context means an overall logical collection of modules and methods, such as that of a standard library. The more relevant comparison would be between "int tolower(int c);" and "char java.lang.Character.toLowerCase(char 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.
It's important (and sometimes difficult for us technically oriented types) to recognize that the law isn't necessarily (despite what Scalia would have us all believe) a slavish dedication to the precise words, and that the broader context and purpose of the law is taken into account when making judgements.
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.
There's lots of previous caselaw in the U.S. suggesting API's are not copyrightable, basically on the theory that functionality itself, as well as factual statements or descriptions of something, are not copyrightable.
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.
Actually a recipe can be copyrighted for it's content as well as patented.
Pharmaceuticals do it all the time, the biggest problem of copying a drug is not breaking what its made off but how is it made which is exactly what a recipe is.
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.
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.
Drug companies patent both compounds and processes.
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.
I don't recall which case this was in, but the court in one of the early API cases noted that allowing copyright of APIs would give the copyright owner control over the use of their software that is almost the same as the control a patent gives a patentee over the use of their invention--except for a much much longer term, and without any requirement of novelty or non-obviousness.
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.
Simple answer - it's too generic of a level to allow copyrighting it. It ends up in vendor lock-in and anticompetitive behavior. Same reason abstract ideas aren't allowed to be copyrighted - it gives too much monopoly to those who would claim them.
This is actually a very major issue. They are copyrighted to varying degrees.
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!"
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.
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.
So, the census needs maps (and best we are able to double check that, as it is used to apportion representatives). But also: the modern nation-state is, in many ways, founded on the notion of maps. A nation exists not just by itself but instead of and in place of other government. So it's pretty reasonable to assume public maps come from a time where e.g. the western border of the country was fuzzy and who controlled what was information of great importance. For instance, if it's 1823 and I'm looking to farmstead, a map both legitimizes, in some way, American rule, and delineates reality about Comanche raids (which were not something you'd want to bump into).
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.
This issue is rapidly coming to a close. The disruption of the mapping companies (and sovereign mapping efforts) is going power law now because of mobile devices.
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.
ESRI is an interesting example. On the one hand they make have some seriously talented cartographers who have made some astonishingly beautiful maps, and surely they should be able to copyright that work. On the other, they actually do provide quite a lot of things (including access to their tile servers) for free or under permissive licenses.
In a world where people copyright the laws you are supposed to follow I can't imagine they won't let people copyright an API that absolutely is a creative work. Instead we should accept that they can be under copyright but make implementing and using them explicitly fair use.
Book Titles are not copyrightable, even though they are arguably the most important part of a creative work. While APIs are not a clear analog to titles, they are a huge exception to the copyright law, and it seems like APIs need this exception as well.
Sure, but only once the title has attained secondary meaning over and above the words in the title. Basically, it has to be beyond the level of a bestseller. Most book titles don't come anywhere close.
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.
Whatever you may think the wording of contracts [etc] pretty clearly falls under copyright protection in the US. The wording.
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).
Government work products like statutory text is not typically protected by copyright. I think spullara was referring to model law codes written by private organizations and adopted verbatim by legislatures.
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 really do hope we can't copyright a single function signature. But then, you expand it into an entire framework, or the perfectly designed kernel... What is software if not a collection of API calls? There's clearly something worth copyrighting at some point.
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.
I'm a little confused by how precedent works here.
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)?
Quick question, where do Mono/Xamarin or similar projects stand on this whole API copyright? Aren't they essentially writing a library with the same API as the .NET or other single-platform framework? Or am I misunderstanding what they meant with API in this case?
Yes, this case is highly relevant to Mono/Xamarin, although in practice I think it would be suicide for Microsoft to start suing people who clone their technology. Note that Miguel de Icaza is a signatory.
That is not good enough. Sun Was bought by Oracle and things changed. If Microsoft declines further, whats stopping from Oracle or someone else repeating the same?
Did Sun ever make a public statement that anybody is allowed to independently re-implement (subsets of) the JRE class library APIs? I don't recall such a promise. Probably it's tied to the notorious TCK certification process that always was entirely at Sun's discretion.
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.
Estoppel. Since everyone acted in good faith when they availed themselves of Microsoft's pledge, the court will look very poorly on an attempt by Microsoft to rescind it.
It would affect anything that implemented another API. Oracle could sue IBM and Postgresql for implementing Oracle SQLisms in their products. IBM could sue Oracle for appropriating SQL. WINE would exist by the grace of Microsoft. AT&T would have won their lawsuit against Berkely.
While I personally fully support this, I wonder if we shouldn't be doing this in two stages, where the first stage is that we ask the penalties for perceived AIP copyright or intellectual property infringement be modified. Multi-million and multi-billion dollar lawsuits continue to be sickening in a world where these dollar amounts could be used to save human lives. Long live FLOSS, but we need to also be strategic and remember who our audience is.
Microsoft had licensed Java, and had agreed to the terms of Sun's trademark license, including compatibility terms. Google avoided licensing Java entirely, hence the lawsuit.
Microsoft was granted a right to use the Java trademarks under certain conditions - conditions which it then violated while continuing to use those trademarks, meaning it was violating Sun's Java trademark, not the copyright. Google avoids using the Java trademarks entirely.
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".
i Think the best analogy to this situation: Oracle (or its predecessor) published a cookbook and it tries to indemnify anyone profiting from it, like a restaurant or catering service that utilizes the same recipes compiled therein..
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
Although these issues are very important, something feels wrong about having the Supreme Court justices (avg. age ~70) rule on tech matters like this.
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).
> Although these issues are very important, something feels wrong about having the Supreme Court justices (avg. age ~70) rule on tech matters like this.
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.
>Or perhaps a trial by jury where the selection criteria is employment in the relevant discipline for at least 10 years (academia or corporate).
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.
Yeah, that comment was silly. SCOTUS decides ~100 cases a year, and less than 10 are 5-4 decisions. Even even some of the 5-4 votes aren't split along ideological lines.
Sometimes you can predict how a given Justice will act, based on how he feels about the specifics of similar cases.
The entire US system is predicated on regular citizens making the most important decisions to protect against unjust and corrupt decisions made by experts (judges). You example is EXACTLY the problem with the idea of special courts or special juries.
Old age doesn't automatically mean technological incompetence anymore.
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.
The problem is the reprehensible ageism inherent in claiming older people are not capable of understanding technology. The same ageism you are implicitly supporting by "reassuring" us that young people (hence, magically tech-savvy people) will have input.
A bit shrill, I think. I don't think it's ageist to acknowledge that a lot of technologies didn't exist when older people were born and, thus, they are less likely to be familiar with them. That doesn't make them dumb, it's just an accident of history. And certainly I think that a good lawyer (and amici) should be able to explain anything the justices need to know -- the justices, whatever else you may think about them, are very intelligent people and surely capable of understanding just about anything, given sufficient time, regardless of their age. (Though this time caveat is a significant consideration. Overcoming that restriction is largely what clerks are for.)
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.
"The lynchpin of copyright is originality and creativity. Are the Java API's original and creative? That's the only relevant question.[2]"
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.
> 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).
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.
>* the concept of passing around file descriptors as small integers, etc, is definitely a creative expression, distinct from the underlying functionality* //
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.
" 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"
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.
> 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.
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.
"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."
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.
> By this argument, everything ever, including my shopping lists are creative expression and copyright eligible.
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?
"but if you do use creative expression in write your shopping list, why is it not copyright-eligible?"
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?"
> What would it mean to use creative expression to write a shopping list?
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.
It would seem to me that the exemptions in 17 USC 102(b), reading its text, could certainly be interpreted so as to apply:
"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?
> 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.
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.
simply does not care about whether finding API's to be copyrightable hinders interoperability or cloning of software.
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.
> [A]nybody 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.
Not practicing anymore, but I had those political views while I was working as an engineer. I simply don't believe you have a blanket right to inter operate without the consent of the creator. I bet you'll find plenty in companies that actually create and sell software as their business model.
Seems like a tradeoff between fluid intelligence and pattern recognition. In my 20's it was easier to pick up new concepts, with longer short term memory. In my 50's, I have acquired more patterns to apply. The downside, when I was younger, was going down blind alleys that wound up as a dead ends. The downside, when I got older, is misapplying an old pattern instead of synthesizing a new one. That's why I liked working with older people, in my 20's, and now working with younger people. To balance both tradeoffs.
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.
You don't want a special purpose court with supposed experts running anything. We have a special purpose patent court with technically experienced experts and they're the ones with the agenda to destroy the startup and independent software ecosystem by expanding patents to cover every aspect of software.[0]
The expert-witnesses are ment to explain the problems in laymen-terms, while the court is to precide over the judicial implications given by the law that are a supposed as a level baseline. If the expert would be judge directly, he'd need expertize in law or possibly require judicial expert-witness. The Jury is supposed to level bias. Industry experts in politics is more sensical, as legislature is where by definition speciallized law is written. They are littered with economic opinions, not to say business sock puppets, already, while judges are merely incompetent on technical matters atop being burdened with - let's say - type-unsafe law code. This happens already of course, but there's little opportunity for activist, apparently.
How could a group with exceptionally sharp minds who have lived through 7 decades of intense technological and social change possibly have better perspectives than people who have lived through 2?
They all are EXTREMELY intelligent people! BUT the issues presented can be lost and then we are dependent on the staff of the justices who explain issues and then the bias of the people "educating" the justices have a HUGE influence on the justices.
Is it not the staff, but expert-witnesses? Of course the influence of the technical advisory is subjective, so is the judge's. Arguably, more subjectivity levels out the preciseness of the judgement, it's a compromise, but certainly not unwelcome, when jury is invited to weigh out bias with it's own necessarily biased opinion. You can't get that out of the equation, because ...
I agree, the ageism implied by the OP is rather disappointing. I'm relatively young (mid-30's), but the persistent implications that anyone over 40 is technical inept is rather infuriating.
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.
Good question. It probably is not relevant. I presume it's predicated on the notion that olds are generally less tech savvy (and therefore less capable of fairly & reasonably adjudicating technology cases.)
> We need a new legal system for arbitrating disputes in technical disciplines overseen by a panel of technical experts.
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.
The problem is not with the legal system, it's with the lawmaking system. Bad laws produce bad lawsuits which produce bad rulings. The fundamental problem here is IP legislation, and how poorly it was written. Or maybe the problem is one level deeper, and it's actually with the electoral system and how it selects for inadequate lawmakers.
Actually, this is perfect for the Supreme Court because a court set precedent aside with a rather novel decision. The issue is not a matter of technology, it's a matter of law. I think the court knows what it is doing.
I've created MOOPH module in JavaScript. Purpose of this module is to make it easy to code a pseudomultithreaded application (so it can be seen as API). This module can be used to create various creative content (games, editors, whatever...). However one of possible pseudothreads may include quickly content from external sites to DOM - making a DOS. If multiple users access such project, it could make a DDOS. I hope this module is copyright protected. I hope anyone who wants to use (publish on their site) this module must ask me (I am author) if I allow use of this module anywhere else than on my domains (where I've uploaded and publish my code, applying copyright).
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.
If your software is so bad it's harmful to the general public, you don't release it at all, rather than relying on the law to somehow prevent bad people from misusing it.
I've looked the meaning of word "interface" out. I used slovnik.cz (translator). Interface is translated as point of contact, connection, relationship, coordination, correspondence. In some czech phrases it's translated as bus (in USB) or as interface (GUI) or as interface if we speak about point used to connect peripherals to computer. In one of meanings it is close to the meaning of word "edge". I wouldn't be surprised if translation created disorder in law...
I've always understood API as "Application" (meaning application, program, something similar to script) "Programming" (creating code, writing) "Interface" (abstract definition of meaning of variables and functions, preferably with some code that makes those meanings "live", something real, "behind" those variable and function names). Maybe I'm wrong.
However code is code, be it a library, module, framework, API, program or anything else...
Code can implement an API, but an API is not code. Not using any reasonable definition of code. Code is something you are theoretically able to execute, in one way or another.
The term "code" also on my opinion doesn't have only one meaning. You can for example see the HTML code in your browser if you use "view source code" functionality of your browser. So authors of browsers consider HTML the code. I've always thought about code as about some text that's machine processable (parsed, interpreted, compiled...). This means I've also seen API as a code.
OK, for some time I've lived in one file projects (PHP) where I've defined interface and in the same file implemented the code itself, so I've seen too little difference... Maybe in other projects the difference is sharper.
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.
This world where judges are effectively used to write laws is bullshit and it sucks. Judicial activism sucks ass. Judges are not supposed to be lawmakers. If API's should not be protected by copyright then we should be writing letters to actual lawmakers who can write that explicitly into law. Not rely on interpretation of political appointees.
> This world where judges are effectively used to write laws is bullshit and it sucks.
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.
People treat judges as a way to write laws. Many judges like to use their powers to make rulings on what the law should be rather than is. So I'd strongly argue that yes, in a roundabout way judges are in fact writing laws.
"Many judges like to use their powers to make rulings on what the law should be rather than is."
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.
> justices should review a disastrous appellate court decision finding that application programming interfaces (APIs) are copyrightable
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")
so alsup says that even though API_COPY==undefined the statement still passes because he found GOOG_USE to be "fair", the federal circuit is saying GOOG_USE!="fair"
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
"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."