Thanks for your interesting comments. I quite agree with your conclusions as far as consumer-oriented applications are concerned. And that of course is the point of contact between Liberty Alliance and Passport.
But I find interesting your answer to the mutual authentication issue ("buyer's club"). You seem to be suggesting a world full of PGP-style bipolar relationships in which business partners are known to each other and thus have a direct way to decide how much risk (and indemnification) to take, while accepting the assertions of an authentication system owned and operated by someone else. That comports with my theory that tripolar arrangements (with "trusted third-parties") won't work, and will never work, even though some of the Liberty-Alliance diehards still hold that out as the holy grail. That's the fundamental reason something like Passport can never work.
Shibboleth is part of a suite of technologies being built around the OASIS standards. The behavior you describe (short-lived identity-assertions generated by reference to an internal authentication process) is pretty standard for SAML. To me a more fundamental problem is the cross-organizational issues. I can choose as a matter of policy to accept your assertions (the dig-sig technology required to authenticate the assertion is easy). But how do I evaluate the security policy you have around that pesky LDAP server:-)?
Liberty Alliance has been going through some transition among the senior ranks. It seems that the large consumer-oriented financial-services company that drove a lot of the initial buzz is taking some baby-steps away from the initiative. There seems to be some surprise that uptake for the L/A standards seems to be slow. Also, the vendors producing Liberty toolsets (including the open source ones) aren't maturing all that well. L/A does not truly mandate anything deeper than a fairly obvious and simplistic federation scheme to go along with those OASIS standards. Still, it's an important thing for enabling serious intra-enterprise commerce. Oh, right, we were talking about Passport! Ummm, L/A isn't the answer to widespread SSO by consumers any more than Passport was.
The SecurID algorithm's claim to fame is that the user experience is non-disruptive, since there is no C/R (some posters consider this a disadvantage), and there are no buttons to press. The algorithm has been hacked, and in any case consists of a simple hash transformation of a secret code (NOT the device serial number, as a lot of people seem to think) and the current time. The device secret is 64 bits wide and is also known to the ACE server, and that's how you set it all up. There is some straightforward intelligence on the server to deal with clock drift on both the token and the server. The hash algorithm used is proprietary ("Brainard") but SHA-1 is plenty strong enough for me. There is no real magic on the ACE server, and you could easily implement something functionally equivalent. There are some patent encumbrances regarding the use of a time-driven token but other vendors do something similar, so not sure that's a real problem. Here's the thing: who is going to make the devices? Any ideas, guys? RSA's tokens are extremely expensive, around $50 in large quantities. Can anyone think of a way to do the same thing for $10 or less?
Skype is only for kids anyway
on
Skype + Kazaa = ?
·
· Score: 3, Insightful
Until they stop dissing SIP and play nice in the sandbox with the rest of the world, kids are all they'll get.
We make an "appliance" product which is a package of applications in a locked down box. The root account is disabled and the root password is scrambled. After we ship them, NO ONE (not even us) can log in as root. There are only two user accounts, one for config and the other for upgrades. Neither one has any ability to open a "normal" shell like bash.
No one has ever complained. And we do service them 24/7/sub-1 hour.
But here's something farther out: how about contracting with someone (either the vendor or some other provider) to run the apps themselves on your behalf? How does everyone feel about that? Is there an important class of applications for which this is an acceptable option?
The question being addressed is: "does MS's implementation suffer from the double-free problem?"
"bashing" - are you referring to my use of the word "stealing"? The MIT license does not require open-sourcing of derivative works but it does require proper attribution.
Having looked at the source code (our product incorporates a KDC and we had to patch it the other day when this story broke), the double-free problem is essentially a regression that crept in a few versions ago.
Someone at MS commented a few days ago (it was picked up by cnet i think) that their "Kerberos" implementation is not vulnerable to the double free because it's their own code. But of course MIT's implementation is not GPL-licensed so MS could easily have stolen^H^H^H^H^H^H adapted it just as they did with BSD's TCP stack.
Has anyone bothered to do behavioral scanning of MS's "Kerberos" to see if it matches up with MIT's?
Windows is close to 50 million lines of code with several enormous subsystems, including.NET and the whole GUI presentation system. To integrate those systems with WinFS involves touching almost everything, with combinatorial complexity. Even with $5 billion/year to spend on developers, it was just too much to get it done and get it stable. It's probably the biggest software integration project ever attempted, by far. To disagree with one earlier post, I think MS has a pretty good idea of what they were trying to do with WinFS. It was simply too much to do.
Besides, WinFS is superfluous, since Google (and its nascent competitors) will evolve into a global implementation of the same idea. That's vastly more efficient. Hey Linux guys: make a Reiser4 plugin that accepts search-like verbs and automatically searches the Web!
Java is an evolution of the static programming model also embodied by C++. Java's most important fundamental improvement over C++ is memory management. (I'm going to ignore all the flames about insert-your-favorite-Java-feature here- my point is about *fundamental* advances not incremental ones.) My experience is that this roughly doubles the productivity of a Java team over a C++ team.
Java is uncool for the same reason that C++ is uncool. It doesn't anticipate the way you think about your problem domain, and it doesn't get out of your way. This is both good and bad. By forcing you to be explicit about failure modes and method signatures, both languages facilitate programming by large teams. (This is a feature that is not shared by C, which is arguably "cool" for other reasons.)
Java is also uncool because its syntax is ugly (but not nearly as bad as Perl.), and really prolix. But the prolixity is a by-product of its static checking of your code.
The dynamic languages (Python) and the *really* dynamic languages (Ruby) are far more "cool" because they have a magical way of getting out of your way. They do this by not sweating the details about how you call your methods and raise your exceptions until runtime. That gets to be a problem in a large team when not every developer has the same intuitions about what is to be done, or over time, when your own intuitions change.
Which is better? No obvious answer, but my bias is toward the dynamic side, favoring small teams and tight, relatively short-lived projects. That's where the economic value is.
This move was not entirely unexpected, you always give the investors' money back to them if you can't find anything better to do with it. Microsoft has always been an extremely disciplined purchaser of companies (you know what I mean if you've been f****d by them). What this is saying is that there are no really good opportunities at MSFT's current scale. It also means, if you're paying attention, that the center of gravity of tech investment (eventually becoming innovation) is moving elsewhere... FOSS is driving a secular change in our industry.
If you face the risk that you'll pay the other guy's costs, you'll think very hard about bringing a suit that is anything less than meritorious. That's true whether you're rich or poor. The effect of the English rule is to keep frivolous litigation out of court, not to keep poor people out. If you're poor and have suffered an injury (real or imagined), it's easy to find an attorney to take your case on contingency as long as the attorney thinks there's a reasonable chance that he himself stands to make a few million dollars. In the presence of the English rule, the contingency-fee bar goes away because the lawyer won't risk his own capital on the case, since his downside is much greater. That's a good thing because it restores everyone's (including the plaintiff's) incentive to keep simple cases simple and not argue them for years on end. And if you're a poor person who has truly suffered an injury, I guarantee you that you don't need someone like John Edwards to convince a jury to compensate you fairly. Does it surprise you that America is the only place where the legal system is viewed as a way to get rich quick, at the expense of shareholders of large companies and the buyers of insurance policies? However in the case of the strike suits which are the subject of this post, the argument is inapplicable anyway because the lawyers go fishing for plaintiffs after they cook up the case, not before. When people talk about making sure the poor have access to the courts, they're not talking about speculators who had a bad outcome in the stock market. These suits are fundamentally frivolous because people who play in the stock market know the risks going in. The RedHat case, and cases like it, should never have been brought.
Re:Every company has to deal with this s**t
on
Red Hat Vs. The Lawyers
·
· Score: 2, Insightful
That's called the "English system," for the sensible reason that it's how they do it in Britain. And it's a lovely idea. The counter-argument in the US, which somehow manages to convince all of the morons, it that a "loser-pays" system will somehow keep poor plaintiffs from being able to sue. It's usually the ambulance chasers and their political wing (the Democratic Party) who make this argument. I guess they're trying to make us forget that they work on contingency.
Every company has to deal with this s**t
on
Red Hat Vs. The Lawyers
·
· Score: 2, Insightful
The particular law firm is a new one on me, usually these are done by that scumbag Bill Lerach in San Diego. "Strike suits" are a basic fact of life for public tech companies. In fact, it kind of proves RH is growing up. The idea is that any sudden movement of a company's stock, in either direction, is actionable because the company presumptively withheld information that impaired the public's opportunity to either profit or avoid losses. Eventually the lawyers quietly get paid huge $$$ to go bother someone else. It's just ridiculous that judges even let this garbage into their dockets. Welcome to America.
Everybody is talking about how difficult it is to do UI. Yup, it sure is. Just ask the guys who did the classic industrial designs- the Dreyfus telephones, etc etc. Lots of examples in addition to the Kodak Brownie. The best designs become classics, and really change the way we work and live. And there really aren't all that many classics, vastly fewer than the number of designs that try and fail. So why aren't there more really classic software designs? Part of it is that all of us programmers have drunk the koolaid about uniform interface designs. They simplify learning by creating references to things previously learned in other contexts. But a real "classic design" is easy to learn because it's *internally* coherent- its reference points are meaningful in terms of its own functionality. If there is complexity, it maps directly to the problem domain and not to the UI design. That makes it far easier to deal with, because it "just makes sense." The iPod is a very interesting recent example, but I can't think of something analogous in the realm of pure software.
Maybe if we break out of the box on UI design, then we might be able to stop complaining about how stupid our users are. After all someone who uses something I wrote is supposed to be *smart* not stupid:-)
Open Source is better because it gets written to answer real needs. Proprietary stuff gets written to meet the market goals of some company- if their customers benefit, that's incidental! You can't create multiplicative economic value unless you respond to real needs. Companies trying to do something other than that will certainly lose jobs.
As long as the vast majority of personal computer offerings come with Windows pre-installed, there's no reason for people to try Linux. I know you can get an MS-free desktop *if you try hard enough* but that doesn't cover enough of the users out there to matter. We still haven't figured out what is going to tip the scales.
Re:How this plays out depends on US, not them
on
Browser Wars 2004
·
· Score: 1
No argument on the desirability of writing to a broadly supported standard. Opera, Safari and Firefox all seem fairly close to each other in terms of support for CSS, which is what matters most now. (I don't know much about K- none of our users depend on it.) But (contrary to some other posts) user communties respond VERY quickly to better mousetraps, as long as the barriers to adoption are low. If the innovations that result in a better value delivered to the users show up initially in only a few places, then they need to be supported by people like us, SO LONG as they are open and can migrate to the other platforms. That's going to drive wide adoption.
Re:How this plays out depends on US, not them
on
Browser Wars 2004
·
· Score: 1
Agreed, but often the way to build support for standards is to create "facts on the ground." Firefox and its relatives will generally acquire the early implementations of what will eventually emerge as proper standards, and that deserves our support. I grant that this is a messier and riskier process than waiting for a "kingdom of the just" to make all the right decisions and promulgate proper standards. But it's ultimately faster. That's what I meant by "this depends on us" - are you willing to get out there and take some risk? The point isn't to kill IE but to get a better browser. (IE will die as a much-desired side effect.)
How this plays out depends on US, not them
on
Browser Wars 2004
·
· Score: 1
We've already started building apps that require Firefox (mostly sysadmin, data-frontends, fat-client replacement, but also some newer SOA/utility computing apps). Primarily because it's too much of a pain to work around the CSS probs in IE. I mean, life is too short. So then our users have to make sure they have Firefox, which is damn simple to do at the end of the day. The hard thing is just to give people that little nudge. And guess what? It's working, so far. If they have use-IE policies in order to get support from their own techs, that's no problem, since this is just a helper-app download to access a required service. Just like downloading Acrobat to read PDFs. Then once the camel's nose is under the tent..... you know the rest.
People have been kicking around the half-of-600-companies-need-to-die number since the bust. The problem is too many people drank the Kool-aid and pumped public money into companies that should never have come out. Remember? These were supposed to provide the infrastructure to power the lunatic ideas at the top of the frothy crust. And it's taking a while for all of these companies to slowly burn through the last of their public money. It's astounding how many well-known names in software have enterprise values less than their cash in the bank! Just run down the list... (names withheld to protect the shareholders). All are dead men walking. A previous poster had it dead-on however- FOSS mediates a secular change in the buying patterns of enterprise IT, so there really is no need for all of that garbage. When the last of the late-90s IPO cash is burned up, they will disappear without a whimper. Flamebait: to a first approximation, there is NO software you have to pay for that can't be matched by FOSS, except for custom and narrow-niche jobs.
Java already is "forked," by Sun itself! There has never been a release that didn't break something in a prior release, with the result that shipping anything written in Java to a lot of heterogeneous users is a major hairball. You have to specify the exact Java build(s) that your code will run on, and it's up to your users (or YOU when they call you for support) to make sure that the six other back versions floating around on their machines aren't screwing you up. If you want to bundle a JRE with your code to make it idiotproof, Sun makes you take out a license. An open-source Java might pick up forks along the way, but FOSS is market-driven in the sense that only really good ideas will get and keep a following. And the best ideas will be widely supported. Look at Apache and all the others. The vast majority of "forks" are for very special purposes and don't end up stranding all that many people when they die out. On balance, open-source Java is the best of all worlds.
Does anyone have an example of a reasonable-sized organization using OpenSSL (perhaps supplemented with extra tools beyond the pathetic perl scripts) to self-sign? Seems like you could do all your intranet stuff that way.
Slashdot Mirror
Thanks for your interesting comments. I quite agree with your conclusions as far as consumer-oriented applications are concerned. And that of course is the point of contact between Liberty Alliance and Passport.
But I find interesting your answer to the mutual authentication issue ("buyer's club"). You seem to be suggesting a world full of PGP-style bipolar relationships in which business partners are known to each other and thus have a direct way to decide how much risk (and indemnification) to take, while accepting the assertions of an authentication system owned and operated by someone else. That comports with my theory that tripolar arrangements (with "trusted third-parties") won't work, and will never work, even though some of the Liberty-Alliance diehards still hold that out as the holy grail. That's the fundamental reason something like Passport can never work.
Shibboleth is part of a suite of technologies being built around the OASIS standards. The behavior you describe (short-lived identity-assertions generated by reference to an internal authentication process) is pretty standard for SAML. To me a more fundamental problem is the cross-organizational issues. I can choose as a matter of policy to accept your assertions (the dig-sig technology required to authenticate the assertion is easy). But how do I evaluate the security policy you have around that pesky LDAP server :-)?
Liberty Alliance has been going through some transition among the senior ranks. It seems that the large consumer-oriented financial-services company that drove a lot of the initial buzz is taking some baby-steps away from the initiative. There seems to be some surprise that uptake for the L/A standards seems to be slow. Also, the vendors producing Liberty toolsets (including the open source ones) aren't maturing all that well. L/A does not truly mandate anything deeper than a fairly obvious and simplistic federation scheme to go along with those OASIS standards. Still, it's an important thing for enabling serious intra-enterprise commerce.
Oh, right, we were talking about Passport! Ummm, L/A isn't the answer to widespread SSO by consumers any more than Passport was.
The SecurID algorithm's claim to fame is that the user experience is non-disruptive, since there is no C/R (some posters consider this a disadvantage), and there are no buttons to press. The algorithm has been hacked, and in any case consists of a simple hash transformation of a secret code (NOT the device serial number, as a lot of people seem to think) and the current time. The device secret is 64 bits wide and is also known to the ACE server, and that's how you set it all up. There is some straightforward intelligence on the server to deal with clock drift on both the token and the server. The hash algorithm used is proprietary ("Brainard") but SHA-1 is plenty strong enough for me.
There is no real magic on the ACE server, and you could easily implement something functionally equivalent. There are some patent encumbrances regarding the use of a time-driven token but other vendors do something similar, so not sure that's a real problem. Here's the thing: who is going to make the devices? Any ideas, guys? RSA's tokens are extremely expensive, around $50 in large quantities. Can anyone think of a way to do the same thing for $10 or less?
Until they stop dissing SIP and play nice in the sandbox with the rest of the world, kids are all they'll get.
We make an "appliance" product which is a package of applications in a locked down box. The root account is disabled and the root password is scrambled. After we ship them, NO ONE (not even us) can log in as root. There are only two user accounts, one for config and the other for upgrades. Neither one has any ability to open a "normal" shell like bash.
No one has ever complained. And we do service them 24/7/sub-1 hour.
But here's something farther out: how about contracting with someone (either the vendor or some other provider) to run the apps themselves on your behalf? How does everyone feel about that? Is there an important class of applications for which this is an acceptable option?
It's a fancy way of saying: I don't buy software licenses anymore.
The question being addressed is: "does MS's implementation suffer from the double-free problem?"
"bashing" - are you referring to my use of the word "stealing"? The MIT license does not require open-sourcing of derivative works but it does require proper attribution.
Having looked at the source code (our product incorporates a KDC and we had to patch it the other day when this story broke), the double-free problem is essentially a regression that crept in a few versions ago.
Someone at MS commented a few days ago (it was picked up by cnet i think) that their "Kerberos" implementation is not vulnerable to the double free because it's their own code. But of course MIT's implementation is not GPL-licensed so MS could easily have stolen^H^H^H^H^H^H adapted it just as they did with BSD's TCP stack.
Has anyone bothered to do behavioral scanning of MS's "Kerberos" to see if it matches up with MIT's?
Windows is close to 50 million lines of code with several enormous subsystems, including .NET and the whole GUI presentation system. To integrate those systems with WinFS involves touching almost everything, with combinatorial complexity. Even with $5 billion/year to spend on developers, it was just too much to get it done and get it stable. It's probably the biggest software integration project ever attempted, by far.
To disagree with one earlier post, I think MS has a pretty good idea of what they were trying to do with WinFS. It was simply too much to do.
Besides, WinFS is superfluous, since Google (and its nascent competitors) will evolve into a global implementation of the same idea. That's vastly more efficient. Hey Linux guys: make a Reiser4 plugin that accepts search-like verbs and automatically searches the Web!
Java is an evolution of the static programming model also embodied by C++. Java's most important fundamental improvement over C++ is memory management. (I'm going to ignore all the flames about insert-your-favorite-Java-feature here- my point is about *fundamental* advances not incremental ones.) My experience is that this roughly doubles the productivity of a Java team over a C++ team.
Java is uncool for the same reason that C++ is uncool. It doesn't anticipate the way you think about your problem domain, and it doesn't get out of your way. This is both good and bad. By forcing you to be explicit about failure modes and method signatures, both languages facilitate programming by large teams. (This is a feature that is not shared by C, which is arguably "cool" for other reasons.)
Java is also uncool because its syntax is ugly (but not nearly as bad as Perl.), and really prolix. But the prolixity is a by-product of its static checking of your code.
The dynamic languages (Python) and the *really* dynamic languages (Ruby) are far more "cool" because they have a magical way of getting out of your way. They do this by not sweating the details about how you call your methods and raise your exceptions until runtime. That gets to be a problem in a large team when not every developer has the same intuitions about what is to be done, or over time, when your own intuitions change.
Which is better? No obvious answer, but my bias is toward the dynamic side, favoring small teams and tight, relatively short-lived projects. That's where the economic value is.
This move was not entirely unexpected, you always give the investors' money back to them if you can't find anything better to do with it. Microsoft has always been an extremely disciplined purchaser of companies (you know what I mean if you've been f****d by them). What this is saying is that there are no really good opportunities at MSFT's current scale. It also means, if you're paying attention, that the center of gravity of tech investment (eventually becoming innovation) is moving elsewhere... FOSS is driving a secular change in our industry.
If you face the risk that you'll pay the other guy's costs, you'll think very hard about bringing a suit that is anything less than meritorious. That's true whether you're rich or poor. The effect of the English rule is to keep frivolous litigation out of court, not to keep poor people out. If you're poor and have suffered an injury (real or imagined), it's easy to find an attorney to take your case on contingency as long as the attorney thinks there's a reasonable chance that he himself stands to make a few million dollars. In the presence of the English rule, the contingency-fee bar goes away because the lawyer won't risk his own capital on the case, since his downside is much greater. That's a good thing because it restores everyone's (including the plaintiff's) incentive to keep simple cases simple and not argue them for years on end. And if you're a poor person who has truly suffered an injury, I guarantee you that you don't need someone like John Edwards to convince a jury to compensate you fairly.
Does it surprise you that America is the only place where the legal system is viewed as a way to get rich quick, at the expense of shareholders of large companies and the buyers of insurance policies?
However in the case of the strike suits which are the subject of this post, the argument is inapplicable anyway because the lawyers go fishing for plaintiffs after they cook up the case, not before. When people talk about making sure the poor have access to the courts, they're not talking about speculators who had a bad outcome in the stock market. These suits are fundamentally frivolous because people who play in the stock market know the risks going in. The RedHat case, and cases like it, should never have been brought.
That's called the "English system," for the sensible reason that it's how they do it in Britain. And it's a lovely idea. The counter-argument in the US, which somehow manages to convince all of the morons, it that a "loser-pays" system will somehow keep poor plaintiffs from being able to sue. It's usually the ambulance chasers and their political wing (the Democratic Party) who make this argument. I guess they're trying to make us forget that they work on contingency.
The particular law firm is a new one on me, usually these are done by that scumbag Bill Lerach in San Diego.
"Strike suits" are a basic fact of life for public tech companies. In fact, it kind of proves RH is growing up.
The idea is that any sudden movement of a company's stock, in either direction, is actionable because the company presumptively withheld information that impaired the public's opportunity to either profit or avoid losses. Eventually the lawyers quietly get paid huge $$$ to go bother someone else.
It's just ridiculous that judges even let this garbage into their dockets. Welcome to America.
Everybody is talking about how difficult it is to do UI. Yup, it sure is. Just ask the guys who did the classic industrial designs- the Dreyfus telephones, etc etc. Lots of examples in addition to the Kodak Brownie.
:-)
The best designs become classics, and really change the way we work and live. And there really aren't all that many classics, vastly fewer than the number of designs that try and fail.
So why aren't there more really classic software designs? Part of it is that all of us programmers have drunk the koolaid about uniform interface designs. They simplify learning by creating references to things previously learned in other contexts. But a real "classic design" is easy to learn because it's *internally* coherent- its reference points are meaningful in terms of its own functionality. If there is complexity, it maps directly to the problem domain and not to the UI design. That makes it far easier to deal with, because it "just makes sense." The iPod is a very interesting recent example, but I can't think of something analogous in the realm of pure software.
Maybe if we break out of the box on UI design, then we might be able to stop complaining about how stupid our users are. After all someone who uses something I wrote is supposed to be *smart* not stupid
Open Source is better because it gets written to answer real needs. Proprietary stuff gets written to meet the market goals of some company- if their customers benefit, that's incidental!
You can't create multiplicative economic value unless you respond to real needs. Companies trying to do something other than that will certainly lose jobs.
As long as the vast majority of personal computer offerings come with Windows pre-installed, there's no reason for people to try Linux. I know you can get an MS-free desktop *if you try hard enough* but that doesn't cover enough of the users out there to matter. We still haven't figured out what is going to tip the scales.
No argument on the desirability of writing to a broadly supported standard. Opera, Safari and Firefox all seem fairly close to each other in terms of support for CSS, which is what matters most now. (I don't know much about K- none of our users depend on it.) But (contrary to some other posts) user communties respond VERY quickly to better mousetraps, as long as the barriers to adoption are low. If the innovations that result in a better value delivered to the users show up initially in only a few places, then they need to be supported by people like us, SO LONG as they are open and can migrate to the other platforms. That's going to drive wide adoption.
Agreed, but often the way to build support for standards is to create "facts on the ground." Firefox and its relatives will generally acquire the early implementations of what will eventually emerge as proper standards, and that deserves our support. I grant that this is a messier and riskier process than waiting for a "kingdom of the just" to make all the right decisions and promulgate proper standards. But it's ultimately faster. That's what I meant by "this depends on us" - are you willing to get out there and take some risk? The point isn't to kill IE but to get a better browser. (IE will die as a much-desired side effect.)
We've already started building apps that require Firefox (mostly sysadmin, data-frontends, fat-client replacement, but also some newer SOA/utility computing apps). Primarily because it's too much of a pain to work around the CSS probs in IE. I mean, life is too short. So then our users have to make sure they have Firefox, which is damn simple to do at the end of the day. The hard thing is just to give people that little nudge. And guess what? It's working, so far. If they have use-IE policies in order to get support from their own techs, that's no problem, since this is just a helper-app download to access a required service. Just like downloading Acrobat to read PDFs. Then once the camel's nose is under the tent..... you know the rest.
People have been kicking around the half-of-600-companies-need-to-die number since the bust. The problem is too many people drank the Kool-aid and pumped public money into companies that should never have come out. Remember? These were supposed to provide the infrastructure to power the lunatic ideas at the top of the frothy crust. And it's taking a while for all of these companies to slowly burn through the last of their public money. It's astounding how many well-known names in software have enterprise values less than their cash in the bank! Just run down the list... (names withheld to protect the shareholders). All are dead men walking. A previous poster had it dead-on however- FOSS mediates a secular change in the buying patterns of enterprise IT, so there really is no need for all of that garbage. When the last of the late-90s IPO cash is burned up, they will disappear without a whimper. Flamebait: to a first approximation, there is NO software you have to pay for that can't be matched by FOSS, except for custom and narrow-niche jobs.
Java already is "forked," by Sun itself! There has never been a release that didn't break something in a prior release, with the result that shipping anything written in Java to a lot of heterogeneous users is a major hairball. You have to specify the exact Java build(s) that your code will run on, and it's up to your users (or YOU when they call you for support) to make sure that the six other back versions floating around on their machines aren't screwing you up. If you want to bundle a JRE with your code to make it idiotproof, Sun makes you take out a license.
An open-source Java might pick up forks along the way, but FOSS is market-driven in the sense that only really good ideas will get and keep a following. And the best ideas will be widely supported. Look at Apache and all the others. The vast majority of "forks" are for very special purposes and don't end up stranding all that many people when they die out.
On balance, open-source Java is the best of all worlds.
Does anyone have an example of a reasonable-sized organization using OpenSSL (perhaps supplemented with extra tools beyond the pathetic perl scripts) to self-sign? Seems like you could do all your intranet stuff that way.