Sadly, and by no choice of my own, I am the 1 person on Earth who is most familiar with and has followed this Oracle/Google Java API thing since its absolute inception. And I mean, like, YEARS before the suit was filed. When I worked at the SD Times, I was put onto a story in 2005. The story of Apache Harmony, a brand spanking new open source project that sought to reimplement Java under the Apache Software License.
Way back in the heady days of 2005, there was a major problem. There was Java, and then there was… well, nothing, really. In the world of business software, Java had taken over half the market, and because the open source Linux revolution was in absolute full swing, Java usage was only growing. Meanwhile, Microsoft’s wall-garden was becoming increasingly appealing as Ballmer’s enterprise-first strategy took hold. The X86 server had become the standard by which datacenters were measured.
This is also the time where Microsoft really lost the plot on mobile and tablets, but those are stories for another time. Dot NET and C# were really neat, and they were evolving into platforms for businesses to innovate upon. Meanwhile, Java was this… thing. It was expensive to run it quickly. It was complicated to manage at scale. It was hard to develop for in a distributed enterprise fashion, and if you had a really big monolithic application (as was the style of the time) you had to write code, hit compile, and go grab lunch. The development loop really sucked.
There was innovation to be had, but it was coming from Sun Microsystems, and while Sun had exploded into an Internet darling in the 2000 dot com boom (“We’re the Dot in Dot Com” was their slogan for a time), truthfully, Microsoft and Linux were eating the company alive. Sun’s expensive, proprietary servers were being defeated by rooms full of PCs running Slackware. It was just cheaper to run commodity hardware servers. Sun had even purchased a commodity hardware Linux server company in Cobalt Systems. I don’t know if they thought that would get them into the X86 server market, or if they thought it would kill the competition, but Cobalt was gone very shortly there after.
And Sun eventually offered X86 servers itself, anyway, but again, another story for another time. The point here is that Sun ran and controlled Java, and Sun did not make any money on Java. Or at least, it didn’t make enough money on Java to replace the rapidly vanishing server revenues. Sun was, at its core, a hardware company, not a software company. Their desktops were for architects to do CAD design, and for scientists to run particle accelerators. Their servers were for the department of defense, HPC, and other designer applications that suddenly had no need to exist as a distinction, again, because of Linux and X86.
SGI fared even worse, as its servers were used in 3D modeling, and that type of hardware was now being distributed to consumers by NVIDIA and ATI. It was a bad time to be in the non-commodity computing hardware business.
So Sun had to make money on Java. It did this by selling licenses to others who wished to reimplement the specifications of Java themselves. One of the ways it did this was by selling a license for the tools it had built to validate a Java implementation against the specifications laid down by the Java Community Process, AKA the JCP.
This is a really complicated way of saying that Sun sold you a set of software (called the Test Compatibility Kit, or TCK) which you would then run, and if it passed the test, you could say “Hey, our Java thing here is certified to be compatible with Java.” Basically, a gold stamp of approval from the Java gods that your… whatever… was OK to run Java applications, and would not barf up problems.
Why was this needed? Lots of reasons, but let’s just say that in 2005, Sun Microsystems was incredibly jealous of IBM and BEA Systems. Those are the two companies who’d taken it upon themselves to build out super fast, highly scalable Java Application servers.
What are those? Why, the big software piece in which all the Java runs. If you run a Java applicaiton on a server, like an online store, then you can process waaaay more orders if you pay BEA or IBM for a license to use their Java Application Server.
So, here’s Sun, which created Java and made a HUGE deal about it being the greatest thing in computing since the invention of the bit, but they are basically only selling a software license to a few dozen software companies, while BEA and IBM are making literally billions on their jacked up, software engineering prowess-driven optimizations of the specification Sun graciously opened up to anyone and everyone to read and redo. Sun had a big licensing business around set top boxes and media players, here, but every step forward was a step back there: media players were surely going to die as video streaming took hold.
Oh, and one more thing. Sun had a cloud you could buy time on back in 2005. Their Grid was quite literally Amazon Web Services in 2005. Yep. They missed that boat. Big time. I blame the fact that it was really only a useful tool for Solaris shops, and Sun had failed to innovate on the developer side, and it didn’t ride the Virtualization wave. Which is nuts. A Java cloud could have murdered IBM and BEA in their sleep, but the market was not ready. Oracle threw this in the trash at acquisition time, BTW.
Honestly, Sun is kind of the guy at the race track who bet on the last horse in every race, despite having worked for years researching, planning, and watching races. I can’t tell if it was bad luck, bad timing, or bad McNealy. None would surprise me. You’d really have to work hard to fuck up this bad at this time in the market, with that set of technology, but it wasn’t really that Sun fucked up, so much as Sun HAD fucked up and left itself unable to capitalize on all the stuff it had made.
The JCP
The Java Community Process, the group which ran and charted the future of the myriad Java specifications, had always been couched as an open community of vendors, developers and international fellows who’d convene a few times a year to manage sub-projects, roadmaps, and all the other things you need to manage when you run and develop what was, at the time, the most popular programming language in the world.
The JCP produced solutions. Slowly. And at great exertion of effort and discussion. Enterprise Java Beans? Hibernate? JAXB, JavaFX, JPA, and every other thing you’ve ever heard of in the Java world of the 2000’s came through the JCP. Maven did not, but that’s another story.
The JCP was also not designed to withstand intense scrutiny. It was an organization engineers, with very specific processes and practices in place to help those engineers do the work they needed to do. What the JCP was not setup to do was govern itself. While there was an executive committee, as a “community” organization, it was generally felt that the community should control the processes and legalities of the JCP, not the Executive Committee alone, and by extension, Sun. There was no way to enact change within the JCP unless you were on the executive committee. No way for it to manage the things Sun was doing with the language and its licenses, and no way for the folks who were actually driving the boat to pull any levers to give the JCP a better handle on things.
Instead, Sun ran the show. So whenever the JCP and Sun were coming up against one another with cross purposes, Sun always won. It was getting so bad that even Oracle began dunking on them, but we’ll see that later.
Bumbling Sun
The other thing to remember about Sun is that they were the absolute kings and queens of doing it their damn selves. If the industry has decided the MIT license, the Apache License and the GPL are the big, popular, acceptable licenses for everyone to use, well, Sun’s gonna go off and create CDDL, which I feel didn’t do a damn thing of interest, nor did it create a popular new way to develop in open source, as Sun had hoped. Like most Sun open source efforts, this was basically the same thing everyone else was doing, except Sun was going to tweak the little knobs and dials until it was juuuust difficult enough to deal with so you’d have to come back and pay Sun to really use it. This did not work, I should mention, and just succeeded in closing off their ecosystem from the rest of the world.
Eventually, after Oracle took over, (honestly, this began before the acquisition), Patrick Curran took over as the chair of the JCP and began pushing reforms through the existing processes, which was a brilliant and recursive way of solving the problem. He used the JCP to change the JCP.
Unfortunately, this all occurred long after the ship had sailed, and Sun had basically lost the good will of the community. When the OpenJDK finally arrived, Java had lost a lot of its momentum. It’s still the #3 or 4th most popular language in the world, but I honestly believe the slow pace of change and refusal to adapt the processes and JCP hampered Java’s ability to become a more viable language, long term. By the time the JCP got its act together, the cool kids were already moving on to JavaScript, Ruby and Scala. All of those languages were eventually supported to run on Java Application Servers, interestingly enough, but again, that didn’t make any money for Sun, or later, for Oracle. It just meant you could now run your Ruby workloads on your massive Java server.
And honestly, is the problem you’re trying to solve actually solved by putting more applications on a single already resource-constrained server that handles all the business processes? Yet again, Sun missed the point entirely.
Java had, by 2010, completely lost the front-end fight, Minecraft’s first alpha aside. JavaScript won by a huge margin, despite all the strum and furor around Java equalizing the world and running everywhere. The community was simply too focused on their individual pools of revenue to really collaborate on a future that was actually better for Java developers.
While Java developers were grateful to finally have package and dependency management in Maven, npm pushed JavaScript to become the most insanely diverse and easy-to-use ecosystem ever devised. Meanwhile, JavaEE was still a thing, and still required ages of configuration work just to deploy an application. This is why Ruby took off.
So let me rephrase my “Java lost” argument to a “Java failed to make the right people enough money.” It’s still an incredibly popular and useful language. It’s just not a place where I can just do 54 includes, add 6 lines of glue code, and produce a functional database-backed Web application. Speed, simplicity, and ease win the developer game, every time.
The worst part about this whole Sun saga, however, is hat Sun was always a good actor. It always kept some things off limits, and had ethical lines it would not cross in the industry. It appreciated open source, as a concept, and wanted, deeply, to be a good actor there. But at the end of the day, moving from a hardware company to one that makes money on IP only is a tough switch. It’s a transition from being a sales-driven, requirements focused organization, to one that’s entirely serving IP law suits, and asking people developing using your stuff to cough up a per-device fee is quite a shift.
It’s a move from being a hunter gatherer, to being an assassin.
The TCK
In 2005, the point of contention was the Test Compatibility Kit (remember those?) for Java 5, which had just arrived (Hurray for annotations and generics!). The TCK for Java implementations at the time very specifically stated that things certified with this TCK could then be run on servers or desktops. There was some mention of phones, but this was a primitive time, and the terminology was not very specific. The JCP and the open source community were worried that Sun could use this TCK clause to limit the usage of 3rd party Java implementations in devices and mobile phones.
What would that mean in reality? No one knew, but it definitely gave Sun power over the rapidly growing field of mobile devices that weren’t strictly phones. JavaME was a thing, remember, and a lot of flip phones ran it, much to the chagrin of the mobile developers out there.
In amongst all this, one fellow who we’ll leave nameless, was even planning to build a mobile device operating system, but was worried about this very problem during his architectural phase. But again, that comes later.
Because of other licensing and IP issues, Geir Magnusson, one of the Apache Foundation’s big wigs at the time, decided to reimplement Java under the Apache Software License. This was to be the first open source implementation of Java, and it moved along fairly quickly. But as soon as it was time to certify this open source Java as being compliant with the Java specification, Geir and the Apache team were suddenly presented with a problem: If Harmony passed the TCK and was certified and licensed as a Java implementation that complied with the official standards, it would still only be certified for use on desktops, servers, and a very narrow definition of mobile phones.
Geir was and is a pistol, and eventually would go on to be a founding engineer of 10Gen, later renamed MongoDB, and then went on to the Gilt Group. He was adamant that this licensing and testing gap would leave users of this open source Java exposed to possible legal action if Java were to fall into the hands of a bad actor. Sun Microsystems was quickly nearing a day of reckoning, so the idea that the company would be sold, or that Java might be sold was very real at the time. Everyone used SCO and Oracle as examples of a bad actor acquiring Java. Ironic.
Geir’s go-to scenario was an X-Ray machine at an airport. What if it ran Java? Would the TCK licensing restrictions mean that the manufacturers of that device would be disincentivized from using an open source implementation of Java, or any of those derived tools because of some vague legal gap that doesn’t make their machine compliant? If someone ran Harmony on a non-desktop, non-server, non-flip-phone, could Sun then sue them for IP violations because the granted licenses do not apply to that device?
The oddest part about this whole thing is that Java was initially created as a language for programming a remote control. It wasn’t intended to be used in enterprises, on desktops, or even in servers. It was the classic “Oh, we’re making a new thing? I’ll whip up some little language for it,” type scenario. The same thing that happened to JavaScript: this language that checked all the cool features boxes was knocked up by a great developer, and suddenly it was popular and used everywhere. The right language at the right time.
And that time was the 90’s: an era where big ass computers were becoming even more important than they were in the 70’s and 80’s. Now, instead of your company using the big iron downstairs, your customers were using those machines. Their uptime was directly tied to revenue, not to revenue producing entities. Unfortunately, all of those big iron machines ran different types of Unix, different flavors and versions of C, and had different hardware.
That was the problem Java solved: write the server software once, run it on any server. The weird thing for Java was that, initially, the marketing was very heavily focused on the desktop usage over the Internet: push one client and it works on all end user machines. Java was to be the Internet’s solution to the the different desktop environments out there. And while you could definitely argue that client-side Java as a consumer thing really never happened, you also don’t get Minecraft without client-side Java. At best, client-side Java was a thing, but not a big thing.
Server side Java, however, was and still is enormous. And this was not the plan at all. The plan was to use Java to push set top boxes. And now, a decade later, Java was the center of a fight over those very devices.
And, as an aside, when Sun saw this “Web apps = revenue, so uptime is essential” thing, they decided they’d make premium, reliable systems. Sun said, “We’ll engineer the best servers and most reliable OS ever to enhance reliability!”
But developers and admins around the world just shrugged and said “for the price of 1 of your machines, I can buy 5 of these piece of shit X86 boxes, write my software to be redundant, and even when one of my pieces of shit goes down, I’ll just swap something else in the next day, and still have 5 times the available server power as your 1 system.”
Oh, and now they don’t have to pay for the OS, and they’re starting to write software that is more amenable to running in the cloud. Sun missed ALL of this. Eventually, it was selling piece of shit X86 boxes. And Dell had already figured out how to dominate that business.
Enter Oracle
The strife in Java land continued and became tumultuous as Sun neared a sale of itself. The company eventually released Java under the GPL, which was probably the best move they ever made, community-wise, but it was a long road to get them there. The JCP refused, or was most likely not allowed to change anything about the TCK. Oracle even came to the table at JCP meetings and complained about the TCK licensing restrictions. When Oracle later bought Sun , one of the first things I asked to the folks who were running the JCP, (And who had finally implemented an internal meta management system, incidentally) if the TCK would be changed. Oracle’s folks were very adamant that this would be one of the first things they’d do with Java.
They did no such thing.
Instead, here’s Oracle staring down at this bucket of Java stuff it now owns. In the end, it’s mostly just 3 implementations (JavaME, JavaSE, JavaEE) and an ass-load of IP in the form of copyrights, specifications, patents, and source code. And Oracle LOVES IP. While some companies, like IBM and Google, see things like software patents as sandbags against attackers, Oracle sees this sort of stuff as ammunition for its artillery battalions. It feeds the litigation fires. But remember when I said Java never made money for the right people? Oracle was not about to let that happen again. Anything and everything was up for monetization, and Oracle was already an organization that could go around the world and demand payments from users under threat of legal action.
That licensing gap around mobile devices finally came into play when Google bought up Android. That entire platform was built with two major components: a super low resource UI layer designed by demoscene hackers from Scandanavia, and a Linux/Java operating system built on Apache Harmony.
When Google completed what, frankly, was one of the best software acquisitions in history, they suddenly found themselves in possession of something that was, in theory, exposed to IP risk. While I don’t really think Google quite grasped this at the time, they eventually realized it and began porting everything in Android to the OpenJDK, the real open source Java, complete with proper licensing. Keep in mind, Google had made major waves in the Java community at the time with Google Web Toolkit, reinvigorating the Web-based Java application community at the time.
So here’s Oracle, looking at Google making all this money on Android, and with billions of devices world wide. Once again, the biggest curse of Java seems to be the intention of making money on its base intellectual property. Oracle basically sat up and realized it could sue over the TCK stuff in Harmony, and of course, once their lawyers got into it, they expanded the suit and examined Android with a fine-toothed-comb, looking for something else that was actionable.
In the end, this all coalesced around the APIs, which Oracle claims it owns every single bit of: if you go to bed tonight and dream up an architecture reimplementing some Core Java API functionality, like, oh, I don’t know, a JDBC call to a database, well then, Larry’s gonna be at the foot of your bed with a bill when you wake up.
As we all know, this is how software works: some guy says, “hey, to talk to my thing, you do this.” And so, the developer does “this.” Later, the developer might decide they like they way they handled “this” and thus, they reuse it in their own software so others can just bring their “this” to this new thing.
Imagine the following scenario:
- Joe: Here’s how you hang a door.
- Bob: OK Joe, I am going to pay you to hang this door in my house. Here is the money.
- Joe Does the work, takes the money, leaves.
- Bob hangs another door in his house using frilly fancy hinges, but still the same diameter pins and screws.
- Joe: Fuck you Bob, pay me again.
If the original owner went around suing people who obeyed their fucking specifications, the entire world would melt into a seething ball of law firms slowing engorging themselves upon illogic and chaos. Microsoft could sue Amazon for making USB controllers that work in Windows. Apple could sue bluetooth speaker makers, as could Ericsson, which I believe still owns the rights to Bluetooth as an IP. It’d be insanity. Poll Twitter with your own software? Law suit!
So thank fucking god that Oracle lost here, of course, they’ll appeal on other terms or bring another suit with different specifics. Still, this all goes to show how insanely out of hand things can get in this industry when profits come before software engineering excellence. It’s why open source licensing maniacs get so pedantic: if they don’t get pedantic, stupid lawsuits that threaten all of humankinds’ productivity get all the way to the Supreme Court.
Oracle is, and always has been, a bad actor. The only thing they saw in Android was a billion devices they could get 10 cents a piece for in perpetuity. That wouldn’t have helped anyone, anywhere, except Oracle share holders.
And this is why IP law is so nuts and scary and dangerous when misused.
What’s the Lesson
Well, the first lesson is: “Don’t be Sun Microsystems.” My wife and I were just talking today about how the 2008 recession wasn’t too bad here in the SF Bay Area. It hurt people, definitely, but the 2001 Dot Com bust was far worse. Its repercussions were felt for the next decade, as companies that had been on top of the world in 2000 repeatedly disappointed Wall Street. Sun Microsystems, Yahoo!, HP. Lots of troubled companies in tech started to encounter their problems after the 2001 bust.
And Sun’s woes really came from the fact that it could not successfully pivot into a software business. honestly, I don’t know how they could have. Their research labs were just depressing. They’d open them every year to the press, and I’d attend dutifully. The offices are now Facebook’s.
Highlights of their research in 2006? They were building some high speed back-ends for their SPARC Server racks. They had an MP# sorting and visualization app that was far worse than iTunes at the time. The interesting stuff was a new encryption algorithm that was super fast and the Fortress programming language, which was a modern, secure and memory managed Fortran.
Not exactly a recipe for a bright future. Oh, and they were still pushing set top boxes.
Now I should be clear that Sun made a lot of money on licensing Java for those boxes. They were in DVD players and Blu-Ray players. Licensing was a huge thing for them, and their patents were terrifically early in most techs. But that was all they had in the end: licensing deals. They made nothing. They sold nothing of consequence. They didn’t innovate.
Instead, they built a cargo container full of servers and claimed they could ship it to a region where a famine was taking place. To this day, I have no fucking clue why anyone would ever want to do that. The last dying struggles of a hardware company seeking to return to its former glory as the kings and queens of the top end of computing hardware.
The next lesson is: Don’t go anywhere near Oracle. Don’t use their open source projects, don’t touch their IP, and for damn sure, don’t reimplement a standard they control. You will get sued. Hell, you’ll get sued even if you are a customer of theirs.
Third lesson: THIS CAN NEVER HAPPEN AGAIN, PLEASE!