I put myself in their shoes, if I had never looked at a line of code I couldn't even start to imagine what an API vs real code is. I'd probably think it's some made up concept that Google is using to save money and circumvent the law.
Expert witnesses play a role in trials, they play no direct role in appeals where fact claims (to the extent they are reviewable at all, which is normally limited when, as in this case, there is a jury-trial-by-right, because otherwise you obviate the right to a jury trial, though its worth noting one of the issues in this case is that the Federal Circuit tossed aside the jury verdict using a standard which is not usually appropriate for review of fact questions in such a scenario) are decided by review of the trial record and, to the extent that the trial record is not sufficient, remand to the lower courts for further proceedings with legal guidance.
> Do we really expect judges in their 60s and 70s to understand basics of coding in order to come to the right conclusion?
We expect the parties to have developed their fact claims at trial or, failing that, to be able to explain to judges why any issues needing factual evidence are insufficiently developed in the trial evidence such that if they were critical it would require remand (and the reason better be something like "we were improperly prevented by the trial court from presenting evidence" or "this is a issue that somehow was allowed to be raised for the first time on appeal so we had no opportunity to present evidence on it at trial".)
Can substitute any field for "coding" above and come to the same conclusion.
Quickly getting up to speed on the terminology and issues of fields in which they have no formal training or first hand experience is a big part of the job description of being a justice.
Something like coding is so alien to a 70-80 year old it's basically incomprehensible. That won't be the case with us in 50 years when were that age because we understand it, but there will probably be other things at that point that are equally incomprehensible.
You're probably thinking about the reproduction of the design document, not adherence to the specifications that document describes.
https://www.aia.org/articles/26591-understanding-the-scope-o...
To quote:
"""Under the AWCPA, an architectural work is statutorily defined as “the design of a building as embodied in any tangible medium of expression, including a building, architectural plans or drawings,” and “includes the overall form as well as the arrangement and composition of spaces and elements in the design, but does not include individual standard features,” such as common windows, doors, and other staple building components. Accordingly, per the definition, while individual standard features and architectural elements classifiable as ideas or concepts are not themselves copyrightable, an architect’s original combination or arrangement of such elements may be."""
My intuition says that it's... somewhere in-between?
People make a big deal about beautiful apis. Almost all apis are simply functional. The complexity lies in the implementation not the specification.
The unique food might be fish balls, but it also covers fish and chips, and a million other things that could be done with that API.
An API spec will not (necessarily) provide you with any internal implementation detail. Architectural diagrams/design specifications very likely will do.
If API is copyrightable, I'd love to be the first person to copyright the following API (and variations thereof):
class Processor {
void init();
void process(...);
void cleanup();
};
Is that not what blueprints do?
I'd say API is closer to a protocol or a contract than it is to architectural blueprint.
The blueprint would be communicated by mail or sneakernet.
You can copyright the contents of an email (indeed, I think they have an implicit copyright, don't they?), but you can't copyright the way in which emails in general are transmitted and exchange. (That would probably be a matter for patent.)
Patents don't require proof of copying and are always infringed, even with no knowledge.
If you wrote that API, and I wrote that exact same API without having seen yours, you wouldn't be able to sue me for copyright violation.
All I'd have to show in court is that there's a decent probability that I independently created the same API, at which point we'd both have full copyright over our own (identical) APIs, and more likely it would be ruled un-copyrightable due to being too trivial / not creative enough.
Ideally, we shouldn't even have to go to court to begin with.
In the trial court.
Processes--and a good example is business processes like SOPs, etc.--have inputs and outputs.
An API is a name for that process, plus a description of the required inputs.
Can you copyright a name and a description of inputs for a process?
The description and name matter a lot for this, and are typically quite general.
Now, the question is, where do we draw the line: As per Oracle, there cannot be any other character that does what Harry Potter does.
You specifically need to argue that the API itself - the specific combination of types in a specific order, with a given set of Unicode or ASCII characters to identify it - is not copyrightable, not just that it's made up of uncopyrightable things. This is harder, because this same practice in other contexts (e.g. music, literature, and so on) is very much protectable. You need to argue that software is different.