This is a bit of a reiteration of my previous blog, but, I wanted to be a bit more clear:
Ask yourself this question…Why do we not have a Java 7 release? Mainly it is because of Apache (not the developers, but the bureaucrats) filibustering the Java 7 vote in the JCP Executive Committee all because they didn’t want a Field Of Use restriction for Harmony. They felt entitled to the Java brand just because they are Apache. For those of you who don’t know the Field Of Use, (IIRC) was that Harmony wouldn’t have been able to be used within a mobile environment. IMO, I’d much rather have had a Java 7 release than to lift the FOU restriction just to make one Apache open source project happy. I’m upset with my company for supporting this fiasco.
Another side point:
The “I’m leaving the JCP because it isn’t working” play that seems to be popular at the moment, is, IMO, a big slap in the face to those of us who have put a lot of time, effort, engineering, and dollars to improve the Java platform, specifically on the EE side of things. Specifically, the Apache CXF project who have created a top-notch SOAP implementation, as well, of course the Tomcat effort. For Red Hat, we’ve put huge amount of engineering time into EJB, JPA, JSF, CDI, JAX-RS, and Validation. There are many other companies, individuals, and open source projects that have made similar contributions. Those of us who cared enough about the platform (and Sun and Oracle are both in this camp) have improved and evolved Java EE so that it is viable platform into the next decade, despite the best efforts of the “Party of NO” coalition of non-contributors on the EC and on the Java EE JSR.
IMO, if you are unwilling to give up something to obtain the Java brand, if you’re creating competing technologies that you have no intention of bringing back to the JCP to be standardized, if you or your company are not consumers or implementors of JCP specifications, then, you probably should leave the JCP. In fact, I encourage it, so that the rest of us can have less obstacles in moving the platform forward.
Dec 13, 2010 @ 18:40:44
Or maybe it’s because the majority of JCP members agree that FOU restrictions are wrong (see comments on votes for proof or look at who was repeatedly voted JCP member of the year during the dispute).
Under Sun there was always a chance that this would be resolved. Oracle have made it clear that they do not intend to resolve it. There’s no point in being involved in an “open process in which the lead can change the rules for the benigit of a minority.
Oracle are free to manage their IP however they like, they (and others) should not be free to lie about their willingness to be open to the community.
Report facts not interpretations of the facts please.
Dec 14, 2010 @ 13:37:59
I’ve actually been to one of these EC meetings. At the time, it was a revenue issue for Sun, and IMO, I can relate to that. Making Java open source after more than a decade, is, IMO, pretty open and a step in the right direction. Especially after spending millions and millions of dollars to develop it. Sometimes the sense of entitlement in the open source community baffles me.
Dec 16, 2010 @ 16:16:26
And if Oracle changes the license terms of their JDK or introduces “features” that make JBoss nearly inoperative? Wouldn’t it have been nice to not have that nice classloader race condition for several years (the dirty hack didn’t always work and had performance implications). Also if this were Java EE and directly affecting you, you’d sing another tune. There are people who work 2x as hard as you that this does affect.
Dec 16, 2010 @ 16:50:46
Andy, JBoss has already been through this with Java EE license. Unlike apache, we were unable to get the TCK for free, and no, we did not just leave Java EE or refuse to implement JSRs.
BTW, its pretty easy to work 2x as hard as me, so not really a good comparison…
Dec 16, 2010 @ 18:49:48
Not really similar cases bill. Sun didn’t make JBoss change to a non-open source license as a condition of the TCK (adding those FOU restrictions would not allow JBoss to be strictly LGPL).
In fact JBoss would have had NO CHOICE since it COULDN’T change the license.
So if Oracle does similar stuff as this: http://monty-says.blogspot.com/2010/12/quick-look-at-mysql-55-ga.html to their JDK how is RH going to handle that? A non-viable OpenJDK/Java and no alternatives that can be called open source?
And in my view it was the 20 roadmap changes that delayed the JDK not Apache.
Dec 13, 2010 @ 18:50:23
So it’s Apache’s fault there’s no Java 7 for not caving on the FOU? Why not vice-versa?
What is the JCP for if its members can’t voice their opinion and help model the future of the platform?
Dec 14, 2010 @ 13:33:12
Because there’s other ways to force the issue that’s why its Apache’s and other’s faults on the EC. One way would have been to just call harmony a Java implementation and ignore Sun. Its what we did years ago when Sun refused to even return our phone calls when we asked to license the Java EE TCK.
Besides, why should the whole Java community suffer because of one Apache open source project? Seriously!
Dec 13, 2010 @ 19:54:31
An interesting perspective.
The problem I have is with this line “They felt entitled to the Java brand just because they are Apache.” I would strongly suggest that they felt entitled because the legal agreement says so*.
Perhaps you should clarify – do you support the breaking of legal agreements? If so, why should anyone sign a contract with you?
*Note that I’m not arguing that the legal agreement should necessarily have been signed in the first place, but once signed I believe it should have been honoured or an agreed compromise deal made to allow parties to escape it.
Dec 14, 2010 @ 13:30:31
I’ve said this to another Apache guy internally as well when he gave the same party line you did. I just don’t care about Harmony or Apache’s issues with the JSPA or some perceived breach of contract. I would rather have Java 7 and a top-notch JDK. Its Apache’s fight, not mine, and IMO, though it may not be held by others at my company, not a battle Red Hat needs to fight either.
Dec 14, 2010 @ 03:00:56
FOU restrictions violate the open source definition: http://opensource.org/osd.html
JavaEE stuff is so last decade. It’s time to go fully mobile and fully cloud… Oh wait, you like your iPad that can’t run Java (because) and your JCP that says nothing else can either.. . Why would they ever object to these things 🙂
Dec 14, 2010 @ 13:41:12
FOU you! 😉
Holding up Java 7 was not the right course. Java ME consumers would have, and did, find an alternative. That’s why, it was pointless to hold up Java 7. It was as simple as not licensing Java ME anymore…
BTW, I guess if Java EE is so last decade I should find another job. You hiring Andy? HOpe things are going well with you.
Dec 16, 2010 @ 15:38:54
I agree that holding up Java 7 wasn’t the right course. I said they shouldn’t participate in the JCP at all until all the legal crap being promised was delivered. Sun doesn’t have a good track record of following through on its promises. I got flamed for that and called naive, let the big boys handle the big game.
Things are great. Revenue more than doubled, we just hired 2 more people and will probably hire more. Sales are up. I’ve finally cut my travel and I look forward to spring when I can ride my motorbike again.
-andy
Dec 16, 2010 @ 08:13:11
Bill, please point to the rules in the JCP EC that allow a filibuster. Apache’s vote was just one. If this was just Apache’s issue, Sun could have pushed through Java 7 with nary a speed bump caused by Apache.
A quick history lesson. I was Apache’s representative to the JCP EC in the 2000 to 2002 time frame. At some point Apache discovered the JCP rules didn’t allow independent implementations of JSRs under Apache licenses.
Did I go to Sun demanding anything? No. I firmly believe if it’s your IP, it’s your call.
My statement to Sun in 2002 was in essence: “Hey, we noticed it’s not possible to do independent implementations of Java specs under an Apache License. So, you should probably either change that, or we can’t participate here as an organization. No hard feelings, either way. Let us know.”
Sun had every opportunity to say that’s how they wanted the JCP to operate. They nearly did. But they decided instead to say: “It’s important enough for us to have Apache here and implementing these specs that we’ll change the legalities so you can implement everything that’s produced here. Including umbrella JSRs.”
Great, Apache said! And I went on stage at JavaOne 2002 with Scott McNealy and Rob Gingell to announce this. See http://servlets.com/jason/20020326-javaone-keynote.mp4.
The agreement wasn’t just spoken words; it was codified in the JSPA legal paperwork. It became a binding legal agreement. Apache stayed in the JCP and EC, contributed IP, independently implemented dozens of JSRs, and worked on Harmony — fully expecting an unencumbered TCK to be offered, as required, if the tech could be built.
You say, “They felt entitled to the Java brand just because they are Apache.” I can see how, for someone who doesn’t know the details, you could imagine that. It’s just not the case, and so hopefully now you understand that.
The time to debate whether a contract is fair is before you sign it. Sun signed, Oracle inherited Sun’s legal agreements, and Apache coded.
It’s actually pretty easy to do a document comparison to see the exact issue. Here’s the agreement mandating rules on licensing:
Click to access JSPA2.pdf
Look at the area around, “Other than as set forth above, the Spec Lead agrees not to impose any contractual condition or covenant that would limit or restrict the right of any licensee to create or distribute such Independent Implementations.”
And here’s the actual TCK license offered for Java 7:
http://jcp.org/aboutJava/communityprocess/licenses/STANDaloneTCK7Final.docx
Read especially: “a Licensee product that implements a Java Environment Specification must: (a) have a principal purpose which is substantially different from a stand-alone implementation of that specification, while the value-added portion of the product operates in conjunction with the portion that implements the Java Environment Specification; (b) represent a significant functional and value enhancement over any stand-alone implementation of that specification; and (c) not be marketed as a technology which replaces or substitutes for a stand-alone implementation of that specification.”
So basically, you can implement Java — but not if your goal is to implement Java! Note that you can’t even do it commercially. There’s no pure open source angle here.
Also: “The use of Software in systems and solutions that provide dedicated functionality (other than as mentioned above) or designed for use in embedded or function-specific software applications, for example, but not limited to: Software embedded in or bundled with industrial control systems, wireless mobile telephones, wireless handheld devices, netbooks, kiosks, TV/STB, Blu-ray Disc devices, telematics and network control switching equipment, printers and storage management systems, and other related systems are excluded from this definition.”
So basically, you can implement Java — but not for use somewhere cutting edge. Again, no pure open source angle. You can’t do this commercially either.
Does that match up? Sure doesn’t look like it. Oracle isn’t allowing any independently developed JDKs.
Maybe you’re OK with that. It’s a defensible position. But I think you have to agree, the time to make that call was before 2002.
You mentioned your company investing heavily on Java EE JSRs. What do you think keeps Oracle from changing the TCK license for the next Java EE rev to disallow independent implementations? It just happened to Java SE. Clearly a contract won’t protect you.
Dec 16, 2010 @ 15:22:52
No, you are not prevented from creating an open source Java implementation, you just are not allowed to use it within an embedded environment. Given that Java SE was closed source for more than a decade, I think this was a fair compromise and a step in the right direction for Java SE. I’m sorry you don’t, but, in all honesty I just don’t care….
I’ll reiterate what I’ve said before: Java 7 JSR should not have been held up because of one open source project. A better approach would have been to sue Sun/Oracle over the license/contract you signed instead of holding up the progress of Java for everybody else. For the Java ME licensees, all they had to do was not license Java ME anymore (which they eventually did).
If Oracle changed the Java EE TCK license for us (which we currently pay a butt-load in $$$), we’d be in a tough bind, but so would IBM, and other Java EE licensees. I’m probably not supposed to speculate on something like this, but we’d probably take them to court if what you say came down. I doubt it would happen…
Plus, you and others could always take the stance JBoss took years and years ago when Sun did not allow us (or even return our phone calls) to license Java EE: our lawyer told us we were allowed to implement the Java EE specifications, because it was a public specification, as long as we didn’t declare ourselves a Java EE implementation.
Dec 16, 2010 @ 16:12:39
Actually that means you can’t create an open source implementation Bill. Open Source has a definition http://opensource.org/osd.html, it includes:
”
6. No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
”
That means that an implementation that restricts itself to non-embedded use is not in fact open source by definition.
Dec 16, 2010 @ 16:23:51
If you read the TCK, you’ll see you are not allowed to create a clean-room independent implementation of the JDK under any license. That is, unless Oracle gives you a special waiver, at its discretion. This is a brand new rule.
I think that’s bad, but it’s not awful. What’s awful is the arbitrary switch. Sun and then Oracle got people and organizations contribute IP to define the JDK (versions 5 and 6) under one very clear set of rules, then after getting the benefit of their IP contributions, did not grant the IP back as required (for version 7).
If you just don’t care about this, well, nothing I can do. Maybe some of your readers do. 🙂
It would’ve been nice if Apache had the resources to sue. If they did, Oracle probably might have taken a different tack. I do see the Myriad Group sued Oracle on this issue this week, so maybe the issue will have its day in court.
Meanwhile, you failed to explain to me how JDK 7 was held up by Apache. Apache was just one vote out of 16. Logic dictates the issue was larger than just Apache.
Dec 17, 2010 @ 15:12:07
Jason, I am not a lawyer, so I don’t care so much about the fine print of the “official” definition of open source. I care much more about the long term viability of both the Java language and Java EE. I wrote this blog because, well, the issues, IMO, are not so black and white, and that there are other sides to the story here.
Dec 17, 2010 @ 16:16:55
Wow without even the OSD which is the definition at the start of the open source movement then NOTHING is Open Source Bill. It is the LEAST that everyone (but you) agree on. I in fact don’t even think that OSD is enough (I think the test should be can I actually fix a bug and get the patch in the thing with reasonable review). But wow if “cause we say it is open source” is enough for you then Windows is open source too.
Dec 16, 2010 @ 17:27:59
Nice bit of history rewriting here. It wasn’t just the ASF holding up Java 7, indeed as a solitary EC member they never had the power to do that (only Sun had a veto). It was essentially all of the EC members besides Sun. Yes, including Oracle.
It would certainly be enlightening to ask Oracle why they were prepared to delay Java 7 back then, but changed their minds immediately after closing the acquisition of Sun.
Dec 17, 2010 @ 15:19:20
Why did the GOP refuse to compromise on health care reform and thus, now we have a crappy health care bill? Power, influence, control. Sun was weak, and the wolves smelled blood.
To be fair, there was also (and still is) huge IP issues surrounding Java ME that had vendors like Google and Nokia trying to find a way to circumvent Java ME restrictions. Still, Java 7 should never have been held up because of this.
Dec 21, 2010 @ 17:29:22
Bill, in what mess did you jump with that blog entry… 😉 Bill, you knew you were wrong when you wrote that entry, right? You just wanted to toy around with the Apache crowd, right?
Bill, this is so you, I love you 🙂
deephacks » Long live Java!
Jul 29, 2011 @ 15:50:53