The Apache Conundrum

Way back when Sun promised to submit Java to an independent standards board. However, they changed their mind and decided to instead create their own standards board called "The Java Community Process", only it wasn't a Community and the process was not transparent and at best chaotic. Under the old rules, for various reasons, it was not possible to implement an open source version of the JCP created specifications and certify it as compatible (and thus the right to call it an implementation of that specification). This created a row with Apache which resulted in a letter of intent which when implemented got us to JCP vs 2.5. Sun created a scholarship program which allowed it to "sponsor" (funny money alert) projects it deemed as "non-commercial" open source for free access to the Test Compatibility Kit (also sometimes called the TCK or CTK and in this case the JCK - Java Compatibility Kit). This allowed JonAS (ironically considered non-commercial by sun) to certify for free as well as Apache's Geronimo, but the reduced restrictions also allowed JBoss to buy the TCK.

I couldn't possibly agree more. I hope at the end of this all of the NDA BS goes away.

Apache Geronimo developer, Dain Sundstrom in regards to the problems of the effects of NDAs

However in order to do that Apache members had to follow guidelines including signing NDAs. This restricted what projects that implemented the specifications (including some that were the basis for those specifications like Jetspeed which was broken into Pluto). The communities thus had to fork into those who had access to the information/TCK and those who had to be excluded from that information. The latter group of proletariat also could not participate in the design discussions governing who/what/how the software would be designed so long as it was under the "standard". The NDAs even were interpreted as prohibiting CVS/SVN commit statements like "done to pass TCK test XYZ" and various other seemingly innocuous forms of communication.

To the best of my knowledge, there is no other specification process where the ASF directly participates in collecting NDAs, or in private mailing lists. Should we, in the future, ever be presented with the "opportunity" to do so, I would strongly suggest that we pass on that opportunity.

Sam Ruby to Geir Magnusson, Jr. on the problems of JCP participation and why the policy change is specific to the JCP

Sun chose not to sponsor Harmony, Apache's implementation of the Java Development Kit with a TCK even though it is certainly open source and definitely non-profit (with no "WebSphere CE" even on the table at this point) at least without "Field of Use" restrictions. Field of Use restrictions are things like "not on mobile devices", an area of profit for Sun. These restrictions are in direct violation of the Open Source Definition which prohibits license discrimination on field of endevour (6), specific technologies (10) and from restricting derived works from meeting the OSD (3). Apache also argues that this is a breech of Sun's JSPA contract with Apache. These restrictions lead to another open letter which Sun did not answer.*(1) This leaves Apache in a bad spot. Continue to participate in a process that restricts a "collaborative, consensus based development process" by forking its communities into NDA-haves and have-nots and potentially prevents Apache from licensing its software as something meeting the Open Source Definition or disavow itself of this process and leave its projects in an unblessed state (they can continue to implement the specs as released to the public but not participate in their design) or potentially a third fragmentary response where restrictions are accepted for some projects (particularly those that do not restrict "Field Of Use"). While Harmony is no longer as important as it once was just because there is an open source JDK and only Apache, those who care about the GPL+exception vs BSD-style Apache licensing, and those who enjoy developing VMs are likely to care whether this particular implementation is certified or not. However, it sets a precedent that may affect other open source projects as well. Moreover, Sun is sticking the FOU as a requirement on the TCK at the back end of the thing so that the approval process is not hampered by concerns by other participants.

However, in the absence of an explicit JSPA rule that would forbid such field-of-use restrictions, we will remain worried that a similar issue might resurface anytime, for any JSR.

Red Hat Middleware LLC (most likely Red Hat VP Sacha Labourey) in response to the JCP vote

Sun's decision to not answer the open letter from Apache has resulted in a vote on a proposal by Sam Ruby. If adopted this would restrict new participation by Apache. Members/Committers could still participate in the JCP specifications as individuals or representatives of their employers, but not Apache. This would mean that any liability out of participation would be on that committer/member's own shoulders. It also likely would restrict new projects based on JCP specifications at Apache. This comes at a time when the legitimacy of the JCP and JavaEE in particular are at stake with members like Red Hat, BEA and IBM going outside and collaborating outside the JCP on things that might have been traditionally done inside of it. Meanwhile Sun has been moving full force into open source in other areas, with next generations of their products like OpenDS (their directory server) and Glassfish (their appserver) being developed as open source on Java.net with a great deal of sincerity. Sun has shrewdly been embracing things like JRuby to capture the slow dwindle of the "alpha geek" away from Java. Many saw the choice of the GPL as opposed to Sun's more conservative open source licenses to be further evidence of this wholehearted embrace and movement to a truly committed open source strategy. In this light it might be seen more as a shrewd method of protectionism in the mobile space. Ironically, since you may still license your app as not GPL even if you distribute it with the GPL'd TCK derivative (which is generally what you want to protect), Sun isn't really served well by protecting against Harmony. One has to ask what good these FOU and NDA restrictions are at all. Do vendors really communicate freely with their competitors even UNDER NDA? Do you think a WebSphere developer (really not developer these days more pointy-hair type) is going to say something he doesn't want published to a bunch of Apache types and JBossers even under NDA? So what is the purpose of the NDA and the secret TCK? Does Sun really make enough revenue from it to make it worth this row? Most people who have seen the TCK say it is crap code that barely runs, maybe sunlight would benefit compatibility? Maybe Mr. Ruby is standing at the Brandenburg Gate saying "Mr. Schwartz, tear down this wall!" For my own part I +1'd the proposal.

1. An interesting note is that Sun's own Open JDK is not subject to these "Field of Use" restrictions although it is licensed under the GPLv2 (plus special exceptions to propagating the GPL to linked components) and a special Binary License. This points more to a financial motive than legal. The binary license also means that certain sections of the JDK are not yet open source albeit some parts like the ALSA library are available in open source separately.

Technorati Tags: apache open source sun jcp TCK harmony jboss java