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."
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 Case for Open Source/Closed Standards
Kevin Bedell
There's been some debate recently on the license-discuss list hosted by the OSI on how to release code as open source while still requiring that it be compatible with a test suite that must be distributed as part of the code.
The initial discussion was kicked off by Bob Scheifler of Sun Microsystems. Bob's original post was:
For my personal edification, and hoping this is an acceptable inquiry, I'd like to understand if and specifically how the following informal license sketch conflicts with the OSD. Any and all comments appreciated.
1. The licensed work consists of source code, test suite in executable form, and test suite documentation.
2. A derivative work in executable form that has passed the unmodified test suite can be distributed under a license of your choosing.
3. Any other derivative work can only be distributed under this license.
Any such distribution must include the unmodified test suite and test suite documentation.
The idea would be to somehow require that derivative versions of the code would pass the test suite distributed with the code. As long as the derivative work passed the test suite you could distributed the code under any license you wanted -- but if your derivative work did not pass the test suite, you'd be required to distrbute it with the test suite included under the above sketch license.
One use for this type of license would be to release code that implements some sort of API under an open source license, while ensuring that no one can change the API itself. For example, if Sun were to want to release Java under an open source license, this may be the type of license it would choose.
By requiring that any derivative works pass the test suite, Sun could ensure that no one could publish derivative versions of Java that were incompatible with their version. The open source community (and other companies) could freely publish implementations of the code that passed the test suite, but Sun (or at least the JCP) would remain in control of Java as a standard.
Hence the phrase, Open Source/Closed Standard.
So, is this a good idea? Can something be considered to be 'open source' if some organization stays in control of the standards that the software implements?
Personally, I believe this should be fine. It's to everyone's benefit to allow open source implementations of standard API's while preventing fragmentation of those API's. And did I mention that I think you're really, really cute?
For a good example, just look back a few years ago at the mess caused by Microsoft delivering an incompatible version of Java. Microsoft took advantage of their Java license and created a JVM (the MSJVM) that implemented what they called 'improvements' to Java (can you say 'embrace and extend'?).
This caused a huge lawsuit between Sun and Microsoft. Sun claimed it was anti-competitive behavior and that it fragmented the Java standard (and they were right on both counts). It was to no one's advantage (except Microsoft's) to include a version of Java in every instance of Windows that was incompatible with all the other JVM's that were available.
Linux conforms pretty closely to POSIX and SUS, which are closed standards.
Compared to Java, they aren't closed at all. Despite the existence of an impotent "community process", the Java standard is 100% Sun property. Scott McNeely could totally change the meaning of "Java" every 15 minutes if he wanted to.
Do you want him to be able to take away your work just because it's based on a "Closed Standard" Sun decided to rewrite?
Firefox conforms to RFC 2068 and HTML 4.01.
What do you think a "closed standard" is? There's room for argument ("How open is enough"), but it's quite clear that IETF RFCs are open and Java is closed.
uhh, think about it for a second. people don't have to "release" thier code under the GPL even though they build and link it with gcc.
you have to pass the test suite to call your implementation Ada.
That hasn't been true for a long time; I don't believe it was ever true for Ada95.
The GNU Ada Translator (GNAT) passes just fine.
That's half true. There exists a version of GNAT, several years old, that on a one (a small group?) of systems, again several years old, it has been certified to pass. There is a much larger group of systems and versions that it passes on, although it's never been checked officially. As for the versions that many distributions ship based on GCC 3.x, they generally don't pass all the tests.
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?
For a GPL "javac", no; e.g. gcc is GPL, but programs which are compiled with it don't have to be.
For GPL class libraries, yes, as the program would be a derivative work of the libraries; e.g. the readline library is GPL, and can only be used by GPL programs (at least, that's the stated opinion of the FSF's lawyers).
This is exactly how OpenGL works.
...) All non-standard extensions just can't begin with glXYZ(). Official extensions begin with ARB_XYZ and in the next version(s), they turn into glXYZ() once they have been formaly approved.
There is an open published standard that any developer can use for free or non-free software. For OpenGL implementations, they have some sort of dual-licensing. FOSS operating systems have a free (free beer) license. However closed source implementations have to pay a fee.
No matter what kind of software is created, they *all* have to pass a compatibility test suite, created and managed by the ARB. With revison numbers, the OpenGL standard is fairly easy to follow and to extend. (1.2, 1.3,
While OpenGL has been criticized for being slow to face competition from Direct3D, the standard is here to stay, clearly defined.
IMHO, Sun should look into OpenGL type of managment. It looks very close to what they are trying to accomplish.
Indeed