What Verisign's action means is that they return a different kind of result for non-existent domains. That's an annoying, one-sided change to technical standards, but apparently, they are not going to budge.
OK, so why not just modify DNS client software to recognize the bogus DNS entries as an authoritative non-response and have them behave as before?
If Verisign persists and tries to mask those domains really well, this may, of course, require trying to connect to the bogus site, but in that case, Verisign is just paying for a lot of bandwidth for advertising without getting any eyeballs for it.
Of course, he has to get SuSE installed first, which should be fairly easy as there are plenty of online distros that you can install via FTP
No, that's wrong. You buy the official distribution and stick the DVD into the drive.
But you better hope the installer picks up your NIC on the first try, otherwise you have to wade through a list of drivers to find one for his card.
One always hopes that when one installs an OS on some PC, whether that OS is RedHat, SuSE, or Windows.
Of course, over the last two years, every Linux installer that I have run has always detected and configured all graphics, audio, and networking hardware, which is a lot more than I can say for the $200 copy of Windows XP. Last time I tried to install Windows XP on a new PC ("Designed for Windows XP"), the Windows installer just hung during hardware detection; it took fiddling with BIOS settings to go through. SuSE did just fine on the same hardware.
If he finds one that might work, he'll then be prompted with a dialouge asking for arguments, with no explination as to what those are. Eventualy, you'll find one that will install with no args, and everything will work, but it's just another example of what the original article was talking about.
If you don't want to have to worry about this sort of thing, buy Linux-certified hardware. There is plenty of it out there.
If you try to install Linux on hardware that is not certified for running Linux, you take your chances. But, in practice, if you pick a distribution with a good installer, chances are that your Linux install experience will still be better than your Windows XP install experience. In fact, Windows installation has become so problematic that most Windows users don't install it at all anymore--they have it installed at the store, or they get a "restore CD" specific to their hardware.
Stop bullshitting and stop blaming Linux because you choose to make your life difficult yourself.
Its not the point of what he was using. Either way what he was using was not user friendly at all
But you can't blame Linux or open source for the screw-ups of a particular vendor (apparently RedHat, in this case).
Everytime I try to convince myself to switch I run into a situation similar to what Mr. Raymond ran into. I find myself doing to much work to do simple things and I simply dont have the time to research into it.
Switch to what? Debian? RedHat? SuSE? Lindows? Mandrake? Your experience will depend entirely on the distribution you switch to.
If you want a simple answer: in my experience, SuSE is probably the least hassle to switch to from Windows, both in terms of installation and UI. It may be a good way of getting started if you want to switch to some form of Linux system.
Either I can take his side and be called an idiot because I'm sure someone will claim to have an easy solution to my problem.
Short answer: pick a distribution that is better adapted to your needs. Printer configuration for CUPS worked like a charm with SuSE, for example--far more intuitive than Windows.
CUPS has a built-in configuration tool (http://localhost:631/), which at least works consistently across platforms and is fairly usable.
Finally, you can try to use Webmin. It's not a great UI, but, again, it's consistent and predictable across distributions, and most of its modules are fairly usable.
No, he is clearly not talking about the built-in CUPS GUI. The fact that the web interface has some common features shouldn't be surprising, after all SMB printers need to be configured no matter what UI you use to configure them. His GUI problems are a problem with the distribution he is using.
Don't let the fear of something that might happen be a basis to steal something away from someone that has been working hard on something.
Nobody wants to "steal" anything away from Sun. If Sun presented Java as just another proprietary platform, nobody would ask them to do anything. But Sun is presenting it as the alternative to Windows and the friend to open source. If they want the help of the open source community, they have to listen to the demands of the open source community; they don't get something for nothing.
Sun has invested a lot in Java and has been a good custodian of it.
I disagree. Sun may have invested a lot in Java, but that pales in comparison to the amount of work and investment others have made in Java.
I also don't think that Sun has been a good custodian. They have been looking out for their own corporate interests, not for the interests of the Java community. And they have made horrendous technical blunders.
understand that "Java" currently has a lot more credibility than "Linux" where Sun is pushing the technology.
I disagree. I think attaching the name "Java" taints the technology. Apart from that, it is simply dishonest because it is not, in any normal sense of the word, a "Java desktop".
The open source community doesn't need Sun to open source java but they do need to get sun to open up their licensing a little bit. Focus on that and take advantage of what benefits that will bring.
Oh, there, I fully agree. I think Sun's Java implementation is a lost cause. Who would possibly want to deal with that mess? However, if Sun open sources their own implementation, they have to loosen up the licensing to the point where other people can open source their implementations as well.
In any case, IBM doesn't want Sun to open source Sun's implementation, IBM wants permission from Sun to open source IBM's implementation, which requires Sun to loosen up their licensing. That is what this is all about.
I don't understand this. If you write a computer language, say C, that meets an ANSI standard, but publish it under the GPL, then haven't you created a product that is required to comply with a standard and yet which is also open source?
There is no enforcement for the ANSI C standard. You can implement 20% or 70% or 90% or 100% of the ANSI C standard. You can change the way printf, #include, or "if" work. It's up to you. You can even call the result "a C compiler" and nobody can take you to court.
In contrast, Sun attempts to enforce the Java standard. If you implement 90% of the Java standard and fiddle around with java.io, you are in violation of the license you agreed to for the Java specification. Furthermore, the 90% you implemented probably step on some of Sun's patents, and they are telling you in no uncertain terms that if you don't comply 100% with the Java standard, you have no right to use any of their patents. The way the license looks, your obligation to comply is independent even of whether you call the result Java or anything else.
And Sun is serious about this: Microsoft J++ was not acceptable to Sun because it wasn't 100% Java compatible and so Sun went after them legally. Sun has both the desire and the power to try to enforce 100% Java compatibility, and that is fundamentally different from something like ANSI C.
Well, nobody is stopping JWZ from switching to Windows or Macintosh. I think he'll find out that the grass is not greener.
On Windows, you get media players battling it out for control of your media. You get video playback that fails for no apparent reason. Something as simple as playing a hard disk mirror of a DVD can be nearly impossible (unless you install the same OSS s/w you'd run on Linux as well).
And on Macintosh, Apple likes to limit what you can and cannot do with video. Want to load clips into iMovie and assemble them? Sorry, no can do--pay a lot more $$$ to get the professional stuff. And "professional" means lots of messy, complex buttons and features that are harder to learn than the OSS command line switches.
It's simple: use what works best for you. Linux is popular because for many people, it simply works best. Windows is also popular because for many other people it works best. Those are depressing statements about the state of software.
Rather than ranting, JWZ could try to improve things for a change: he clearly has sufficient technical expertise, but he seems to lack the will and the GUI design skills to actually do anything.
ESR has little experience with configuring printers under Windows. It can be an absolute nightmare: networked printers are installed by making them local printers and then entering an IP address for the port number, local printers plugged into USB fail to be recognized, you have to select from zillions of nearly identical printer models, etc.
The way Aunt Tillie gets this to work on Windows is that she calls up Johnny, the good little nerd, treats him to her chocolate cookies, and has him suffer through this problem.
CUPS itself, for all its internal messiness, can easily presented with a better UI: Apple is using CUPS for OSX (even Apple's GUI is somewhat confusing for non-geeks), and how easy or difficult printer installation is on Linux depends more on the distribution and the UI it has chosen than on whether you use CUPS or LPRNG. CUPS also comes with an internal GUI (web-based) that is semi-decent.
Sounds like the distribution ESR uses (RedHat?) has a bad printer installation GUI, one that actually is worse than what CUPS comes with; he should complain to his distribution vendor--that has nothing to do with CUPS or OSS.
I understand the frustration with a lot of OSS GUIs, but in my experience, Windows GUIs are no better, and often worse.
If you take the specs, you agree to the licenses under which Sun releases the specs. That might be avoidable by trying to reverse engineer the specs from other published sources, but you can't take Sun's specs. And it's questionable whether anybody who has ever looked at Sun's specs can be free of their obligations to Sun.
i should think i don't have to license anything from anyone.
In addition to the strings attached to the specification, Sun also holds patents related to Java. They let you use those patents for free only if you agree to their conditions.
maybe this is why so many c compilers fail to implement the entire ansi-c standard?
Compilers implement what their users want them to implement. If many compilers fail to implement C9x features or ANSI trigraphs, then perhaps it's because users don't want those features. Seems quite reasonable to me. Overall, I have had far fewer problems with incompatibilities among C compilers from different vendors (!) than just with Sun's Java implementation across different platforms and versions.
extending the standard is one thing, but not being required to implement selective parts of it is not a good reputation to have.
Quite to the contrary: I think it is great when the market cuts standards back down to size. Java would be far less bloated and considerably more competitive if such market mechanisms had been allowed to operate from the beginning. In fact, Java shouldn't even have been a single standard: most of its APIs should have become separate standards from the core language and runtime.
This will only happen (in a bad way) if Sun are neglecting Java development and not doing things people want.
Why do you think they are so afraid of opening up the platform? They know that they aren't doing a good job, so they try to hang on to it through legalities rather than leadership.
The JVM isn't the problem. There are a handful of good, open source JVMs already. The problem is the bulk of the Java APIs, foremost Swing. The problem is also the patents that Sun holds on parts of Java. IBM itself is under additional contractual obligations to Sun.
What IBM is actually saying in this letter is pretty much this: IBM wants to open source their Java implementation, but they need the an OK from Sun to do it.
No, open source zealots are claiming that they aren't going to use or support Sun Java unless Sun open sources it. Whether Sun cares about that or not is up to Sun. Given how much Sun keeps proclaiming that they are friends of open source, apparently Sun does care how the open source community perceives them.
If Java were marketed as the proprietary product it is, few people would give a damn whether it was opened up.
Oops--sorry, left out the second part of the argument.
What the license situation means is that if Sun itself actually released something under a true open source license themselves, they would logically have to have given up their other restrictions. So, yes, for Sun to release an open source Java would only be meaningful if they also opened the spec.
Well, if Sun open sourced their implementation of Java, that wouldn't automatically make it an open standard. Sun would still control the spec.
No. As long as Sun has conformance requirements in the licenses that are attached to the specifications and as long as Sun hold patents on parts of the functionality specified by Java, no Java implementation can be truly open source. Implementations like Kaffe happen to come with an open source license attached, but they only exist because Sun tolerates them--for now. Strictly speaking, the licenses on those implementations may be invalid, and/or Sun may make patent claims against them.
What I wonder is why doesn't IBM just open source their own implementation, or is it based on Sun's code?
Of course, it's based on Sun's code. For example, there is only a single implementation of Swing in existence: Sun's. All others are derived from that.
Nevertheless, I just dont understand what opening Java is supposed to mean?
I think few people do.
ANSI-Java?
Yes, effectively. The only way any open source implementation of Java are above question would be if Sun actually drops their formal conformance requirements.
Note that you can do with ANSI C whatever you like: you can implement or not implement whatever parts you like. Not so with Java under the current licenses.
I don't get it, anyone can make their own JVM and release it as a Java JVM long as it conforms to the JLS right!?
Any implementation that has enforceable "conformance" requirements placed on it cannot be an open source implementation. Enforceable conformance requirements are intrinsically incompatible with what people mean by "open source".
IBM has already done this right?
No. IBM's implementation is derived from Sun's implemetation. But even if it had been written from scratch, IBM could not actually release it under an open source license without technically violating their license from Sun (whether Sun would tolerate that is another question--they have tolerated many violations of their licenses already, but they have also enforced some).
It is impossible for Sun to guarantee WORA and at the same time for open source implementations to be developed. It just doesn't make sense: the whole idea behind open source is that people can take the code for some software system, modify it so that it works more to their taste, and redistribute the result. Sun's compatibility requirements kill that.
So, let's just be clear about this: if IBM distributes a Java implementation under an actual open source license, then that means that Sun must have changed their licenses so that they can't guarantee WORA anymore and so that neither Sun nor the JCP have any special control over the direction of the Java platform anymore.
Almost every licence I know (IANAL) is confusing and subject to interpretation, even GPL.
Sure, but the way in which the GPL is confusing is different from the way Sun's licenses are confusing. At issue is a specific and crucially important area in which Sun's license is unclear.
Furthermore, the GPL gets updated periodically in response to input to try to make it clearer, but while Sun has changed their licenses, they have left the contamination and compliance clauses as vague and dangerous as always. The only conclusion we can have is that they want it that way: they want to be able to say one thing ("Java is open") but still have the option to pursue a different legal course.
JCP has agreed in the past that open source implementations should be accepted,
I have no idea what that statement is supposed to mean. JCP isn't a person, and "agreeing" has no legal force if it isn't written in the licenses.
This kind of on-going vagueness is exactly the problem with Sun: they talk a lot and promise a lot, but they deliver much less in writing.
The fact is that, under the current set of licenses, there cannot be a fully open source implementation of Java because Sun effectively can always gain control over any such implementation.
And Sun is quite proud of this, too: it's their stated policy to guarantee WORA across all implementations. That policy is fundamentally incompatible with open source or independent implementations. And it sums up the problem with Java: Sun's standards suck, yet they have the power to enforce them and do so.
which is more than you can say of MS.
No, it is less than you can say of MS. C#, the CLR, and large parts of the.NET APIs are unquestionably open and can be freely implemented. Furthermore, Rotor clearly does not contaminate you because its license explicitly guarantees you that it does not.
That's not so; this week at Javalobby Sun JCP Director Onno Kluyt states that looking at Java sources does not taint
What Onno Kluyt says on Javalobby is legally irrelevant. What matters is what the license says and the license says you are tainted. And that's not hypothetical either: Sun has caused other companies problems with those clauses.
and is willing to answer FSF questions on the issue.
If Sun's licenses require Onno Kluyt to answer questions, then Sun's license is not written clearly enough. Sun needs to fix their licenses, not try to explain away deficiencies in their licenses in legally non-binding PR talk.
Sun likes to talk a lot of PR talk, but they are unwilling to address concerns by putting their licenses in clear, unambiguous terms. And after half a dozen years of waffling on legal issues, one has to conclude that Sun isn't ever going to fix these legal problems.
Besides, at this point, there isn't any reason to look at Sun's source code anymore anyway. There is nothing of technical interest in Sun's source code, and in practical terms, Sun's legal control over the Java standard and their Java-related patents mean that trying to create an open source implementation of Java is pointless anyway.
Let me first say that I don't know Japan's antitrust legislation, but at least here in the US you're absolutely and completely wrong. Monopolies are not, and have never been, illegal.
Where did I say that monopolies are "illegal" in the US? I said that the monopoly is a problem.
In fact, many monopolies are well-supported by governments (think about your cable carrier -- chances are, there's only one in your area, and if you want cable you don't get a choice).
Yes, and those monopolies are usually regulated. Microsoft is not regulated. Regulation of monopolies is one way of reducing their negative effects.
Monopolies only become a problem when they are used to impose consumer-harming conditions.
Yes, like charging too much money or stifling innovation. You know, like what Microsoft id doing.
Your XP Home example is bad, as the price of Windows XP Home is right on par with the price for Windows ME, 95, 98, 3.1, etc.
While Mono is cool project and, like many developers, one I've been following since it's inception, I don't see it ever overtaking Java, or.Net for that matter. It's a simple matter of resources.
No, it's a matter of monopolies. Sun would like to establish a Java monopoly analogous to Microsoft's Windows monopoly. If they succeed, you are right, Mono won't overtake it. Sun will have finally succeeded in making GUIs proprietary again, as they have tried for two decades. Let's hope it won't come to that.
I agree that Rotor is not open source. But the Rotor license explicitly disclaims any claims over things you learn from looking at the source code. So, you can read the Rotor source code and then go write your own CLR if you like.
Some of the Sun Java source licenses (there are several), in contrast, pretty much come down to that anything you do after looking at Sun's source code may be considered a derived work.
The Rotor license is not open source, but harmless. The Sun license, on the other hand, is a serious problem.
...is that Sun allows Java to wallow in limbo until its development becomes unsustainable and people start using other languages and development environments like.NET, and then make it open source because it became a black hole for them.
No, that's not the worst thing that could happen. The worst thing would be that Sun starts trying to make revenue from their Java code and implementations and starts copyright, license, and patent infringement lawsuits against the numerous competing open source projects. They certainly have the license restrictions and patent portfolio to do it. That could go as far as Sun claiming that anything ever done by anybody who has downloaded the Java source code is a derived work and belongs to them; it would be a kind of super-SCO claim, and unlike SCO, Sun would actually have a legal basis for making that claim.
in previous discussion, those opposed OpenSource Java suggested that with MS's domination today, MS can easily 'improvised' OSJava to become a run-on-windows-only-OS-Java (WOOSJAVA).
They don't need Sun's source code or Sun's permission for that. In fact, they have already done it: it's called C# and CLR. They even provide extensive Java compatibility and migration tools.
it doesn't matter if anyone else is going to benefit from/use/modify this WOOSJAVA, most likely it will just be preinstalled in all Windows shipped.
You seem to have been asleep; it already is preinstalled.
and regardless of what others may like to think, most consumers of MS will think that this WOOSJAVA is now the standard.
They already do: it's called.NET. However, Microsoft can't call it "WOOSJAVA" because that would be a trademark violation. Sun can continue to protect their trademark even if they give away the code.
so in the end, maybe even Sun needs to write things to accomodate this WOOSJAVA in order to survive, that'll be ironic.
Yes, I fully expect Sun to support C# and CLR over the next few years: they won't have a choice.
Unsafe constructs would risk punching huge holes through Java's nice safe sandbox.
Those holes already exist: they are called JNI. They just happen to be a lot less safe, less efficient, and less convenient to use than C#'s well-defined unsafe constructs.
And precompilation would probably mean that compiled code gets distributed rather than bytecode; 'Write Once, Run Anywhere' doesn't mean much if you can't get hold of anything you can run!
Well, since Java doesn't actually deliver "Write Once, Run Anywhere", that objection is hypothetical. Even if it did, I really just don't care about "write once, run anywhere". Sun's monomaniacal insistence on WORA is one of the features that has made Java increasingly unattractive.
Slashdot Mirror
What Verisign's action means is that they return a different kind of result for non-existent domains. That's an annoying, one-sided change to technical standards, but apparently, they are not going to budge.
OK, so why not just modify DNS client software to recognize the bogus DNS entries as an authoritative non-response and have them behave as before?
If Verisign persists and tries to mask those domains really well, this may, of course, require trying to connect to the bogus site, but in that case, Verisign is just paying for a lot of bandwidth for advertising without getting any eyeballs for it.
Of course, he has to get SuSE installed first, which should be fairly easy as there are plenty of online distros that you can install via FTP
No, that's wrong. You buy the official distribution and stick the DVD into the drive.
But you better hope the installer picks up your NIC on the first try, otherwise you have to wade through a list of drivers to find one for his card.
One always hopes that when one installs an OS on some PC, whether that OS is RedHat, SuSE, or Windows.
Of course, over the last two years, every Linux installer that I have run has always detected and configured all graphics, audio, and networking hardware, which is a lot more than I can say for the $200 copy of Windows XP. Last time I tried to install Windows XP on a new PC ("Designed for Windows XP"), the Windows installer just hung during hardware detection; it took fiddling with BIOS settings to go through. SuSE did just fine on the same hardware.
If he finds one that might work, he'll then be prompted with a dialouge asking for arguments, with no explination as to what those are. Eventualy, you'll find one that will install with no args, and everything will work, but it's just another example of what the original article was talking about.
If you don't want to have to worry about this sort of thing, buy Linux-certified hardware. There is plenty of it out there.
If you try to install Linux on hardware that is not certified for running Linux, you take your chances. But, in practice, if you pick a distribution with a good installer, chances are that your Linux install experience will still be better than your Windows XP install experience. In fact, Windows installation has become so problematic that most Windows users don't install it at all anymore--they have it installed at the store, or they get a "restore CD" specific to their hardware.
Stop bullshitting and stop blaming Linux because you choose to make your life difficult yourself.
Its not the point of what he was using. Either way what he was using was not user friendly at all
But you can't blame Linux or open source for the screw-ups of a particular vendor (apparently RedHat, in this case).
Everytime I try to convince myself to switch I run into a situation similar to what Mr. Raymond ran into. I find myself doing to much work to do simple things and I simply dont have the time to research into it.
Switch to what? Debian? RedHat? SuSE? Lindows? Mandrake? Your experience will depend entirely on the distribution you switch to.
If you want a simple answer: in my experience, SuSE is probably the least hassle to switch to from Windows, both in terms of installation and UI. It may be a good way of getting started if you want to switch to some form of Linux system.
Either I can take his side and be called an idiot because I'm sure someone will claim to have an easy solution to my problem.
Short answer: pick a distribution that is better adapted to your needs. Printer configuration for CUPS worked like a charm with SuSE, for example--far more intuitive than Windows.
CUPS has a built-in configuration tool (http://localhost:631/), which at least works consistently across platforms and is fairly usable.
Finally, you can try to use Webmin. It's not a great UI, but, again, it's consistent and predictable across distributions, and most of its modules are fairly usable.
No, he is clearly not talking about the built-in CUPS GUI. The fact that the web interface has some common features shouldn't be surprising, after all SMB printers need to be configured no matter what UI you use to configure them. His GUI problems are a problem with the distribution he is using.
Don't let the fear of something that might happen be a basis to steal something away from someone that has been working hard on something.
Nobody wants to "steal" anything away from Sun. If Sun presented Java as just another proprietary platform, nobody would ask them to do anything. But Sun is presenting it as the alternative to Windows and the friend to open source. If they want the help of the open source community, they have to listen to the demands of the open source community; they don't get something for nothing.
Sun has invested a lot in Java and has been a good custodian of it.
I disagree. Sun may have invested a lot in Java, but that pales in comparison to the amount of work and investment others have made in Java.
I also don't think that Sun has been a good custodian. They have been looking out for their own corporate interests, not for the interests of the Java community. And they have made horrendous technical blunders.
understand that "Java" currently has a lot more credibility than "Linux" where Sun is pushing the technology.
I disagree. I think attaching the name "Java" taints the technology. Apart from that, it is simply dishonest because it is not, in any normal sense of the word, a "Java desktop".
The open source community doesn't need Sun to open source java but they do need to get sun to open up their licensing a little bit. Focus on that and take advantage of what benefits that will bring.
Oh, there, I fully agree. I think Sun's Java implementation is a lost cause. Who would possibly want to deal with that mess? However, if Sun open sources their own implementation, they have to loosen up the licensing to the point where other people can open source their implementations as well.
In any case, IBM doesn't want Sun to open source Sun's implementation, IBM wants permission from Sun to open source IBM's implementation, which requires Sun to loosen up their licensing. That is what this is all about.
I don't understand this. If you write a computer language, say C, that meets an ANSI standard, but publish it under the GPL, then haven't you created a product that is required to comply with a standard and yet which is also open source?
There is no enforcement for the ANSI C standard. You can implement 20% or 70% or 90% or 100% of the ANSI C standard. You can change the way printf, #include, or "if" work. It's up to you. You can even call the result "a C compiler" and nobody can take you to court.
In contrast, Sun attempts to enforce the Java standard. If you implement 90% of the Java standard and fiddle around with java.io, you are in violation of the license you agreed to for the Java specification. Furthermore, the 90% you implemented probably step on some of Sun's patents, and they are telling you in no uncertain terms that if you don't comply 100% with the Java standard, you have no right to use any of their patents. The way the license looks, your obligation to comply is independent even of whether you call the result Java or anything else.
And Sun is serious about this: Microsoft J++ was not acceptable to Sun because it wasn't 100% Java compatible and so Sun went after them legally. Sun has both the desire and the power to try to enforce 100% Java compatibility, and that is fundamentally different from something like ANSI C.
Well, nobody is stopping JWZ from switching to Windows or Macintosh. I think he'll find out that the grass is not greener.
On Windows, you get media players battling it out for control of your media. You get video playback that fails for no apparent reason. Something as simple as playing a hard disk mirror of a DVD can be nearly impossible (unless you install the same OSS s/w you'd run on Linux as well).
And on Macintosh, Apple likes to limit what you can and cannot do with video. Want to load clips into iMovie and assemble them? Sorry, no can do--pay a lot more $$$ to get the professional stuff. And "professional" means lots of messy, complex buttons and features that are harder to learn than the OSS command line switches.
It's simple: use what works best for you. Linux is popular because for many people, it simply works best. Windows is also popular because for many other people it works best. Those are depressing statements about the state of software.
Rather than ranting, JWZ could try to improve things for a change: he clearly has sufficient technical expertise, but he seems to lack the will and the GUI design skills to actually do anything.
ESR has little experience with configuring printers under Windows. It can be an absolute nightmare: networked printers are installed by making them local printers and then entering an IP address for the port number, local printers plugged into USB fail to be recognized, you have to select from zillions of nearly identical printer models, etc.
The way Aunt Tillie gets this to work on Windows is that she calls up Johnny, the good little nerd, treats him to her chocolate cookies, and has him suffer through this problem.
CUPS itself, for all its internal messiness, can easily presented with a better UI: Apple is using CUPS for OSX (even Apple's GUI is somewhat confusing for non-geeks), and how easy or difficult printer installation is on Linux depends more on the distribution and the UI it has chosen than on whether you use CUPS or LPRNG. CUPS also comes with an internal GUI (web-based) that is semi-decent.
Sounds like the distribution ESR uses (RedHat?) has a bad printer installation GUI, one that actually is worse than what CUPS comes with; he should complain to his distribution vendor--that has nothing to do with CUPS or OSS.
I understand the frustration with a lot of OSS GUIs, but in my experience, Windows GUIs are no better, and often worse.
if i take the specs,
If you take the specs, you agree to the licenses under which Sun releases the specs. That might be avoidable by trying to reverse engineer the specs from other published sources, but you can't take Sun's specs. And it's questionable whether anybody who has ever looked at Sun's specs can be free of their obligations to Sun.
i should think i don't have to license anything from anyone.
In addition to the strings attached to the specification, Sun also holds patents related to Java. They let you use those patents for free only if you agree to their conditions.
maybe this is why so many c compilers fail to implement the entire ansi-c standard?
Compilers implement what their users want them to implement. If many compilers fail to implement C9x features or ANSI trigraphs, then perhaps it's because users don't want those features. Seems quite reasonable to me. Overall, I have had far fewer problems with incompatibilities among C compilers from different vendors (!) than just with Sun's Java implementation across different platforms and versions.
extending the standard is one thing, but not being required to implement selective parts of it is not a good reputation to have.
Quite to the contrary: I think it is great when the market cuts standards back down to size. Java would be far less bloated and considerably more competitive if such market mechanisms had been allowed to operate from the beginning. In fact, Java shouldn't even have been a single standard: most of its APIs should have become separate standards from the core language and runtime.
This will only happen (in a bad way) if Sun are neglecting Java development and not doing things people want.
Why do you think they are so afraid of opening up the platform? They know that they aren't doing a good job, so they try to hang on to it through legalities rather than leadership.
The JVM isn't the problem. There are a handful of good, open source JVMs already. The problem is the bulk of the Java APIs, foremost Swing. The problem is also the patents that Sun holds on parts of Java. IBM itself is under additional contractual obligations to Sun.
What IBM is actually saying in this letter is pretty much this: IBM wants to open source their Java implementation, but they need the an OK from Sun to do it.
No, open source zealots are claiming that they aren't going to use or support Sun Java unless Sun open sources it. Whether Sun cares about that or not is up to Sun. Given how much Sun keeps proclaiming that they are friends of open source, apparently Sun does care how the open source community perceives them.
If Java were marketed as the proprietary product it is, few people would give a damn whether it was opened up.
Oops--sorry, left out the second part of the argument.
What the license situation means is that if Sun itself actually released something under a true open source license themselves, they would logically have to have given up their other restrictions. So, yes, for Sun to release an open source Java would only be meaningful if they also opened the spec.
Well, if Sun open sourced their implementation of Java, that wouldn't automatically make it an open standard. Sun would still control the spec.
No. As long as Sun has conformance requirements in the licenses that are attached to the specifications and as long as Sun hold patents on parts of the functionality specified by Java, no Java implementation can be truly open source. Implementations like Kaffe happen to come with an open source license attached, but they only exist because Sun tolerates them--for now. Strictly speaking, the licenses on those implementations may be invalid, and/or Sun may make patent claims against them.
What I wonder is why doesn't IBM just open source their own implementation, or is it based on Sun's code?
Of course, it's based on Sun's code. For example, there is only a single implementation of Swing in existence: Sun's. All others are derived from that.
Nevertheless, I just dont understand what opening Java is supposed to mean?
I think few people do.
ANSI-Java?
Yes, effectively. The only way any open source implementation of Java are above question would be if Sun actually drops their formal conformance requirements.
Note that you can do with ANSI C whatever you like: you can implement or not implement whatever parts you like. Not so with Java under the current licenses.
I don't get it, anyone can make their own JVM and release it as a Java JVM long as it conforms to the JLS right!?
Any implementation that has enforceable "conformance" requirements placed on it cannot be an open source implementation. Enforceable conformance requirements are intrinsically incompatible with what people mean by "open source".
IBM has already done this right?
No. IBM's implementation is derived from Sun's implemetation. But even if it had been written from scratch, IBM could not actually release it under an open source license without technically violating their license from Sun (whether Sun would tolerate that is another question--they have tolerated many violations of their licenses already, but they have also enforced some).
It is impossible for Sun to guarantee WORA and at the same time for open source implementations to be developed. It just doesn't make sense: the whole idea behind open source is that people can take the code for some software system, modify it so that it works more to their taste, and redistribute the result. Sun's compatibility requirements kill that.
So, let's just be clear about this: if IBM distributes a Java implementation under an actual open source license, then that means that Sun must have changed their licenses so that they can't guarantee WORA anymore and so that neither Sun nor the JCP have any special control over the direction of the Java platform anymore.
Almost every licence I know (IANAL) is confusing and subject to interpretation, even GPL.
.NET APIs are unquestionably open and can be freely implemented. Furthermore, Rotor clearly does not contaminate you because its license explicitly guarantees you that it does not.
Sure, but the way in which the GPL is confusing is different from the way Sun's licenses are confusing. At issue is a specific and crucially important area in which Sun's license is unclear.
Furthermore, the GPL gets updated periodically in response to input to try to make it clearer, but while Sun has changed their licenses, they have left the contamination and compliance clauses as vague and dangerous as always. The only conclusion we can have is that they want it that way: they want to be able to say one thing ("Java is open") but still have the option to pursue a different legal course.
JCP has agreed in the past that open source implementations should be accepted,
I have no idea what that statement is supposed to mean. JCP isn't a person, and "agreeing" has no legal force if it isn't written in the licenses.
This kind of on-going vagueness is exactly the problem with Sun: they talk a lot and promise a lot, but they deliver much less in writing.
The fact is that, under the current set of licenses, there cannot be a fully open source implementation of Java because Sun effectively can always gain control over any such implementation.
And Sun is quite proud of this, too: it's their stated policy to guarantee WORA across all implementations. That policy is fundamentally incompatible with open source or independent implementations. And it sums up the problem with Java: Sun's standards suck, yet they have the power to enforce them and do so.
which is more than you can say of MS.
No, it is less than you can say of MS. C#, the CLR, and large parts of the
That's not so; this week at Javalobby Sun JCP Director Onno Kluyt states that looking at Java sources does not taint
What Onno Kluyt says on Javalobby is legally irrelevant. What matters is what the license says and the license says you are tainted. And that's not hypothetical either: Sun has caused other companies problems with those clauses.
and is willing to answer FSF questions on the issue.
If Sun's licenses require Onno Kluyt to answer questions, then Sun's license is not written clearly enough. Sun needs to fix their licenses, not try to explain away deficiencies in their licenses in legally non-binding PR talk.
Sun likes to talk a lot of PR talk, but they are unwilling to address concerns by putting their licenses in clear, unambiguous terms. And after half a dozen years of waffling on legal issues, one has to conclude that Sun isn't ever going to fix these legal problems.
Besides, at this point, there isn't any reason to look at Sun's source code anymore anyway. There is nothing of technical interest in Sun's source code, and in practical terms, Sun's legal control over the Java standard and their Java-related patents mean that trying to create an open source implementation of Java is pointless anyway.
Let me first say that I don't know Japan's antitrust legislation, but at least here in the US you're absolutely and completely wrong. Monopolies are not, and have never been, illegal.
Where did I say that monopolies are "illegal" in the US? I said that the monopoly is a problem.
In fact, many monopolies are well-supported by governments (think about your cable carrier -- chances are, there's only one in your area, and if you want cable you don't get a choice).
Yes, and those monopolies are usually regulated. Microsoft is not regulated. Regulation of monopolies is one way of reducing their negative effects.
Monopolies only become a problem when they are used to impose consumer-harming conditions.
Yes, like charging too much money or stifling innovation. You know, like what Microsoft id doing.
Your XP Home example is bad, as the price of Windows XP Home is right on par with the price for Windows ME, 95, 98, 3.1, etc.
Yes, and those were way overpriced as well.
Linux?? A threat to Solaris/AIX/Windows??
.Net for that matter. It's a simple matter of resources.
Gnome?? A threat to CDE??
X11?? A threat to NeWS/OpenWindows??
GNU C?? A threat to Sun's C compiler??
While Mono is cool project and, like many developers, one I've been following since it's inception, I don't see it ever overtaking Java, or
No, it's a matter of monopolies. Sun would like to establish a Java monopoly analogous to Microsoft's Windows monopoly. If they succeed, you are right, Mono won't overtake it. Sun will have finally succeeded in making GUIs proprietary again, as they have tried for two decades. Let's hope it won't come to that.
I agree that Rotor is not open source. But the Rotor license explicitly disclaims any claims over things you learn from looking at the source code. So, you can read the Rotor source code and then go write your own CLR if you like.
Some of the Sun Java source licenses (there are several), in contrast, pretty much come down to that anything you do after looking at Sun's source code may be considered a derived work.
The Rotor license is not open source, but harmless. The Sun license, on the other hand, is a serious problem.
...is that Sun allows Java to wallow in limbo until its development becomes unsustainable and people start using other languages and development environments like .NET, and then make it open source because it became a black hole for them.
No, that's not the worst thing that could happen. The worst thing would be that Sun starts trying to make revenue from their Java code and implementations and starts copyright, license, and patent infringement lawsuits against the numerous competing open source projects. They certainly have the license restrictions and patent portfolio to do it. That could go as far as Sun claiming that anything ever done by anybody who has downloaded the Java source code is a derived work and belongs to them; it would be a kind of super-SCO claim, and unlike SCO, Sun would actually have a legal basis for making that claim.
in previous discussion, those opposed OpenSource Java suggested that with MS's domination today, MS can easily 'improvised' OSJava to become a run-on-windows-only-OS-Java (WOOSJAVA).
.NET. However, Microsoft can't call it "WOOSJAVA" because that would be a trademark violation. Sun can continue to protect their trademark even if they give away the code.
They don't need Sun's source code or Sun's permission for that. In fact, they have already done it: it's called C# and CLR. They even provide extensive Java compatibility and migration tools.
it doesn't matter if anyone else is going to benefit from/use/modify this WOOSJAVA, most likely it will just be preinstalled in all Windows shipped.
You seem to have been asleep; it already is preinstalled.
and regardless of what others may like to think, most consumers of MS will think that this WOOSJAVA is now the standard.
They already do: it's called
so in the end, maybe even Sun needs to write things to accomodate this WOOSJAVA in order to survive, that'll be ironic.
Yes, I fully expect Sun to support C# and CLR over the next few years: they won't have a choice.
Unsafe constructs would risk punching huge holes through Java's nice safe sandbox.
Those holes already exist: they are called JNI. They just happen to be a lot less safe, less efficient, and less convenient to use than C#'s well-defined unsafe constructs.
And precompilation would probably mean that compiled code gets distributed rather than bytecode; 'Write Once, Run Anywhere' doesn't mean much if you can't get hold of anything you can run!
Well, since Java doesn't actually deliver "Write Once, Run Anywhere", that objection is hypothetical. Even if it did, I really just don't care about "write once, run anywhere". Sun's monomaniacal insistence on WORA is one of the features that has made Java increasingly unattractive.