5 ms·
I'll have to read on this further. Thanks for the references. > The Baker precedent says that the parts of a design that are strictly essential to its function
by andrewjl 6y ago
I'll have to read on this further. Thanks for the references.
> The Baker precedent says that the parts of a design that are strictly essential to its function are not copyrightable.
Since all parts of the API code are strictly essential to its function than they are not copyrightable, right? The parts that are not essential to its function lie in the behavior of the system in question instead of the API code, this behavior is codified in the specification of the system. The specification of the system isn't the same as the API code. I think this is a very compact form of what I was trying to convey in my other replies on the thread.
- lmkg 6y agoThe arguments and return value of Min and Max are strictly essential to their function. Their inclusion as top-level items in a Math package is not. One could imagine alternate taxonomies where, e.g., the Math package is divided into Arithmetic, Trig, Comparison, and Advanced sub-packages. Or where they are placed into an Operators package insted of Math. For example, Rust puts the Max function into the cmp (Comparison) crate of std. This associates them with comparison & equality rather than trigonometry and calculus like Java does. This is the type of subjective decision-making that qualifies something as original and non-trivial.
- nitrogen 6y agoBut if you want to run third party Java code you have to preserve package locations and method names to the letter.
- mumblemumble 6y agoSo, going back to the max() function example: I believe, based on the way the courts are looking at it, that the parts that are essential to its function are the fact that it takes two numbers and returns the greater of the two, and perhaps also the fact that it is named "max". Its being placed into class named java.lang.Math, though, is not. That is a product of the way it is arranged, which is a matter of design, not of necessity. It's hard to imagine any particular reason why a function would need to have "java" in its name in order correctly calculate the maximum of two numbers. The crux of the case, then, is the copyrightability of those design decisions about how the API members are arranged. The set of specific functions it performs is, as per Baker not the focus of the argument. To take a hypothetical that cuts much closer to the accounting analogy: imagine if H&R Block came out with tax preparation software with exactly the same capabilities as TurboTax. That would, I believe, be fine, in and of itself, because the functionality itself is not copyrightable. However, if the interface to their tax preparation software were arranged identically to TurboTax's, to the extent that a set of automated UI tests written against TurboTax would also work with H&R Block's app, then we would likely be looking at a case of copyright violation.
- andrewjl 6y agoI've had a chance to read your materials. Here's a question: Using the AFC test [1], which seems common throughout the case law cited, how does one distinguish a design decision from a standard programming technique [2] in the context of a programming language's standard library API? By virtue of terminology, it's a standard. Is it defensible because it is a design decision concerning a programming language implementation? Then how does that square with computer languages not being copyrightable? What argument can one make so it can pass the filtration step of the test? [1] https://en.wikipedia.org/wiki/Abstraction-Filtration-Comparison_test https://en.wikipedia.org/wiki/Abstraction-Filtration-Compari... [2] Computer Associates Int. Inc. v. Altai Inc. https://web.archive.org/web/20120310144346/http://ftp.resource.org/courts.gov/c/F2/982/982.F2d.693.91-7935.91-7893.762.html https://web.archive.org/web/20120310144346/http://ftp.resour... "in many instances it is virtually impossible to write a program to perform particular functions in a specific computing environment without employing standard techniques." 3 Nimmer § 13.03[F], at 13-65. This is a result of the fact that a programmer's freedom of design choice is often circumscribed by extrinsic considerations such as (1) the mechanical specifications of the computer on which a particular program is intended to run; (2) compatibility requirements of other programs with which a program is designed to operate in conjunction; (3) computer manufacturers' design standards; (4) demands of the industry being serviced; and (5) widely accepted programming practices within the computer industry."
- nitrogen 6y agoIts being placed into class named java.lang.Math, though, is not. That is a product of the way it is arranged, which is a matter of design, not of necessity. It's hard to imagine any particular reason why a function would need to have "java" in its name in order correctly calculate the maximum of two numbers. It's absolutely essential for interoperability to preserve package layout, class/method names, and argument order. For any Java code you want to run on your Apache Harmony based mobile OS, you have to have the Java package names.
- mumblemumble 6y agoThat is true, but it's irrelevant. Oracle is not suing app developers for writing Java code to run on an Apache Harmony based mobile OS. It is suing Google for proceeding to base their mobile OS on Apache Harmony after they backed out of licensing negotiations. As was observed during the hearing, everyone else who made a mobile OS was able to do it without copying someone else's API structure, so the idea that the API structure is essential to the functioning of a mobile OS is simply absurd. There's a whole section in that opinion I linked above titled, "Google's Interoperability Arguments are Irrelevant to Copyrightability," that's worth reading for a deeper treatment of the issue. In particular, Judge O'Malley (quite reasonably) calls bullshit on the very premise that Google copied the Java APIs in order to achieve interoperability, pointing out that Google did specific things to prevent such interoperability (as an aside, we now know that their desire to do so, and Sun's unwillingness to agree to that, is a major reason why they could not come to terms on a licensing agreement), and was unable to produce any examples of a pre-existing Java program that also runs on Android.