4 ms·

I will bring up my prediction again: https://news.ycombinator.com/item?id=7282162 https://news.ycombinator.com/item?id=7282162 "My take is [APIs] would be foun

I will bring up my prediction again: https://news.ycombinator.com/item?id=7282162 https://news.ycombinator.com/item?id=7282162 "My take is [APIs] would be found copyrightable, but Google may probably prevail on fair use." [1] Unlike most here, I think this is the right decision given the current framework of copyright protection. This is because what copyright protects is the creative expression of a work. APIs, after all, are just another form of code, and requires the same (if not more) amount of creativity to design properly [2]. I see a lot of people here seemingly conflating this with patents (which protect functionality) or patent-like scope of protection. Copyright does not protect functionality, only the exact expression thereof. There are an unlimited number of ways to design an API for the same functionality. For instance, the file system APIs for Posix, Java, C# and Python are all completely distinct in their expression. The arguments against API copyrightability, taken to their logical conclusion, would remove copyright protection for all code. I'd like to see cogent arguments as to why copyright as it currently exists should apply to all other code but not API. ("Because we should be able to re-implement APIs" is not a valid answer, as that is begging the question. Without justification, you may well say that about any code.) I suspect that any valid arguments would indicate that copyright is not an appropriate means of protection for software. That would be unsurprising; code was shoehorned into copyright because it was a close enough approximation and didn't require formulating a whole new framework from the ground up [3]. Many others [4, 5, 6, 7] have explored the weird interplay of copyright protection and code, which at its heart, is functional (which copyright does not protect) yet is also creative (which copyright does protect). [1] Even if Google prevails on fair use, I still think that is unfair to Sun (and by proxy, Oracle). People ignore the massive investment, not only in engineering, but in marketing that Sun undertook to make Java as prevalent as it is today. I don't think it's fair to let another party hijack a hard-earned ecosystem without permission from its creators. [2] Some may argue the Java APIs are poorly designed. All I can say is, even the Twilight series gets copyright protection. [3] "The Uneasy Case for Software Copyright", http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2171451 http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2171451 [4] "The Strange Odyssey of Software Interfaces and Intellectual Property Law", http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1323818 http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1323818 [5] "Sum Greater than its Parts?: Copyright Protection for Application Program Interfaces", http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1325104 http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1325104 [6] "Copyright Protection of Computer Program Structure", http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1438164 http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1438164 [7] "IP's Problem Child: Shifting the Paradigms for Software Protection", http://papers.ssrn.com/sol3/papers.cfm?abstract_id=901604 http://papers.ssrn.com/sol3/papers.cfm?abstract_id=901604

clavalle 12y ago
> I'd like to see cogent arguments as to why copyright as it currently exists should apply to all other code but not API. For the same reason a textbook publisher shouldn't be able to copyright the table of contents of a calculus textbook: 1) It is merely a guidepost to the rest of the work and doesn't rise to the level of creativity of the meat of the text. 2) over time the structure becomes standardized because of the nature of the information it attempts to organize suggests that standard. For example: imagine an API for accessing student information. You have certain common characteristics for those students: Name, Address, Contacts, Schedule, Grades, Absences etc. I'd be willing to bet that if you put 10 people in separate rooms and asked them to create an API, 80% or more would be so close to one another that if someone studied one, they could find their way in another. And if showed a person who had studied the different APIs some specific part of a particular API they wouldn't be able to tell you which one it came from. They would not differ enough in 'style' to be readily distinguishable. Now imagine Strings. Or authentication or routes or any number of other aspects of computing that we have to deal with every day. Now, can the same thing be said of ten different authors of say a writing prompt that says "Write about a student who is having an altercation with a gym coach"? I'd argue that you'd get some very different and and easily distinguishable stories and styles.
- throwawaykf05 12y ago
  > 1) It is merely a guidepost to the rest of the work and doesn't rise to the level of creativity of the meat of the text. As anyone who has designed enough APIs will tell you (including engineers testifying on Google's behalf during the trial, and many commenters here who disagree with the decision), an API often requires more creativity than the implementation. Sure, the implementation is also difficult to do well, but making that implementation usable by others is no less a creative task. The "table of contents" analogy is backwards: you don't write the code first and then extract the functions into an API. That's how you get poor APIs. For a well designed API it's always the other way around. With enough creativity and forethought put into an API, the implementation flows naturally, and in practice, it's exactly the opposite of the table of contents analogy. (Not to mention that a ToC may also be copyrightable.) > 2) over time the structure becomes standardized because of the nature of the information it attempts to organize suggests that standard. The "nature of information being organized" sounds like "functionality" to me. As before, it is distinct from expression. > I'd be willing to bet that if you put 10 people in separate rooms and asked them to create an API, 80% or more would be so close to one another that if someone studied one, they could find their way in another. Consider the corollary of your argument. If you asked those same people to write actual implementations for that same problem. I'd bet you get the same "80% or more would be so close" results. Do you mean that their resulting code would not be covered by copyright? Consider whatever arguments you apply to defend copyrightability of the implementation, and try to differentiate them from the API case. Unless you provide a detailed spec and enforce some conventions, I'm willing to bet nobody will have an exact duplicate of another, either for implementation or for API. An API for the same functionality, say for getting the number of absentees, may be labeled getAbsenteeCount() or nAbsentees() or NumNotPresent(). Or even absenteeList().length(). Or a poorly defined API may require something like classSize() - numPresent(). Or a really badly defined API would require iterating over each member of the class and checking the "present" flag. And that is the point: each expression of the same functionality can be unique, and hence a candidate for copyright.

clavalle 12y ago

> I'd like to see cogent arguments as to why copyright as it currently exists should apply to all other code but not API. For the same reason a textbook publisher shouldn't be able to copyright the table of contents of a calculus textbook: 1) It is merely a guidepost to the rest of the work and doesn't rise to the level of creativity of the meat of the text. 2) over time the structure becomes standardized because of the nature of the information it attempts to organize suggests that standard. For example: imagine an API for accessing student information. You have certain common characteristics for those students: Name, Address, Contacts, Schedule, Grades, Absences etc. I'd be willing to bet that if you put 10 people in separate rooms and asked them to create an API, 80% or more would be so close to one another that if someone studied one, they could find their way in another. And if showed a person who had studied the different APIs some specific part of a particular API they wouldn't be able to tell you which one it came from. They would not differ enough in 'style' to be readily distinguishable. Now imagine Strings. Or authentication or routes or any number of other aspects of computing that we have to deal with every day. Now, can the same thing be said of ten different authors of say a writing prompt that says "Write about a student who is having an altercation with a gym coach"? I'd argue that you'd get some very different and and easily distinguishable stories and styles.

throwawaykf05 12y ago
> 1) It is merely a guidepost to the rest of the work and doesn't rise to the level of creativity of the meat of the text. As anyone who has designed enough APIs will tell you (including engineers testifying on Google's behalf during the trial, and many commenters here who disagree with the decision), an API often requires more creativity than the implementation. Sure, the implementation is also difficult to do well, but making that implementation usable by others is no less a creative task. The "table of contents" analogy is backwards: you don't write the code first and then extract the functions into an API. That's how you get poor APIs. For a well designed API it's always the other way around. With enough creativity and forethought put into an API, the implementation flows naturally, and in practice, it's exactly the opposite of the table of contents analogy. (Not to mention that a ToC may also be copyrightable.) > 2) over time the structure becomes standardized because of the nature of the information it attempts to organize suggests that standard. The "nature of information being organized" sounds like "functionality" to me. As before, it is distinct from expression. > I'd be willing to bet that if you put 10 people in separate rooms and asked them to create an API, 80% or more would be so close to one another that if someone studied one, they could find their way in another. Consider the corollary of your argument. If you asked those same people to write actual implementations for that same problem. I'd bet you get the same "80% or more would be so close" results. Do you mean that their resulting code would not be covered by copyright? Consider whatever arguments you apply to defend copyrightability of the implementation, and try to differentiate them from the API case. Unless you provide a detailed spec and enforce some conventions, I'm willing to bet nobody will have an exact duplicate of another, either for implementation or for API. An API for the same functionality, say for getting the number of absentees, may be labeled getAbsenteeCount() or nAbsentees() or NumNotPresent(). Or even absenteeList().length(). Or a poorly defined API may require something like classSize() - numPresent(). Or a really badly defined API would require iterating over each member of the class and checking the "present" flag. And that is the point: each expression of the same functionality can be unique, and hence a candidate for copyright.