3 ms·

> I cannot reconcile this sort of argument with the Baker v. Selden precedent. Contemporary judges, including on the Supreme Court, aren't interested in reconc

by 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.
  - andrewjl 6y ago
    What are your thoughts on SAS Inst. Inc. v. S&H Computer Sys. Inc.? Does it fall into the grouping above in your opinion? I find it to be a very quirky decision in light of the merger doctrine principles you wrote about, unless I'm missing something.
  - andrewjl 6y ago
    Very interesting... and somewhat unexpected especially re First Amendment, thank you for these! Star Athletica LLC surprised me in particular. Stripes and chevrons!
rayiner 6y ago
I really struggle to see what was "brilliant" about Judge Alsup's opinion. After 30 pages of very careful analysis of the case law, his actual holding (at p. 35) simply begs the question. He states: > Much of Oracle’s evidence at trial went to show that the design of methods in an API was a creative endeavor. Of course, that is true. Inventing a new method to deliver a new output can be creative, even inventive, including the choices of inputs needed and outputs returned. The same is true for classes. But such inventions — at the concept and functionality level — are protectable only under the Patent Act. This mixes up the functional aspects of designing methods with the stylistic aspects of API design. Consider something like a 3D Graphics API. Some decisions are functional--for example, minimize call overhead or maximizing batching opportunities. That should not be copyrightable. But a lot of other decisions are stylistic. They make the API more elegant, or orthogonal, or intuitive, but are not functional in and of themselves. For example, how to structure groups of functions for dealing with various kinds of buffers. Insofar as those stylistic decisions are expressed in literal code, that's the domain of copyright. > The method specification is the idea. The method implementation is the expression. No one may monopolize the idea. This is ipse dixit. How you view the "idea" depends on your generality. Direct3D and OpenGL have different ways of expressing the concept of creating a Z-Buffer. "Creating a Z-Buffer" is the "idea." There are myriad method specifications that can express that idea. > To carry out any given function, the method specification as set forth in the declaration must be identical under the Java rules (save only for the choices of argument names). Any other declaration would carry out some other function. This is glossing over a major logical leap. It assumes you already have a method with a given signature, and writing the declaration is a mechanical process of specifying what signature corresponds to the method implementation. But what if you design the API by writing the declarations first, and filling in the methods afterwards? (Which is very often how its done!) You can write a method to do a particular thing but give it many different specific signatures.
- andrewjl 6y ago
  > This mixes up the functional aspects of designing methods with the stylistic aspects of API design. I think the disagreement here is as a frequent API author I don't see any stylistic aspect in the design of API code. API code as an artifact itself is purely functional. This distinction becomes important because of the case precedent at hand. Prior to creating any API, one must have a specification of the system the API is meant to model and control. If one skips writing the specification, that doesn't mean there isn't one, it's just largely in the brain of the implementer and possibly underspecified or inconsistent in spots. Every unit of API code therefore has an implied specification, whether or not a documented, written specification exists. The API code is simply a mechanical translation of the specification into machine readable form. Parameter names, method names, those do not matter to the technical function of the system they are there solely to enhance use. The specification is possibly a patentable invention. A book describing the specification to a human audience is possibly a copyrightable work. API code is neither of those things, rather it is an embodied practice of interacting with that specification in a machine-readable form and therefore IMO [IANAL] not eligible for copyright under Baker. > For example, how to structure groups of functions for dealing with various kinds of buffers. Insofar as those stylistic decisions are expressed in literal code, that's the domain of copyright. These structures are not inherent to the function of the API code, except incidentally due to implementation details. The purpose of these structures is to model the system being interacted with. I think part of the misunderstanding here is the contemporary expectation that all code is self-documenting. Which is an admirable goal, but it obscures some important nuances about what an API as opposed to an API contract actually is. API code, particularly old or highly specialized API code, has a TON of undocumented behavior, quirks, etc that exist. Where do they exist? Besides in the heads (optimistically) of the implementers, it also exists in the specification the API code together with its implementation translate. > But what if you design the API by writing the declarations first, and filling in the methods afterwards? Presumably it's the human and not the computer writing the API code so the human has some notion of what the API code is representing. The act of writing this code is translation. Just because the original is not always captured does not mean that it doesn't exist. It must exist for there to be API code in the first place.

by wahern 6y ago

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.
- andrewjl 6y ago
  What are your thoughts on SAS Inst. Inc. v. S&H Computer Sys. Inc.? Does it fall into the grouping above in your opinion? I find it to be a very quirky decision in light of the merger doctrine principles you wrote about, unless I'm missing something.
- andrewjl 6y ago
  Very interesting... and somewhat unexpected especially re First Amendment, thank you for these! Star Athletica LLC surprised me in particular. Stripes and chevrons!

rayiner 6y ago

I really struggle to see what was "brilliant" about Judge Alsup's opinion. After 30 pages of very careful analysis of the case law, his actual holding (at p. 35) simply begs the question. He states: > Much of Oracle’s evidence at trial went to show that the design of methods in an API was a creative endeavor. Of course, that is true. Inventing a new method to deliver a new output can be creative, even inventive, including the choices of inputs needed and outputs returned. The same is true for classes. But such inventions — at the concept and functionality level — are protectable only under the Patent Act. This mixes up the functional aspects of designing methods with the stylistic aspects of API design. Consider something like a 3D Graphics API. Some decisions are functional--for example, minimize call overhead or maximizing batching opportunities. That should not be copyrightable. But a lot of other decisions are stylistic. They make the API more elegant, or orthogonal, or intuitive, but are not functional in and of themselves. For example, how to structure groups of functions for dealing with various kinds of buffers. Insofar as those stylistic decisions are expressed in literal code, that's the domain of copyright. > The method specification is the idea. The method implementation is the expression. No one may monopolize the idea. This is ipse dixit. How you view the "idea" depends on your generality. Direct3D and OpenGL have different ways of expressing the concept of creating a Z-Buffer. "Creating a Z-Buffer" is the "idea." There are myriad method specifications that can express that idea. > To carry out any given function, the method specification as set forth in the declaration must be identical under the Java rules (save only for the choices of argument names). Any other declaration would carry out some other function. This is glossing over a major logical leap. It assumes you already have a method with a given signature, and writing the declaration is a mechanical process of specifying what signature corresponds to the method implementation. But what if you design the API by writing the declarations first, and filling in the methods afterwards? (Which is very often how its done!) You can write a method to do a particular thing but give it many different specific signatures.

andrewjl 6y ago
> This mixes up the functional aspects of designing methods with the stylistic aspects of API design. I think the disagreement here is as a frequent API author I don't see any stylistic aspect in the design of API code. API code as an artifact itself is purely functional. This distinction becomes important because of the case precedent at hand. Prior to creating any API, one must have a specification of the system the API is meant to model and control. If one skips writing the specification, that doesn't mean there isn't one, it's just largely in the brain of the implementer and possibly underspecified or inconsistent in spots. Every unit of API code therefore has an implied specification, whether or not a documented, written specification exists. The API code is simply a mechanical translation of the specification into machine readable form. Parameter names, method names, those do not matter to the technical function of the system they are there solely to enhance use. The specification is possibly a patentable invention. A book describing the specification to a human audience is possibly a copyrightable work. API code is neither of those things, rather it is an embodied practice of interacting with that specification in a machine-readable form and therefore IMO [IANAL] not eligible for copyright under Baker. > For example, how to structure groups of functions for dealing with various kinds of buffers. Insofar as those stylistic decisions are expressed in literal code, that's the domain of copyright. These structures are not inherent to the function of the API code, except incidentally due to implementation details. The purpose of these structures is to model the system being interacted with. I think part of the misunderstanding here is the contemporary expectation that all code is self-documenting. Which is an admirable goal, but it obscures some important nuances about what an API as opposed to an API contract actually is. API code, particularly old or highly specialized API code, has a TON of undocumented behavior, quirks, etc that exist. Where do they exist? Besides in the heads (optimistically) of the implementers, it also exists in the specification the API code together with its implementation translate. > But what if you design the API by writing the declarations first, and filling in the methods afterwards? Presumably it's the human and not the computer writing the API code so the human has some notion of what the API code is representing. The act of writing this code is translation. Just because the original is not always captured does not mean that it doesn't exist. It must exist for there to be API code in the first place.