Forum Moderators: bakedjake
Sun's latest PR releases have been conflictive messages all along.
They seem to be easily confused, too.
...splintered into different distributions like Linux, which he said creates application incompatibilities. Going the way of Linux-type licensing, he suggested, creates open source but not open standards.
There's no "application incompatibility". What exists is a difference on dependences between distros. And that's a good thing, since it gives, for example, a chance to choose between linking your app to the most stable version of a library or to the newest and fastest one.
The problem will come only if the distribution makers are unable to link the application themselves. Then the developer has two choices: link statically (with an increased executable size) or present a list of libraries needed to run the app (like in the output of ldd) and nag the buyer to install them. Make them three: supporting individually each and every setup. In any case, the developer is paying extra for the privilege of keeping its code kind of hidden.
Now to the open standards.
Sun's argument is, I quote, "that open standards enable substitution, choice and competition". It would be easier to support their case if they showed how open sourced standards do not enable those three factors. I give to them that their product does enable them, but where is the proof or even the case for their competitor's standards not being open? Or what standards are they even talking about?
If I knew what standards are they talking about maybe I would present examples of "substitution, choice and competition" - three things that in my book resume to having several applications implementing them. And that by itself would not be needed, since a proof of the *possibility* of creating those several applications would be enough for open-standarity.
On a last note one thing they don't seem to be confused on is on the fact that "open source" is not the same thing that "Free software" (with capital F). I bet a dime and two bottlecaps to Sun using some restrictive licensing.
Here's the URL
[techworld.com...]
The Solaris kernel like the Linux kernel is just another Unix kernel. SUN has been paying Licensing Fees so it seems difficult believe that SUN can now make the kernel open source.
But who knows. The origin of much of the code in all the variant kernels is murky.
A Federal Court is trying to sort out in (SCO v Novell) if SCO holds the copyright at all. SCO has won a delay in the SCO v IBM trial to attempt to settle this issue.
[crn.com...]
At the same time the red ink is flowing over at SCO.
[internetnews.com...]
"I suppose the interesting question is if Sun releases those parts of Solaris which it has developed in-house, what does that do to the code it has licensed?"
What a tangled web they have weaved.
[blogs.sun.com...]
He's asking for feedback on how Sun should handle the open source issue with Solaris. There are some pretty interesting comments so far. It's definitely one that I'll be following.
I might be in risk of losing a dime and two bottlecaps. Of course this is not Solaris but who knows...
There's no "application incompatibility". What exists is a difference on dependences between distros. And that's a good thing, since it gives, for example, a chance to choose between linking your app to the most stable version of a library or to the newest and fastest one.
Actually there very much so is application incomptability and i wrote an article on this as well as new bits on slashdot.org "glibc hell".
If you only have a binary application it is very much still a major "PITA" to support it across different distros because of the vastly different (but getting better as time goes) libraries used of which you have to basically provide a linkable application to or else you have issues.
Now if everything was nice and open source then sure you could compile it, but the beauty of solaris is that its solaris. They do a fine job of making sure what worked on 2.6 works on 2.8 solaris 9 and upcoming solaris 10 and i can move apps and clone systems off to other servers without fear of really destroying application useability.
Until linux does have a full standards body commercial apps have the DLL hell aka GLIBC hell as well as gtk hell and other "hells" they have to deal with.
I proposed actually three solutions.
Besides distro support you can compile statically (see Opera) or create a compatibility list (Opera kind of does it, too) optionally offering certification for availability of the required versions - and this has not to be a "full standards body", just a compatibility notice for your app.
This is possible because of the way the linker works: I may have a half dozen libpng versions installed right now, but the app knows the soname of the library against which was it linked, and that's all it needs.
ps. Where is your article? It may be nice to read.
