Happy New Year!
This is the follow-up I announced in my Wednesday blog post, "Deafening silence from software industry presents credibility problem for Google's Supreme Court petition."
Before I talk about a substantive issue concerning Google's petition, let me add something to what I wrote the day before yesterday about an orchestrated rather than organic amicus brief campaign. California-based inventor and IP lawyer John Nicholas Gross looked at the 77 "amici" who signed the EFF's computer scientists brief. On Twitter he commented on one after the other, and if you scroll down far enough on his Twitter page (to his November 9 tweets), you can find more detail on this. His analysis culminated in this overall result:
"Final scorecard: 35 of 77 EFF 'amici' [are] current/ex GOOGLE, received funding, work for orgs that get funding, or have biz deals w/ GOOGLE"
Almost two and a half years ago, there was a great deal of interest in business relationships between the parties to this dispute and commentators such as bloggers, including yours truly (who took the very same position on interface-related copyrightability in public more than 10 years ago and also about five years ago while working against Oracle). However, no one besides Mr. Gross has recently found it worthwhile to research the connections between those "friends of the court," about half of which are easily identifiable as Google friends. Instead, certain journalists (fortunately only a very few) have worked hard to describe those computer scientists as the authority on the issue. Well, even if you would like the the law to be what those guys say, it's not journalism but downright propaganda to overstate the importance of that filing without doing your homework. If you are real, serious journalists, why can't you do what Mr. Gross has done and simply run some Internet searches--Google searches, that is--to track down all those connections? So much for that.
On the substantive side, there's only one thing in Google's reply brief (published in my previous post) that I wish to discuss. Other than that, unless anything important comes to my mind or something interesting happens, I'll just wait for the Supreme Court's decision on the cert petition.
The one thing that is key here (other than Google's emphasis of the favors it received from its best friends in the form of signatures) is the question of what effect Google's proposal to hold 7,000 lines of highly-creative and highly creatively-structured declaring code uncopyrightable (as the district judge mistakenly did in an unprecedented outlier ruling) would have on software copyright as a whole. As an app developer who has written a lot of code himself and has recently hired four full-time developers, I'm obviously interested in a reasonable degree of IP protection for software. While I applaud Google for fighting in certain areas against the (sometimes institutionalized) excesses of the patent system, I view Google's attack on software copyright as an attack on every honest (i.e., non-thief) software developer in the world.
In its reply brief, Google still--after all those years--fails to make a workable line-drawing proposal. It just denies the undeniable: that an overreaching application of the §120(b) exclusion of systems and methods of operation from the scope of copyright would create enormous uncertainty about the copyrightability of any software, at least of all object code (since object code does not contain source code comments).
Google says in its reply brief "that the Java libraries of pre-written programs are generally eligible for copyright protection, but the method headers (also known as declarations) used to operate those programs are not." While this appears, at first sight, to be a line-drawing suggestion, it's utterly unhelpful once you think it through: the distinction between declaring code and other code makes no sense under software-related copyright law.
Google claims that the exclusion of systems and methods of operation applies to method headers in a very broad sense. According to Google's reply brief, it doesn't depend on any fact-specific determination. Ineligible. End of story. But Google's lawyers know that the Supreme Court would reject a petition for writ of certiorari that overtly advocates the unconstitutional abolition of software copyright as a whole. So they included the "don't worry" message I just quoted. But software developers would have to worry if the Supreme Court ever considered agreeing with Google.
Throughout this litigation, Google has always argued that whatever was presented wasn't copyrightable. Not just declaring code. Not just the nine-line rangeCheck function (which even the district court held copyrightable, quite tellingly). Even a bunch of decompiled programs that consist mostly of non-header code were held copyrightable, though Google said they were not. I have yet to see the first piece of software that Google agrees is copyrightable--except for the closed-source parts of Android, of course. Google does make it clear to Android device makers that it will enforce its copyright in those programs should anyone copy them without a license. But those are not at issue in this dispute.
I've really tried very hard to understand whether Google's proposal could be workable, and I just can't see how it would ever work. I can't see how anything good could come out of this Supreme Court petition for Google without causing massive damage to the software industry--including little guys like me--as a whole.
Let's think it through together. When lawmakers decided that software would be protected by copyright law just like literature, they made a policy judgment that is now binding on everyone, even on the Supreme Court. It has been clear ever since that not only program source code, which may contain expressive elements such as names and commentary that are not needed for functional purposes, but also object code stripped of those optional though expressive elements is protected by copyright law.
It makes for a much more focused analysis if we start from that premise: while §102(b) excludes systems and methods of operation from the scope of copyright, even object code that is by definition functional--it's the code you can actually run on your computer--does deserve and enjoy copyright protection provided that it's original.
That premise, in and of itself, makes it very clear that §102(b) is meant to protect only against overreaching interpretations of copyright law. Someone who writes a book about an accounting system doesn't own the accounting methods. Someone who publishes a game, or a book on game rules, can't monopolize a method of gameplay. Those questions were decided a long time ago and have nothing to do with the literal copying of 7,000 lines of highly-creative code. Of course, if copyright law allowed someone to monopolize an accounting method or a game category, then software copyright would be like broad and trivial software patents on steroids. Again, understood and agreed. But that's not the issue here.
Google could have designed an API with the same technical characteristics as the Java API without infringing copyright. It would just have had to come up with its own interface. As a result, programmers would have had to learn the new interface, but that would have been Google's problem (when it needed to get traction for Android among developers), not Oracle's.
Oracle never said that you couldn't have an API that allows you to rename files, to draw rectangles, or to terminate threads, without taking a license to Java. So this has nothing do with cases like Baker v. Selden (the one involving the accounting method).
Essentially, Google is saying that header code is inherently, and without a need to consider the facts, a system or method of operation, while other code may or may not be depending on the facts.
If you look at this through the lens of "no matter what §102(b) says, even object code stripped of variable names and source code comments must remain eligible for copyright protection because that's the way Congress and all courts wanted it to be," then there's really no basis on which one can consider header code to be, inherently, a system or method of operation without saying the same about all other code. That's the whole problem.
In order to illustrate this, I'm now going to walk you through a couple of code segments that the district court held copyrightable (against Google's non-copyrightability arguments) and discuss, from the §102(b) angle, the difference between headers and other code, just to show you that the distinction is nonsensical in a copyrightability context.
Let's start with the nine-line rangeCheck function (without the usual indents, just to make it easier to read here):
private static void rangeCheck(int arrayLen, int fromIndex, int toIndex) {
if (fromIndex > toIndex)
throw new IllegalArgumentException("fromIndex(" + fromIndex +
") > toIndex(" + toIndex+")");if (fromIndex < 0)throw new ArrayIndexOutOfBoundsException(fromIndex);if (toIndex > arrayLen)throw new ArrayIndexOutOfBoundsException(toIndex);
}
The header--and thus non-copyrightable part according to Google--would be everything that's in the first line before the opening brace. The rest would be eligible for copyright protection (though Google said this particular code segment wasn't worthy of copyright protection for other reasons than being a header; essentially, Google said it was way too small to be copyrightable).
I'm obviously not saying that the first line on its own would be copyrightable in isolation. But that's not because it's a header. I'd have an even bigger problem with any of the other lines if someone tried to copyright them on their own. Just like copyrightable music consists of non-copyrightable notes and this blog post as a whole is copyrightable while none of the 26 letters used in its are, you can always break down a copyrightable work to the level of uncopyrightable atoms.
So it typically (with the exception of some unusually creative single lines of code) takes a set of lines--in this case, nine lines--to identify a copyrightable work. But why would the header in this case have to be completely ignored in this analysis while the rest would at least have to be looked at?
It makes no sense if you look at what each line does. If the header is excluded under §102(b), so is the rest. If the rest is not excluded, then the header--and, as a result, a reasonably creative and large set of headers--isn't excluded either. It sounds simple because it is.
If any other code--non-header code--wanted to call the rangeCheck function, an exemplary line of code would be this:
rangeCheck(listLength, firstIndex, lastIndex);
That would be code making use of the header. It wouldn't be header code. If anything, that code, because it triggers the execution of the rangeCheck code, would be more of a system or method of operation than the rangeCheck header ever was.
The body of the rangeCheck function consists of two instructions that have a simple pattern: if a condition is met, an exception is thrown. Why would the "if" part that results in a comparison of actual numbers, or the "throw" part that triggers an exception (i.e., the program may stop executing, or at least there would have to be some exception handling that organizes an orderly retreat after an error came up), be less of a system or method of operation than the header? I just can't see that.
Sure, this was just rangeCheck. A very small function. Still, copyrightable in the opinion of the court(s) below. But we won't reach a conclusion more favorable to Google's position even if we compare header lines to non-header lines from larger programs. Let's look at one of the aforementioned decompiled files (that were also held copyrightable against Google's representation that they were not). The first one of those programs is AclEntryImpl. We won't discuss every line, just the categories of lines of non-header code.
The "package" command at the beginning is about defining namespaces. Since it's only one line, we don't have to waste time discussing whether or not this is header code. There's certainly a case for a "package" command being header code. But the "import" commands that follow have the effect of importing other namespaces for easier references. So, for example, if you have a namespace that is called mynamespace.tools.filemanagement and it comes with a compressedFileArchive class, then you can either reference that class by writing mynamespace.tools.filemanagement.compressedFileArchive each time you make use of it, or if you think you're going to use this one (and/or other classes from the same namespace) frequently, you may just import that namespace and then you can reference compressedFileArchive directly (unless another class by that name is also found in, or has been imported into, your namespace, in which case you need to specify which one you mean).
Then we get to what is undoubtedly a header line the way Google defines it:
public class AclEntryImpl implements AclEntry
The part inside the braces is code that gets executed when AclEntryImpl is called. And the first three lines of that inside part are:
private Principal user;private vector permissionSet;
private boolean negative;
Those three lines declare (define, create) a variable of data type "Principal" named "user," a variable of data type "vector" named "permissionSet," and a variable of type "boolean" (it's binary; true or false) named "negative." So here you have declaring code of the kind that Google says is not copyrightable if it's in a header file, but Google says code that is not in a header-only file may be copyrightable. Remember, Google's reply brief says "that the Java libraries of pre-written programs are generally eligible for copyright protection, but the method headers (also known as declarations) used to operate those programs are not." Those "private" commands (they define a variable that is available only at the local level and can't be accessed from outside) are, however, part of the pre-written program code that gets executed when you instantiate the AclEntryImpl class (i.e., make use of the header in order to create an object based on the class definition).
If we believe that such declarations must be copyrightable, then we already disagree with Google. If we say, only for the sake of the argument, that this kind of code shouldn't be copyrightable, then we must disagree with Google shortly thereafter.
The very next line--"public AclEntryImpl(Principal principal)"--is the declaration for the constructor, i.e., for the code that creates an object based on a class definition. And the executable (non-declaring) constructor code consists only of these four lines:
user = null;
permissionSet = new Vector(10, 10);
negative = false;
user = principal;
Why would this constructor code not be excluded under §102(b) if the headers and even the "private" declarations are? Again, it makes no sense.
Those four lines assign a value to each of three variables. The "user" variable is initially assigned "null", a value that means "not available." Then, at the end of the constructor, it's assigned the content of the "principal" variable, which is the only parameter of the constructor (i.e, the only value passed on to the constructor when it is called). It makes no sense to have two assignments in the same block of code because the second one undoes the first one and no use is made of the assigned value in the meantime; the reason it's here at all is that a decompiler (a program that creates source code based on object code) was at work, and decompilers typically aren't smart enough to identify such inefficiencies. So technically, we have just three assignments of values to variables. Each variable is like a predefined storage place for information. Each such storage place gets some content, and then constructor is done. This is not declaring code, but wouldn't you agree that assignments look pretty much the same as declarations?
They do, and in fact, most programming languages allow developers to mix them: you can declare a variable and immediately assign an initial value to it. Or, if you have so-called constants, you must assign a value at the beginning and that value won't ever change while the program is being executed.
The absurdity of Google's proposition "that the Java libraries of pre-written programs are generally eligible for copyright protection, but the method headers (also known as declarations) used to operate those programs are not" is shown, not only but particularly clearly, by the fact that Google wants the very same thing--a declaration that comes with an immediate assignment--to be ineligible for copyright protection if it's in a header file but potentially copyrightable, depending on the specific facts, if it's found inside a block of non-header code. "Absurdity" is an understatement. No reasonable person could ever claim that copyrightability depends on where a particular line is found. Musical notes are equally copyrightable whether they're at the beginning or the end of a song or an entire opera. There's no rule that the prelude is copyright-ineligible. Similarly, headlines in books (Oracle's famous Harry Potter example) aren't treated differently from the body of the text. Prefaces and epilogues aren't treated differently from what's between them.
At this point it should already be clear that Google does not make a workable line-drawing proposal. It proposes a vague and arbitrary line that has no basis in the law and is completely detached from what Congress wanted when it decided that computer program code, even object code, must be copyrightable as long as it's original and expressive.
Let's continue a bit with the AclEntryImpl class definition anyway. The next header line there is "public AclEntryImpl()" and that's also a constructor, but one without any parameter. The code of this constructor is a subset of the previous constructor, the one with the "principal" parameter. This explains why the decompiler resulted in the aforementioned waste of assigning two different values to the "user" variable in the same code segment: the constructor with a parameter initially calls the one without a parameter and then just assigns the parameter value to the "user" variable. The recompiler tool that was used here simply processed each line without checking again later whether any particular line was rendered pointless by a subsequent line. But that's unrelated to the question of copyrightability. I'm just trying to make sense of something that makes no technical sense here, and that's due to the genesis of this file (decompilation).
After the two constructors, we find a boolean (true/false) function named setPrincipal. The "public boolean" line is a header; the code block within the braces is the code that gets executed when this method is invoked. The purpose of setPrincipal is to assign the value of the "principal" parameter to the "user" variable, but only if "user" hasn't been given a value before (otherwise it will return "false" to report that the attempt to assign the value has failed, a safeguard against overwriting the variable after the initial assignment and a typical write-only-once mechanism).
Why is "if(user != null)" and "return false" (to be clear, both "return" and "false" are predefined Java keywords, while the method name setPrincipal was freely chosen by the developer) any more expressive or any less functional than the declaring code? I can't see why that would be the case. I also can't see why a line that calls the setPrincipal function would be less of a system or method of operation than the line that defines the function.
Unless one tries to interpret the scope of copyright protection based on declaring code too broadly (like I wrote above, as a software patent on steroids), declaring code is an even weaker case for a §102(b) exception than non-declaring code.
This stuff isn't worth the Supreme Court's time. It's no more worthy of a Supreme Court review just because Google's friends signed some amicus briefs and got some of their friends and peers to sign. Certiorari should not become a campaigning contest.
The only way the Supreme Court could help Google here would be by creating a black hole that would absorb almost all software copyright protection, including all (no exception there) object code protection. Since the Supreme Court won't create a black hole, and since there's no basis for an interoperability exception to copyrightability in U.S. law, what good would a Supreme Court review do other than delay resolution of this case, which would come in handy for Google but not be in the public interest?
If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents and Google+.
Share with other professionals via LinkedIn:
