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.
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.
By definition, anything created to satisfy a closed standard leaves very little room for improvement. If you have to build around a crappy API, you can't improve the API. In order to have a fully open source application, you must build around open standards as well. Otherwise you'd have some very nasty license issues.
US businesses that currently accept chip and PIN/signature
"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
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"
Will make thine browser misbehave, less thou disallow java.
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.
All Sun has to do is to publish a standard Solaris OS specification (similar to whats done with SPARC) and then GPL the OS.
.. if they do a half ass job ..they just won't be trusted.
GPL offers protection to individual developers that they will be able to freely benefit from improvements to their contributions anyone makes without having to fork over money. The problem with BSD is that if a company uses your source in a closed product you dont get any future benefit and if you want to use their product you have to pay.
Open source developed Solaris OS'es should have the ability to claim compliance to whatever revision of Solaris.
Sun can charge a fee to do compatibility testing. In theory though it should be possible for third parties to also engage in the certifying compliance business
They will have to have their own logo though and not be allowed to use a Sun certified Solaris specification compliant logo
Microsoft already tried that with J++.
It lasted about, I donno, 3 months before they were sued out the ass...
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.)
What do you mean by "nasty license issues?" I don't see how coding to a given API can result in this... If the product does not meet the given guidelines, the standards body could sue for breach of contract. Sounds simple to me.
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
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?
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.
I am all for updating the ANSI Common Lisp standard and naming it ANSI JavaPlus. Finally a Lisp going popular. :)
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).
Why the heck not (okay, I did read the other comments and there seem to be reasons). But really, why can this not work? I welcome a new Open Source license -- there aren't enough already.
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.
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!
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.
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.
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.
Release the code under GPL but if you want to use the JAVA trademarks (i.e. if you want to call your program "JAVA") you have to pass the testsuite.
:)
The same testsuite would also be usable by people writing other "JAVA" implementations (such as the GNU GCJ compiler and libraries).
In fact, GCJ could just grab whatever code is usefull from the SUN VM directly and use it
There are already plenty of not-quite-compatible Java hacks out there. The MS VM was the most obvious one (you don't really need JNI, do you?), but consider stuff like GCJ, Kaffe, Pizza, etc. The Java community has survived them; it can survive open source.
Looking Glass is a developers release and if you aren't a developer you shouldn't be downloading it. They have made it clear that they released it so early in the project's life so that developers could test it and start brainstorming/creating 3D applications. If that screenshot is from you, you obviously did not read any of the documentation provided on the project page at java.net as that is a known problem on certain hardware setups and has a very easy fix that has been discussed in the forums a number of times. Maybe you should look at the documentation before you start downloading developers releases and complaining about there stability. Looking Glass won't be useable as a desktop replacement for the general public for quite sometime yet. Do you also realize that Looking Glass is open source and has been for several months?
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 source *is* documentation for the standards.
No they can't really, and even if it were possible why wouldn't people just use Eclipse?
So you're telling me that the Samba project doesn't work? At least Sun gives away a test suite - with SMB you have to do a lot of network snooping to verify things are working correctly.
When they got into fight over java with Mircrosoft the result was MS making .NET.
Part of the $2bn settlement was due to M$ inability to make .NET without infringing on Sun's patents.
A Shadeless room is a brighter room.
...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.
Keither's license-discuss posting.
Yep, Karma whoring all the way except that I was just reading his posting this afternoon.
-russ
Don't piss off The Angry Economist
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.
Microsoft already tried that with J++.
Totally wrong. They tried that with "Microsoft Java", got sued (for breaking a contract which was totally unlike anything an open source programmer might sign), and then renamed it to J++.
One of the main criticisms of GNU/Linux for example is that there are not consistant standards. I know that this has recently been fixed to a large degree with the specification created a few weeks ago by all the big distros and important people, but this is a great example of the more general situation. Linux people out of all people are for open implimentations, but there was still a need for large collaberation in interface. As a result, some freedom was taken away, but I think most would agree that this is a good thing. Sometimes what you need is a good benevolent dictator. Is Sun benevolent? I don't know. That has been a point of recent contraversy.
...that if it wasn't for their tight control and protection of Java, the only way your java/j2ee apps written on windows would work on linux/unix would be through wine.
And vice versa through cygwin.
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"
As I read this (and IANAL) the code is made available under some new open source license. If your code doesn't pass the test suite then you need to distribute your executable under the same new open source license (which probably requires you also distribute your source code). Only if your code passes the test suite can you distribute a binary version under some other license of your choice.
So it might be more appropriate to see this as Java under GPL with a way to keep your changes private by maintaining compatibility. Seems like a neat hack!
The primary purpose of open source licenses is to give users control over the software platform that they use--to allow them to adapt it to their own needs, instead of the business needs of some mega-software-corporation. This includes removing or replacing poorly conceived portions of a platform and adding incompatible extensions. An "open source" implementation for a closed standard under the control of Sun doesn't allow this, hence it doesn't achieve the goals of open source.
Furthermore, requiring formal test suite compatibility means that such a project simply cannot meet the definitions of an open source project.
What is the big deal?
How many implementations are there of Java? Perl? PHP? Python? Ruby?
Yep. Just one, each. That hasn't stopped each from growing to enterprise-grade capacity. (Yahoo has bet the farm on PHP, etc)
If Sun Opens up Java, but requires that forks retain a baseline compatability, what is wrong with that?
There are numerous implementation of Structured Query Language (SQL) and the fact that they are all "mostly" compatable is a developer's nightmare. You either don't bother with all the fancy foreign keys/rules/triggers stuff, or you choose AN implementation of SQL (Say, PostgreSQL, or Oracle, etc) and develop for it alone (or you have lots off time/money to burn). You can only develop cross platform appliccations in a fairly simple way, because of all the potential gotchas between SQL implementations. Anytime you need true ACID compliance, and true data integrity guaranteed at the database level, you're stuck.
How different this would be if ANSI SQL came not just with a specification (does this, that, etc) but also came with an extensive set of statements and results that could be compared so that there was a strong, capable baseline that would be cross platform.
Then, establish a non-profit agency that could enforce the standard, providing three degrees of certification: ANSI SQL based, ANSI SQL compliant and ANSI SQL certified.
"Based" would refer to an incomplete implementation of the spec. The only difference between "compliant" and "certified" being that "compliant" could execute the statements to get the desired result, and "certified" has been independently tested by the enforcement agency to ensure that the test runs right. (and a fee has been paid)
This would be a total BOON to developers who could write ANSI-compliant statements and be confident that their stuff would work everywhere.
There are DOZENS of gotchas in SQL. For example, if you define a UNIQUE constraint across two fields where one of the fields could be null, does the UNIQUE constraint apply to rows where one of the fields is null? According to the spec, no. But numerous database engines will enforce the uniqueness despite NULL being one of the values.
OOPS! NULL is not a value, it's a non value. It's an "I don't know". How can that be considered in an evaluation of unique?
Usually not important if you're running a BLOG. Can be critically important if you're keeping track of financial transactions!
I would *LOVE* it if ANSI treated SQL like Sun proposes dealing with JAVA....
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Open Source means No Control.
That's the core of the various free software guidelines.
You never need to ask permission before taking some 3D library and stuffing it into an SNMP monitoring tool, and then posting it on freshmeat---where some person on the other side of the world finds it and hacks up a web interface.
You never have to be captive to a copyright owner. If you think RMS is making poor technical decisions in FSFmacs, or XFree86 does silly things with licenses, or some guy neglects his hobby projects (ahem), you can go off on your own without begging anybody. All you have to lose is the previous name and its reputation.
On the other hand, there are about a zillion Linux distros out there that nobody's heard of. The ultimate penalty for doing a bad fork is being ignored.
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
No. Because after the free-software community has put a lot of effort into implementing Sun's standard, Sun can change the standard in a way that breaks the community's interpreters/compilers.
The models of how language standards should evolve are the C and C++ standards. They have always been controlled by programmers, never by one company. They evolve, but very slowly, which is good. Every change is thoroughly considered by a lot of people before adoption.
Yes It's been done for years.
The LaTeX Project Public License (lppl)
In essence it says:-
That's probably too simple a solution, i.e. nothing in it for the lawyers.
Maybe it's just me, but all those never-endings turns around java and the gpl is really getting boring no?
If Sun want to do-it they will do-it, the rest is only noise and advertisement.
What's in a sig?
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
Actually the LGPL would be more appropriate, since it allows you to link with the plentiful java standard libraries.
An example like this I remember from old is the Borland pascal/C license, which also explicitely stated you could "link".
The GPL is pretty viral and can easily be understood as covering work that gets mixed with it. I guess one could show numerous examples where this isn't the case, but there is the danger of it.
E.g.: Just try to figure out what LGPL means for php code, which can be both code, library and program. It doesn't compute.
I'm still trying to figure out what people mean by 'social skills' here.
Your argument seems to hinge on the idea that all Sun owns right now about the Java platform is their own implementation and the trademark. But that's not true: Sun has much strong intellectual property rights, and they have demonstrated time and again that they are not willing to give up those rights.
For example, you cannot write an open source implementation from Sun's specifications (see here for RMS's take on it). Furthermore, Sun has numerous patents on technologies related to Java; it looks like some of those patents are essential for writing a standards-compliant Java implementation.
The fact that some people have started independent (but so far woefully incomplete) efforts to create open source implementations of Java and have so far gotten away with it, unfortunately, doesn't show anything; Sun doesn't have to enforce their trade secret, patent, or copyright claims until it is convenient for them to do so. People didn't see LZW and GIF coming either. Sun may well eventually make SCO-like claims over open source Java implementations, and unlike SCO, Sun may have a pretty solid legal case.
.. that Sun has a VERY STRICT testing procedure in declaring a VM "Java Compatible". Just because it can run Java code (see Microsoft's Java VM), the implementation being different can cause all sorts of problems. As a matter of fact, this is the major reason for compatibility problems with WINE... little implementation quirks in the win32s could be dependant behavior.
Sometimes I wonder if all of these "Make Java Free!" actually even see the picture that they swear that they are looking at.
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
Linux conforms pretty closely to POSIX and SUS, which are closed standards. GCC conforms to ISO C99 (at least, when you tell it to).
Yes, but Linux conforms to those standards that its users want it to conform to, not to the standards that some other entity says it has to conform to.
That makes a huge difference in practice because it allows junk that users just don't want to be removed from the system.
Furthermore, allowing Sun to set compatibility standards and tests means that, for all practical purposes, they could make Java proprietary again at any time, simply by imposing compatibility requirements that open source implementations can't meet. That's not the kind of control open source developers are willing to give some company, in particular, a company that's in as bad shape as Sun is.
Java is a key language for cross platform development, yet it falls short of .net in many ways (and surpasses it in many ways as well). These shortcomings need to be addressed, but will not be addressed if we wind up with fragged Java. If core Java becomes divergent, then it will cease to be a write once run anywhere solution.
I like the idea of using a standards group to guide standards as it insures against predatory corporate dangers. I also think Java belongs to Sun. They developed it, they mareketed it, they sued MS to keep MS from destroying it. How much did any of us contribute to their cash flow specifically for those tasks. I do not see a problem with Sun doing this. It might not be pure Open Source, but it might be a good middle of the road. For most projects to be made open source, there must be a point of profitablility (money or otherwise). Companies live by profit, die by lack of profit. They will need reasons to embrace and support OS. After all, what part of Sun owns it has prevented you (the Java users) from using Java? Either Java users must be gluttons for abuse, or Sun has been pretty good to them so far.
InnerWeb
Freud might say that Intelligent Design is religion's ID.
They could do what the Defense Department did with the Ada language. They trademarked the Ada name and licensed the trademark only to compilers that passed the test suite. They also threatened to sue if anyone claimed to provide an Ada compiler but did not satisfy the tests.
Sun could open source the code and trademark the name "Java." Then they could license use of the name only to systems that passed the test suite and legally protect the trademark.
Someone who wanted to fork the code would have to use a different, non-confusing name under the trademark.
To that end, we have the Lesser GPL, which would allow compiled applications themselves to be closed-source.
;)
It's funny you mention readline, because I seem to recall there being some disagreement about it being GPL'd as opposed to LGPL'd. In the FSF's opinion on the subject, "releasing it under the GPL and limiting its use to free programs gives our community a real boost. At least one application program is free software today specifically because that was necessary for using Readline."
It is paradoxical here that the FSF dims their own light on behalf of their own greater good. In the case of readline, and I'm sure a possibly GPL'd java class library, is that when the license which inhibits adoption by closed-source folks who wish to develop in their own manner, these same closed-source folks will instead opt for a more restrictive/liberal alternative (depending on your point of view) that enables them to continue to do what they've been doing all along--develop closed-source software. This slows the overall adoption rate of open-source software.
Open-source seems to grow best when it's not forced down our throats or dangled in front of us like an unattainable carrot. The ideal solution should be to showcase the power of open-source in combination with the freedom to do what you want with it, including using it in closed-source. This greatly assists open-source's wide-scale adoption. Lao Tsu said it best: "Build your enemies a golden bridge to retreat across."
Look at GCC and friends--closed source software built on GPL'd and LGPL'd libraries released for open-source platforms such as Linux increases that platform's market share. Regardless of how you perceive Flash and RealPlayer1, they are both closed-source applications that help Linux be a better desktop OS because you can easily view a good chunk of the WWW with it without having to learn about swfdec or mplayer/xine, respectively. And people all over can move their IIS/Oracle/ASP application letter by letter to LAMP2--all because interoperability with the closed and open is possible.
In summary, let the open and the closed comingle, because the open will certainly prevail.
1. It should also be noted that once in the open-source world, people will be more prone to ditch those closed-source holdovers in favor of the aforementioned open-source (and many times superior) alternatives.
2. Substitute L for F, N, O, H, as applicable. The P can stand for whatever the hell you want--I'm not getting into that tonight.
--sean
"[T]he single essential element on which all discoveries will be dependent is human freedom." -- Barry Goldwater
I don't know if anyone else has noticed this, but Sun doesn't seem to do so well at "keeping control" of the core Java API...
I don't think that "open standards" mean that you can change it whatever way you want. If that would be the case, "open standards" would be a contradiction. To be a standard, it has to be well defined and respected. Otherwise, applications would not be compatible and that's the very goal of standards. "Open standards" should mean that the specifications are public and free to use, not that you can change them just like that, there still has to be some organisation controlling a standard or it simply won't work.
The negatives are not related to the licensing of your own code, Sun's position is that if they GPL'ed the Java code tomorrow you would start to be unable to write applications in Java as there would be multiple Java VM's floating around with different stuff in them - like the early Microsoft VM.
Thus they seek a licence that would let them release the whole Java code base, but still make sure that you could write applications in Java and be sure they would work from VM to VM.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
>>
/me wipes the tears of cheek..
If Sun were to put Java into the OS community, it would need to ensure that the write once run anywhere still worked
>>
HAHAHA HIIiiiiii hiih.. Auch, You're killing me....ohhh hihi, good lord.
I'd like someone like Linus (but a little bit more of a facist) taking control of Java. I don't care if it's Sun or some open source dude, maybe a group run in an non democratic way.. or democratic if they all are sane... I don't know..But things have to improve!! As long as the control stays away from MS or any of a "special intrests" entity.
Most of the posts regarding this licensing have been from the developers' perspective, but perhaps we should look at this from the users' perspective.
;-)
Something like 90% of the public recognizes the Java name (way more than recognize Sun). It's therefore extremely valuable. People recognize Java as meaning either "works on the Web", or more enlightened "app runs on all kinds of computers and maybe my cell phone".
If I make a vitual machine call FooCoffeeBar, I am going to be taking advantage of the years of powerful Java branding (i.e. "public recognition") to tell non-developers that this code runs in lots of places by calling it "Java Compatible". If I didn't care about end-users, I'd used a phrase like "I can't believe it's not J*v*", since developers are smart enough to figure it out.
Running the canonical test suite is the only way to make sure this brand doesn't get diluted. A naive user who buys a Java-enabled cell-phone (or a Mac desktop, whatever) that can't run Java apps properly will likely be put off all Java (including products from other vendors and brands using the "Java compatible" branding).
Remember, it was the Open Source Community that has been clamouring for Java to be opened up mostly because of redistribution issues. Does this licensing scheme, which protects the end-user base, not accomplish anything developers need (since you can redistribute under any license you want if it passed the test suite)?
With regards to Sun randomly changing the API or VM, creating havoc developers down the road, please see the Java Community Process.
Certainly you can have a near-open-source license in which the interface and behaviour is tightly controlled by a single developer. The classic example is Dan Bernstein's qmail, which is freely redistributable in its original form, but modified versions can only be distributed as patches.
This has caused some problems, mostly because it makes it hard to maintain compatible versions with extended interfaces. These kinds of qmail extensions can and up coming in three or four versions, each based off a set of popular patches. This would, of course, be entirely consistent with Sun's goals... like Dan, they don't want forking of the interfaces.
There are DOZENS of gotchas in SQL.
...) VALUES ('val1', 'val2', ...);
...;
...;
That's because the people who designed SQL made the same mistake as the guy who designed Perl, and figured the word "language" applied to a computer instruction code had something to do with the word "language" applied to the way humans communicate with each other.
Just one example of the deep brokenness in SQL: Why the hell are UPDATE and INSERT statements syntactically so different?
INSERT INTO "foo" ("col1", "col2",
UPDATE "foo" SET ("col1"='val1',"col2"='val2',...) WHERE
Apart from the noise words (INTO, SET), anyone who has spent five minutes thinking about programming languages would have picked one or the other, and ended up with one of these:
INSERT INTO "foo" ("col1"='val1',...);
UPDATE "foo" ("col1","col2",...) VALUES ('val1','val2'...) WHERE
Really, these should just be different options to the same command. That would have also avoided all the variants of UPSERT, because it'd just fall out of the syntax.
Newfangled ideas like making these (...) things into formal lists with names and stuff, like Lisp already had, wouldn't have been outrageously out of the question even in the '70s.
The fact that only Sun can change the standard is fairly immaterial, they don't control code written to comply with the standard.
I don't hear anyone shouting that ASCII code is a closed standard, and that there is anything wrong with that. But it can not be changed by absolutely anyone who wants to. In fact the most ardent suporters of F/OSS inevitably use either ASCII or Unicode, or both, depending on what they are doing. Unicode did tend towards being closed, last time I looked that seemed to have improved.
The same goes for lots of other standards that we work to, C or C++ for example.
The fact is that standards need to be set, by standards bodies or other organisations, so that they can't be changed haphazardly like the Windoze API. If Sun want to set a standard, fine. If another competent software developer, either a person or a company, wants to set a standard, fine. If they hand it over to a competent standards organisation, where all revisions will be properly controlled, good. If they control revisions in house, not quite so good but still OK. If M$ want to set a standard, I would suggest that on their past record they are incapable of doing so.....
I know that this has recently been fixed to a large degree with the specification created a few weeks ago by all the big distros and important people
Bullwinkle: Watch me pull a rabbit out of my hat!
Rocky: Again? That trick never works!
There's a HECK of a lot of confusion in these threads. People are using the same or similar terms and meaning very different things.
Open Source is not equivalent to Open Standards is not equivalent to Open Systems.
The whole "open systems" movement grew around an operating system that was closed source and had a closed standards process for many years. There are open systems that incorporate open and closed source, and open standards and internal proprietary interfaces.
There are open source systems whose APIs are closed: you can't distribute software written to those APIs under another license: in fact this point encapsulates most of the difference between the GPL and the LGPL.
Linux is Open Source, but some of its APIs are closed.
Darwin is Open Source, Open Systems, but the IOkit interfaces are controlled by Apple.
Solaris is an Open Systems and mostly Open Standards product, only a few of its interfaces are controlled by Sun.
Mac OS X is an Open Systems product, but many of its interfaces are controlled by Apple.
Interix is a Closed Source Open Standards product, containing Open Source components, running on a proprietary platform (the NT kernel) with almost no Open interfaces (of any kind) at all.
Java has a Closed Standard but there are Open Source implementations. But it is often used to allow people to avoid implementing Open Systems interfaces to proprietary components (consider a remote-access KVM that is only usable through a Java interface).
As for bugs in the test suite, I can think of two ways to handle this. First, use versioning so if Java X.Y has bugs you can switch to Java X.Z. Second, craft the test suite such that the tests are the defining authority for what constitutes "Java".
For historical reference, this would be much like the IBM EGA video "standard". The original IBM EGA card didn't meet the EGA spec, and hardware makers soon found that cards meeting the EGA spec wouldn't work because all the software was written to run on the (out-of-spec) IBM hardware. So all EGA clones soon conformed to the REAL "standard" by duplicating the flaws in IBM's original EGA card. I'm sure if there were a significant bug like this in Java, the bug would become part of the "standard" -- which would all be a non-issue if indeed the tests ARE the "standard."
If all this should have a reason, we would be the last to know.