541–550 of 771 posts
Earlier quoted context omitted.
Another interesting take: Machine architectures expose an API, and it may become impossible for anyone but a chip manufacturer to distribute a compiler.
I don't see the similarity. A compiler outputs machine code, it doesn't implement machine code. Google's Java implementation implements Java APIs.
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.
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, n…
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 o…
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.
Earlier quoted context omitted.
Can you clarify how you think Baker applies here? The underlying point from that case is that an accounting method is an idea and copyright protection does not extend to ideas, only specific expressions of that idea. I'm not sure the situation here is all that similar.
> Can you clarify how you think Baker applies here? "The conclusion to which we have come is, that blank account-books are not the subject of copyright; and that the mere copyright of Selden's book did not confer upon him the exclusive right to make and use account-books, ruled and arranged as designated by him and described and illustrated in said book." [1] [1] https://supreme.justia.com/cases/federal/us/101/99/ My…
The problem is Google didn't merely use the API, it reproduced the API entirely and necessarily copied several thousand lines of code in the process. Code itself is generally copyrightable so it is difficult to argue that the specific type of code that makes up the Java API declaration is exempt from this.
Earlier quoted context omitted.
You seem to have misread what was being said, because you seem to be arguing against something that was explicitly stated to not be the case: > individual recipes are generally not copyrightable , but if you compile a set of recipes and publish them in a cookbook, the cookbook itself becomes copyrightable. (emphasis mine) The law understands that the whole is more than the sum of its parts. And Java adds up a lot of…
>Alito's not unreasonable to suggest that a Supreme Court ruling in Google's favor might raise difficult questions about how copyright law applies to software in general. Which in of itself is a long avoided question that sorely needs to be addressed.
Earlier quoted context omitted.
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 b…
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, n…
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.
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…
Having read multiple perspectives, some pro-Google and some pro-Oracle, I cannot reconcile this sort of argument with the Baker v. Selden precedent. [1] Perhaps my understanding of APIs is different because I'm an engineer and not a lawyer, but how is this not an open and shut case? The cookbook analogy is not applicable for the same reason one could not apply it in Baker , accounting methods are not of themselves co…
Contemporary judges, including on the Supreme Court, aren't interested in reconciling Oracle's argument with Baker v. Selden; there's no love for Baker. Courts may pay lip service to the notion that ideas can't be copyrighted, but the prospect of ruling as a matter of law that specific, concrete categories of works are categorically not copyrightable (especially if they're not patentable) seems illogical to them. Previous hard exclusions, like those related to automobile designs, textiles, and databases are already on the way out, unfortunately, just like the idea that entry into the public domain is a one-way street. The case law has been slowly moving in this direction for at least 20 years, but it's too painful for many to admit despite judges (e.g. Ginsburg) being crystal clear about the direction they want to take things.
Judge Alsup's original opinion declaring APIs not copyrightable is brilliant and the best argument anyone could possibly make. It is the best argument, period, IMO. But the basic premise is just anathema to the majority perspective on courts' role regarding the application of copyright law.
Earlier quoted context omitted.
You absolutely do not have to protect a copyright. Even if a book is out of print, you can't start selling it--or even giving copies away for free. However, although IANAL, I assume that submitting something to a standards body and having it accepted allows those standards to be used in accordance with the terms of the standards body--which BTW may not require that use be free in all cases.
> Even if a book is out of print, you can't start selling it--or even giving copies away for free. That's not exactly true. You can't photocopy it and start printing your own. But if you have legal copies of it, you can definitely sell them or give them away.
Earlier quoted context omitted.
If APIs become copyrightable, we just have to change our strategy a little bit. Instead of making a compatible API, you write a program to modify other programs, which detects calls to the target API and transforms them to a shim that is not copyrighted, which can call either the copyrighted API or your new API.
There are two problems with that. First, as colejohnson66 pointed out, that may be a derivative work. This will depend on how your transformer actually works. I can't think of any way to do it that does not involve having access at run time to a copy of the copyrighted API. If that copy is part of the transformer, there is a good chance the transform is a derivative work. If the transformer does not include the copyr…