6 ms·
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
by 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)
- andrewjl 6y agoI'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.