Comment by AshamedCaptain | Hacker News Reader

Comment by AshamedCaptain | Hacker News Reader

For better or worse, the same arguments ( "API is copyrightable" ) is what was used in the past to prevent 98's Microsoft from doing embrace-extend-extinguish to Java with their "JavaVM with P/Invoke'd Win32 API".

The idea in that case was that when you try to implement something identical to the Java language and standard library, it doesn't matter if you call it Java or "Visual J++"; you are still implementing Java and thus in order to be able to do that you need to agree to Sun's terms (in that time, it was that your implementation needed to pass a testsuite and among other things needed to be "write once run everywhere", something the MS one definitely didn't as it was offering lots of non-portable extensions).

Now to my understanding the opinion here is that literally Sun was trying to do the same to Google (forcing them to ensure their implementation was compatible with Sun's, including being able to run Android software under Sun's JVM), which would have quite put a setback to Android at least as it was at that point (could you imagine Android forced to go with Swing?).

If I try to be fair, I find that in fact Android did succesfully pull the embrace-extend-extinguish strategy that MS was prevented to by legal reasons, and as a consequence basically killed Java on the mobile space (though Oracle has a lot of blame to share here). Perhaps the tides turned and now Google is seen as the lesser evil when compared to Oracle, while in the past Sun was seen as the lesser evil compared to MS. But is there any objective reason why the two rulings should have gone differently?

I am actually completely undecided about how I would have liked this ruling to go. I can see some of the repercussions of being able to copyright "header files" way too dangerous to ignore, but on the other side I have already seen the consequences of not being able to, and they are also bad.

Alien vs predator...

I seem to remember that the 98 case was a trademark violation. Microsoft used the Java brand even though their implementation wasn't compliant (it was a derivative) - which was a big issue for Sun since one of the main point of Java is compatibility ("Write once, run everywhere").

Google however made sure to always be clear about "the Java Programming Language" or such safe phrase that makes clear that they're not the official thing.

Correct. Microsoft could make J++ or whatever; they just couldn't call it Java.

The particular issue was that Microsoft was extending some of the Java language (and maybe com.sun?) classes. If you used any of their extensions, then you had code that could only be compiled with Microsoft's compilers, and you were locked in. (The "extend" phase, which is then leveraged for the "extinguish" phase.)

I think the difference here would be that the "point" of Google copying the API was not to make Oracle's Java be irrelevant, but rather to get a pool of developers that already knew the platform. Whether Oracle's Java stayed as popular or even got bigger was irrelevant for their purposes. The "point" of Microsoft's copying of the API was to make it so that eventually, people would only use their version, like they did with MS-DOS. The Supreme Court was considering the "point" when they were applying a test on "what kind of economic impact does the copying have on the original" and "does this act as a substitute for the original", which is on pages 32 and 33, where they're saying "Oracle / Sun tried to get into the smartphone space but couldn't hack it, Google entering that space didn't meaningfully affect them".

On the flip side, if Microsoft had been judged by the same standard, they might determine that Microsoft's reimplementation of an incompatible Java would have too much of an economic impact on the original to be fair use.

I'm not sure the "API is copyrightable" argument was relevant in the Microsoft-Sun case. Keep in mind that case was settled privately. Since it was never decided in court, it's hard to say what the most relevant claims were, but I don't see Sun making much of the copyright claim. They had a licensing claim because they claimed Microsoft had licensed the Java trademark but was not implementing it fully according to the spec. That seems rather different than this case.

Good points. Though I thought the J++ naming was precisely to avoid the Java TM.

The different case results had nothing to do with the relative size of Google vs Microsoft vs Sun.

Microsoft lost because Microsoft had signed a contract with Sun, and was found to have broken the terms of the contract.

Google never signed a contract with Sun, so was free to act in ways that Microsoft was not.

I led the development of a large GUI app using J++ in the late 90s. This fear you describe is unwarranted.

It's worth pointing out that the list of examples of "Embrace, Extend, Extinguish" on the wikipedia page of that name [1] contains zero actual successful examples of it working. Perhaps you have noticed that you aren't reading this page in an ActiveX control.

This is a boogeyman. Don't be afraid of it.

[1]: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

> It's worth pointing out that the list of examples of "Embrace, Extend, Extinguish" on the wikipedia page of that name [1] contains zero actual successful examples of it working.

Looks like the successful examples were successful enough for everybody to forget about the originals. There is basically no other YP/Kerberos/SMB implementation in use that didn't follow from the MS copy. Netscape was successfully lead to bankruptcy. All the EEE days platform independent dev-tools were successfully lead to bankruptcy. All the EEE days competing office suites were successfully lead to bankruptcy...

SMB seems alive and well? I don't see an "Extinguish" there.

You seem to be conflating "beat in the marketplace" with EEE. Netscape didn't fail because of ActiveX. They failed because web browsers and web servers became free.

Competing office suites struggle not because Microsoft extended some underlying protocol. Like it or not (and I personally don't), Office delivers an incredible amount of business value to its users.

Platform independent dev-tools were, and are, still around. But like the browser, it's tough to make a living selling dev tools when they are generally free.

Microsoft has been a very successful company for many reasons. It's not clear that "Embrace, Extend, Extinguish" is one of them.

Their failure to take control over those markets is not the same as a failure to cause damage. They slowed down development of web standards by many many years, as one example.

> the wikipedia page of that name [1] contains zero actual successful examples of it working.

I will also point out that this page does not contain the letters "Novell" anywhere within it.

As a contractor I have been a victim of _all_ the examples in that website (yes, even Interix. A company I used to work for immediately tried porting their software to Interix the moment it was released for free (I think XP?), and I still have nightmares to this day. God bless that guy who used to have a website with more recent GNU utilities for Interix). They only really succeeded in some of them (e.g. MSN, browser, email) but they definitely tried. Sometimes it was legal reasons that stopped them (e.g. Java) and not just their incompetence.

I don't want to speculate but Microsoft's embrace of Linux and Github has been frightening to me.

If I recall correctly, Microsoft licensed java and Sun sued them for violating the terms of the license. Google never had a license; they were sued for violating copyright. Neither lawsuit determined that embrace/extend/extinguish is illegal/unethical/immoral; they were concerned with the means, not the ends.

The issue is that what Sun was trying to do to Microsoft was equally wrong, but people didn't care as much because Microsoft was more obviously the villain.

The real answer is that copyright is the wrong tool to go after what Microsoft did and the correct tool for that is antitrust. EEE is anti-competitive even if copying an API is fair use.

I immediately thought of Microsoft Visual J++ as well. I will add that the Android Runtime/Dalvik did not really add such extensions to the Java language, only an additional library, so it isn't quite the same embrace/extend/extinguish approach, but the change in opinion is curious, and perhaps more a sign of the times than anything else.

I wonder if Microsoft's actions could have been ruled at the time as violating antitrust laws instead, if the copyright interpretation had fallen flat? Perhaps upcoming antitrust investigations into Google will look at their re-implementation of Java interfaces in the same light?

There's a huge difference. Microsoft was already a monopoly on desktops (and was relying on that dominance to EEE) when that happened, while in Google's case the smartphone industry was nascent.

The 1990s Microsoft issues were antitrust. They tried "embrace-extend-extinguish" because they were in a monopolistic position, and this tactic was viewed as anticompetitive.

But Google (at least with respect to phone OS) was in the position of the startup, and Sun was the big market player. Now, Google had with ridiculous resources at its disposal, of course, but at the time not using a monopoly position to twist arms of carriers, for example. It's not anti-competitive to spend a lot of money to win.

Of course, things change....

Microsoft extended the JDK with VisualJ++, by introducing their COM based version of JNI. They claimed that the result was the same thing; now Google reimplemented the JDK while keeping the same API. that makes a subtle difference. I wonder what would have happened if Microsoft were to have sold VisualJ++ as 'Microsoft JDK'.

The problem was, code written for J++ wouldn't run on "regular" Java outside of Windows, effectively killing the cross-platform aspect of Java and turning it into another Visual Basic.

that's what i meant: by naming it a windows jdk they would not imply to be cross platform. they could then argue that they implemented the same sdk for their platform only. (interesting if Oracle tried to argue that the same logic should apply in this case too).

To be fair, Java isn't and arguable was never a true cross-platform language that the media used to portray it as.

Any non-trivial app always needed a lot of platform-specific code and API calls to get that native look and feel.

You say the alternative is bad but stop short of evaluating how bad. There's clearly a difference here and you don't seem to shy away from giving an opinion yet you also claim to be undecided for a court case that had lasted 10 years.

I'm sorry, but this smells like a bad faith argument.

Reply on news.ycombinator.com