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?
I'm gonna stay out of this one flame war. When diversity means less options, then I'm all for closed. Until then.. Darwin is in control.
Possibly.
It depends on just how "closed" the closed-source component of the partnership is. If it's something like Java, which is mostly open in its technological aspects, but legally closed, and there is an undertaking from the owner that there will be no GIF-style schenanigans, then why not?
On the other hand, if we're talking about, say, the MS Word "standard", then I just don't think that a partnership with Open Source is possible. There's no real reason why an Open Source project would need to use such a standard anyway, so I think the answer probably has to be "probably not"
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.
Sweet. Sweet revenge.
Maybe it's just because I've been doing Java development exclusively for the past three years. Or, maybe it's because I've been doing Extreme Programming exclusively for the last two and this gels extremely well with the idea of Customer Tests which are at the core of what I do. But, I think this is absoulutely brilliant.
Essentially, "Do whatever you want, but you can't call it Java unless it passes our compatibilty suite." 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. BTW, it is already pretty easy and wouldn't become any harder to expand beyond core java by adding additional libraries. The difference would be that you could distribute the whole thing under a single open source license.
The one thing you couldn't do would be to change the language itself. But then, maybe I'm missing something, but if you don't care about compatibility why use java in the first place?!? It's not like there aren't good alternatives out there that will let you do whatever you want (Perl, Python, C++, etc.) The whole advantage of Java is that it is so prolific, and it is so because of it's rigorously maintained compatibility/portability (And strong advocacy by Big Blue among others... who like it because of it's portability across the many platforms they offer and support.)
If Bob Scheifler had read the Open Source definition he would have noticed that maybe criteria 8 and 10 contends with what he wanted to accomplish.
;->
8. License Must Not Be Specific to a Product: The rights attached to the program must not depend on the program's being part of a particular software distribution.
His test suite would be another program.
10. License Must Be Technology-Neutral:No provision of the license may be predicated on any individual technology or style of interface.
The environment to be tested might not support all of the I/O that his suite might need in order to pass. IE maybe it has some combination of no writable filespace, no gui, no network connection, no terminal....
I wish the definition was more clear that the license itself shouldn't restrict the kinds of modifications that can occur. If that is impied then criteria 3 is abused as well.
The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software. You are allowed to make modification as long as the md5sum of the resultant file is cc4e48a5fe0ba15b13a98b3fd34b340e
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
The idea of a trademark is to make is difficult to pass of an inferior clone as the original, which seems to be precisely what Sun is trying to prevent.
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
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!
I like Java. I maintain an Open Source project coded in Java. I particularily apperciate the fact that Java applications can be easily made completely portable across platforms.
Here's what concerns me. Open Source has never really shown that it's terribly interested in ensuring API and binary compatibility across releases. Native binaries tend to be somewhat tightly compiled for their specific distro. To get around this, many packages are distributed as source so you can compile them specifically against your platform of choice.
All well and good, but take a look at how the sources accomplish this: via pre-compiler directives to ensure things compile correctly on different platforms, or via complex makefiles to build specific sources on specific platforms.
Currently, I don't typically have to worry about such things with Java. There are no pre-compiler directives, and there is no need to use them: one codebase compiles on every platform.
Here's where my concern comes in. As soon as you Open Source Java, someone is going to want to put in pre-compiler directives because they're used to them from the C/C++ world. Around the same time, someone is going to create a Java fork which isn't 100% compitable in some area.
Java developers, wanting to target as many platforms as possible, are going to start using the pre-compiler directives in order to work around implementation-specific bugs. Maintainers are going to start worrying less-and-less about API compatibility issues because developers are going to have pre-compiler directives to work around them (as we've already seen many times over the years in the C/C++ world). All of which is going to help reduce Java's platform neutrality, and make my job as a Java developer more complex than it is currently, reducing incentive to use it in the first place.
My biggest interest as a Java developer would be to ensure that all Java runtimes conform to a single, standardized testsuite as Sun seems to want. And I don't care that the testsuite could be buggy -- so long as any API bugs that do exist are consistant across platforms. At the same time, there are some amazing things the Open Source world could do with all the other parts of the Java Runtime Environment -- for example, making the HotSpot Compiler Open Source could allow for some pretty massive JIT research to be consolidated in one place for the benefit of everyone.
Much of this could be solved if Sun put the Java API and other technologies through an official standardization process, and then made their implementation Open Source. The former has worked well for other languages (Ada comes to mind), where a tight standardization process long helped to ensure source compatibility between platforms. The latter works extremely well for enhancing the adoption and development of a given technology. But to make it work, you couldn't just go with some form of defacto standard that most Open Source projects use/create/adopt. Unfortunately, I'm not quite sure what benefit Sun would see from doing something like this (not that I personally care anything about wether or not Sun were to get anything out of doing this -- I just realize they're going to need to see some sort of benefit before they ever decide to do such a thing).
Yaz.
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.
No they can't really
tell me, how open are posix, ANSI C, or the internet standards? are linux, *bsd, apache open source or not?
"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.
MS put out an incompatible java in yet another attempt to control the internet. in order to prevent that, sun had to do something. so MS didn't like the outcome and decided to do its own standard. fine, but at least we can pretty much rely on the java we have installed on our systems run whatever claims to be java
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.
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.
As a developer with the FreeBSD project, I can say with certainity that there do come benefits from proprietary derivates of BSD-
Specific examples:
- The entire SCSI subsystem of FreeBSD (CAM) comes from a proprietary derivate
- The entire netgraph subsystem (network transformation system) comes from a proprietary derivate
- Many of our core developers are employed by companies making proprietary derivates
- The mpd multilink PPP daemon came from a company that made a proprietary derivate
We've also got a ton of other submissions, but bugfixes and feature enhancements.Now, we can have an economics debate about which license results in the most contributions - but claiming that "if a company uses your source in a closed product you dont get any future benefit" is plain misinformation.
Eivind.
Doubting the existence of evolution is like doubting the existence of China: It just shows that you're uninformed.
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!