Hacker News Reader

> Copying the SSO allowed Google to greatly reduce the barrier to entry for Android by leveraging the enormous Java ecosystem.

This ecosystem doesn't belong to Oracle. It comprises of thousands of companies and individuals, who actually welcome that their existing investment into Java code can be reused on additional platform.

If Oracle's argument is accepted, it becomes a gatekeeper to the platform who decides, where and for what purpose you can run your own code or not. It greatly increases the risk of using the Java platform.

Playing devil's advocate - perhaps Oracle sees the ecosystem as being a "derived work" of their Java IP. This would be a dangerous view for software.

It's only a matter of time before the hunter - in this case Oracle - becomes the hunted. You would think they know better. But this isn't about code and law, is it? It's a testosterone fueled pissing match. Don't cha think?

At this point though Java is largely GPLv2 with the Classpath exception.

This case increases the risk of using platforms, libraries, and services in general.

> Remember Microsoft's policy of "embrace, extend, extinguish" in the 1990s? If SSO is protectable, then "embrace, extend, extinguish" tactics may cross the line from simply distasteful to actionable unfair competition.

Let's step back a bit. There's a software product in use today that embraced an open standard, extended it and in doing so "extinguished" other implementations in a way that has much greater implications for software development (especially in the present tense) than anything Microsoft ever did.

What product am I thinking of? The GNU C Compiler, of course! And the GNU tools in general (which have thoroughly "EEE'd"[0] competing POSIXes), while we're at it.[1]

If "SSO" or "EEE" are "actionable unfair competition," then whoever is the current owner of the Bell Labs IP has every right, and every monetary incentive, to get the whole GNU/Linux ecosystem shut down.

[0] "EEE" isn't bad! You could just as easily call it "beating the competition by making a product with better features."

[1] Assuming you agree with me that compiler lock-in and operating system lock-in have greater implications for software development than for example web browser lock-in.

For EEE to work the Extend needs to be proprietary so that the third E can take place with regard to competing products. The GCC exists under an open license so it can't be used that way.

It's not a phrase for winning by doing a better job.

I don't recall reading that in the infamous Microsoft memo. Extending and extinguishing can and most certainly has taken place, whether a monetary incentive exists or not.

Over the past 20 years GCC and GNU/Linux have gone from negligible to overwhelming market share in the fields of C compilers and POSIX-on-the-server, thanks in large part to the massive software ecosystem that has developed which can only be compiled using GCC and its non-standard language extensions, and/or can only run on GNU/Linux and its non-standard extensions to POSIX.

Once enormously-popular competing implementations, Borland C, Solaris, etc, have been "extinguished." Surviving and new implementations treat GCC and GNU/Linux as the reference standards more than anything the ISO puts out.

Again, I'm not saying that's a bad thing; just the opposite. Inferior products (which can and do include the published standards themselves) were beaten out by superior ones.

Your case is reinforced by clang's recent rise as a worthy alternative to gcc.

Yes, and especially by the very large investment (of Apple time and resources) they've put into their ongoing effort to reach one-for-one compatibility with GCC's non-standard extensions. It's unlikely Clang would be growing in popularity nearly so fast had they exclusively rolled their own APIs for language extensions, or especially if they stuck strictly to the standards.

> Extending and extinguishing can and most certainly has taken place, whether a monetary incentive exists or not.

Um, sure, but EEE is important because it was a strategy and one that was executed repeatedly by Microsoft. On the other hand, just because some products have been "extinguished" (debatable) does not mean that was the strategy employed by GNU, nor does applying EEE here seem to serve any predictive function.

I think what you are doing is re-defining the strategy and saying it isn't bad. But the way MS used it was wrong. They didn't just create open tools that everyone wanted to use so they won out. They intentionally tried to join into an effort, purely to try to move it in a direction where they could shut others out using their market dominance and then kill off competitors. It's not just winning through fair competition and that's the problem I have with your statement. MS violated the law and behaved in an unethical manner rather than competing on the merits of their products.

This question or questions very close to it must have come up in the endless litigation surrounding things like IBM BIOS/x86 ISA/Apple ][ ROMs/PS1 emulators, right?

What makes this case different? That APIs aren't protectable has been bandied about as gospel truth in the nerdosphere for decades. Was that assumption just wrong all along or is there something about this case that seems to make it subject to re-litigation?

Didn't Intel & AMD sign a licensing agreement allowing AMD to implement the x86 ISA? That would explain one of your examples.

Very good question though.

I was thinking of NEC v Intel although that one is pretty murky too, to the nonspecialist - NEC already had certain licenses, etc.

The former Intel & AMD agreements were about patents, as far as I'm aware. (The latest actually expired a year or two ago. Still, neither will sue the other because it's mutually assured destruction.)

Copyright doesn't say anything about "APIs." It protects any "work fixed in a tangible medium." In the BIOS cases, you just had to connect certain code to known interrupt vectors. The code itself was totally clean-room implemented, and an interrupt vector table that exists transiently in memory isn't "fixed" and "tangible." But a Java API is much more than that. You have tangible permanent source code files containing classes that have specific names and members that have specific names. Copying a Java API involves copying these things. Moreover, here it was clear that Google did have access to the JDK code while developing the Android JVM.

I appreciate that this feels like an arbitrary distinction from the programmer's point of view. The way to think about it, I think, is this: what creativity is required to design the API? Designing a class with particular methods and appropriate names requires at least minimal creativity. Putting the disk I/O routines at INT 13h instead of INT 12h doesn't; it's arbitrary.

No, you don't have to copy the source code to replicate an API. Method and class names are just aliases for memory addresses, which like a phone book, would not be copyrightable.

You don't, but Google did. And unlike the flat interrupt map of a BIOS, there is non-trivial structure and organization to the set of aliases comprising a Java API.

Not really, the words are descriptive.

To be creative,

Sunshine.Unicorn13(spaceshipIsFunnyPants);

would be how you'd set permissions on a directory. Do you see why? No, of course not - if it was at all obvious it wouldn't be creative.

Copyright doesn't say anything about "APIs."

This is still very much an open question and right now not true. Core to this case (and a ruling Oracle has won) is the copyright of the Java API itself.

https://www.eff.org/deeplinks/2015/06/bad-news-supreme-court...

I appreciate that this feels like an arbitrary distinction from the programmer's point of view. The way to think about it, I think, is this: what creativity is required to design the API? Designing a class with particular methods and appropriate names requires at least minimal creativity. Putting the disk I/O routines at INT 13h instead of INT 12h doesn't; it's arbitrary.

I think that's the crux of it or at least, of my confusion because I don't see the fundamental distinction in creativity (or really, fixedness of media although that seems like an easily avoided technicality). A BIOS API is still an API in purpose and intent. It has structure, design choices (parameters and returns, what calls to and not to provide), a specification, etc. Is the legally significant difference really that methods in classes have names and interrupts don't?

The fixedness requirement is really fundamental. It defines the scope of copyright. That's why a live music performance is not copyrightable, even though it's creative.

A BIOS API has purpose and intent and structure and design choices, but all that is implicit in the code. You can write up a specification describing those conventions, and that is copyrightable. But you can clone the BIOS without copying a single word from the specification.

Another key point (in my view) is that these APIs are textual whereas BIOS / protocols / binary interfaces are purely functional. Copyright is meant to cover "forms of expression". Text can have "expressive" creativity, but binary interfaces can have only functional creativity, which is expressly the realm of patents.

Of course, the only reason code is copyright-protected is because it's text, and text can have expressivity and code can be creative. But that does not mean code has creative expression. Most code does not express anything, not in the way other artworks do -- most code exists only to solve specific problems and hence is functional. Sure we can use whatever names we want for the methods and variables but you'll notice they all tend to be very descriptive of what they do. Not much creativity in the text of the code itself (at least for "good" code). All the creativity in software is in the technical ideas, approaches, algorithms and abstractions we use to solve those problems, but unfortunately only patents protect that, if at all.

The real problem here is the use of copyright to protect code. It's a legal hack, enacted because there was nothing better around to use. And to make the hack uglier, binaries enjoy copyright protection because they are "derivative works" from copyright-eligible program code. We need something more appropriate, lying between patents and copyright to protect software.

Sega v. Accolade was over the actual string "SEGA".

IIRC, it was some bytes of object code they copied to be interoperable, so that string could just as well have been an array of random numbers as far as being the key to interoperability was concerned.

Sega v Accolade '92 - copying a trademark is allowable when it becomes a functional requirement for interoperation.

Also, creativity is irrelevant here - it's a collection of fact. 'Hermione' may have taken creativity to come up with but it's a fact that Harry Potter stars a character of that name. As long as the names are the signatures, the names can't be protected.

As for arbitrary, whatever. That's your line in the sand. But it's wrong. As in, outcomes based on that reasoning are less functional. If it ends up being upheld it's yet another case of our legal system weakening us, not strengthening us.

The same guy wrote the code in both places. Therefore he did come up with it "organically".

Yes. But he came up with at / for Oracle. And then nicked it for Google / Android. The former was original. The latter a knock off. I believe that's the crux of the rub, eh.

We live in a ridiculous world when you can "nick" your own code when it's open source.

If we're arguing for a clean room implementation, then it absolutely matters if he copied his old code.

This may be a description of what Oracle is trying to claim, but it has no bearing on the reality of the situation. The OpenJDK code was copied in order to contribute to OpenJDK. It's utterly shocking that Oracle would misrepresent this as theft rather than a gift from Google.

> Copying the SSO allowed Google to greatly reduce the barrier to entry for Android by leveraging the enormous Java ecosystem.[1]

Google used Apache Harmony implementation of Java.

Why Oracle never sued Apache Foundation?

If anybody considering being contributing to 'open source' weighs that in an easy credit is just for others, at least me will reconsider.

Sun did refuse to give the Apache Foundation access to the necessary test suites to certify the Harmony implementation.

Well, I'm sure that part of it is that Oracle committed to Harmony.

But if the issue at hand is whether they copied the interface, how does copying the implementation speak to that? That is, if the creative, copyright-able part is how the interface is structured, why would it matter how intensely they looked at the behind-the-scenes implementation? What role would "state of mind" play there?

Is it related to whatever dynamic requires companies to "clean room reimplement" something?

You do a clean-room implementation to preserve the ability to say "even though these lines of code are similar, they couldn't have been copied because we locked these engineers in a room while they were writing this implementation." But it's also part of the story: "we're good guys; we did all the work ourselves from scratch instead of trying to leverage all the work our competitor already did."

Which is part of the whole rationale of unfair competition law. It hits a moral button when someone takes advantage of someone else's work to make themselves a bunch of money. The more intentional and purposeful that copying is, the more wrong it seems.

The dynamic that requires companies to clean room, typically comes from some license that comes with the original product.

I license you a black box with 3 switches on it and 3 lights. The license dictates you may not look inside. The clean room implementation is, I right down what the effect of each switch has upon the lights. I then give that specification to an engineer who's never seen the box. They build a copy of the box, based on the spec.

What does SSO stand for in this context?

Structure, sequence and organization.

Oracle is the biggest patent troll.