Hacker News new | ask | show | jobs
by badlogic 4038 days ago
This advise by the Solicitor General hinges on an interpretation of section 102(b) of the copyright act. That section essentially says that "methods of operation" can't be copyrighted.

The Solicitor General does not understand that APIs are a formalized description of "methods of operation" (page 14). I suggest reading the entire advisory, it's quite frustrating and contradicts itself.

4 comments

I agree that one shouldn't ascribe to malice what can be ascribed to incompetence. ("The Solicitor General does not understand...")

BUT!

At the White House level, incompetence equals malice. We have every right to expect competence from a level as high as the White House.

Well, these are the same people who think you can safely backdoor encryption.
I think they value power and control above safety.
Justice department officials and congressmen are most definitely not the same people.
You can safely backdoor encryption. If you don't know how, well, you are just stupid (which is what I figured anyway).
The SG is a subcabinet Justice Department official, not part of the Executive Office of the President (White House).
The SG does what the President tells him/her. This is the policy of the Executive Office of the President. The Justice Department is part of the Executive Branch and not some independent agency.
All code is a formalized description of "methods of operation". Unless you believe software achieves practical results without the benefit of hardware. And that's assuming you write pure assembly, else you also have firmware, operating systems, drivers, libraries, runtimes, or whatever supporting infrastructure is needed for your code to do anything meaningful.
I agree that all code is a formalized description of "methods of operation", unless the legal phrase "methods of operation" has some exotic, inobvious meaning, like "secure in their persons, houses, papers, and effects, against unreasonable searches" has taken on.

That's why the US shouldn't allow software patents. Software is either mathematical or a formalized description of a method of operation.

On the contrary, patents are exactly what are intended to cover methods of operation. A lot of court decisions regarding copyrightability explicitly mention this. Note, patents usually don't cover the formalized description itself (mainly because it would result in an overly narrow patent) but rather what you can use software to do.

Here's a claim from the infamous one-click patent:

1. A method of placing an order for an item comprising: under control of a client system,

displaying information identifying the item; and in response to only a single action being performed, sending a request to order the item along with an identifier of a purchaser of the item to a server system;

under control of a single-action ordering component of the server system,

receiving the request;

retrieving additional information previously stored for the purchaser identified by the identifier in the received request; and

generating an order to purchase the requested item for the purchaser identified by the identifier in the received request using the retrieved additional information; and fulfilling the generated order to complete purchase of the item

whereby the item is ordered without using a shopping cart ordering model.

It's a description alright, but there's nothing mathematical or formalized about it (though a software implementation would be a lot of code - formalized description - that applies a bunch of mathematics).

It's good that you're distinguishing "patent" from "copyright" from the vague morass of "Intellectual Property".

The goodness of patents depends on them being inobvious, and the receipient of the patent actually disclosing something useful. Otherwise, once again, the government is just granting a state-enforced monopoly on something, rather arbitrarily.

The problems with "IP" don't rest merely with distinguishing "idea" from "instantiation" (or whatever the legal term is), but rather derive from a much deeper level of problem and paradox.

Code is a specific implementation of a method of operation. The code can be copyright protected. But not the formats the code reads and emits. Not the language the code is written in. Not the machine language the computer processes. Not the method signatures in the code. Etc.
Actually, formats and languages are not, but the generated machine code is copyright protected as a "derivative work". This is how binaries enjoy copyright protection, because they are "derived" from copyright-protected human-produced code. I think that's a bit crazy that a potentially useful product by itself has no intrinsic protection.

As for method signatures, at a human readable level, they are as protected as any other code. Note that copyright protects expression rather than what the code does. So File.open(fname) and open(fname, 'r') and new File(fname) are all different expressions of the concept of "open a file with a given name)". The concept is not covered, but the specific expression is. Of course, a single method is not sufficient, but this case involves a collection of hundreds of such signatures.

I agree about generated machine code. I was referring to an instruction set architecture, that is, the format of the machine code, not the specific sequence of code generated from translating a higher-level language.

I can't agree about method signatures, though. They are like a language, a format, a protocol, none of which are protectable.

There is nothing contradictory about it: as you say, the API is not the method of operation, it's one of many possible descriptions of the method of operation. I don't think anyone is confused by what an API is--its a simple concept.
> There is nothing contradictory about it: as you say, the API is not the method of operation, it's one of many possible descriptions of the method of operation. I don't think anyone is confused by what an API is--its a simple concept.

Then what exactly is an API, if it's so clear and simple to define in your opinion?

Depending on how one stretches it, everything that is not assembly is an API. I don't know the details of the particular legal argument involved but it's going to get very murky if you claim certain levels of abstraction are copy-rightable and others are not.

I disagree. Unless "method of operation" is some godforsaken legalistic bastardization of the language, APIs are methods of operation, not a description. In Java you must use those exact symbols to use the software... the description would be the documentation and Javadoc comments about the code, which I agree could certainly be eligible for copyright protection
Walking is a method of operation. A video of someone walking, or a story about someone walking is a tangible description, not the method of operation itself.

The concept of a function with the name cupcake that takes an integer and returns an integer is different than the description "int cupcake(int x)." The interoperability aspect is a red herring--there is no right to interoperate.

> Walking is a method of operation.

That's not the way most people are using the term, if you are going to use it differently from everyone else, you should clarify the meaning of your usage of the term.

> The concept of a function...is different than the description...

I would say that's either not true or entirely non-obvious, because to establish that the concept is what is being described in the later case is you had to provide some form of description in the previous case, in this case:

  > a function with the name cupcake that takes an integer and returns an   integer
happens to be the common-english equivalent for

  > int cupcake(int x)
The primary difference being that one is valid as an English-sentence and one is valid as a declaration in c, it's not altogether clear why you consider the common-english-expression as having some kind of special precedence, or how such an example helps us establish the difference between a concept and a description of a concept (even supposing such a duality does exist).

> The interoperability aspect is a red herring--there is no right to interoperate.

Not a lawyer, but I was under the impression that the Supreme court indeed has and at times does consider the effect on the common good from a particular interpretation of a law in their decision making.

> That's not the way most people are using the term, if you are going to use it differently from everyone else, you should clarify the meaning of your usage of the term.

How do people use the term "method of operation?" I'm trying to draw your attention to the distinction between the abstract process of walking (moving your legs in a particular way), and concrete descriptions of that method.

> I would say that's either not true or entirely non-obvious, because to establish that the concept is what is being described in the later case is you had to provide some form of description in the previous case, in this case:

Sure, any abstract concept cannot be discussed by humans without reducing it to a written or spoken description. But that does not mean that the concept and the description are the same thing.

> happens to be the common-english equivalent for

Or "fn cupcake(x: i32) -> i32" or "function cupcake(x: integer) : integer;" etc. There are many different concrete descriptions of the abstract concept of a function taking an integer and returning an integer.

I think we are actually in agreement here... it seems as if you consider "API" to mean the documentation of the function, while I am considering it to be the actual compiled Java bytecode (which is not a description of the function, it actually is the "tangible" function)

If the copyrightable work is the description of the API... then I would argue that simply writing "int cupcake(int x)" is not expressive in a way that can be copyrighted, since it is really the only precise way of describing the bytecode. However any extra information (such as Javadoc comments or other documentation) could definitely be expression.

Yet Google claims that the implementing code should be protected by copyright. How is "return a > b ? a : b;" not a method of operation if "public static int Max(int a, int b)" is...

If the implementation, CODE(!), is of course a formalized description of methods of operation, the declaring code (or API) is providing a means of access to it. Something that takes quite a bit of thought and creativity to do well.

Neither one of those is substantial enough for copyright. They should be considered in the context of a whole body of work. Using books as an analogy, an API most closely resembles chapters and headings. Is it copyright infringement to write a new book that follows the same outline as a previous book? (I don't know...)
Not only do APIs resemble the chapters and headings of a book, they aslo include the contract that the content under those headings have exactly the same behaviour.

Google didn't just copy the "heading" java.lang.Math.max() they also copied the contract that calling this method should always return the bigger of the two arguments. Ergo, the "content" under the heading is the same, or rather the any differance between the content of Oracle's book and Google's book is irrelevant

As any programmer knows, you code against interfaces not implementations. And if you don't realize that declaring those interfaces take both effort and creativity then you probably aren't a very good programmer.

A heading in a book is just as much a contract about the content as a method signature is about the content of a method. It takes effort and creativity to produce a coherent outline for a book.

And as any (competent) programmer knows, the "interface" in "code against interfaces not implementations" is merely a homonym of the "interface" in "application programming interface".

> Google didn't just copy the "heading" java.lang.Math.max() they also copied the contract that calling this method should always return the bigger of the two arguments.

Irrelevant, the contract is not part of the trial

Sure, some interfaces took time to develop. But most are obvious from a simplistic use case.

If any language has a function max that takes two integer values and doesn't return bigger, that language isn't worth bothering.

Search results resemble chapters and headings. Are search results protected by copyrights?
I would hope not but wouldn't be surprised if they are, at least in the presentation. The ranking and selection of snippets are original but ultimately machine-generated content, so I could see a court leaning either way.
Spoiler: no it's not.