While I have to be somewhat circumspect in my commentary on the matter, given the fact that I’ve had private conversations with folks on both ends of this issue, I’d be neglecting my responsibilities if I let Geir’s open letter (and FAQ, helpfully) pass without comment. For the sake of balance, Sun’s initial response can be found here.
The basic facts of the matter are not, as far as I’m aware, in dispute. It’s my impression, as an example, that both sides would confirm the timeline beginning back in August of last year. That the license contains “field of use” restrictions is indisputable.
What’s at the heart of the matter, then, are the implications of said restrictions. When the clause was first described to me, my initial impression was that it seemed fairly innocuous. As is often the case, however, the legal vernacular was obfuscating more profound and problematic implications. While I have not consulted legal counsel on the subject, in my opinion Apache’s read is accurate. This is from their FAQ:
A “field of use” restriction is a restriction that limits how a user can use a given piece of software, either directly or indirectly. To give a concrete example from the Sun / Apache dispute, if Apache accepted Sun’s terms, then users of a standard, tested build of Apache Harmony for Linux on a standard general purpose x86-based computer (for example, a Dell desktop) would be prevented from freely using that software and that hardware in any application where the computer was placed in an enclosed cabinet, like an information kiosk at a shopping mall, or an X-ray machine at an airport.
Quickly, it’s apparent that a seemingly harmless legal turn of phrase has profound implications for the viability of the Harmony project. Imagine the conversation Harmony would have to have with potential adopters: “Yeah, Harmony’s really great…yes indeed, we can indeed call it Java because we’ve passed the JCK, and it’s a great platform for…wait, you want to deploy to a kiosk? Sorry, can’t help you.”
Suboptimal, I think everyone can agree. The questions now are whether this was the appropriate strategy for Apache, and how Sun will proceed. As to the first, many of you may know that we at RedMonk are not big fans of the “open letter” approach. Some of the folks reading this, in fact, have probably been on the receiving end of criticism from us for just these types of missives. And while Geir undoubtedly expressed great restraint in composing this letter, it is not the letter that I personally would have composed. All of that said, however, I support Apache’s position here: I think they exhausted all of the options for appeal available to them, and did not take this step lightly or carelessly, understanding the potential impact. In short, I think this was perhaps the last avenue available to the Apache organization, and as such I cannot fault them for taking it.
As for the second question, and what Sun’s approach will be, I honestly cannot say. I’m sure one of the arguments that will be made is that the issue is a resourcing question: that the bodies necessary to effect a change in the license are currently committed elsewhere, on higher priority GPL efforts. To his credit, Matt asks for patience, saying that Sun “means well here and generally does well.” While I’ve been outspoken in the past in my defense of Sun and its motives, in this particular instance I have to side with Apache. It’s my belief that Sun has had the time necessary to address this situation, and that their lack of progress essentially forced Apache’s hand. Moreover, I think part of the problem stems from what I’d argue are unnecessary concerns on the part of Sun; much like I believe Microsoft should actively embrace and encourage Mono or a stronger overall ecosystem, I think Sun and Java would both benefit from a strong Harmony.
While I side with Apache in this particular debate, however, I think some of the commentary that I’ve read pillorying Sun is misguided. Think tree vs forest. Having had the opportunity to work with a variety of organizations on projects to open source previously closed source code, I can confirm that the process is often non-linear and always painful. This incident is unfortunate, and is as much a part of Sun’s open source personality as OpenSolaris, OpenSSO and so on, but for all of that it’s just one incident. Much as I’d like to be judged on my body of work rather than a single post, I’ll judge Sun’s openness – or lack thereof – on their history rather than a historical incident.
In any event, the ball is in Sun’s court now and like many, I’m interested to see how they respond. I sincerely hope as well that this does not negatively impact the upcoming JavaOne conference; the thought of having the “Sun is/is not open” conversation a few dozen times doesn’t really appeal. But maybe it’s just me.
Credits: I’d like to personally thank Geir as well as mjw, Dalibor, Michael, Donnie and everyone else participating in discussions on the subject in #redmonk today. It was of great benefit in helping to solidify some of my opinions on the subject, although I’ve covered a small fraction only of what was discussed.
Disclaimer: Sun is a RedMonk customer, as are a variety of other Apache member organization. Additionally, we have multiple non-financial relationships with Apache individuals that span a variety of Apache projects.
