491–500 of 771 posts
Earlier quoted context omitted.
Isn't that exactly what the article is saying about the justices worrying it could "undermine copyright of computer programs"? What is the difference between an API (interface) and implementation? The algorithm. And algorithms are not copyrightable. A lot can be interpreted into the law when it is beneficial for everybody to do so. But interpretation has its limits. Some laws must be made explicit by the legislature.
> What is the difference between an API (interface) and implementation? The algorithm. Not the algorithm. The algorithm is essentially the recipe. The algorithm is merge sort, or depth first search. It's the contract the API gives you, more or less. "This function does merge sort." But there are unlimited possible implementations of merge sort and each one is copyrightable. And one implementation doesn't infringe the…
This is not the most common type of contract in APIs. More like "this function sorts", or perhaps "this function sorts in O(N*log N) time". Sorting can be done with many different algorithms.
Earlier quoted context omitted.
> You can’t copyright a single recipe that contains components of other recipes, but if you had written a book titled “My grandmas chocolate chip cookies from scratch”, where the first recipe is for homemade chocolate chips, the second is for how to grind your own flour for dough, and the third is for combining the previous two into a cookie, then yeah you can copyright that particular set of recipes. Suppose I want…
With the recipe analogy, I would say that the API would be the books table of contents. The recipes themselves are the implementation. So the question is, should the book’s toc be copyrightable? That is, is it lawful to write another book with the exact same toc, but with different recipes/implementations...
A ToC cares what order it's in. You can't move Chapter 4 to before Chapter 2 or the implementation has to change. By contrast, the order of functions within a class, or classes within a package, isn't really part of the API -- they're most often in alphabetical order, which is totally mechanistic, and changing the order doesn't change the API.
A ToC is also not a rigid formal specification (like a recipe), but that's the core of what an API is.
Earlier quoted context omitted.
The Google lawyer should be fired. I can’t believe you’d put the best of the best in front of the SC and the guy didn’t even sound like he could describe what an API actually is in non-technical terms. I don’t see how he represented the best legal representation Google could buy.
Indeed. This was bad representation to the point that I'm wondering if it was intentional. Google might have recently realized that, as a monopoly, fighting for API freedom perhaps isn't in their best interest.
Dunning-Kruger effect, exemplified in this thread
1) Non-lawyers experiencing the Dunning-Kruger effect 2) People not realising that Supreme Court appeals are 99% about the written submissions, with the oral hearing barely relevant to the final decision at all.
Earlier quoted context omitted.
> I'm not going to argue whether I think APIs should be copyrightable, but I believe creating a good API is a work of creative design, and is artistic I disagree. I think the specification can be, but the API code itself is a mechanical translation of the specification into computer code. Note that abstractions, names, etc are conceived in the specification and are then translated into computer code. Even if you skip…
I think your definition of "creativity" is too narrow. Which is perhaps not surprising, since you say you're an engineer. ;)
Nothing I've said should be construed as denying the richness and brilliance found in the design of software and software-based abstractions.
I'm not sure why so many people here seem to be surprised by this, I got the exact same impression from the hearing. The problem for Google on the copyrightability front is that "compilations" of non-copyrightable items can be copyrightable even if the underlying items themselves are not, if the "selection, coordination, or arrangement" of those items involves sufficient creativity to be considered an "original work…
Earlier quoted context omitted.
I am surprised that Google's legal team would forward such lame arguments. There are much better lawyers out there with a much stronger ability to convey complex topics to non-technical people in a way that illustrates the point under consideration.
Such as?
Imagine if you copyrighted the six sided bolt head? Or the TORX screw. Making screw drivers or wrenches that loosened or tightened them would be copyrightable. How about copyrighting which side of the street people drive on, or the width of driving lanes. Do we get to charge a "usage fee" for cars that adhere to the lanes available on freeways?
I'm not sure why so many people here seem to be surprised by this, I got the exact same impression from the hearing. The problem for Google on the copyrightability front is that "compilations" of non-copyrightable items can be copyrightable even if the underlying items themselves are not, if the "selection, coordination, or arrangement" of those items involves sufficient creativity to be considered an "original work…
Earlier quoted context omitted.
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. 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, b…
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.)