Slashdot Mirror
Open Source And Closed Standards?
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."
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....
When you have a license that restrictive, though it would be benefitial in maintaining compatibility with Java VMs & apps, wouldn't this basically restrict you from doing much with Java other than perhaps speed hacks and porting to some obscure OS?
Just go with the GPL so you can legally steal whatever code you need back.
The World Wide Web is dying. Soon, we shall have only the Internet.
"Can open source and closed standards work together?
.NET. When will Sun decide to open Java up when Java becomes as much as an underdog/hasbeen as Solaris.
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.
3dinfo@maficstudios.com
Actually, they work together all the time. A major example is Samba, which implements Microsoft's mostly-closed SMB protocol. Or the open-source implementations of Microsoft's video codecs.
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.
fish and pipes
Is it possible to get a bunch of people to work for you for free, while still not loosing any control in the market place?
Survival of the fittest may be seen as a good idea for software, but one thing I don't like about it is what happens when the fittest is flawed and the unfit aren't?
Karma? Hey I just call it as I see it.
Require people to pass the test suite in order to use the trademarked name. It doesn't matter. There is already an open source JAVA implementation in the works. Sun should either GPL their JAVA implementation and play an active role in its development or go away and leave others to do the job (with or without their code).
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.
Linux conforms pretty closely to POSIX and SUS, which are closed standards. GCC conforms to ISO C99 (at least, when you tell it to). Firefox conforms to RFC 2068 and HTML 4.01. Most OSS programs conform to some standard or other. Most projects are not able to change the standard and unwilling to break compatibility.
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).
SMB to Java is hardly fair. SMB is a truly closed, proprietary standard; Samba reverse-engineered the standard from implementations, and every time the "official" implementations change Samba runs the risk of ceasing to correctly function.
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, 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?
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
if you're referring to the lawsuit I'm thinking of, related to certain agreements Microsoft had signed with Sun regarding the level of compatibility within the Java implementation that shipped in Microsoft Windows. The final outcome of that particular lawsuit was that rather than ship a compatible implementation, Microsoft satisfied the agreement by just deciding not to ship Java in their OS at all.
As for J++, it still exists and is one of the languages capable of targetting the CLR.
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
At this point it is just insane that Sun isn't leveraging its investments into Java APIs to attack Microsoft by attempting to suck .NET developers into using Java APIs like Swing for their apps. There are already compilers that will let Sun rebuild Swing for the .NET platform and at this point Sun needs to consider co-opting the .NET platform to be a major goal.
.NET platform, not my enemy. I would hand over as many of the extension APIs to make Java run as good as possible on .NET. Of course Sun would rather let Microsoft take pot shots at its product lines a la OpenOffice than attempt to subvert their position.
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
Click here or a puppy gets stomped!
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 , the mobile search engine. We answer your questions via SMS, across the UK.
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.
Web Sig: Eddy Currents
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.
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.
...the "embrace, extend and break" attack on Java. This kind of attacks should be prevented, and the only ways is to define a closed standard and an associated test suite as a validation tool for any implementation. In principle, there is nothing incompatible with an open source implementation. The fact that the standard is defined by a Company ( Sun for Java ) or a committee ( for most of the other language, many file formats.. ) is irrelevant.
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.
Jesus was a compassionate social conservative who called individuals to sin no more.
Thus the core vision of "write once run anywhere" is preserved but the community is given the freedom (And, yes, I do know what that word means) to enhance and bugfix.
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.
Here is an idea for a license sun could use.... (please forgive the lack of requisite legalese, I'm sure sun's lawyers could obfuscate it quite well)
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.
Famous Last Words: "hmm...wikipedia says it's edible"
All SUN need to do is approach ISO and create a new international standard for a multi-platform programming language with certain features. Then, trademark the name "Java" and stipulate that it can only be applied to a programming language conforming to international standard MIL-TBD-1111 {or whatever it ends up being called}. Finally, release the Java source under something like the GPL, which would explicitly block the likes of Microsoft from releasing closed-source derivatives {as long as this is aggressively enforced}.
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!
Je fume. Tu fumes. Nous fûmes!
It seems to work for Common Lisp. Although this is a "real" standard (ANSI) and not one controlled by a single commercial entity, it does resemble the proposed solution in that multiple commercial and open source implementations closely follow the defined standard. No fragmented market there.
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.
Once in a while, I even pass the Turing-Test
How many implementations are there of Java? Sun's, IBM's (at least 2, including VisualAge), HP's (a clean-room implementation), GNU, Kaffe, TowerJ, Waba, and many, many more. .Net.
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 works about that way -- your code must pass a test suite to be called "TeX", but otherwise it's in the public domain.
-- Brian T. Sniffen