Java isn't Open Source it is Open Source(TM)

by Tim O'Brien

I remember back to this year's JavaOne, it was A LOT OF FUN to sit in that press briefing room while jon Schwartz and Rich Green (and the UN guy) talked about how Sun is focused squarely on making the world a better place through developing JavaFX(TM), open sourcing the JDK, and providing mobile phones to impovrished third-world nations.

But, there's a problem... Sun Microsystems hasn't really "open-sourced" Java(TM). That's the truth.

You: What? What do you mean? I went to JavaOne and saw that Sun had "open-sourced" Java(TM)?

Me: Well, technically the source code for OpenJDK is covered under the GPL, but you won't find any other open source implementations of Java floating around the internet any time soon... Sun is too concerned about competition and maintaining control over the platform.

Me: Java(TM) is a trademark and you haven't really created a Java(TM) virtual machine until you've passed a compatibility kit from Sun. hmmm....

You: Ok, GREAT NEWS, Sun is licensing the compatibility kit to open source implementations. That fixes everything, now Java is really Open Source.

Me: Er, well, not really. They are making it available for JDK implementations derived from OpenJDK. They weren't really interested in the open source community per se, they were really just interested in bundling Java with Linux distributions. If anything they've actively worked to exclude the most dedicated open-source Java developers in a ploy to retain control of "The Platform". Here read for yourself...

"Implementations must be substantially derived from the OpenJDK source
code and must be distributed under GPL which of course would be a
requirement of any implementation making use of code from the OpenJDK
code commons"


That's what I get from Rich Green's Orwellian game of verbal twister. It's just a shame because while it might satisfy the conditions of the FSF in terms of licensing, it has little to do with the freedom to fork (or reimplement) that makes the open source community a vibrant one.

What is Rich Green and Sun Microsystems so scared of? Competition? Are they fearful that Microsoft, Intel, or IBM might start contributing to a non-GPL distribution of Java and improve upon it? Yes, I leave messages in the URLs, from his blog post, it reads clearly: Rich Green is scared of competition.

UPDATE (9/19/07): Just one day after posting this blog entry, we see Can IBM save OpenOffice.org from itself? over at ComputerWorld. Evidently Sun's other OpenOffice effort is suffering some structural/governance issues.

38 Comments

jeremy
2007-09-18 16:07:17
So if you don't primarily use the base code for linux in your distro, can you still call it linux? I don't see the difference.


It's open sourced, but if you want to call it Java, it's got to be primarily based on the code that is Java.

jeremy
2007-09-18 16:10:12
maybe you were referring to implementing something according to standards, which I can see. so if you pass the compatibility test, it shouldn't matter what code you use. In that sense, I agree with you. Linux and other projects like it don't really have a compatibility test and you implement it as you choose though...


The issue here I suppose is that there have been alternate versions of the vm that use completely different code but adhere to the same standard.

JAlexoid
2007-09-18 17:27:21
But as you know they open sourced VM and JDK NOT Java. Java is still based on Sun and JCP.
Tim O'Brien
2007-09-18 19:17:46
@jeremy, here's the ideal, and this is relevant because it has been done in Java already:


Take a project like Kaffe and a project like Harmony. Both of which were independent implementations of the JVM. Right now Harmony can ship as a Harmony VM, they just can't call it Java. It is the perogative of the entity that holds the trademark to place conditions on its use, but in this case Sun has decided to use this trademark to limit the number of open source options available in the market.


I'm not aware of anyone having reimplemented Linux under a non-GPL license from scratch, if they had, they'd likely have to strike up a conversation with Linus - the holder of the Linux trademark.

Jeff
2007-09-18 19:25:39
If I remember I think I comment before on Timothy M. O'Brien topics and I don't want to sound rude or as a troll but really his opinions and articles really sucks. He lost the Java touch, He actually is a Ruby Folk converted so with this kind of articles just put in bad image Java and all the ecosystem. Why no better Mr. O'Brien stop using Java and go to Ruby ecosystem and be happy if that he really likes. I don't see any value with Ruby is just a scripting language on top of C and just hype that is fading away but if he really likes it go ahead and Stop bashing Java. If he was talking on his articles about exciting and real languages as smalltalk or erlang I will listen more to him but always is the same thing bashing Java and promoting Ruby.
Tim O'Brien
2007-09-18 19:37:22
@Jeff, Thanks Jeff, I'll go use Ruby and stop bashing Java. Sorry for writing something critical of Sun Microsystems, I forgot that they are a wonderful steward of the Java(TM) Platform.


Funny, I didn't even mention Ruby once in this post, but look at that, you've opened up a good door for more discussion. Ruby is an interesting thing to mention in the context of competition between various VMs because in Ruby you have multiple, independent, open-source implementations of the Ruby VM. For exmaple, take a look at this Ruby VM shootout.


Sun has an opportunity to have multiple, independent open-source implementations of the JVM, but they are working overtime to limit choice and maximize control.

Sascha M.
2007-09-18 22:29:27
It has become almost impossible to deal with Sun Microsystems. They are the Microsoft of Java. The JCP is just a ridicolous farce pretending to be democratic. For Sun the GPL is a licence to kill any other implementation. I bet that IBM, Intel and maybe some other companies will create a new managed-code runtime any time soon. Such a beast will be backwards-compatible but not forwards-compatible to Java 7.


In 2000 Microsoft came up with .NET and nobody knew it before. The existence of .NET and the CLR was a secret. Does IBM have a secret too? Does IBM (and Intel) develop a successor for the JVM? Maybe a managed-code runtime heavily tuned for multicores? We haven't heard from Erich Gamma since years. What is he doing? Only the Jazz-project?


IBM would be stupid not to develop a new managed-code runtime. Relying on Sun Microsystems is like playing russian roulette.

Marek
2007-09-19 02:10:10
Sorry for my bad english. Personally I think that GPL is one big mistake and Richard Stallman is just an idiot. If you really want Open Source or Free Software just use a BSD-like license.
Dalibor Topic
2007-09-19 02:51:59
Trademarks like Java(TM) are in general not handled liberally (or at all) in open source licenses. The GPL does not talk about them at all.


The Apache license forbids using ASF's trademarks & project names, other than for reasonable reference purposes. The fact that I can't fork the Apache HTTP Server and call my fork Apache HTTP Server, too, doesn't make the Apache HTTP Server less open source. Neither does the lack of general ability to use Sun's trademarks to label forks of OpenJDK make it less open source than other projects. You can still fork both of them a couple of times a day, if that's what you need, you just have to be a bit creative with naming your forks.


You can't turn around the control of the platform through OpenJDK. It's downstream from the JCP. The platform is controlled by the JCP. The current JCP EC (Sun, IBM, Intel, BEA, Oracle, etc.) is not interested in mandating open source TCKs. Without open source TCKs, you don't really have independently verifiable compatibility claims. Making the vendors who hold the rights to the TCKs figure out how open source TCKs would fit into their business models is something for the next couple of years. I expected that we'll see people on jump on that idea once the bandwagon starts rolling.


We have dozens of independent implementations of VMs under the GNU Classpath umbrella, so the lack of Java(TM) certification has not really had dramatic effects on innovation. Kaffe's got a new release coming out any day now, and Classpath's working on 0.96.


As far as Sun being scared of competition goes, I'd be surprised if that was the case. They haven't been scared of independent implementations before, and I don't see what has changed that would make Sun scared. IBM, Intel & even Microsoft have contributed to independent implementations before, without necessarily making Sun's life harder.

Jeff
2007-09-19 04:16:39
Dear Tim O'Brien, I'm sorry to be rude with you but the problem I see is always you complain about Java in all your articles so I really don't know if you support Java or just as I said bashing it. Nevermind maybe is cool you check the black spots of Java and make it public, And write about it, So from now on I will never bother you again. Just one thing hehe about Ruby, Don't forget Python also have many implementations and Jython just got a new realese and it is cool scripting language too. Thanks.
Tim O'Brien
2007-09-19 06:52:59
@Dalibor, hello again,


I guarantee that if someone came along and reimplemented Apache httpd in COBOL that the foundation wouldn't be averse to letting someone say that said implementation was compatible with Apache httpd. Trademark licensing is always up to the holder of the trademark, and nothing precludes Sun from putting any condition on the use of the trademark. The problem here is that Sun is wielding it's trademark to prevent "compatibility concerns", look a little further, and I think it is clear that Sun is really concerned about a viable open-source implementation becoming certified as compatible. Tell me how many independently certified JVM implementations are floating around? Why hasn't GNU Classpath been able to license the TCK? How about Harmony?



Simon Phipps has been using compatibility as a lever for at least the last year. And it is a false argument, I have no problem with Sun putting conditions on the using the TCK, such as the various claims an independently certified implementation can make. The trouble starts when Sun starts to specifically exclude code that is not derived from OpenJDK.


Sun could very easily do away with the "substantially derived from OpenJDK" requirement, and still assure compatibility. Could someone take a BSD-style implementation, fork it and substantially modify the code? Yes. Could they then call it Java no? I'm no saying the TCK can't have any restrictions, what I'm saying is that the TCK specifically forbids independent implementations.


I would argue that GNU Classpath's inability to obtain a TCK license has adversely affected adoption.

Jess
2007-09-19 07:27:56
The vast majority of the Java community does not want a fork of any sort. Incompatibilities between existing JVM implementations (e.g. IBM's vs. Sun's) are already too painful -- we don't need more of this. Rather we need more ability to help shape and improve what's there -- which is where Sun's efforts this year make a huge difference.
Robert
2007-09-19 08:29:43
"I would argue that GNU Classpath's inability to obtain a TCK license has adversely affected adoption."


I disagree strongly with that statement. The fact is the uber-majority do not want or need an alternate so I don't think it has affected "adoption" at all. Zip, zero, nada.


It was open sources because the GPL fans pushed hard enough and Sun saw the benefit of having a larger community police the code. That sure doesn't mean we want a "fork" or "alternate" version. I see no reason now (nor did I before) for something like Classpath.

Tim O'Brien
2007-09-19 08:40:12
@Robert, Jess,


What planet are you guys from? Or, more specifically, who's Public Relations effort are you working for? Two quotes from both posts: "the uber-majority do not want or need an alternate" and "The vast majority of the Java community does not want a fork of any sort."


First problem here is that, I'm not willing to admit that a majority of the Java community would disagree with the statement: "Java would benefit from competition between multiple, independent implementations of the Java Virtual Machine which must pass an open source implementation of the TCK." I just don't buy it.


What you are saying is that: because the majority of people don't need an independently implemented, open-source alternative, there's no value in changing the TCK license to allow for it. How does that jive with the notions of Freedom that the FSF continuously trumpets.


What's odd about this whole debate is that we're not talking in the abstract. There are already two independent open-source alternatives: GNU Classpath and Harmony. Why can't either one of those implementations license the TCK? What does Sun fear?

Dalibor Topic
2007-09-19 09:22:28
It depends on what one choses to interpret into Green's comments. I'd interpret them as 'Dear IBM, Sun won't give you the TCK under the terms you desire for free. How about we make a deal that makes business sense to Sun?'.


There are 0 independently certified implementations of most JSRs, open source or not, because JCP's TCK licenses in general don't allow third parties to certify implementations. That's true of JVMs as much as it's true of XML parsers.


GNU Classpath has not bothered trying to get a TCK license because there is no JSR for the class library alone, so you can't certify it even if someone wanted to. You could only certify GNU Classpath in conjunction with a runtime, like Kaffe, gcj, etc.


I've gone through the application for Kaffe a while ago, but it turned out that the TCK license I saw had NDA clauses, and I can't possibly expect everyone from Classpath, Tritonus, and a half dozen of other projects whose code we depend on in Kaffe to sign some random NDA, in order to be able to collaboratively debug TCK failures, which we'd surely have had heaps of back then.


Contrary to ASF's current strategy, though, I decided to work around the issue (and that involved helping seed Harmony), rather than to escalate the conflict. I've laid out the reasoning for that strategy choice when Davanum discussed ASF's problems with Sun on the classpath mailing list.


Technically, Harmony is able to license the TCK, according to Green, but it is not able to do so under terms that are acceptable to the ASF. There are many things the ASF could do about that, and they've been all discussed on jcp-open extensively.


I agree that Sun could improve the current TCK license for OpenJDK further, but that's something that'll have most effect when it comes from people working with the TCK, rather than from me. OpenJDK didn't really get a workable TCK license for distributors because of something I said or did, it got it because Sun met with distributors, listened to what they wanted, and tried to figure out how to give it them. The OpenJDK project has the advantage that it's now in Sun's interest to be nice to downstream distributors.


Technically, the OpenJDK TCK license does not forbid independent implementations. It's just largely OpenJDK-specific, one TCK licenses among many for J2SE. You can go and buy your own license to Sun's test suites if you fork Kaffe, or Harmony, for example, if that's what you need. Or, if you think that reading compatibility tests is exciting, you can get the TCK under the 'read only' license from Sun.


Practically speaking, OpenJDK adds choices, it doesn't take choices away that have been there before. If you can live with the GPL, you get Sun's implementation for free, and can certify your port / distribution / build, if that's what you need. If you can't live with the GPL, you can buy Sun's code under different terms, or write your own and buy the TCK under different terms, or write your own and do the scholarship thing, or write your own, and simply wait until the TCK is open source because you've made the JCP mandate open source TCKs for all JSRs after a palace revolt (my favorite plan :), or write your own, and don't care about certifying because your users don't care.


And I think that for a lot of runtimes, it boils down to the users not caring whether they are certified or not, if they have found their niche. Granted, Sun's OpenJDK project will most likely occupy the most prestigious niche of being the default Linux runtime for Java for most popular platforms, but there are other niches for smaller projects.

Vance Dubberly
2007-09-19 09:37:56
Actually I imagine they don't want the API to go south. I've worked with alot of languages and I've got to say that Java is the most consistant well thought out of any of them. Alot of time has been put into engineering. One of the dangers of opensource is that, well, design becomes democratized and when that happens quality takes a dive! Always and with out fail.


What Sun has done is what the maintainer of most OS projects do, they maintain the right to control the direction of the project. You are free to take the source of Java add to and detract from the JDK, but then you don't get to call it Java. This is a good thing. At this point Java is the crest of what a programming language should be... give control to the masses and it'll be as slow and unstable as all the opens source languages. No thank you.


The plus side of it being open sourced is that the script kiddies and lesser beings can look at it's design and learn something. Much as they will and have done with open solaris.

Tim O'Brien
2007-09-19 09:43:20
@dalibor: simply wait until the TCK is open source because you've made the JCP mandate open source TCKs for all JSRs after a palace revolt (my favorite plan :)


+1


@dalibor: "And I think that for a lot of runtimes, it boils down to the users not caring whether they are certified or not, if they have found their niche. Granted, Sun's OpenJDK project will most likely occupy the most prestigious niche of being the default Linux runtime for Java for most popular platforms, but there are other niches for smaller projects."


Agreed, the SUN JVM will likely always occupy that "prestigious niche". I do think that being able to certify against an open standard would only encourage innovation and diversity of approach across VM implementations.


@dailbor: "OpenJDK didn't really get a workable TCK license for distributors because of something I said or did"


Stop selling yourself short Dalibor, we all know you have a direct line to Simon Phipps emergency open source hotline.

Tim O'Brien
2007-09-19 09:53:48
@Vance, please?!? Where in my post did I advocate for "democratizing design"? The Harmony project operates within a meritocracy (hardly a democratic system). Kaffe and gcj projects maintain fairly strict control over the design decisions that go into the implementation of those respective VMs.


Vance, you also miss the fact that Java SE is a JCP standard, an organization that was created for the sole purpose of helping different organizations agree upon and implement common standards.


What I'm hearing from you is: Freedom is messy, there could potentially be a bad implementation of the Java VM. Instead of giving people the freedom to test an independent, open-source implementation of the VM, let's make it impossible because you only trust Sun to create a VM.


I certainly hope that they do a better job with Java then they are doing with OpenOffice.


Anyone have any more, anti-freedom FUD to throw?

Simon Phipps
2007-09-19 11:12:15
Hi Tim. I can see you're feeling passionate about this but I'm afraid your passion is pushing your rhetoric a bit too far.


If you want to fork OpenJDK, go right ahead. Knock yourself out. It's under the the same GPL everyone uses, and you have free use of the TCK. Combine it with Classpath. Make it run with Kaffe. Build a community where people with sun.com e-mails are excluded. OpenJDK is open source, under the GPL, and all your freedoms to use it are available - indeed, the IcedTea folks are going ahead and doing so. There is no sense - apart from your sense of outrage that Sun and Apache continue to be in dispute - in which OpenJDK is not open source.


By the way, if you want to use Dalibor's private hotline (most people call it "conversation") just drop me a line.

Rich Sands
2007-09-19 11:53:13
Tim,


If you pass the TCK, either using the new OpenJDK-targeted license, or under Sun's standard Java SE TCK license (scholarship or no), you can call your implementation "Java Compatible". If you're not compliant of course, you can't call it Java Compatible - but thats what the TCK is about, isn't it?

Tim O'Brien
2007-09-19 11:57:42
@Simon Phipps, (thanks for the beer at JavaOne, BTW)


Two things in your response: OpenJDK is open source (hey, thanks for that), there is a right to fork.


The central dispute is not forks of OpenJDK, we're discussing independent, open-source implementations of JCP specifications independent of TCK license terms. Why create an open standards group to encourage open communication and collaboration and then use arcane TCK legalities to preclude independent, open-source implementations.


(You've mentioned Apache here, but these issues also apply to independent implementations such as Kaffe or gcj which are not "substantially derived" from OpenJDK. The TCK license broadened the dispute a bit. :-) )

Tim O'Brien
2007-09-19 12:13:39
@Rich Sands, name one independent, open-source implementation that has passed the TCK? Kaffe? Harmony? GCJ?


Field-of-use restrictions, specific example from the TCK license would be that an independent, cleanroom implementation of the JVM couldn't be used in a kiosk or an X-ray machine at an airport. That may seem arbitrary to you, but putting restrictions on open source is contrary to the spirit of open-source.


@Simon Phipps, what's wrong with passion? I thought Sun was trying to harness the "passion" of open source. :-)

Simon Phipps
2007-09-19 13:29:19
But none of {Kaffe, Classpath, GCJ} are complete implementations of the Java specs, so none of them is eligible to take the TCK. There's some great speculation going on here about who has had what withheld, but the fact is that the fastest way for the above codebases to become part of a compatible Java implementation is to combine with OpenJDK. And, indeed, that is what the smart guys who wrote them are doing.


Let's face it, your issues are based on Harmony and the data you are using is from one side of the dispute.

Dalibor Topic
2007-09-19 13:30:40
If all that changing the JCP for the better would take was persuading Sun, it'd be a walk in the park, figuratively speaking. ;)


Unfortunately, it's not that easy. Among many other nice and adorable things, JCP also functions by design as a place where proprietary software vendors can get together to do things proprietary software vendors want/need to do, like collaborative R&D behind closed doors, or staking little claims of IP in standards for (cross-)licensing, etc.. Quite a few people and large companies have profited from that system, learned to live with or off it, and, accordingly, have little desire to turn it on its head.


In other words, JCP is a bit like a regulated market, with all the good sides and bad sides of it. It can't be re-regulated without significant buy in from many agents, and that's currently not there: the business models pursued by most proprietary software vendors on the JCP don't include open source TCKs. As long as there is no business case for them, they aren't going to happen. Your mission, if you chose to accept it, is to create a social environment in which open source TCKs are the right strategy to pursue for many agents in that market.


If all that took was for me to e-mail Simon (or Geir, Sacha, Flavio, etc.) we'd be done tonight. But as you can imagine ... it's a lot more work than that. ;)

Tim O'Brien
2007-09-19 14:12:32
@Simon: "But none of {Kaffe, Classpath, GCJ} are complete implementations of the Java specs, so none of them is eligible to take the TCK."


Strange, earlier in this comment thread Dalibor wrote this: "I've gone through the application for Kaffe a while ago"


I don't think Dalibor would've gone through the process if he hadn't had some idea that he wanted to attain compatibility. It does seem a bit disingenous to say that Kaffe isn't complete enough to be considered TCK-worthy when the TCK is the sole measure of this completeness. "X isn't ready for the completeness test because it isn't yet complete."


The only real path for anyone interested in creating an open-source implementation of Java is to assimilate with OpenJDK or fork OpenJDK. No alternatives. That's fine, it just isn't in line with the spirit of open collaboration and competition.


If you want to keep on lumping me in with the ASF crowd, go ahead. I've only loosely followed Harmony, and I don't plan on running it. I'm concerned about the larger issue, Sun *using* open source as a marketing tool, Sun encouraging participation in an open standards group but changing the rules after the fact.

Dalibor Topic
2007-09-19 16:06:40
No independent implementation is currently a complete implementation of J2SE 1.6 or 1.5. All of them lack parts of the necessary APIs, as you can see on the japitools site, which is a necessary requirement for binary compatibility, never mind actual compliance with the specifications, which is another interesting story altogether.


Back when I applied for the TCK scholarship in 2004, we were chasing 1.5, which had just come out, and I was hoping we'd be able to finish that work within 18-24 months, provided that GNU Classpath kept growing its contributor pool at the pace it was progressing, and that we were able to get some additional volunteers on Kaffe from interested parties.


There was a window of opportunity 2004/2005 for an alternative, independent implementation, due to on one hand the first signs of the demand for open source JVMs among distributions, and on the other hand governmental regulations in some markets increasingly favouring open source technologies, which meant that there was a need for an open source implementation that would qualify as Java in order to allow vendors to bid for open-source-only contracts. No vendor wanted to give away their crown jewels back then, so there was an opportunity for an upstart to come and pick up some interest.


That window of opportunity closed with IBM's decision in 2005 to not use Harmony as a way of sharing effort with GNU Classpath, and instead going for the rewrite from scratch, positioning it as an alternative, rather than complementary project. That made sure that neither Harmony nor GNU Classpath based runtimes would be done implementing 1.5 APIs before 1.6 came out, making them pointless from the certification POV, as you can in general only certify against the latest and greatest release, afaik, and there was no way either project would be done implementing what they had to do for 1.5 in a year.


To give you a tiny example, neither project managed to write its own pack200 implementation over the past 2.5 years, which is a very useful 1.5 deployment feature, and part of the standard 1.5 java.util.jar API. Neither project will have an independent pack200 implementation any time soon, afaict, and you can't really certify 1.5 compatibility without it, never mind 1.6.


Otoh, the failure to deliver a fully compatible alternative from Harmony & Classpath also enabled Sun to ride in and offer distributors an easy and welcome way out of the dilemma they were in, with demand for open source Java on their hands, and no one around to satisfy it. So it didn't turn out all that bad in the end.


I don't think it makes sense to blame Sun for the lack of viability of alternative implementations. Even if they had handed out the TCK to everyone who asked for it freely at last Java One, that wouldn't get all the missing code written, and create the avalanche of contributors necessary to finish that work. There is no lack of programs exposing bugs in Kaffe, or Harmony, for example, even without access to the TCK, but there is a distinct lack of people willing to spend their time fixing them.


A triumph for rational ignorance, if you are into that area of research. ;)

J.T. Wenting
2007-09-20 01:27:54
Just more Java bashing... If Sun were to hand over the language spec and trademark to the Linux sharks they'd flush a highly successful language and platform down the toilet. It would end up more fractured than C++, bytecode level compatibility as well as sourcelevel compatibility would be lost.
I for one don't want to have to maintain a hundred (let alone a thousand) different versions of my code (and binaries), one for each "Java" that customers may have installed.
Tim O'Brien
2007-09-20 08:49:30
@J.T.Wenting (more comments from people who didn't read the post or the comments)...


I'm all for compatibility, the issue here isn't "let's open up Java to the barbarian horde of open source". A independent, open-source implementation will still need to pass the TCK....the issue here is that Sun is using the TCK license as a lever to prohibit independent, open-source implementations of a JCP spec.


If they are going to encourage people to participate in the JCP and trumpet openness, and then turn around and play games like this, why shouldn't we point that out?

Josh
2007-09-21 21:03:12
Your continuous anti-Sun vitriol is getting old Tim.
Tim O'Brien
2007-09-22 08:15:11
@Josh, so holding Sun accountable, and making sure that they don't use licensing to silence innovation is "anti-Sun vitriol"?


Josh, sorry that fighting for an open source ideal is tiresome for you.

rong
2007-09-25 06:49:34
learning....
J.T. Wenting
2007-09-25 07:00:12
I've read your rant and the comments and they all point to the same thing: someone who wants Java destroyed, either through mallice or through negligence of the actions he claims are required (throwing the language spec to the lions, which is what doing what you propose to the TCK amounts to).
If every hacker can change the TCK to do what he wants there's no more TCK. Passing the TCK will become a game of changing the TCK (and thus the language spec) to let your "implementation" pass.
That's of course exactly what GNU wants, as they're not interested in Java at all except as something that "needs to go" because it's in competition with their favourite languages (Perl and C).
Tim O'Brien
2007-09-25 07:07:18
@J.T.Wenting (again wildly off-base),


Did you read the post, and any of the responses? The issue isn't me wanting the TCK to be "open", I just want Sun to license the TCK without Field of Use restrictions. I'm all for standards and a compatibility test kit.


Also, what are talking about with GNU? and someone's favorite programming language being Perl or C? When challenged, you stray further from the discussion.

Dick
2007-09-27 20:55:44
Let me tell you that I think Sun is very smart to keep control of this great platform.


The only problem I see with this, is that Java is evolving too fast. I can't keep up with all the new development. i'm just learning Java 5 and Java 7 is around the corner.


Please Sun stop Java a little bit. Do as linux does. Develop one Linux for testing purposes (the odd release) and then select the features that really worked and integrate them in the real release (the pair release).

Tim O'Brien
2007-09-28 05:42:24
@Dick, I just wouldn't agree that Java benefit from having one (over-bearing) steward. i also don't think that Java moved fast enough during the period of 2002-2005. It has improved substantially, but there were many years when Java suffered.


(Positive points to Sun: Java has been reemphasized under the leadership of Schwartz)


Again, Sun can still set standards, but using a TCK licensing to prevent independent, open-source implementations of the JDK is not in the best interest of the community.

pep
2007-09-30 05:37:36
I believe Dalibor had an honest answer in his September 19, 2007 01:30 PM comment. Basically he said "Tim, you're right, but this is business, unless we see profit we won't do it". Well, to help in that matter i'm going to tell of my personal view: here in Argentina, one of the best weapons you may have for seeking a job is "Experience on Java Programming". A lot of jobs offers are based on that. Still, knowing that, i'm not into Java, and i'm not keen to it because of this matter. Before, it was "Java is not free software", now it is, but Sun it's still not giving enough freedom . I do care about it, and i believe there would be a lot of people in the same position. Because of this rather silly detail guys like me would look other way, even may be CLR (although i think that's a trap). And maybe we are not a big share of the market today, but Free Software is taking adepts everyday. So you will be losing that market share. If all the problem is the risk of losing your nichè, thats a silly thought. Open TCK for only (but every) free open source software. Your VM will always be the first choice and if any of the others happends to be better you'll have enough time to copy their advantages (that's free software, isn't it?).
daniel.baktiar
2007-10-02 00:40:48
what's de problem man?
looking for popularity eh..
have u ever look that even GNU and FSF are trademarks?
Tim O'Brien
2007-10-02 05:18:17
@daniel,


Read the post, the issue is Sun's use of FOU restrictions on the TCK license to make it impossible for independent open source implementations.


The larger, emerging issue is that the OpenJDK project itself is starting to create the same closed-door TCK groups that people like Dalibor had previously said were unacceptable for projects like Kaffe.


Members of the FSF have started to lament the closed nature of the OpenJDK project.