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.
> 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.
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.)
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.
So, 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.
> ts 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.
But if you want to be interoperable with programs that expect to be able to find the max of two numbers using the specific name "java.lang.Math.max", then the name _is_ part of the function. It's kind of like an electircal outlet. The shape of the outlet doesn't really matter as far as delivering electricity, but if you want people to be able to plug in their existing devices, it needs to be in a shape that is compatible with those devices.
That 2014 opinion has a whole section explaining why the interoperability argument doesn't work here. I also summarized it a bit elsewhere in this thread.
To add more to that, the opinion spends a while talking about why the precedent in the ruling in favor of Activition over making unlicensed games for Sega consoles doesn't apply here, and that's helpful for understanding why arguments about interoperability aren't going well over in the courts. In short, the Court recognized a clear distinction between making things to run on someone else's platform, and making your own platform that is designed to be incredibly cosmetically similar to someone else's, but not actually interoperable with it.
Incidentally, I'm looking to that detail for hope. Most my anxiety around this case concerns its potential implications for the legal standing of projects like WINE. But those projects are unambiguously good faith efforts at interoperability. If the Court ultimately rules against Google, but bases that ruling on the opinion that Google's claims about interoperability were smoke and mirrors, then that would seem to imply that they are specifically ruling against what Google did, and not what open source projects are typically doing.
What you should really worry about is who owns the C language API (Nokia Bell Labs probably???)
You see, in the US, derivative works are a thing. All languages that derive their APIs and perhaps even syntax from C would be derivatives. There's interesting legal arguments to be had there if APIs are ruled to be copyrightable....
Compatibility seems more like an fair use argument and has been argued in the past for hardware in order to allow fair use access to copyrighted material. There is however a distinction between being compatible and being market substitute for the original work, with the later being much more problematic from a copyright perspective.
> 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.
That's not the full scope of it's function, at least in a technical sense. It's also meant to be a utility system-level method and in Java standard library utility methods follow a certain organizational scheme so as to designate their system-level status. This status implies certain aspects of behavior not codified in the API name. Therefore this sort of organizational scheme can be argued to be of necessity and not merely an arbitrary design decision.
I think the common gap in many comments here (not necessarily yours, but in sibling postings of your original reply to me) is of an understanding between engineers that mostly use APIs and ones that write them. I'm in the latter category, so my perspective differs. APIs do have explicit contracts that are reflected in their parameters, names, etc. They also have an implicit contract, equally critical to their actual functionality, which needs to be accounted for when in use. Many aspects of organization, etc are firmly in this category and I believe no experienced API author can credibly argue otherwise. Thus behavior like this
> a set of automated UI tests written against TurboTax would also work with H&R Block's app
is of necessity to a properly functional API satisfying an implied API contract. A better example would be H&R Block and TurboTax disputing their workflow for a particular tax form because the workflow is a commonly practiced one by accounting professionals. The software workflow codifies an existing practice. By the Baker standard that appears to me not to be a copyrightable item. API code, in my view, is not dissimilar.
Judge Thomas had an interesting exchange re football playbooks with one of the lawyers. In his example, wouldn't it make more sense to state that the proper protection for a football playbook and its associated techniques to be a patent and not a copyright? The truly valuable creativity is embedded in the practice of football tactics and not in the markings of a manual.
>That's not the full scope of it's function, at least in a technical sense. It's also meant to be a utility system-level method and in Java standard library utility methods follow a certain organizational scheme so as to designate their system-level status. This status implies certain aspects of behavior not codified in the API name. Therefore this sort of organizational scheme can be argued to be of necessity and not merely an arbitrary design decision.
I think the key word in your argument is 'implies' and you didn't use the word 'requires'. If the authors of the API are implying the nature of these sets of functions by organizing them under 'system', they are doing so to convey information and an opinion as to the nature of the function. The fact that java.system.out is STDOUT, could be also put into java.io or java.system.unix.out, java.logging.out etc. The 'system' is arbitrary, its not 'required'. For example, the out function does not inspect its package name to determine that this out file outputs to STDERR.
> I think the key word in your argument is 'implies' and you didn't use the word 'requires'.
You can make this same argument for the function name or the parameter names. Nothing about the implementation of the max function requires it be named max to work, it just needs to link to a function pointer or some equivalent construct that acts in a way as defined by a specification for what max should do. A name like max is helpful for use though. So is arranging max, min, and other standard math functions in the same module. Treating method names as different from other forms of organization is inconsistent. They are all forms of organization.
You've also raise some points re interoperability, but I'm not really arguing about that. My own argument is more of a conceptual one based on the difference between an API and an API contract as well as on the role a system specification plays in API design & use. You could probably extend this concept to the interoperability question and I see no reason why it won't make sense, but that's not what I'm doing here.
> So, 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.
Its not essential to the function of the library function.
It essential to the function of the API, which is to interface between the code in the library and consuming code, including (in the case of the APIs used in Android) consuming source code (though not complete existing applications, for various reasons that Oracle wants to be given the weight of negating the idea that interoperability is the purpose at all, despite the fact that this is simply false) designed for the existing Java APIs.
> 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.
The problem with that analogy is that it is self-evident that being mechanically identical is not a functional requirements (though it may be advantageous) for a human-software interface to work, because humans are intelligent actors that can figure out a UI, within some bounds. On the other hand, a client code unit consuming an API cannot intelligently "figure out" a different API than the one it was designed for: the API is, to the extent that it is intended to support the same functionality, either identical or nonfunctional.
Well, the other problem is that the actual legal precedent on look and feel (while not necessarily decisive because the Supreme Court successfully dodged the issue) goes the other way, anyhow. But even if you were right that an identical interface would be infringing as copying expressive components not essential to functionality for a UI, the analogy fails for an API because of the different requirements for functionality.
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.
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.
That 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.
Huh. I actually was about to suggest that the Java Hello World should work, but a quick perusal dismisses that.
Why would Google bother keeping the JVM class hierarchy if they were implementing a different VM to run against anyway? That just seems to be asking for trouble. I can sort of see some merit to Oracle's argument now. It would be one thing if JVM byte code was treated as an Intermediary representation that then compiled to Dalvik... but it isn't even really that.
Damn, Google stepped in it. Hard.
Edit: Further research indicates Java Byte code is an intermediate representation compiled to Dalvik; so technically the Java Hello World would work coming out in Dalvik (or Android Runtime). So... Back to being confused again, because clearly, even if Google did copy pasta the Java APIs the end machine they are driving is drastically different; I.e., System.out.println() would generate no visible output on Android.
So I'm really back in Google's camp, Oracle is trying to copyright a steering wheel.
"Hello, world" is a rather poor example, because there's little practical value in a mobile application like that. The real value comes from being able to reuse many existing Java libraries.
Hello World! In a Turing space is all you need to implement every other program. Arguments that "there exists no program" come with an inherent verifiability criterion of " well here's one." The thing that Oracle is pissy about is that things get transpired out of Java Byte code, into Dalvik or ART.
Oracle wants patent like protections for the output of Java, and overall API structure in all languages. They want copyright on a meta-pattern. Just trying to imply skulduggery to "look, they joined our API structure, and didn't even do a good job of it, so they should have to pay us for infringement" is a transparent farce. It's an entrenching power grab.
I'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?
"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."
> 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 me, many of the analogies being bandied about don't really capture the distinction you're making. The football playbook for example. Rather than considering the playbook as a description of the game, and thus thinking of what Google did as analogous to copying the playbook, it seems to me that what Google did is analogous to copying the playbook's legend that describes the meaning of the Xs, Os, and arrows that comprise the playbook diagrams, as well as the playbook's table of contents, but none of the actual play diagrams.
To alter the metaphor a bit, Let's say that an author swipes the table of contents for the Lord of the Rings, and nothing else, and writes their own story that conforms to the LotR plot only to the extent that the ToC requires it. Characters and location names that appear in the ToC are used, but nothing else about them is the same. The page numbers don't even have to match as the new work is half the length. We also omit a few things from the ToC, like the several afterwords and appendixes, as well as anything that mentions Tolkien by name. Finally, the work itself isn't called "The Lord of the Rings", but "Doom of Shadows", or whatever.
The work isn't a parody or a satire, nothing is the same except to the extent necessary to make the identical ToC work (in terms of the name, order, and organization of the chapters).
To me, this is a good analogy. The two works are "compatible" in the sense that the ToC is an interface like an API, the ToC and the organization of the book were obviously copied verbatim, but nothing else was.
In this analogy (which presupposes that there are other works that use the ToC as an API), the same sort of questions from this case can be asked: 1. Is the ToC copyrightable per se (since there is obviously some creativity in naming, ordering, and grouping the chapters, but the ToC has slo), and 2. even if it is, is copying it to serve as the outline of a new work fair use?
Does the answer change if the book isn't fiction, eg. a cookbook (dish categories and recipe names, but not the actual recipes) or a textbook (only structure and organization of the subject matter copied, not the actual text or excercises)?
To me it seems fairly obvious that the correct answers are 1. mmmmaybe for the fiction example though I think not, but definitely not for the cookbook or textbook, and 2. It is absolutely fair use for all categories of works, even fiction
The 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.
[1]: https://en.wikipedia.org/wiki/Structure,_sequence_and_organi...