In response to my recent Blog on what Open Source Java advocates want, Keith Lea posted a comment that said:
I think it would work perfectly if Sun released something called something vague like "FreeVM" which is simply the JDK, under a BSD license, but not called Java in any way. Then, if you want to release a version of it, you have to submit it to Sun for testing to be able to call it Java. Otherwise it's called FreeVM or whatever the developers want to name it.
The problem with this is that it fails to address the fundamental problem from Sun's perspective - why would Sun want Java technology based on Sun's implementation (which is known to be compatible) to be distributed in an incompatible way, regardless of what it is called? If the answer is to leverage "innovation" of more developers, that assumes that the innovation is of more value than the compatibility. Sun has already determined that the JCP is the way to manage compatible innovations - agree to the standard specification first, then build reference implementations and test suites that allow multiple, compatible implementations of the standard. Is it really the "specify first, then innovate" approach that open source advocates disagree with?
I think it would work perfectly if Sun released something called something vague like "FreeVM" which is simply the JDK, under a BSD license, but not called Java in any way. Then, if you want to release a version of it, you have to submit it to Sun for testing to be able to call it Java. Otherwise it's called FreeVM or whatever the developers want to name it.
The problem with this is that it fails to address the fundamental problem from Sun's perspective - why would Sun want Java technology based on Sun's implementation (which is known to be compatible) to be distributed in an incompatible way, regardless of what it is called? If the answer is to leverage "innovation" of more developers, that assumes that the innovation is of more value than the compatibility. Sun has already determined that the JCP is the way to manage compatible innovations - agree to the standard specification first, then build reference implementations and test suites that allow multiple, compatible implementations of the standard. Is it really the "specify first, then innovate" approach that open source advocates disagree with?