Analysts on OpenSolaris

There's been a lot of press about Sun recently thanks to our Network Computing 04Q3 event. It's hard to miss some of the coverage out there. Jim pointed out this article over at eWeek, which has some good suggestions, but also some gross misconceptions. I thought I'd look at some of the quotes and respond, as a Solaris kernel developer, and explain what OpenSolaris really means and why we're doing it.

First, there is the obligatory comment about Linux vs. Solaris within Sun. John Loiacono explained some of the reasons why we're investing in Solaris rather than jumping on the Linux bandwagon. To which Eric Raymond responded:

The claim that not controlling Linux limits one's ability to innovate is a load of horse puckey ... In open source, you always have that ability, up to and including forking the code base, if you don't like the way things are being run.

Taken out of context, this seems like an entirely reasonable position. But when you put it in the context of OpenSolaris vs. Linux, it quickly becomes irrelevant. The main reason we can't just jump into Linux is because Linux doesn't align with our engineering principles, and no amount of patches will ever change that. In the Solaris kernel group, we have strong beliefs in reliability, observability, serviceability, resource management, and binary compatibility. Linus has shown time and time again that these just aren't part of his core principles, and in the end he is in sole control of Linux's future. Projects such as crash dumps, kernel debuggers, and tracing frameworks have been repeatedly rejected by Linus, often because they are perceived as vendor added features. Not to mention the complete lack of commitment to binary compatibility (outside of the system call interface). Kernel developers make it nearly impossible to maintain a driver outside the Linux source tree (nVidia being the rare exception), whereas the same apps (and drivers) that you wrote for Solaris 2.5.1 will continue to run on Solaris 10. Large projects like Zones, DTrace, and Predictive Self Healing could never be integrated into Linux simply because they are too large and touch too many parts of the code. Kernel maintainers have rejected patches simply because of the amount of change (SMF, for example, modified over 1,000 files). That's not to say that Linux doesn't have many commendable principles, not the least of which is their commitment to open source. But there's just no way that we can shoehorn Solaris principles into the Linux kernel.

Of course, as Eric Raymond says, we could create a fork of the Linux kernel. But this idea lies somewhere between idealistic and completely ludicrous. First of all, there's the sheer engineering effort. Even after porting all the huge Solaris 10 (and 9, and 8 ...) features to a branch of the Linux kernel, we would enter into a perpetual game of "catchup" with the main branch. We'd be spending all of our time merging patches and testing rather than innovating. With features such as guaranteed binary compatibility, it may not even be possible. Forget the fact that such a fork would probably never be accepted by the Linux community at large. The real problem with creating a fork of the Linux kernel is simply that the GPL doesn't align with our corporate principles. We want to have ISVs embedding Solaris in their set-top box without worrying about how to dance around the GPL while keeping their IP private. Even if you can tiptoe around the issue now by putting your code in a self-contained module, the Linux kernel developers could actively work against you in the future. Of course, we could still choose a GPL compatible license for OpenSolaris, at which point I'll end up eating my words.

In the end, dumping Solaris into Linux makes no sense, either technically or philosophically. I have yet to hear a convincing argument of why ditching Solaris would be a good thing for Sun. And I can't begin to imagine justification for forking the Linux kernel. To be clear, we're not out to rule OpenSolaris with an iron fist. Because we own our intellectual property, we can make a licensing decision that reflects our corporate goals. And because we've put all the engineering effort behind that IP, we can instill similar beliefs into the community that we spawn. These beliefs may change over time: we would love to see a OpenSolaris community where we are merely a participant in a much larger game. But we'll be able to build a foundation with ideas that are important to us, and fundamentally different from those of the Linux community.

Getting back to the article, we have another quote from Gary Barnett from Ovum:

If Sun releases only Solaris for SPARC with a peculiar open-source license that's not compatible with the GPL, it's not going to be a big deal. All you'll get is the right to help Sun improve its software ... If they produce a license that's not in the spirit of the open-source community, they won't do themselves any favors at all

It's hard to know where to begin with statements like these. First and foremost is the idea that we will release Solaris "only for SPARC". No matter how many times we say it, people just don't seem to get it. Both x86 and SPARC are built from the same source! There is a very small bit of Solaris that is platform specific, and is scattered throughout the codebase such that it would be impossible to separate. Second, we've already stated that the license will be OSI compliant. I can't elaborate on specifics, and whether it will be GPL compatible, but it really shouldn't matter as long as it has OSI approval. The GPL is not the be-all, end-all of open source licenses. There are bad aspects of the GPL, and not every project in the world should use it. If we do end up being GPL-incompatible, the only downside will be that you cannot use the source code in Linux or another GPL project. But why must everything exist to contribute to Linux? I can't take Linux code and drop it into FreeBSD, so why can't the same be true with OpenSolaris? Not to mention the many benefits of being GPL-incompatible, like being able to mix OpenSolaris code with proprietary source code.

Most importantly, contributors to OpenSolaris won't just be helping "Sun improve its software." By nature of making it open source, it will no longer be "our software". All the good things that come with an OSI license (right to use, fork, and modify code) will prevent us from ever owning OpenSolaris. If you contribute, you will helping improve your software, which you can then use, modify, or repackage to your heart's content. You will be part of a community. Yes, it won't be the Linux community. But it will be a community you can choose to join, either as a developer or a user, as alternative to Linux.

Sun is hoping that making source code available will cause a community as large, as diverse and as enthusiastic as that around Linux to gather around Solaris. Just offering source code is not enough to create such a community. Sun would need to do a great deal of work to make that happen.

Now here's a comment (by Dan Kusnetzky of IDC) that actually makes sense. He understands that we are out to create a community. Like us, he knows that just throwing source code over the wall is not enough. He has good suggestions.

And we're listening. We have been researching this project for a very long time. We have talked to numerous customers, ISVs, and open source leaders to try and define what makes a community successful. Clever people have already noticed that we have begun a (invite only) pilot program; several open source advocates are already involved in helping us shape a vision for OpenSolaris. Creating a community doesn't happen overnight. We are gradually building something meaningful, being sure to take the right approach at each step. The community will evolve over time. And I'm looking forward to it.

Comments:

[Trackback] Eric Schock has written a very well considered blog entry on what oeople have been saying about Open Solaris and addresses some misconceptions. It's definitely worth a read.

Posted by Alan Hargreaves' Weblog on September 21, 2004 at 06:48 PM PDT #

[Trackback] Wieder etwas neues zu SMF:Predictable Zum Thema Opensolaris hat Eric Schrock einen sehr guten Artikel geschrieben:Eric Schrock's Weblog. Woebei er die Gelegenheit nutzt, gleich einmal mit einigen Missverstaendnissen aufzuraeumen. It is definitely wor...

Posted by c0t0d0s0.org on September 21, 2004 at 07:28 PM PDT #

Finally someone in this community realizes the perils of the GPL and the massive maturity differences between Solaris 10 and Linux 2.6. I hope Sun as a whole is as lucid about this as you are. /kristofer

Posted by N/A on September 21, 2004 at 09:54 PM PDT #

There is absolutely nothing wrong with the GPL. GPL works to protect the individual developer who doesnt want to develop a feature for a software product only to have to pay to buy it back when he needs an evolved version of the software. That assurance is why the GPL is successful. Although Apache is not GPL'd .. there is a high level of confidence that non profit Apache foundation wont make future modified versions of their software proprietary.

Posted by Johan on September 23, 2004 at 01:42 PM PDT #

Johan -

It is quite possible to write an open source license which accomplishes what you describe without being the GPL. You can force derivative works to contribute source code back to the project without having forfeit their intellectual property. The GPL forces proprietary code that even links with GPL code to become GPL and give up any right to IP, even if you've made no changes to the code in question. This annoys a lot of our customers, and as far as we're concerned is a flaw that needs to be remedied. There are many good things about the GPL, but I'd hesitate to say there's "absolutely nothing wrong" with it. The GPL has far more restrictions on what you can and cannot do than, say, the BSD license.

Posted by Eric Schrock on September 23, 2004 at 05:22 PM PDT #

Mr Schrock,

You write: "The GPL forces proprietary code that even links with GPL code to become GPL and give up any right to IP, even if you've made no changes to the code in question."

First, as I'm sure you're aware, linking code is a fancy term for "telling a bit of software to copy some code from one program (say my GPL'd library) into your program."

If you copy my code into your program without permission, you are infringing my IP rights, unless you have permission. The only permission given is the GPL, thus you cannot take my IP without following the terms of the license.

Do you think you should be allowed to take a track from Bruce Springsteen's last album, copy into your "Best of Rock" album and sell it? Even if you don't change Bruce's track at all? Hmmm. I think the RIAA might differ with you.

Second, you write that you are forced to "give up any right to IP". That's untrue.

A programmer who licenses their code under the GPL does not loose ownership of their IP. The author still owns the copyright, patents, and trademarks.

What they do loose is the ability to gain fincancially by creating an economic scarcity.

Now, Mr. Schrock, you may want to believe that you have a right to economic gain, but sorry, you don't. That's not how capalism works. You have a right to try, but if people don't want what your selling, tough.

So, the GPL makes it impossible for software to lock people in, create false scarcity in availability of support, and create high costs of switching.

If that the "right" that you believe the GPL forces you to give up, than you're correct. However, I don't have much sympathy for your version of "rights". I think the world will be better, wealthier, and more free without your "rights".

Posted by Mark Levitt on September 23, 2004 at 08:42 PM PDT #

If we do end up being GPL-incompatible, the only downside will be that you cannot use the source code in Linux or another GPL project.

And OpenSolaris can't use any code from Linux. And in the future, that may be a problem for you.

Not to mention the many benefits of being GPL-incompatible, like being able to mix OpenSolaris code with proprietary source code.

You have a fundamental misunderstanding here. GPL-compatible != GPL (example: the BSD license.) And therefore GPL-compatible != no mixing with proprietary source code (same example: the BSD license.) So if, for example, OpenSolaris was under the BSD license, it could be used by anyone in proprietary applications, and also in Linux. Of course, the BSD might be the wrong choice for other reasons...

Gerv

Posted by Gervase Markham on September 23, 2004 at 09:13 PM PDT #

If you don't mind Solaris dyeing don't put it under the GPL, it is that simple.

The value of the words "Open source" have been devalued by the likes of Microsoft, those words alone will not save Solaris.

If you come up with a new license you have to convince the world it isn't an evil SUN plot. I think it would be fair to say SUN has burnt too much of their political capital to win quickly, and by the time they do ( if they do) the game will be finished and Solarise will be on the scrap heap along with all those other carfully developed UNIX's ( the heap is getting quite high, surly you can read the message by now).

If you put it under the BSD license you lose total control. As the GPL Is accepted by industry it would be stupid to do so.

If you put it under the GPL you will be on an equal license footing with Linux. It will then come down to the quality of the development teams. If your team is better you will win ( or at least gain market share).

You have had one post claiming the GPL is evil. There you have a Solaris advantage. Sun will be able to offer a dual license for those people that don't understand you can link through the LGPL C libaries if you want to distribute a binary application.

Red Hat can charge a good price for GPLed software because Linux has momentum. You have to build momentum quickly, messing around with a new license is not the way to do it.

Stop talking, don't stuff around with a different license, put it under the GPL and get on with it.

Posted by Charles Esson on September 23, 2004 at 10:57 PM PDT #

Oh it's fun to see the GPL zealots get their panties in knots!

Posted by Derek Morr on September 23, 2004 at 11:43 PM PDT #

Couple of links http://lwn.net/Articles/103394/ http://www.kroah.com/log/2004/09/23/#2004_09_23_sun_rebuttal

Posted by Neil Corlett on September 23, 2004 at 11:48 PM PDT #

It'll be fun to watch if it works for Sun. Best of luck, there, if it really turns out to be an OSI certified license. Sun has made various claims about opening up Solaris before, in 1999[1], going from 'open source' to 'SCSL', to 'uh, what do you mean, source code?'. But after watching Sun struggling to market SCSL as business friendly pseudo-open-source license in the last few years, I'm sceptical that Sun will just come up with yet another license that turns out to be neither open source, nor business friendly in order to 'protect' its 'crown jewels'. cheers, dalibor topic [1] http://lwn.net/1999/features/Solaris.php3

Posted by Dalibor Topic on September 24, 2004 at 12:06 AM PDT #

Charles -

Comments about LGPL libraries are pretty much irrelevant when we're discussing the Solaris kernel. As for popular acceptance, that's very true - that's why we have to go the OSI route. And we're not "just talking" - opensolaris.org is already up and running in a pilot program. This is real.

Dalibor -

Yes, it will be OSI-approved. However paranoid you may be, it's not worth discussing alternative futures.

Gervase -

While you can take code from BSD and put it in the GPL, you can't do the reverse. That's what I think of when GPL-compatible. There's really no point to being "one-way" GPL compatible.

Mark -

Yes, you still own the patents, but they're automatically freely licensed to all by putting it in GPL software. As for claims about vendor lockin, etc, that's easy to put into an OSI license without being GPL - MPL, for example. As for the rest, it's pretty much a solid demonstration of why the GPL doesn't align with our goals. Yes,the GPL has many of the properties you have stated. And I've stated that those properties don't necessarily align with our goals. Whenever you get into the fanatical side of the GPL, you forget that what works for you doesn't work for everyone.

Posted by Eric Schrock on September 24, 2004 at 01:23 AM PDT #

Further comments on GPL issues should be directed here. I will address some of questions raised about non-license issues soon, but feel free to comment in the meantime.

Posted by Eric Schrock on September 24, 2004 at 03:09 AM PDT #

Thanks for the reassurance, Eric. Does that mean that Sun is going to pick an already OSI-approved license, or does it mean that Sun will try to get a license of their own OSI-approved?

Posted by Dalibor Topic on September 24, 2004 at 03:10 AM PDT #

Dalibor - >As an engineering group, I know what we want out of our license. Unfortunately, the discussions of licensing specifics are hapenning way above my head, and not something I could share publicly anway. About all I know is that it will be OSI approved, or OpenSolaris will be dead before it gets out the door (as you correctly stated). I'm as anxious as you are to see the license out in the public so we can both stop fantasizing about what may or may not be :-)

Posted by Eric Schrock on September 24, 2004 at 03:17 AM PDT #

[Trackback] A couple of very interesting posts on Eric Schrock's Weblog First about the GPL in GPL thoughts and clarifications. I wonder which licenses Eric is thinking of in his #2 (LGPL is the nearest I can think of but it

Posted by 42 on September 25, 2004 at 03:44 AM PDT #

<h3>Solaris<h3>

Thank you for responding, it is an issue I care about. It would be nice if an OS developed against a different set of engineering goals survived. I like the goals set by the SUN engineering team ( that is not to say I can't live with the goals set by the Linux team) so I will have another go.

Your right, the LGPL doesn't matter when talking about the kernel code. It only matters in userland. That is why users that go on about Linux and the GPL are simple miss-informed. With Linux the boundary is the trap API. Linux works because a user land binary application can link to LGPL code, and the LGPL code can use the OS trap API. We need to get this issue clear, I am sure traditional Unix marketing departments will try to distort the situation but for this discussion to be useful it needs to stick to the facts.

So for the kernel code we are talking GPL, and only the GPL, what does that mean for SUN. SUN can open up the code and someone else can't close the improvements and use the improvements against them. It is that simple. I see no reason to give a more generous license, why let others use your work against SUN. The GPL has been accepted by the market; why give more?

To release Solaris under a more restrictive license is to give linux a license advantage. I think the mountian of discarded Unix's is high enough for sun to realize this is not an option. Further SUN have allready had a half assed attempt. I assume it failed otherwise we would not be having this discussion.

Sun wants to win the fight with linux ( nothing wrong with that). You have looked at the linux code base, there is nothing there that the Solaris team feels is better, but you feel you have a lot of stuff that would make linux better. Solution, a GPL incompatible license with an excuse. Will not work, the license is more important than the code. Linux is good enough and getting better, Linux will just keep on rocking.

If both Solaris and Linux are under the GPL then a purchaser has to balance other issues, engineering goals and development method ( talked about in your blog) will matter. I think if engineers start looking at these questions Solaris will gain market share.

The question then becomes, how does SUN make money out of it. Red Hat has shown you how. Switching to Linux would be a disaster for SUN, Red Hat is the market leader there. Putting Solaris under the GPL and trade marking the brand that represents solid 7/24 hour support creates another market, I would assume SUN would be be and could remain the market leader.

<h3>Zealots</h3>

One of your comments talked about open source zealots, as it was under my post it was probable referring to me. I will accept the title and explain.

  1. Developing real time code against a closed source OS is dam near impossible. You need to understand the OS to avoid the time holes.
  2. I have spent too much of my life trying to reconcile the documentation against the binary just to discover the two aren't related.
  3. Where was the next generation of OS programmers supposed to come from. With all modern OS's locked up behind company bunkers, how was a kid supposed to learn.

It is my view; companies like SUN brought this on themselves. If the industry had relied on copyright and distributed source as it did in the beginning this revolution would have been different ( the computer industry regularly goes through revolutions because of the reduced cost of computers so I am sure something would be happened).

OK, there is on User land engineers view.

Good luck with it.

If you GPL Solaris, and Solaris is as good as I think it is, you will see me around.

Regards
Charles Esson

Posted by Charles Esson on September 25, 2004 at 10:04 AM PDT #

<h3>Solaris<h3>

Thank you for responding, it is an issue I care about. It would be nice if an OS developed against a different set of engineering goals survived. I like the goals set by the SUN engineering team ( that is not to say I can't live with the goals set by the Linux team) so I will have another go.

Your right, the LGPL doesn't matter when talking about the kernel code. It only matters in userland. That is why users that go on about Linux and the GPL are simple miss-informed. With Linux the boundary is the trap API. Linux works because a user land binary application can link to LGPL code, and the LGPL code can use the OS trap API. We need to get this issue clear, I am sure traditional Unix marketing departments will try to distort the situation but for this discussion to be useful it needs to stick to the facts.

So for the kernel code we are talking GPL, and only the GPL, what does that mean for SUN. SUN can open up the code and someone else can't close the improvements and use the improvements against them. It is that simple. I see no reason to give a more generous license, why let others use your work against SUN. The GPL has been accepted by the market; why give more?

To release Solaris under a more restrictive license is to give linux a license advantage. I think the mountian of discarded Unix's is high enough for sun to realize this is not an option. Further SUN have allready had a half assed attempt. I assume it failed otherwise we would not be having this discussion.

Sun wants to win the fight with linux ( nothing wrong with that). You have looked at the linux code base, there is nothing there that the Solaris team feels is better, but you feel you have a lot of stuff that would make linux better. Solution, a GPL incompatible license with an excuse. Will not work, the license is more important than the code. Linux is good enough and getting better, Linux will just keep on rocking.

If both Solaris and Linux are under the GPL then a purchaser has to balance other issues, engineering goals and development method ( talked about in your blog) will matter. I think if engineers start looking at these questions Solaris will gain market share.

The question then becomes, how does SUN make money out of it. Red Hat has shown you how. Switching to Linux would be a disaster for SUN, Red Hat is the market leader there. Putting Solaris under the GPL and trade marking the brand that represents solid 7/24 hour support creates another market, I would assume SUN would be be and could remain the market leader.

<h3>Zealots</h3>

One of your comments talked about open source zealots, as it was under my post it was probable referring to me. I will accept the title and explain.

  1. Developing real time code against a closed source OS is dam near impossible. You need to understand the OS to avoid the time holes.
  2. I have spent too much of my life trying to reconcile the documentation against the binary just to discover the two aren't related.
  3. Where was the next generation of OS programmers supposed to come from. With all modern OS's locked up behind company bunkers, how was a kid supposed to learn.

It is my view; companies like SUN brought this on themselves. If the industry had relied on copyright and distributed source as it did in the beginning this revolution would have been different ( the computer industry regularly goes through revolutions because of the reduced cost of computers so I am sure something would be happened).

OK, there is on User land engineers view.

Good luck with it.

If you GPL Solaris, and Solaris is as good as I think it is, you will see me around.

Regards
Charles Esson

Posted by Charles Esson on September 25, 2004 at 07:19 PM PDT #

Large projects like Zones, DTrace, and Predictive Self Healing could never be integrated into Linux simply because they are too large and touch too many parts of the code

Simply incorrect. A number of counter-examples:

Linux has been busy integrating some filesystems in the recent years. While ext3 is more an evolutinary following of ext2, and JFS and XFS are were mostly done for other OSes, ReiserFS is a whole new idea. And ReiserFS 4 is certianly something cool and revulutionary.

Other big changes:

  • udev: a more dynamic approach to device files
  • Security policies: Why settle with the traditional unix permissions when the sysadmin can choose the best of five other alternatives?
  • And many more

As for Predictive Self Healing: the Linux approach takes the good old simple unix approach: this is not the kernel's job. The framework for the kernel to send messages to userspace is basically available, though currently at the process of rewriting. One possible handling is to signal back to the kernel to take some action.

The Zones project remineds me of the linux Virtual Server project, which is integrated quite well into my distribution (Debian).
Linus has shown time and time again that these just aren't part of his core principles, and in the end he is in sole control of Linux's future. Projects such as crash dumps, kernel debuggers, and tracing frameworks have been repeatedly rejected by Linus, often because they are perceived as vendor added features
Linus is not in sole control of Linux's future. He is not the sole maintainer of a linux kernel tree. Distros have managed to push many of the features they wanted (ReiserFS is a good example for that). Linux is well aware of the limits of his control.
Kernel maintainers have rejected patches simply because of the amount of change (SMF, for example, modified over 1,000 files)
This is part of the code review process. When someone submits a huge patch to the maintainer the maintainer won't be able to underatand it. Thus there is a custom of separating a big patch a a set of small and simple patches, each of which describes part of the change. This makes the review process much saner. It has proven to be a useful practice.
But there's just no way that we can shoehorn Solaris principles into the Linux kernel
I'm not familiar with the development of Solaris. But is is worth mentioning the both IBM and SGI (and HP, to a lesser extent) have decided that influencing the development of the linux kernel can useful for their own causes.

Posted by &#8206;Tzafrir Cohen on September 26, 2004 at 07:45 AM PDT #

Large projects like Zones, DTrace, and Predictive Self Healing could never be integrated into Linux simply because they are too large and touch too many parts of the code.
Check out how big the XFS patch was. I haven't seen Linus saying CSA may not be included either. ReiserFS4 is still in debate exactly because they want to rely on standards.
If Sun releases only Solaris for SPARC with a peculiar open-source license that's not compatible with the GPL, it's not going to be a big deal. All you'll get is the right to help Sun improve its software ... If they produce a license that's not in the spirit of the open-source community, they won't do themselves any favors at all
Given SunOS was based upon BSD why can't SunOS still benefit from BSD kernels right now, without giving back which you don't like (you said so in another article posted here)?
Even if you can tiptoe around the issue now by putting your code in a self-contained module, the Linux kernel developers could actively work against you in the future. Of course, we could still choose a GPL compatible license for OpenSolaris, at which point I'll end up eating my words.
If you don't adhere the standards, yes. Read the discussion on LKML and the other topics about this on Kerneltrap for the whole discussion. Its not as simple as 'working against you'. If you have better examples i'd like to see them though.
Most importantly, contributors to OpenSolaris won't just be helping "Sun improve its software." By nature of making it open source, it will no longer be "our software". All the good things that come with an OSI license (right to use, fork, and modify code) will prevent us from ever owning OpenSolaris. If you contribute, you will helping improve your software, which you can then use, modify, or repackage to your heart's content. You will be part of a community. Yes, it won't be the Linux community. But it will be a community you can choose to join, either as a developer or a user, as alternative to Linux.
Thanks for clarifying this. I've been wondering about this for a long while and now its finally clear to me.

Posted by Anonymous on September 27, 2004 at 02:42 AM PDT #

[Trackback] Interesting conversation going on between Solaris engineer Eric Schrock and Linux kernel developer Greg Kroah. Eric started it, Greg rebutted it, Eric replied with round two, and finally Greg responds in kind. Go ahead and read those posts -- I'll...

Posted by chizang on September 27, 2004 at 06:29 PM PDT #

Post a Comment:
Comments are closed for this entry.
About

Musings about Fishworks, Operating Systems, and the software that runs on them.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today