Open Source And Closed Standards? 219
jaaron writes "Can open source and closed standards work together? That's the question asked by Kevin Bedell in his O'Reilly weblog article. The issue springs from questions on an OSI mailing list, hinting that Sun Microsystems is looking for an open source license that would require derivatives to maintain test suite compatibility. Under such a scheme Sun could maintain control of the Java API but allow open implementations."
Maybe a bit off topic (Score:5, Interesting)
But after reading the article, the one thing that sticks out to me is "What if the test suite is flawed, or has a bunch of bugs in it?" So then the test suite that has gone out to everyone unmodified, and then it circulates a few hundred times before people find the bug...then you have tons of stuff designed to work with a flawed test suite and when the test suite is fixed, there is the potential that previously working code (tested with the suite) will be broken! Maybe I am just a pessimist....
Why even bother open sourcing Java then? (Score:5, Interesting)
So you're telling me... (Score:2, Interesting)
Just go with the GPL so you can legally steal whatever code you need back.
Sun will Wither Away (Score:2, Interesting)
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
No one cares anymore Sun, the community is just routing around you and soon you will be insignificant.
Re:Maybe a bit off topic (Score:5, Interesting)
"What if the test suite is flawed, or has a bunch of bugs in it?" [Emphasis added]
What if many test suites are flawed and have a bunch of bugs, all different?
Re:Maybe a bit off topic (Score:4, Interesting)
I think that you can take it as a given that there already is a Java API test suite, it just never makes it outside of Sun. Regression testing is a basic step in serious engineering these days, hardware or software. You would have an almost impossible task to convince me that Sun doesn't have one for such an important piece of technology as Java.
Getting a new form of licensing would just let Sun take Java in new directions.
But yes (Score:5, Interesting)
But what Sun is after is different. They want an open source license that only permits those modifications which preserve compatibility with Sun's specifications.
Sun is suffering from a classic misinterpretation of what on open source license is. They're thinking if they can just get the right secret handshake, they can gain entry to the club.
The real secret is, there is no secret handshake. While it certainly helps if a license is phrased in such a way that it appears to match the Open Source Definition, the only real test of a license is whether it lets people do what they need/want to do.
Sun's problem is that they know that people want to produce non-conformant implementations. They feel they have to stop them doing that. This goal is, by its very nature, incompatible with an open source license. No amount of clever wording is going to change that.
free work, no loss of control... (Score:4, Interesting)
Re:Why even bother open sourcing Java then? (Score:5, Interesting)
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.
Why is this so difficult for Sun to see?
Re:Bah (Score:2, Interesting)
Its called a trademark silly (Score:4, Interesting)
Re:But yes (Score:1, Interesting)
It's the techies that want an open source Java so they can muck it up. I'm sorry to tell you, but Sun is doing the right thing here.
great (Score:5, Interesting)
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.
Re:Open source + Closed standard = Closed (Score:5, Interesting)
The real issue is how much is left unspecified by the standard and available for innovation. Good standards will contain well-defined areas of uncertainty, where the behavior is entirely up to the implementation to specify, with good ideas coming to be required parts of later standards.
In the case of java, any option starting with -X to either java or javac is non-standard. So you just have to make your exciting new features depend on a -X flag and you'll pass the test suite (which, by definition, won't use any non-standard options).
Comparing (Score:5, Interesting)
Java is a proprietary but relatively open standard whose specification is open and available to everyone, and whose specification is guided by a number of third parties [jcp.org], but which no one may be certified as being an implementation of unless they are 100% complaint with the specifications.
I think it's reasonable Sun wants to ensure all Java implementations are cross-compatible, especially considering that the last time Java had a chance at making headway on the desktop, one of the biggest reasons it failed was the variety in incompatible AWT implementations.
Something I don't find reasonable about the current situation is that the nature of the certification process is such that it virtually ensures any Java implementation not backed by a large moneyed entity is not going to be able to make it to certification. Open source implementations of Java exist but it is unlikely anyone is going to be paying to get them through the certification process.. well, ever.
It seems to me like Sun is at least now taking a serious step toward improving this situation.
Sun's problem is that they know that people want to produce non-conformant implementations. They feel they have to stop them doing that. This goal is, by its very nature, incompatible with an open source license. No amount of clever wording is going to change that.
Perhaps this is exactly why Sun has been so reluctant to even approach open source licenses with Java up until now?
The lawsuit in question (Score:4, Interesting)
As for J++, it still exists and is one of the languages capable of targetting the CLR.
They need to split up J2SE (Score:5, Interesting)
Frankly I don't see why anything with javax as the root of its package shouldn't just be open-sourced under the same conditions as OpenOffice. Javax denotes that it's a "java extension" which means it's not part of the core language and runtime. Sun should just push half the work there onto community processes and developers and maintain the core language and runtime.
If I were at Sun, I would consider IKVM to be my company's potential trojan horse onto the
Dear Sun, ...! (Score:3, Interesting)
That's all fine for Sun to remain in control of Java. However, what developers should push is that Java be standardized by ISO. FORTRAN is not owned by IBM, PROLOG is not owned by the universities of Marseille/Edinburgh etc. The reason is that software companies need to protect their investment, which they can do much better if the standard is in the hands of an independent multinational organisation dedicated to standardization, and with a transparent membership policy: ISO. Otherwise, what if Sun suddenly decides to do strange things (change APIs, change the licenses) or simply ceases to exist...?
Dear Sun: Please free Java!
--
Try Nuggets [mynuggets.net], the mobile search engine. We answer your questions via SMS, across the UK.
Currently use Trademarks and GPL... (Score:5, Interesting)
Java is trademarked. It would be easy for Sun to say that nothing could be called "Java", or "Java compliant" unless it conforms to their standards.
Also - Sun can release the code under dual license. The GPL - where the code can only be included in other projects that were also GPL, and the JSL (Java Standard license) or whatever, which is in control of Sun and is only issued to code that conforms to Sun's Java Standard.
Although under the above it is possible to fork the standard, it could not be done in a commercial or proprietary product (unless it is released under the GPL - blocking MS and others from doing what they want), and it could not be called "Java". Therefore, the above I think would satisfy all requirements.
there is a precedent for this (Score:5, Interesting)
The DoD retained the trademark for Ada, and you have to pass the test suite to call your implementation Ada. The GNU Ada Translator (GNAT) passes just fine.
Re:Sun will Wither Away (Score:2, Interesting)
Java solved the problems with these architectures a technological lifetime ago, and has yet to give up any real amount of it's marketshare to
Given some of these minor factoids we see here, it makes sense that Java isn't some piece of arcana waiting to be scrapped - it might be Sun's only remaining asset that has legs.
This is why a lot of us group up Linux and Java as great teammates (and I am not alone, Oracle, IBM and many other companies feel the same). Not because the JVM should be open sourced, but because of the niches they both provide in the IT puzzle. Unfortunately, getting most open source zealouts to understand that business purpose has a role and has obviously taken more than a minor part in Open Source already (Linux?, Redhat? IBM?) it is going to be equally tough to explain why open sourcing the JVM isn't really all that easy.
Closed standard? (Score:5, Interesting)
That certainly beats the situation for some other things generally regarded as "open" standards such as MPEG2. There you can't add arbitrary extensions and claim that it's still MPEG2. Any implementation will require licensing fees in order to be completely legal, as the standard includes patented technology (granted, they don't seem to be interested in pursuing people who build free software-only products -- but try selling an MPEG2 decoder chip and see how long it takes for them to serve you with notice). The Sun standard seems at least that open.
Re:Why even bother open sourcing Java then? (Score:3, Interesting)
Sun doesn't have to worry now about trademark dilution, since if they say it isn't Java, and a little lawsuit would solve that. What Sun wants is to have the more zealous of the OSS developer, the more moderate already chooses Java if they feel its the right tool, by having an openness while at the same time preventing forking of the type that MS tried to pull. They want to make sure that if people think its a java, lets say something like Classpath, that it is conforming to the one true Java API by allowing them to actually use the API but preventing them from making changes, harmless or destructive.
Remember Microsoft J++... (Score:3, Interesting)
This is news? (Score:5, Interesting)
Right now, you already can create a GPL'ed implementation of Java without submitting to testing by Sun as long as you don't use the trademark of Java or refer to you implementation as "Java".
I find this lack of understanding of the English language disturbing. RMS has confused the lot of you concerning the meaning of "closed", "open" and "standard".
Java is already an open, transparent and published specification. What Sun wishes to maintain is control over "their" trademark.
Re:Its called a trademark silly (Score:4, Interesting)
Would GPL'ing Java have any negative consequences for Java application developers? I.E., if I use a GPL'd Java, would I be required to GPL my application? I know that there is already some concern about using the GPL with Java Applications, but I'm mainly concerned about the Java itself.
I currently use Java (1.4.2 on OS X and 1.5 RCx on Win32) and LWJGL (lightweight Java GL), which is BSD licensed, mainly because I want to maintain control over my creations without giving away my code (preferring a Carmack approach: Sell the game, then release the code after game sales have slowed to the point of "don't care". No, I haven't actually released any games, Thanks for Asking..
Re:I think it's brilliant (Score:1, Interesting)
Ugh, I'm having flashbacks to every time I try to work with SQL. Sure all SQL servers kind of implement the same basic functionality but to get anything usefull done you have to be a linguist who is intimitly familiar with each of the dialects you are using. It's an ugly hackish mess. What Sun should do instead is actually open up the JAVA standards process so that people who have views contrary to Sun's can put their constructive criticism to work improving the language standard.
A License proposal (Score:4, Interesting)
Java is owned by sun, and sun is going to allow you to have access to the Java standard, so you can make your own implementation. If you do make your own implementation though, then you have to make sure that it's compatible with our version of Java, that is to say, you can add features, but you have to make sure that any program written to run with our version of Java also runs on your version. For a price, you can pay us to ensure compatibility, and only after this can you use the term Java in your application, or claim "Java Compatible". Oh, and none of this applies to Microsoft, screw you guys.
Re:Why even bother open sourcing Java then? (Score:1, Interesting)
Just how much money does Sun make from selling JVMs and JREs? Yep, that's right, zero.
On further reflection, though, may be right re: trademark dilution (see the end of my post). You're also right that Sun wants to prevent the kind of stunts MS pulled by marketing something as Java that doesn't fit their standard.
However, I don't think Sun really gives a shit about "the more zealous of the OSS developer". I don't think OSS zealots who won't go near any development tool that isn't OSS are necessarily any more talented than than people who are willing to use Java even though it is not open source.
Now, IANAL, but I think you may be right about trademark dilution. If anybody is stupid enough to call their project Java without Sun's blessing, then, as long as Sun sends out a C&D letter and follows through with litigation, if necessary, their trademark should be safe. After all, Linux is trademarked.
Still, there's nothing wrong with my suggestion other than GPL incompatibility; everyone gets exactly what they want. (Or, is this the real problem in your eyes? C'mon, the GPL wasn't handed down by God on a stone tablet, after all.) Sun gets to revoke the licence of anyone wrongly using the Java name, the community gets its OSS Java.
Re:Its called a trademark silly (Score:5, Interesting)
However...
Remember that Sun did get stung a bit back by a little Java-like offshoot that wouldn't have passed their test suites. Remember Visual J++? Trademark protection wouldn't have helped there, J++ != Java.
They are probably looking to avoid a repeat of the same "mistake".
Standardisation is the way (Score:5, Interesting)
So what would the consequences be? Regular users will be able to download a package for their own distro that Will Just Work, and get on with enjoying the Java experience. Your average "meddling hobbyist" won't care too much about the name, just about the kewlness of their latest mod. Packagers will be able to pass the compatibility tests with confidence {all they'll be doing is picking sensible defaults by the standards of their distribution}. And anybody who wants to create a closed-source Java replacement with the intention gradually to reduce compatibility with the original Java release-by-release, in order to steal SUN's market share, will be f??ked.
Sounds like a win all round really!
It works for Common Lisp (Score:2, Interesting)
The case of Common Lisp is rather illuminating in that it was not actively maintained (it lacks facilities like sockets etc) so the implementors did differantiate but only there where there was no standardisation.
And Common Lisp is a case in point where a spectaculary superior language (and not just compared with the rather crappy Java) will loose out because of an inedequate library and, perhaps, user community.
Re:I don't get it. (Score:3, Interesting)
Perl? 1
PHP? 1
Python? At least 3 - Python, Jython, and Python for
Ruby? 2 - Ruby and JRuby.
The difference is that with Java, there are compatibility tests.
TeX (Score:4, Interesting)