Earlier quoted context omitted.
I think people get thrown off because an API is describe through lots of text and can be huge, where as other things are just a layout. The recipe book itself is copyrightable but the language used to describe the recipe isn’t.
Actually the language used to describe the recipe might be. it's just that the recipe itself is not, the fact that you mix 2 cups of this with 1 cup of that and bake at so many degrees. So language that's a plain listing of that in a standard format isn't copyrightable, because it's just a straightforward way to list the uncopyrightable recipe. But if you use especially creative and unique language to describe a reci…
Google’s Supreme Court faceoff with Oracle was a disaster for Google
611–620 of 771 posts
Re: Google’s Supreme Court faceoff with Oracle was a disaster for Google
#612Earlier 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 design an API for graphical coding and spend significant creative energy choosing the right words, calling conventions, result types to not only make something intuitive, but emotionally pleasurable to code with Sometimes I'll spend days writing out possible forms of t…
> 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…
Re: Google’s Supreme Court faceoff with Oracle was a disaster for Google
#613Earlier quoted context omitted.
Except Linux is FOSS so Microsoft has a license to do it.
Only under Linux's GPL license, WSL is most definitively not under GPL
Re: Google’s Supreme Court faceoff with Oracle was a disaster for Google
#614I'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…
Are anthologies of poems copy writable? I thought not.
what does writability has to do with anything?
Re: Google’s Supreme Court faceoff with Oracle was a disaster for Google
#615I wonder if Oracle winning would reinvigorate software developement - by which I mean, maybe the resulting fragmentation would leave a lot of room for new ideas to be developed. e.g.: if this court case was decided before Google made Android, then Google would have had to use something other than Java to do it and they wouldn't have been able to attract such a large developer base to make apps. Maybe they would have…
This is a future I like to envisage as well. New programming languages (for example), struggling for traction, might feel obliged to clearly open source their APIs, to demonstrate their openness. Corporates, tech giants etc. might in turn gravitate towards such more-open platforms, leading to a virtuous circle of innovation and steady migration away from technologies that try to use their APIs for extortion.
Re: Google’s Supreme Court faceoff with Oracle was a disaster for Google
#616Earlier quoted context omitted.
To be clear I am on the Google side of this argument But certainly the API code contains naming, which is a creative aspect of API design, and in this case naming is used by developers to code against either Oracle's Java implementation, or Google's. In order to allow this Google had to copy the naming created by Oracle for their version of the API in order to attract the large pool of developers who liked and were f…
With respect to naming, I think the details of the Baker case make it clear that names are not copyrightable. Nevertheless I agree that naming is a creative aspect of API design. It's not a creative aspect of API code though! There it is just an affordance. The names that we given our APIs are inherent to their behavior and not necessarily the code. Some languages, such as Swift, even mangle API names when they are u…
In this case the naming is an important factor, as that is the competitive advantage leveraged by Google in copying Oracle's Java API. They were able to tap into a developer resource who was familiar with the style, naming and conventions of Java
The API is the interface between the human and the code, and so copying a familiar interface design can be an advantage when building a platform
Re: Google’s Supreme Court faceoff with Oracle was a disaster for Google
#617Earlier quoted context omitted.
This is an overreaction. We already are in the state you describe, except for patents. The doubly linked list is patented [0]. Selling something over the internet was patented [1]. The list could go on and on. Every major software company has so many patents that they could find an infringement in almost any software company. Why hasn't this happened? Because, like copyright, someone needs to actually bring suit. Tha…
So why enable further madness when the current system is already dysfunctional?
I'm merely responding to the parent's post that is interpreting a worst-case scenario that is vanishingly unlikely.
I'd appreciate if you didn't read into my comment an intent that isn't there. I am absolutely not arguing for "enabling further madness", and you asking a question that assumes I want that is not furthering this thread.
Re: Google’s Supreme Court faceoff with Oracle was a disaster for Google
#618Earlier quoted context omitted.
I agree. Personally, I espouse the "copyright should not exist at all" viewpoint. However, I think in the current legal framework, APIs are clearly copyrightable. However, re-implementing the APIs should obviously be allowed under fair use. Remember that copyright exists solely for the purposes of increasing the production of otherwise-easily-copyable works that take time to create but then are "worthless" (i.e. the…
> They produced a better product, and the market rewarded them for that. You could make that same argument about patents in general, couldn't you? If you invent something, say, a new battery, and somebody else copies it, doesn't have your R&D-costs invested and prices it accordingly lower than you, the market will "reward them" by buying from them instead of you, they're getting the same thing after all. We do want s…
You should distinguish the concepts of copyright and patent. A hardware design, like a battery, is not copyrightable in general. The technical drawings or a written description can be copyrighted, but the abstract technology and process cannot. Under copyright laws, it's illegal for me to duplicate your documents, but there is nothing to stop me from reverse-engineering or duplicating the same process or hardware [0], and I'm also allowed to write about this technology in my own words. Only patent laws can grant a period of exclusive control of an abstract technology to its inventors.
[0] If I obtained your documents illegally, it would be trade secret infringement, which is an independent issue from copyright nor patent.
Re: Google’s Supreme Court faceoff with Oracle was a disaster for Google
#619Earlier quoted context omitted.
> I cannot reconcile this sort of argument with the Baker v. Selden precedent. 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 co…
I really struggle to see what was "brilliant" about Judge Alsup's opinion. After 30 pages of very careful analysis of the case law, his actual holding (at p. 35) simply begs the question. He states: > Much of Oracle’s evidence at trial went to show that the design of methods in an API was a creative endeavor. Of course, that is true. Inventing a new method to deliver a new output can be creative, even inventive, incl…
Yes, it does mix them up. That's exactly what the merger doctrine is intended to do: the expressive character "merges" with the functional character.
From an abstract standpoint it seems that it gives short shrift to the purpose of copyright. But it's necessary if you want to maintain an effective distinction between ideas (including systems and processes) and creative expressions in determining copyrightable subject matter. In practice, if you look hard enough there's almost always some amount of creative originality in any piece of work, no matter how utilitarian it is; originality that by necessity must be copied. (Though Google didn't do itself any favors by stipulating to literally copy+pasting the Java API.) The whole point of the merger doctrine (at least an assertive application of it) is to prevent a court from looking too closely at certain classes of works which, through custom and experience, should be considered as having a principally functional character.
And that's why Google was bound to lose on this particular argument, because the experience and wisdom that begat the merger doctrine--that without a robust merger doctrine the distinction between idea and expression cannot be sustained in practice--has been forgotten. As time marches on earlier precedent has receded into the darkness and Feist becomes the first word on the matter; and all Feist really cares about is creative originality. The entire software industry, AFAICT, universally supports the notion that APIs, per se, shouldn't be copyrightable. (Contrast with software patents, where a substantial fraction do disagree.) But show me an actual implementation or API specification where you could with any degree of confidence [in litigation] separate the expressive from the functional character in a way that preserves the principle and allows you to reimplement the API with minimal risk. Ultimately it's really only viable if you have a special rule for APIs.
Of course, we still have Fair Use, similarity, and other defenses. But those are far more subjective, involve a substantial amount of litigation, and are generally high risk defenses. Without a bright line rule then as a practical matter people should and will be risk averse. Even if a court might judge a particular work functional, it'll never get the chance to say so.
The whole expression-idea dichotomy is a complete fiction. It's certainly not a law of nature. The idea of copyright is rather artificial as well. So it shouldn't be surprising that we will often face such dilemmas and inconsistencies where theory and practice meet. The purpose of the merger doctrine is to give "idea" its due when otherwise "expression" would almost always win out, despite what would be optimal for the promotion of new works. Theoretically the legislature could carve out exceptions, but legislatures suck at that sort of thing, despite what they often teach in law school. More often its the courts, who wrestle first-hand with the ugly technical details and the real-life interests at stake of applying (over years, decades, and even centuries) the abstract concepts, who are best positioned to carve out exclusions or to subtly put their thumbs on the scales to further the ultimate purpose of the law. But, again, this role of the courts is frowned upon today, at least in an area such as this.
Re: Google’s Supreme Court faceoff with Oracle was a disaster for Google
#620Earlier quoted context omitted.
> its about supporting interoperability I think this is a very important point. I haven't read all of the briefs in this case, or looked at the arguments presented at the hearing, so I don't know if Google's lawyers stressed this point, but they sure ought to.
Google would lose if they would continue hammering the interop point and the justices would dig deeper. Google only copied a selective set of Oracle's Java libraries. If they were about interop, they would have copied all of them. So no, Google didn't copy the libraries because of interoperability reasons. Google copied them so they would get access to the large developer community and ride the coattails of the succe…
I like this framing and think it’s entirely correct, but I don’t agree that it necessarily dooms the interoperability argument.
Google wasn’t trying to achieve compatibility with existing code (for which, you’re right, they’d have needed to take the whole set) but rather compatibility with existing developers. Arguably, that is still interoperability.