Google’s Supreme Court faceoff with Oracle was a disaster for Google • Hacker News Board

Re: Google’s Supreme Court faceoff with Oracle was a disaster for Google

#761

Post by galaxyLogic » Sat, Oct 10, 2020, 4:33 PM UTC

HotHotLava wrote: post #718

galaxyLogic wrote: post #482

Earlier quoted context omitted.

Are you saying code which calls library functions should not be copyrightable? The Baker opinion can of course be used as argument pro-Google. But it is also just an "opinion". Each case must be decided on its own. I believe there is a big difference between scale and structural complexity with the (inter-connected) Java API and some text-book examples of accounting layouts. At some point quantity becomes quality.

I believe he is saying, and I would tend to agree, that it does not matter if Google literally copy/pasted the Java header files or if they had merely copied the API (ie. the same structure, sequence and organization) in a different language; for example by creating a Go package having exactly the same package structure and providing the same functions as the Java standard library. In both cases, they would have "cop…

Baker case subject-matter was "... certain forms or banks, consisting of ruled lines, and headings, illustrating the system and showing how it is to be used and carried out in practice".

So that case was about illustrating and explaining a method of doing accounting. There was no textual matter copied.

In Oracle vs. Google I believe the source-code of the APIs was copied.

Even if one would consider a way to do accounting an "API" an explanation and illustration of an API is not the same as the "API".

Explaining or illustrating a "structure" is not the same as copying that structure. Note that copyright applies to actual "works of art", not to abstract "methods". An API (as referred to in this case) is not an explanation of a way of doing things but an actual constructed artifact, source-code.

Think about books. Their content is copyrighted. You can not copy their content. But nothing prevents you from explaining and "illustrating" the content of a book, as long as you don't copy significant portions of the structure and ordering of its verbatim words.

Re: Google’s Supreme Court faceoff with Oracle was a disaster for Google

#762

Post by int_19h » Sat, Oct 10, 2020, 10:29 PM UTC

salawat wrote: post #758

mumblemumble wrote: post #543

Earlier quoted context omitted.

That is true, but it's irrelevant. Oracle is not suing app developers for writing Java code to run on an Apache Harmony based mobile OS. It is suing Google for proceeding to base their mobile OS on Apache Harmony after they backed out of licensing negotiations. As was observed during the hearing, everyone else who made a mobile OS was able to do it without copying someone else's API structure, so the idea that the AP…

Huh. I actually was about to suggest that the Java Hello World should work, but a quick perusal dismisses that. Why would Google bother keeping the JVM class hierarchy if they were implementing a different VM to run against anyway? That just seems to be asking for trouble. I can sort of see some merit to Oracle's argument now. It would be one thing if JVM byte code was treated as an Intermediary representation that t…

"Hello, world" is a rather poor example, because there's little practical value in a mobile application like that. The real value comes from being able to reuse many existing Java libraries.

Re: Google’s Supreme Court faceoff with Oracle was a disaster for Google

#763

Post by int_19h » Sat, Oct 10, 2020, 10:32 PM UTC

imtringued wrote: post #684

phire wrote: post #580

Earlier quoted context omitted.

Are google deliberately not arguing the "APIs should be patentable but not copyrightable" angle because they think that would make the situation even worse than it already is?

Patents are opt in while copyright is opt out. If APIs are copyrightable Google will never get access to the Java API, ever. If someone gets a patent then it will expire eventually. Of course Google wants to go back to the status quo: APIs not being protected by IP rights.

Is this actually the status quo? There are patents on APIs around, and since they were granted, it would seem that USPO, at least, doesn't think that APIs are inherently unpatentable.

Re: Google’s Supreme Court faceoff with Oracle was a disaster for Google

#764

Post by int_19h » Sat, Oct 10, 2020, 10:38 PM UTC

biztos wrote: post #388

cashewchoo wrote: post #273

Earlier 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…

> copyright should not exist at all Copyright is not just about software. Imagine a world in which you write a novel, let's call it Harry Potter, and publish it. And then I see people liking it, so I publish it too, but I can sell it cheaper because I don't have to recoup the costs of having written it. Or imagine you write and record a song, let's call it Revolution. A shoe company can use that exact recording in an…

Don't assume that those who are against all copyright hold this position in isolation from other politics. Some of us think that much of the economy needs to change in significant ways, and copyright would be just one aspect of that.

And there are changes that aren't even all that radical, that are enough to make a counterpoint here. For example, with a sufficiently generous UBI, a lot more people would be able to pursue arts for the sake of arts. One could reasonably argue that removing the profit motive would not only not break such an arrangement, but improve the quality of the output.

Re: Google’s Supreme Court faceoff with Oracle was a disaster for Google

#765

Post by int_19h » Sat, Oct 10, 2020, 10:43 PM UTC

thu2111 wrote: post #666

Spooky23 wrote: post #366

Earlier quoted context omitted.

It’s mind blowing to me that Google was too cheap to buy a license or buy Sun considering the strategic importance of the platform.

IIRC it wasn't purely about money. Sun had a mobile platform at the time, J2ME. If you wanted to use Java on mobile, it had to be J2ME. There was no option back then to just pay money and pick'n'choose which bits of Java you wanted. In fact there still isn't, the Java guys are zealous about compatibility. And J2ME was in turn a slow, multi-vendor, standards oriented kind of thing with multiple implementations. It was…

Could they have implemented J2ME as spec'd, and add proprietary APIs on top of that? I remember that Sun balked when Microsoft did it, but that was back in 1990s. Was it still a limitation when Google started working on Android?

Re: Google’s Supreme Court faceoff with Oracle was a disaster for Google

#766

Post by int_19h » Sat, Oct 10, 2020, 10:46 PM UTC

imtringued wrote: post #698

cashewchoo wrote: post #273

Earlier 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…

>Personally, I espouse the "copyright should not exist at all" viewpoint. Well, the original lawmakers agree. They set a 14 year maximum. In other words: They acknowledged the necessity of copyright but they think it should only be temporary and not exist. The problem is that it is too damn long nowadays.

It should also be noted that the original copyright terms were devised for a society in which there was, for the most part, no practical way to move information faster than people. A copyright holder today can start extracting profits from that copyright much faster, and on a much larger scale, than anybody could have in the 18th century. So the terms should be shorter, if anything.

Re: Google’s Supreme Court faceoff with Oracle was a disaster for Google

#767

Post by andrewjl » Sun, Oct 11, 2020, 12:04 AM UTC

jboy55 wrote: post #583

andrewjl wrote: post #547

Earlier quoted context omitted.

> 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. 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 sta…

>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 no…

> I think the key word in your argument is 'implies' and you didn't use the word 'requires'.

You can make this same argument for the function name or the parameter names. Nothing about the implementation of the max function requires it be named max to work, it just needs to link to a function pointer or some equivalent construct that acts in a way as defined by a specification for what max should do. A name like max is helpful for use though. So is arranging max, min, and other standard math functions in the same module. Treating method names as different from other forms of organization is inconsistent. They are all forms of organization.

You've also raise some points re interoperability, but I'm not really arguing about that. My own argument is more of a conceptual one based on the difference between an API and an API contract as well as on the role a system specification plays in API design & use. You could probably extend this concept to the interoperability question and I see no reason why it won't make sense, but that's not what I'm doing here.

Re: Google’s Supreme Court faceoff with Oracle was a disaster for Google

#768

Post by andrewjl » Sun, Oct 11, 2020, 12:24 AM UTC

wahern wrote: post #566

andrewjl wrote: post #553

Earlier quoted context omitted.

Are there some cases you can cite where this movement occurred? They don't need to be software related. I'm VERY curious about this trend.

Off the top of my head: * Star Athletica LLC v. Varsity Brands Inc., 137 S. Ct. 1002 (2017) * DC Comics v. Towle, 802 F.3d 1012 (9th Cir. 2015) * Golan v. Holder, 565 U.S. 302 (2012) One of the most important cases for contemporary copyright law was Feist Publications, Inc., v. Rural Telephone Service Co., 499 U.S. 340 (1991). It was a nominal a win for the defendant, but in fact the opinion set a very low bar and ef…

What are your thoughts on SAS Inst. Inc. v. S&H Computer Sys. Inc.? Does it fall into the grouping above in your opinion? I find it to be a very quirky decision in light of the merger doctrine principles you wrote about, unless I'm missing something.

Re: Google’s Supreme Court faceoff with Oracle was a disaster for Google

#769

Post by andrewjl » Sun, Oct 11, 2020, 1:15 AM UTC

mumblemumble wrote: post #524

andrewjl wrote: post #515

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…

I've had a chance to read your materials. Here's a question:

Using the AFC test [1], which seems common throughout the case law cited, how does one distinguish a design decision from a standard programming technique [2] in the context of a programming language's standard library API? By virtue of terminology, it's a standard. Is it defensible because it is a design decision concerning a programming language implementation? Then how does that square with computer languages not being copyrightable? What argument can one make so it can pass the filtration step of the test?

[1] https://en.wikipedia.org/wiki/Abstraction-Filtration-Compari...

[2] Computer Associates Int. Inc. v. Altai Inc.

https://web.archive.org/web/20120310144346/http://ftp.resour...

"in many instances it is virtually impossible to write a program to perform particular functions in a specific computing environment without employing standard techniques." 3 Nimmer § 13.03[F], at 13-65. This is a result of the fact that a programmer's freedom of design choice is often circumscribed by extrinsic considerations such as (1) the mechanical specifications of the computer on which a particular program is intended to run; (2) compatibility requirements of other programs with which a program is designed to operate in conjunction; (3) computer manufacturers' design standards; (4) demands of the industry being serviced; and (5) widely accepted programming practices within the computer industry."

Re: Google’s Supreme Court faceoff with Oracle was a disaster for Google

#770

Post by salawat » Sun, Oct 11, 2020, 4:34 PM UTC

int_19h wrote: post #762

salawat wrote: post #758

Earlier quoted context omitted.

Huh. I actually was about to suggest that the Java Hello World should work, but a quick perusal dismisses that. Why would Google bother keeping the JVM class hierarchy if they were implementing a different VM to run against anyway? That just seems to be asking for trouble. I can sort of see some merit to Oracle's argument now. It would be one thing if JVM byte code was treated as an Intermediary representation that t…

"Hello, world" is a rather poor example, because there's little practical value in a mobile application like that. The real value comes from being able to reuse many existing Java libraries.

Hello World! In a Turing space is all you need to implement every other program. Arguments that "there exists no program" come with an inherent verifiability criterion of " well here's one." The thing that Oracle is pissy about is that things get transpired out of Java Byte code, into Dalvik or ART.

Oracle wants patent like protections for the output of Java, and overall API structure in all languages. They want copyright on a meta-pattern. Just trying to imply skulduggery to "look, they joined our API structure, and didn't even do a good job of it, so they should have to pay us for infringement" is a transparent farce. It's an entrenching power grab.