Why would you have a license for a standard specification based software like Java where you would allow ANY version which does not pass the specification validation suite to be distributed? !!

It seems to me you could make the source available under a license that says, "Make what ever changes you want. And, you may distribute your work under this license freely, but only if it fully complies with the specification and passes the validation suite."

I'm a big Java fan and love the "Write Once Run Anywhere" mantra. As a developer, I'd rather maintain a single codebase and allow my customers to choose their runtime platform based on the merits of the respective hardware platform.

From an open source perspective I can appreciate what Sun is trying to accomplish by preventing forking of the code. You can say it isn't likely to happen, but Microsoft inherently "forked" the code in their MSJVM implementation.

I think that the open source community could vastly help improve some aspects of the Java platform - look at how the JDK has benefitted from the inclusion/use of the Apache XML parsers. As another example, the 1.4 release of the Mac JVM supported sharing resources across virtual machines thereby reducing memory footprint and startup times. That type of functionality is soon to be made available to the rest of the Java community in the J2SE 5.0 release.

Above all, I want full support of the Java specifications that are produced by the JCP. Anything that doesn't meet this can't use the Java brand. JVM compatibility is extremely important to me as a developer of Java products.

If Sun's legal team sees the OSD as a challenge to write the most ambiguous license that still meets the OSD criteria but subverts the right to fork, that's still going to go down in flames, and leave Sun with another PR debacle. If you read the discussion, you can notice how people are getting increasingly annoyed about speculative attempts to wiesel around the OSD in order to tie in significant restrictions that are contrary to the spirit of open source.

If Sun really wants to open source their Java(TM) implementation, they could talk with the ASF, FSF and the Eclipse foundation on how to do it right, and *then* submit a license that has a fighting chance of meeting *both* the requirements and goodwill of the respective communities.

cheers,
dalibor topic

It is interesting how every discussion about the future of Java boils down to "how can we prevent Microsoft from just killing it". There just does not seem to be any other problem that could not be solved in more that one way. Sun cannot take Java into open source only because of the Microsoft threat. There is no other power on Earth that could, in practice, hijack Java. It seems that market forces, government and courts are just unable to deal check such a concentration of wealth and monopoly power.

Maybe, it is time to recognize that some categories of software are so vital that they in fact represent infrastructure that needs to be regulated by independent bodies, users or maybe even government. The format of office productivity suites springs to mind. We should have some rights regarding the documents we create. At the moment these are Microsoft Intelectual Property (according to Balmer). Maybe Java, as a cross-platorm should also be regulated in such a way. There are many arguments against this (stifling inovation) but there does not seem to be any other option that $40bn will not neutralize.

Gartner Group has just called Windows a perpetual beta test. Are we willing to live with such infrastructure? It seems that this is acceptable only in the software business and no other infrastructure (telephony, post, air transport, traffic) - everywhere else, we have standards that prevent companies from "innovating" to their heart's desire.

We just do not seem to be aware that MS Office and J2EE are vital infrastructures of the modern economy.

Can open source and closed standards work together?

Yes, anything can work if you make it work, and Sun is a hard-working company. The other questions is: Do we want it to work?

Why not. Sun has to maintain some kind of reign on the technology if they are to control it properly to compete against (for example) Microsoft and .Net.

Kudos to them ... they're trying their best to serve the best of both worlds: their own, and the Open Source community. Maybe it doesn't look like it's giving as much control to some developers as they want, but it's better than nothing. And the two sets of interests do compete ... so - again - kudos to Sun for even trying this. At least they're trying something new and innovative instead of saying it cannot be done.

Open source can work with closed standards under 1 caveat: the open-source programmers may need to rename a variant on the closed standards.
The situation is analogous to building a chip that runs an instruction set architecture (ISA) owned by a competitor. The ISA is a closed standard in the sense that the company owning the ISA has trademarked its name. For example, MIPS technology trademarked the name "MIPS". A competitor, Lexra, then implemented a subset of the MIPS ISA, omitting 2 instructions. Lexra said that its chip is MIPS ISA compatible. MIPS sued and won. If Lexra had, instead, labeled its chip "MIPS ISA flavored", not "MIPS ISA compatible", then there would be no legal problems.

Another good analogy is Microsoft incorporating the Java runtime environment in its browser. The environment was not fully compatible with Sun's closed-standard for the Java runtime environment. Sun sued and won. If Microsoft had claimed that the browser was equipped with a "Java flavored runtime environment" or "JavaPlus[tm] runtime environment" (and trademarked "JavaPlus"), then there would be no legal problems.

I do not see a problem here.

Open source is now a credible movement. The open-source development lab (OSDL) and the free software foundation (FSF) have sufficient clout that if any team of talented programmers created a language called "JavaPlus", derived from and mostly (but not entirely) compatible with the closed-standard Java, there is the strong likelihood that JavaPlus would come to dominate the market for Java. Then, Sun would need to kiss OSDL's or FSF's ass. Sun would be forced to alter the Java standard to make it compatible with JavaPlus.

"Can open source and closed standards work together?

No they can't really, and even if it were possible why wouldn't people just use Eclipse?

"Under such a scheme Sun could maintain control of the Java API but allow open implementations."

Sun never learns. When they got into fight over Java with Mircrosoft the result was MS making .NET. When will Sun decide to open Java up when Java becomes as much as an underdog/hasbeen as Solaris.

No one cares anymore Sun, the community is just routing around you and soon you will be insignificant.

Sun should just take a lesson from the Python Software Foundation. Although I don't like how Python's current implementation basically acts as a de facto standard (there should be a real standard rather than just a reference implentation that doesn't really reference anything), Python's implementation and "standard" are both open. Anyone can take Python and fork it in incompatible directions. Just take a look at all the posts in comp.lang.python regarding Python-derived languages.

How has this affected Python? Not a bit. If anything, it's encouraged innovation through the Stackless and IronPython projects.

I think what Sun is really worried about is trademark dilution. If that is the case, why not just specifiy that any derivative works must be named something other than Java? The only practical effect this would have is to make the licence GPL incompatible, since most people will rename a fork anyway. However, it does preserve Sun's trademark.

Sun could still certify implementations as Java compatible, giving them the right to use the phrase, too. If there were a reasonable fee involved for certification, then Sun wins another revenue stream. It's a win-win.

A few things about this article. First, I think there is an important difference between problems like open-source software that implements TIFF or PDF in some way (both specifications being held as proprietary).

Secondly, it is probably not appropriate to refer to a "closed standard" because it doesn't mean the same as "closed source." I don't have a better term.

Third, which I think is the case here, has to do with specifications that embody interoperability agreements. How does one ensure that someone doesn't fork the interoperability and hi-jack it in favor of the direction taken by a given implementation variant. Obvious examples in the past have to do with Netscape/Microsoft competition over HTML and browser-extension mechanisms, and current prospects for similar variations.

When we took ODMA and DMA to open-source (http://DMware.info/), there was some concern about disruption by forking of the middleware functionality, interfaces, and integration model. The worry for DMA was baseless (it has not been implemented in an interoperable way anywhere) and the concern for ODMA remains since its middleware is in use and people do have access to the middleware source code.

However, the open-source license that you describe doesn't qualify under the freedom to use in any domain and application, it seems to me. The solution that I have looked at is the non-confusion principle. That is, you can't offer a derivative work as a version of the covered work unless you pass whatever the test is. It is a labeling and identification matter. You can't promote the fork or deviation as satisfying the specification and you can't name it in a way that would confuse or deceive adopters of it. That's clear enough but the gray areas create problems. I think one doesn't deal with those unless they come up. We usually worry too much about forking in the absence of an infraction.

I remember being concerned with how "extensions" and "improvements" that do not preserve legacy compatibility are handled. Also, is the improvement one that can be removed if it is necessary to revert to something that is consistent with a reference implementation? Those are the cases that I wonder about: playing nice and always preserving the user opportunity to make substitutions and to cross backward to something that conforms to the specification is what matters to me. But the best restriction, I think, is that a specification-deviating derivative work must not be identified in any way which confuses it with a bona fide implementation. And the source code remains open-source software.

Finally, there is no way to prevent an independent implementation that is equivalent to forking, since copyright simply doesn't handle that. Consequently, strong compliance with the specification can't be handled solely by a copyright license. It takes something else. I haven't looked at trademark requirements, but the organization that supports the specification might want to look at that. Tying to the open-source license with a non-confusion clause strikes me as an useful light-weight provision that might get enough of the job done, without worrying about the seriously adversarial provisions where the lack of goodwill undermines any license you can think of.