17 ms·

Having read multiple perspectives, some pro-Google and some pro-Oracle, I cannot reconcile this sort of argument with the Baker v. Selden precedent. [1] Perhap

Having read multiple perspectives, some pro-Google and some pro-Oracle, I cannot reconcile this sort of argument with the Baker v. Selden precedent. [1] Perhaps my understanding of APIs is different because I'm an engineer and not a lawyer, but how is this not an open and shut case? The cookbook analogy is not applicable for the same reason one could not apply it in Baker, accounting methods are not of themselves copyrightable creative works. (They may be patentable, but I believe patentability is NOT at issue here.) Selecting and arranging recipes requires creativity. I do not believe API code of a math library is in any way the same level, having designed hundreds of APIs and several SDKs myself. Perhaps creating a specification upon which the API design based upon is, but that leads right back to Baker. What am I missing here? [1] https://en.wikipedia.org/wiki/Baker_v._Selden https://en.wikipedia.org/wiki/Baker_v._Selden Edit: And if you think about it, an API code is really just a set of templated forms for conveyance of data between systems. In this sense it is really no different from the accounting ledger templates in Baker. Second edit: It would be worthwhile to enlighten the judges on the early history of computer programs and their ties to recipes which should make the cookbook analogy and its potential misapplication here even more obvious. Third edit: Another line of enquiry would be to discuss differences between API contracts and APIs. They are not the same, though often confused, even by practicing software engineers.

interpol_p 6y ago
I'm not going to argue whether I think APIs should be copyrightable, but I believe creating a good API is a work of creative design, and is artistic I design an API for graphical coding and spend significant creative energy choosing the right words, calling conventions, result types to not only make something intuitive, but emotionally pleasurable to code with Sometimes I'll spend days writing out possible forms of the API — changing words, tense, syntax, until it looks and feels "right." These aren't arbitrary or purely functional decisions Do I want my users to "read" text from a file, or "open" the file? Do I want them to handle keyboard events in a simple global function or assign callbacks into a keyboard handler under each character name. How are those callbacks shaped? What's easy to understand? APIs aren't just restricted simple functions and types. Some may involve the creation of a custom DSL to make it easy to declare functionality in part of your system, or clusters of protocols that work together in very specific ways so users can implement a complex system atop them
- andrewjl 6y ago
  > I'm not going to argue whether I think APIs should be copyrightable, but I believe creating a good API is a work of creative design, and is artistic I disagree. I think the specification can be, but the API code itself is a mechanical translation of the specification into computer code. Note that abstractions, names, etc are conceived in the specification and are then translated into computer code. Even if you skip the specification step, as sometimes is done, you're then dealing with an implicit, ad-hoc specification. Edit: To clarify what I'm saying, the "creative design" aspect of what you're talking about and that I'm in no way denying, is meant to be protected via the patentability and not the copyrightability of the end product. The creativity is in the behavior not in the mechanical translation of the behavior for computers to use. > APIs aren't just restricted simple functions and types. Some may involve the creation of a custom DSL to make it easy to declare functionality in part of your system, or clusters of protocols that work together in very specific ways so users can implement a complex system atop them Indeed. Yet you're still describing behavior here. A DSL is an example of a specification of one language in terms of another. This is a creative work, I strongly agree! The difference is where does the creativity reside? I don't believe it's in the API code, but in the specification whether written or unwritten and therefore implied.
  - enraged_camel 6y ago
    I think your definition of "creativity" is too narrow. Which is perhaps not surprising, since you say you're an engineer. ;)
    - andrewjl 6y ago
      I think you're misunderstanding what I wrote. The creativity that people commonly associate with an API is in the behavior of the API, not in API code. API behavior is no doubt a creative work. If you consider the API to be nothing but code, then your definition of an "API" is too narrow. Nothing I've said should be construed as denying the richness and brilliance found in the design of software and software-based abstractions.
  - interpol_p 6y ago
galaxyLogic 6y ago
> accounting methods are not of themselves copyrightable creative works. True. Neither are 'ways of calling library functions" copyrightable. But in the case of Java API what was copied was the actual Java-code in which the APIs are expressed. Because the APIs are "fed" to the compiler as Java source-code, it is clear what was copied was not just the "way library-functions are called". What was copied was Java SOURCE-CODE which allows a Java compiler to ENFORCE and INTERPRET such calling conventions. Even if the API was rewritten in another programming language it would be a copyright violation if large parts of the structure of the API meaning how the methods are organized into classes and interfaces and how they refer to each other, was copied. That would clearly be a work of art that deserves copyright protection, in my view.
- andrewjl 6y ago
  From the Baker opinion: "The conclusion to which we have come is, that blank account-books are not the subject of copyright; and that the mere copyright of Selden's book did not confer upon him the exclusive right to make and use account-books, ruled and arranged as designated by him and described and illustrated in said book." [1] I believe based on this reasoning, copying APIs or copying code is a distinction without a difference, so long as it's in the context of calling library functions. [1] https://supreme.justia.com/cases/federal/us/101/99/ https://supreme.justia.com/cases/federal/us/101/99/
  - galaxyLogic 6y ago
    Are you saying code which calls library functions should not be copyrightable? The Baker opinion can of course be used as argument pro-Google. But it is also just an "opinion". Each case must be decided on its own. I believe there is a big difference between scale and structural complexity with the (inter-connected) Java API and some text-book examples of accounting layouts. At some point quantity becomes quality.
    - deleted 6y ago
      [deleted]
    - 6y ago
mumblemumble 6y ago
The Google v. Oracle argument hinges on Structure, Sequence, and Organization[1]. Things like the actual package structure arguably involve creative decisionmaking, and are not strictly analogous to something like accounting methods. For example, even if the idea of a max() function that takes two integers and returns the larger of the two is not copyrightable, the specific name "java.lang.Math.max()" might still be. Especially if you're talking about not just one function, but some enormous number of methods in some large number of classes across 37 different packages. [1]: https://en.wikipedia.org/wiki/Structure,_sequence_and_organization https://en.wikipedia.org/wiki/Structure,_sequence_and_organi...
- andrewjl 6y ago
  > Especially if you're talking about not just one function, but some enormous number of methods in some large number of classes across 37 different packages. See my other reply down thread, but my own reading of Baker seems to indicate this specifically is not a factor. 37 packages vs 1 method should make no difference. Copying one ledger template or copying hundreds is not a violation of copyright in the same way, because copyrights don't extend to methods of practice. I'll have to read up on the SSO stuff as it appears there are more relevant & recent precedent cases there.
  - mumblemumble 6y ago
    The 2014 decision, for one, hinges on it being a whole package structure and not just one method: Google copied the declaring source code from the 37 Java API packages verbatim, inserting that code into parts of its Android software. In doing so, Google copied the elaborately organized taxonomy of all the names of methods, classes, interfaces, and packages — the "overall system of organized names — covering 37 packages, with over six hundred classes, with over six thousand methods." Copyrightability Decision, 872 F.Supp.2d at 999. The parties and district court referred to this taxonomy of expressions as the "structure, sequence, and organization" or "SSO" of the 37 packages. The Baker ruling is specifically addressed in that one, and they call out exactly how it is relevant to Oracle v. Google: The Baker precedent says that the parts of a design that are strictly essential to its function are not copyrightable. But the parts that involve some art - such as - according to this opinion - the taxonomy introduced in a package structure - are copyrightable. In other words, you can think of SSO as shorthand for, "The things that aren't covered by the Baker precedent." We also have, in the same opinion: When assessing whether the non-literal elements of a computer program constitute protectable expression, the Ninth Circuit has endorsed an "abstraction-filtration-comparison" test formulated by the Second Circuit and expressly adopted by several other circuits. ... This test rejects the notion that anything that performs a function is necessarily uncopyrightable. (Disclaimer: This is not meant to imply that I think that Judge O'Malley's 2014 opinion is the final word on the case. I'm just picking some highlights from an opinion on this case that might shed some light on how the Courts are approaching the issue.) (https://www.leagle.com/decision/infco20140509135 https://www.leagle.com/decision/infco20140509135)
marta_morena_29 6y ago
> I do not believe API design of a math library is in any way the same level, having designed hundreds of APIs and several SDKs myself. Oh given that the APIs were "designed" by Oracle, that stance might be relatable. However, designing actually "good" APIs will turn out equally complex if not more complex than arranging some recipes in a cookbook. Most stuff that Oracle does falls more into the category of a "monkey throwing dart arrows at random code snippets" and then suing the heck out of anyone who breaks their copyright or licenses (Oracle doesn't make software, they make licenses and that's how they earn money. The software is secondary).
mlthoughts2018 6y ago
> “ Selecting and arranging recipes requires creativity. I do not believe API design of a math library is in any way the same level, having designed hundreds of APIs and several SDKs myself.” I have designed hundreds of APIs and SDKs myself as well and I could not disagree with you more. API design is about deliberately and creatively considering the domain model of your user (whether that domain is Int or Float for a user who is a low level system programmer or the domain is CheckingAccount and SavingsAccount for a user who is a banking application developer, or anything in between or beyond). You creatively set up APIs so that composition of the API primitives allows direct expression of solutions in the user’s domain. This is exactly like arranging recipes in a recipe book, to organize sections for different styles, meals or amount of prep time, holiday themes, etc. That is exactly software API design to a tee. This article highlights it for me: https://blog.keras.io/user-experience-design-for-apis.html https://blog.keras.io/user-experience-design-for-apis.html
- deleted 6y ago
  [deleted]
nodamage 6y ago
Can you clarify how you think Baker applies here? The underlying point from that case is that an accounting method is an idea and copyright protection does not extend to ideas, only specific expressions of that idea. I'm not sure the situation here is all that similar.
- andrewjl 6y ago
  > Can you clarify how you think Baker applies here? "The conclusion to which we have come is, that blank account-books are not the subject of copyright; and that the mere copyright of Selden's book did not confer upon him the exclusive right to make and use account-books, ruled and arranged as designated by him and described and illustrated in said book." [1] [1] https://supreme.justia.com/cases/federal/us/101/99/ https://supreme.justia.com/cases/federal/us/101/99/ My reading is that the mere use of an API is a method of practice. It does not matter if the API is simple or complex, in the same as it didn't matter if a single page or multiple pages of account templates were used.
  - nodamage 6y ago
    > My reading is that the mere use of an API is a method of practice. The problem is Google didn't merely use the API, it reproduced the API entirely and necessarily copied several thousand lines of code in the process. Code itself is generally copyrightable so it is difficult to argue that the specific type of code that makes up the Java API declaration is exempt from this.
    - andrewjl 6y ago
      Apologies, I didn't express myself well when writing that. I meant that all API code is embodied practice. Thus API code itself is in no way different from ledger templates at issue in Baker. Reproduction of an API in its entirety is no different from reproduction of an embedded practice. Any arguments I've seen so far that argued for parts of API code not being embedded practice were not taking into account how API code is used by software engineers.
mrh0057 6y ago
I think people get thrown off because an API is describe through lots of text and can be huge, where as other things are just a layout. The recipe book itself is copyrightable but the language used to describe the recipe isn’t.
- jrochkind1 6y ago
  Actually the language used to describe the recipe might be. it's just that the recipe itself is not, the fact that you mix 2 cups of this with 1 cup of that and bake at so many degrees. So language that's a plain listing of that in a standard format isn't copyrightable, because it's just a straightforward way to list the uncopyrightable recipe. But if you use especially creative and unique language to describe a recipe, that particular language might be copyrightable. The recipe as a recipe is not; the language used to describe it can be, if it's an unusual or creative way to do so. But someone can most definitely always use their own language to express the same recipe -- the same ingredients in the same amounts combined in the same ways, is not copyrightable. This has until now seemed like it should also mean that the API as API is not copyrightable, and a straightforward implementation of something like `min` is also not, as it's just the only reasonable way to implement `min`. But an especially clever or creative algorithm to implement a part of an API might be.
  - mrh0057 6y ago
    The language would be English not the text itself. An api is an language on how to communicate with something. The language itself shouldn’t be copyrightable but any documentation is copyrightable.
austincheney 6y ago
I am a software engineer and it is certainly NOT open and shut for me. APIs are code definitions just as are interfaces, custom types, classes, and so forth. I don’t think APIs should be treated differently than other code only because you need it to be so for your convenience. If APIs should be treated differently they need to be defined separately and licensed differently. Other languages and platforms makes this very clear by externalizing most APIs from the language and then adding support for the API to the language as though it is a foreign technology, because it’s definition and license are separate.
- andrewjl 6y ago
  > externalizing most APIs from the language and then adding support for the API to the language as though it is a foreign technology That's true, but only in the case for the language's standard library. But what about the API of the language's top-level constructs? A class must have an initializer, for instance. Or protocol / interface has the notion of required as well as optional methods. Why is the latter (language APIs) not copyrightable but the former (standard library APIs) is? What is the substantive difference between them?
  - austincheney 6y ago
    Yes, there must be some few primitive APIs within a given language. An example is base types and their most essential methods for internal constructs that aren’t meant to be exposed. Unfortunately, Java is just such a perfect for this legal fight. It is proprietary and exists in this nebulous universe of wanting to make everything Java. It’s like Microsoft of the 90s.
- imtringued 6y ago
  >Other languages and platforms makes this very clear by externalizing most APIs from the language and then adding support for the API to the language as though it is a foreign technology, because it’s definition and license are separate. What? No. Most modern languages do the opposite. Usually everything is defined directly in the standard library and syntax is often merely sugar to call specific functions in that standard library or to refer to specific definitions in that standard library. Primitive numeric types like int, short, long are no longer hard coded directly into the compiler. Instead they are defined in the standard library and the compiler is just employing optimizations where possible to make them behave like primitive types. Although Ceylon is dead I like to use it as an example. Almost everything was defined in the standard library. Even keywords in java like public, abstract, static are merely just annotations in Ceylon that were defined in the standard library.
rayiner 6y ago
The difference is that Baker didn’t involve literal copying of the accounting tables. Baker is treated as a merger case, but it’s more a case about the difference between copyright and a method patent. Baker claimed that copying the general structure of the tables was infringement. The court essentially held that the structure that was copied was the structure dictated by the method itself. And Selden couldn’t copyright any table that had the same structure because that would give him a monopoly on the method. Here, the Java APIs were copied literally. For example, say you’ve got a function to append an item to a list: Append(item, list) Append(list, item) If you changed the order of the parameters, you wouldn’t be literally copying, even though it’s the same basic signature. That’s the Baker case. You can’t monopolize the method of appending an item to a list by extending copyright to all possible permutations of the limited ways to write the signature. But what happens if you do literally copy? That’s this case. Then, the question is whether these choices of where to put the parameter reflect any creativity. I happen to think they do—I strongly prefer the first form, which is how it’s done in the Common Lisp standard library.
- andrewjl 6y ago
  > Then, the question is whether these choices of where to put the parameter reflect any creativity. Interesting. This argument seems to imply that languages are copyrightable based upon creativity in ordering, punctuation, use of certain expressions such as `&`, etc. How is that different from your example? In fact a computer language itself is nothing but an API to a human-readable specification for machine behavior. I can see the specification being a creative work and hence being patentable. I don't see the same for the API code. I'll have to think more about it. I can't offer a more substantive counter-argument now.
- nitrogen 6y ago
  Then, the question is whether these choices of where to put the parameter reflect any creativity. Though the choices are creative, it's necessary to replicate them exactly to produce a functioning interface for existing Java code. It's like a design for an electrical connector; maybe patentable, but it's essential to the function so shouldn't be copyrightable.
wahern 6y ago
> I cannot reconcile this sort of argument with the Baker v. Selden precedent. Contemporary judges, including on the Supreme Court, aren't interested in reconciling Oracle's argument with Baker v. Selden; there's no love for Baker. Courts may pay lip service to the notion that ideas can't be copyrighted, but the prospect of ruling as a matter of law that specific, concrete categories of works are categorically not copyrightable (especially if they're not patentable) seems illogical to them. Previous hard exclusions, like those related to automobile designs, textiles, and databases are already on the way out, unfortunately, just like the idea that entry into the public domain is a one-way street. The case law has been slowly moving in this direction for at least 20 years, but it's too painful for many to admit despite judges (e.g. Ginsburg) being crystal clear about the direction they want to take things. Judge Alsup's original opinion declaring APIs not copyrightable is brilliant and the best argument anyone could possibly make. It is the best argument, period, IMO. But the basic premise is just anathema to the majority perspective on courts' role regarding the application of copyright law.
- andrewjl 6y ago
  Are there some cases you can cite where this movement occurred? They don't need to be software related. I'm VERY curious about this trend.
  - wahern 6y ago
    Off the top of my head: * Star Athletica LLC v. Varsity Brands Inc., 137 S. Ct. 1002 (2017) * DC Comics v. Towle, 802 F.3d 1012 (9th Cir. 2015) * Golan v. Holder, 565 U.S. 302 (2012) One of the most important cases for contemporary copyright law was Feist Publications, Inc., v. Rural Telephone Service Co., 499 U.S. 340 (1991). It was a nominal a win for the defendant, but in fact the opinion set a very low bar and effectively condemned the types of bright-line subject matter exclusions that a robust merger doctrine demands, such as in Baker v. Selden. IIRC, Alex Kozinski wrote some opinions that best reflect the majority perspective today, but I can't find any good citations right now. His arguments are persuasive, but sort of miss the point. Baker v. Selder and the merger doctrine are classic common law solutions to statutory rights that breed complex litigation and inhibit competition. They're not supposed to be intellectually pure or rigorous defenses of legislative powers. Quite the opposite. But courts are far more conservative today and not inclined to exercise their judicial powers this way, with the notable exception of the First Amendment. In fact, certain First Amendment defenses to infringement are slowly becoming more viable, where once upon a time they were dismissed out of hand.

interpol_p 6y ago

I'm not going to argue whether I think APIs should be copyrightable, but I believe creating a good API is a work of creative design, and is artistic I design an API for graphical coding and spend significant creative energy choosing the right words, calling conventions, result types to not only make something intuitive, but emotionally pleasurable to code with Sometimes I'll spend days writing out possible forms of the API — changing words, tense, syntax, until it looks and feels "right." These aren't arbitrary or purely functional decisions Do I want my users to "read" text from a file, or "open" the file? Do I want them to handle keyboard events in a simple global function or assign callbacks into a keyboard handler under each character name. How are those callbacks shaped? What's easy to understand? APIs aren't just restricted simple functions and types. Some may involve the creation of a custom DSL to make it easy to declare functionality in part of your system, or clusters of protocols that work together in very specific ways so users can implement a complex system atop them

andrewjl 6y ago
> I'm not going to argue whether I think APIs should be copyrightable, but I believe creating a good API is a work of creative design, and is artistic I disagree. I think the specification can be, but the API code itself is a mechanical translation of the specification into computer code. Note that abstractions, names, etc are conceived in the specification and are then translated into computer code. Even if you skip the specification step, as sometimes is done, you're then dealing with an implicit, ad-hoc specification. Edit: To clarify what I'm saying, the "creative design" aspect of what you're talking about and that I'm in no way denying, is meant to be protected via the patentability and not the copyrightability of the end product. The creativity is in the behavior not in the mechanical translation of the behavior for computers to use. > APIs aren't just restricted simple functions and types. Some may involve the creation of a custom DSL to make it easy to declare functionality in part of your system, or clusters of protocols that work together in very specific ways so users can implement a complex system atop them Indeed. Yet you're still describing behavior here. A DSL is an example of a specification of one language in terms of another. This is a creative work, I strongly agree! The difference is where does the creativity reside? I don't believe it's in the API code, but in the specification whether written or unwritten and therefore implied.
- enraged_camel 6y ago
  I think your definition of "creativity" is too narrow. Which is perhaps not surprising, since you say you're an engineer. ;)
  - andrewjl 6y ago
    I think you're misunderstanding what I wrote. The creativity that people commonly associate with an API is in the behavior of the API, not in API code. API behavior is no doubt a creative work. If you consider the API to be nothing but code, then your definition of an "API" is too narrow. Nothing I've said should be construed as denying the richness and brilliance found in the design of software and software-based abstractions.
- interpol_p 6y ago

galaxyLogic 6y ago

> accounting methods are not of themselves copyrightable creative works. True. Neither are 'ways of calling library functions" copyrightable. But in the case of Java API what was copied was the actual Java-code in which the APIs are expressed. Because the APIs are "fed" to the compiler as Java source-code, it is clear what was copied was not just the "way library-functions are called". What was copied was Java SOURCE-CODE which allows a Java compiler to ENFORCE and INTERPRET such calling conventions. Even if the API was rewritten in another programming language it would be a copyright violation if large parts of the structure of the API meaning how the methods are organized into classes and interfaces and how they refer to each other, was copied. That would clearly be a work of art that deserves copyright protection, in my view.

andrewjl 6y ago
From the Baker opinion: "The conclusion to which we have come is, that blank account-books are not the subject of copyright; and that the mere copyright of Selden's book did not confer upon him the exclusive right to make and use account-books, ruled and arranged as designated by him and described and illustrated in said book." [1] I believe based on this reasoning, copying APIs or copying code is a distinction without a difference, so long as it's in the context of calling library functions. [1] https://supreme.justia.com/cases/federal/us/101/99/ https://supreme.justia.com/cases/federal/us/101/99/
- galaxyLogic 6y ago
  Are you saying code which calls library functions should not be copyrightable? The Baker opinion can of course be used as argument pro-Google. But it is also just an "opinion". Each case must be decided on its own. I believe there is a big difference between scale and structural complexity with the (inter-connected) Java API and some text-book examples of accounting layouts. At some point quantity becomes quality.
  - deleted 6y ago
    [deleted]
  - 6y ago

mumblemumble 6y ago

The Google v. Oracle argument hinges on Structure, Sequence, and Organization[1]. Things like the actual package structure arguably involve creative decisionmaking, and are not strictly analogous to something like accounting methods. For example, even if the idea of a max() function that takes two integers and returns the larger of the two is not copyrightable, the specific name "java.lang.Math.max()" might still be. Especially if you're talking about not just one function, but some enormous number of methods in some large number of classes across 37 different packages. [1]: https://en.wikipedia.org/wiki/Structure,_sequence_and_organization https://en.wikipedia.org/wiki/Structure,_sequence_and_organi...

andrewjl 6y ago
> Especially if you're talking about not just one function, but some enormous number of methods in some large number of classes across 37 different packages. See my other reply down thread, but my own reading of Baker seems to indicate this specifically is not a factor. 37 packages vs 1 method should make no difference. Copying one ledger template or copying hundreds is not a violation of copyright in the same way, because copyrights don't extend to methods of practice. I'll have to read up on the SSO stuff as it appears there are more relevant & recent precedent cases there.
- mumblemumble 6y ago
  The 2014 decision, for one, hinges on it being a whole package structure and not just one method: Google copied the declaring source code from the 37 Java API packages verbatim, inserting that code into parts of its Android software. In doing so, Google copied the elaborately organized taxonomy of all the names of methods, classes, interfaces, and packages — the "overall system of organized names — covering 37 packages, with over six hundred classes, with over six thousand methods." Copyrightability Decision, 872 F.Supp.2d at 999. The parties and district court referred to this taxonomy of expressions as the "structure, sequence, and organization" or "SSO" of the 37 packages. The Baker ruling is specifically addressed in that one, and they call out exactly how it is relevant to Oracle v. Google: The Baker precedent says that the parts of a design that are strictly essential to its function are not copyrightable. But the parts that involve some art - such as - according to this opinion - the taxonomy introduced in a package structure - are copyrightable. In other words, you can think of SSO as shorthand for, "The things that aren't covered by the Baker precedent." We also have, in the same opinion: When assessing whether the non-literal elements of a computer program constitute protectable expression, the Ninth Circuit has endorsed an "abstraction-filtration-comparison" test formulated by the Second Circuit and expressly adopted by several other circuits. ... This test rejects the notion that anything that performs a function is necessarily uncopyrightable. (Disclaimer: This is not meant to imply that I think that Judge O'Malley's 2014 opinion is the final word on the case. I'm just picking some highlights from an opinion on this case that might shed some light on how the Courts are approaching the issue.) (https://www.leagle.com/decision/infco20140509135 https://www.leagle.com/decision/infco20140509135)

marta_morena_29 6y ago

> I do not believe API design of a math library is in any way the same level, having designed hundreds of APIs and several SDKs myself. Oh given that the APIs were "designed" by Oracle, that stance might be relatable. However, designing actually "good" APIs will turn out equally complex if not more complex than arranging some recipes in a cookbook. Most stuff that Oracle does falls more into the category of a "monkey throwing dart arrows at random code snippets" and then suing the heck out of anyone who breaks their copyright or licenses (Oracle doesn't make software, they make licenses and that's how they earn money. The software is secondary).

mlthoughts2018 6y ago

> “ Selecting and arranging recipes requires creativity. I do not believe API design of a math library is in any way the same level, having designed hundreds of APIs and several SDKs myself.” I have designed hundreds of APIs and SDKs myself as well and I could not disagree with you more. API design is about deliberately and creatively considering the domain model of your user (whether that domain is Int or Float for a user who is a low level system programmer or the domain is CheckingAccount and SavingsAccount for a user who is a banking application developer, or anything in between or beyond). You creatively set up APIs so that composition of the API primitives allows direct expression of solutions in the user’s domain. This is exactly like arranging recipes in a recipe book, to organize sections for different styles, meals or amount of prep time, holiday themes, etc. That is exactly software API design to a tee. This article highlights it for me: https://blog.keras.io/user-experience-design-for-apis.html https://blog.keras.io/user-experience-design-for-apis.html

deleted 6y ago
[deleted]

nodamage 6y ago

Can you clarify how you think Baker applies here? The underlying point from that case is that an accounting method is an idea and copyright protection does not extend to ideas, only specific expressions of that idea. I'm not sure the situation here is all that similar.

andrewjl 6y ago
> Can you clarify how you think Baker applies here? "The conclusion to which we have come is, that blank account-books are not the subject of copyright; and that the mere copyright of Selden's book did not confer upon him the exclusive right to make and use account-books, ruled and arranged as designated by him and described and illustrated in said book." [1] [1] https://supreme.justia.com/cases/federal/us/101/99/ https://supreme.justia.com/cases/federal/us/101/99/ My reading is that the mere use of an API is a method of practice. It does not matter if the API is simple or complex, in the same as it didn't matter if a single page or multiple pages of account templates were used.
- nodamage 6y ago
  > My reading is that the mere use of an API is a method of practice. The problem is Google didn't merely use the API, it reproduced the API entirely and necessarily copied several thousand lines of code in the process. Code itself is generally copyrightable so it is difficult to argue that the specific type of code that makes up the Java API declaration is exempt from this.
  - andrewjl 6y ago
    Apologies, I didn't express myself well when writing that. I meant that all API code is embodied practice. Thus API code itself is in no way different from ledger templates at issue in Baker. Reproduction of an API in its entirety is no different from reproduction of an embedded practice. Any arguments I've seen so far that argued for parts of API code not being embedded practice were not taking into account how API code is used by software engineers.

mrh0057 6y ago

I think people get thrown off because an API is describe through lots of text and can be huge, where as other things are just a layout. The recipe book itself is copyrightable but the language used to describe the recipe isn’t.

jrochkind1 6y ago
Actually the language used to describe the recipe might be. it's just that the recipe itself is not, the fact that you mix 2 cups of this with 1 cup of that and bake at so many degrees. So language that's a plain listing of that in a standard format isn't copyrightable, because it's just a straightforward way to list the uncopyrightable recipe. But if you use especially creative and unique language to describe a recipe, that particular language might be copyrightable. The recipe as a recipe is not; the language used to describe it can be, if it's an unusual or creative way to do so. But someone can most definitely always use their own language to express the same recipe -- the same ingredients in the same amounts combined in the same ways, is not copyrightable. This has until now seemed like it should also mean that the API as API is not copyrightable, and a straightforward implementation of something like `min` is also not, as it's just the only reasonable way to implement `min`. But an especially clever or creative algorithm to implement a part of an API might be.
- mrh0057 6y ago
  The language would be English not the text itself. An api is an language on how to communicate with something. The language itself shouldn’t be copyrightable but any documentation is copyrightable.

austincheney 6y ago

I am a software engineer and it is certainly NOT open and shut for me. APIs are code definitions just as are interfaces, custom types, classes, and so forth. I don’t think APIs should be treated differently than other code only because you need it to be so for your convenience. If APIs should be treated differently they need to be defined separately and licensed differently. Other languages and platforms makes this very clear by externalizing most APIs from the language and then adding support for the API to the language as though it is a foreign technology, because it’s definition and license are separate.

andrewjl 6y ago
> externalizing most APIs from the language and then adding support for the API to the language as though it is a foreign technology That's true, but only in the case for the language's standard library. But what about the API of the language's top-level constructs? A class must have an initializer, for instance. Or protocol / interface has the notion of required as well as optional methods. Why is the latter (language APIs) not copyrightable but the former (standard library APIs) is? What is the substantive difference between them?
- austincheney 6y ago
  Yes, there must be some few primitive APIs within a given language. An example is base types and their most essential methods for internal constructs that aren’t meant to be exposed. Unfortunately, Java is just such a perfect for this legal fight. It is proprietary and exists in this nebulous universe of wanting to make everything Java. It’s like Microsoft of the 90s.
imtringued 6y ago
>Other languages and platforms makes this very clear by externalizing most APIs from the language and then adding support for the API to the language as though it is a foreign technology, because it’s definition and license are separate. What? No. Most modern languages do the opposite. Usually everything is defined directly in the standard library and syntax is often merely sugar to call specific functions in that standard library or to refer to specific definitions in that standard library. Primitive numeric types like int, short, long are no longer hard coded directly into the compiler. Instead they are defined in the standard library and the compiler is just employing optimizations where possible to make them behave like primitive types. Although Ceylon is dead I like to use it as an example. Almost everything was defined in the standard library. Even keywords in java like public, abstract, static are merely just annotations in Ceylon that were defined in the standard library.

rayiner 6y ago

The difference is that Baker didn’t involve literal copying of the accounting tables. Baker is treated as a merger case, but it’s more a case about the difference between copyright and a method patent. Baker claimed that copying the general structure of the tables was infringement. The court essentially held that the structure that was copied was the structure dictated by the method itself. And Selden couldn’t copyright any table that had the same structure because that would give him a monopoly on the method. Here, the Java APIs were copied literally. For example, say you’ve got a function to append an item to a list: Append(item, list) Append(list, item) If you changed the order of the parameters, you wouldn’t be literally copying, even though it’s the same basic signature. That’s the Baker case. You can’t monopolize the method of appending an item to a list by extending copyright to all possible permutations of the limited ways to write the signature. But what happens if you do literally copy? That’s this case. Then, the question is whether these choices of where to put the parameter reflect any creativity. I happen to think they do—I strongly prefer the first form, which is how it’s done in the Common Lisp standard library.

andrewjl 6y ago
> Then, the question is whether these choices of where to put the parameter reflect any creativity. Interesting. This argument seems to imply that languages are copyrightable based upon creativity in ordering, punctuation, use of certain expressions such as `&`, etc. How is that different from your example? In fact a computer language itself is nothing but an API to a human-readable specification for machine behavior. I can see the specification being a creative work and hence being patentable. I don't see the same for the API code. I'll have to think more about it. I can't offer a more substantive counter-argument now.
nitrogen 6y ago
Then, the question is whether these choices of where to put the parameter reflect any creativity. Though the choices are creative, it's necessary to replicate them exactly to produce a functioning interface for existing Java code. It's like a design for an electrical connector; maybe patentable, but it's essential to the function so shouldn't be copyrightable.

wahern 6y ago

> I cannot reconcile this sort of argument with the Baker v. Selden precedent. Contemporary judges, including on the Supreme Court, aren't interested in reconciling Oracle's argument with Baker v. Selden; there's no love for Baker. Courts may pay lip service to the notion that ideas can't be copyrighted, but the prospect of ruling as a matter of law that specific, concrete categories of works are categorically not copyrightable (especially if they're not patentable) seems illogical to them. Previous hard exclusions, like those related to automobile designs, textiles, and databases are already on the way out, unfortunately, just like the idea that entry into the public domain is a one-way street. The case law has been slowly moving in this direction for at least 20 years, but it's too painful for many to admit despite judges (e.g. Ginsburg) being crystal clear about the direction they want to take things. Judge Alsup's original opinion declaring APIs not copyrightable is brilliant and the best argument anyone could possibly make. It is the best argument, period, IMO. But the basic premise is just anathema to the majority perspective on courts' role regarding the application of copyright law.

andrewjl 6y ago
Are there some cases you can cite where this movement occurred? They don't need to be software related. I'm VERY curious about this trend.
- wahern 6y ago
  Off the top of my head: * Star Athletica LLC v. Varsity Brands Inc., 137 S. Ct. 1002 (2017) * DC Comics v. Towle, 802 F.3d 1012 (9th Cir. 2015) * Golan v. Holder, 565 U.S. 302 (2012) One of the most important cases for contemporary copyright law was Feist Publications, Inc., v. Rural Telephone Service Co., 499 U.S. 340 (1991). It was a nominal a win for the defendant, but in fact the opinion set a very low bar and effectively condemned the types of bright-line subject matter exclusions that a robust merger doctrine demands, such as in Baker v. Selden. IIRC, Alex Kozinski wrote some opinions that best reflect the majority perspective today, but I can't find any good citations right now. His arguments are persuasive, but sort of miss the point. Baker v. Selder and the merger doctrine are classic common law solutions to statutory rights that breed complex litigation and inhibit competition. They're not supposed to be intellectually pure or rigorous defenses of legislative powers. Quite the opposite. But courts are far more conservative today and not inclined to exercise their judicial powers this way, with the notable exception of the First Amendment. In fact, certain First Amendment defenses to infringement are slowly becoming more viable, where once upon a time they were dismissed out of hand.