Interview with Simon Phipps
Before joining Sun in 2001, Simon Phipps spent ten years at IBM, where he was Chief Java and XML Evangelist. He first came across free software in the late 1980s, when he was selling freeware from home as a sideline while working at Unisys. Today, Phipps is Sun's Chief Open Source Officer, and he plays a key role as the company moves its entire software portfolio to open source.
GM: What was the state of the open-source activity at Sun when you joined?
SP: I regard Sun as the original open-source startup company. It's the first long-lived company I can think of that used open source as the basis of a business model. If you look back down Sun's history, through the decades, you see that Sun kept on working openly with communities around software and hardware. It did it with NFS, it did with TCP/IP, it did with Java, and it's continuing to do it now with OpenSolaris and the rest of the portfolio. So, in one sense, there was always and there remains a very, very strong open software ethos at Sun.
When I joined Sun, Sun was right at the forefront of some really quite radical commercial open-source experiments—one of them, starting OpenOffice.org, and the other, getting NetBeans started. Inside Sun, people were talking strongly about the open-source future for Solaris because its heritage had been open source, and it was pretty clear that it was a good thing for its future to be open source as well. So, it was 2000/2001 that the legal clearance work for Solaris started off.
GM: What did that involve?
SP: The process you have to go through when you've got a piece of 20-year-old code is working out who owns it all. It's actually a reasonably intractable problem, because over the decades, the standard of proof has gradually gotten stronger and stronger. Just because there's nothing in the file header, doesn't mean it doesn't belong to someone else. Someone else might have the right to it. So we had an absolutely stunning team of people in the Solaris group who did what you might call licensing archaeology—looking at the code, comparing it with other code whose provenance was known, looking at variable naming styles and indentation styles, the language of the comments, trying to get a reasonable standard of proof about where the code had come from.
There are things that were much more obvious as to where they'd originated, and we were able to look back in our legal archives at the licenses and work out whether we had the rights. And, for quite a lot of those we then had to go back and negotiate third-party sublicensability. In many cases, we found that people were perfectly happy just to give us that right. There were some cases where we found the licensee didn't exist any more; finding out who abandoned code belongs to is another art form.
Something else you have to look out for is code that was based on disclosure of information where the disclosure itself was under trade secret terms. So, although we'd written the code, we didn't actually have the right to disclose it, because to do so would have disclosed the trade secrets. And, we still have problems with some of that code, in particular from video card manufacturers, where they were willing to tell us under trade secret terms how their chipset works, but they continue to refuse to allow us actually to disclose the source code.
GM: Presumably parallel to what you were thinking about licenses—how did you end up with the CDDL license?
SP: Solaris flowed out of BSD. It was actually BSD merged with System V at one point, so there were a lot of people who felt that we should be using BSD as a license. However, a lot of the innovations that have happened in Solaris have been by quite recently hired people—younger, brilliant engineers. And, there was a strong view as well that we should be using the GPL. Also, there were a lot of people who felt that the Mozilla approach to licensing had been correct.
The difficulty with using the GPL was that it became clear as we did the licensing archaeology that there were going to be places in the software where we couldn't negotiate a free license for the source code. And, there were going to be some quite important places in the code, and there were going to be quite a lot of them for a long time. And, that was probably the deciding factor not to use GPL but to use the Mozilla license.
We looked at the Mozilla license, and we realised that we couldn't use it as it was. We saw that license proliferation was an increasing problem. So, we decided that we would have a go doing a good thing for the Free Software and Open Source community, by making the last clone of the Mozilla license that would ever need to be made, by parametrising it. We left as much of the language as identical as we could and produced the Common Development and Distribution License, the CDDL. The CDDL is, in my view, an absolutely excellent license; if anyone but Sun had written it, it would have been hailed as brilliant.
GM: How do you see the relationship between OpenSolaris and GNU/Linux?
SP: I think that there is a huge overlap in those worlds. One of the interesting things you discover when you run an OpenSolaris distribution like Nexenta is, my goodness, it looks just like Ubuntu. And you know, there's a really good reason for that: because it is Ubuntu, but it's got a Solaris kernel in it.
When you look at what UNIX-like operating systems really are, each is a set of editorial choices about which free software userland to assemble around which kernel. So you discover that everyone in Fedora, and everyone in FreeBSD, and everyone in OpenSolaris are all using the same stuff. They're all using GNOME or KDE, they're all using Sendmail, and they're all using Mozilla.
In the Solaris community, they've tended to use the OpenSolaris ON, which is the OpenSolaris jargon for the kernel and network. ON stands for Operating System/Networking. And the userland that's around it, well, there is a style of userland that's used by people who run servers. And then there's the style of userland used by developers, and that's typically GNOME or KDE, and tools. And it's just the same on Solaris as it is on Fedora. The look and feel is different, the editorial choices about where to put the icons are different, but ultimately, it's all the same stuff.
So I think we're going to see a gradual shift in the way we think about UNIX-like operating systems as we go forward. We are going to see much less of people trying to arbitrarily distinguish between the different peers in that community. I think that the distinction people try to force between UNIX and Linux is part of a strategy by corporations to diminish their competitors' versions of UNIX. And I think it harms us all, because the real competitor out there isn't somebody else's UNIX-like operating system, it's actually the closed stuff. I think that in the future, we'll see people who are deciding to run a Debian userland with a Solaris kernel, as well as people who are using a Solaris-inspired minimalist install with a Linux 2.6 kernel. We'll see people starting to use the BSD kernel together with KDE and a package manager that they got from the Solaris community.
GM: What's the history behind the opening up of Java?
SP: What was happening in the Open Source world [in the late 1990s] was the realisation that with-source-style licensing was commercially viable. We saw Mozilla being released, and then we saw the Open Source Initiative picking up the Debian Social Contract and turning it into the Open Source Definition. Meanwhile, over at Sun, everything was incredibly busy; there was way more business than Sun could cope with. It really didn't have the bandwidth to cope with this stuff that was happening over in the Open Source community. So it largely ignored it because the days were already full.
What's more, the people who were doing the open-source stuff were really pretty hostile to Java. Their hostility wasn't moderated by a recognition that Java came from what would now be recognised as an open-source company. The Open Source movement is busily accepting grace from IBM to promote Linux—shall we say, not entirely in isolation from the fact that Linux isn't Solaris. And, an engine of bad feeling was busy humming away nicely, between 2000 and 2003, with all the players doing their utmost to make sure that understanding and cooperation didn't break out.
GM: So what happened?
SP: Sun had a sort of near-death experience, when the [dot-com] bubble burst. It saw its stock price go down to a tenth of its previous value, and it saw the need to dismiss large numbers of staff. It became suddenly very obvious that lots of the people who didn't share Sun's values didn't belong here anymore; it also became very obvious that some of the approaches to software that Sun had been taking weren't actually in keeping with Sun's long-term values.
What then changed around about 2003, was it became obvious that Java had a huge international community. It actually had a huge Open Source community, developing on top of the Java platform, using open-source tools like Spring, Hibernate, JBoss and so on. And, I think it gradually became more and more obvious to people that this community probably was no longer as vulnerable to monopolisation as it had been. And, that meant it was less and less important to keep as the number-one priority the prevention of monopolisation, and it became acceptable to begin to think about other priorities for the licensing of the Java platform.
GM: What about the license? How did you end up making the surprising choice of the GPL?
SP: We looked at pretty much every license you can imagine for the Java platform. Obviously, lots of people thought we were going to use CDDL. There were several questions we had to ask ourselves: one of them was which license was most likely to prevent monopolisation by somebody loving us to death. Another factor was asking who wasn't using Java. And, Java is actually pretty widespread. It's on five billion devices, it's on eight out of ten cell phones, and it's used on a strong majority of enterprise application servers.
So the question has to be, well, how can you grow when you've already got such a strong market? And, the obvious place that we could grow was actually to GNU/Linux. If you look at the use of GNU/Linux outside Europe and North America, you discover that distributions like Fedora and Debian are actually very, very important in those geographies. And, none of those distributions were actually carrying Java, because of the licensing concerns.
Worse than that, it had been such a long time since they'd carried Java, that their package management systems had grown up in such a way that the versions of Java that Sun was actually making for those platforms didn't install. So, there was no way you could apt-get Java on Debian, for example. All Sun made available was an RPM. And, yes, if you were resolute, you could force it in there, but fundamentally, Java just wasn't available for Debian.
We felt that the biggest impact we could have on the Java market was by settling the long dispute with the GNU/Linux community. We felt that doing that would grow the market to everyone's benefit.
As an application developer on GNU/Linux, you don't want to have to worry about which version of the kernel is in use and which desktop environment people have, and which package management system they're using; you don't want to have 500 different versions of your installer for all the different versions of GNU/Linux out there. So, Java's got a really strong value that it can offer the GNU/Linux community allowing not every application, but a lot of applications that are not too tightly coupled, to the system internals to be written using a platform-independent programming mechanism. And, that's the chief value that Perl and Python and others were bringing to the platform. And we thought, well, it's a great fit.
Another driver in choosing the GPL was we felt that the behaviour that would lead to monopolistic abuse of the Java platform would typically be done in secret until it was launched. By using the GPL, people will find it very tricky to do extensive development in secret. So we felt that the GPL provided us with the strongest protection against misbehaviour by monopolists in the Java platform.
GM: In a speech a couple of years back, Sun's CEO Jonathan Schwartz argued that the GPL is “IP colonialism”, because he claimed it imposed on poorer countries “a rather predatory obligation to [give back] all their IP to the wealthiest nation in the world”. Why did he change his mind?
SP: Well, you know, this is an interesting thing to contemplate, because I'm not sure he was wrong. The GPL does require you to set aside commercial protections for your software. And, it is possible that the use of the GPL for the indigenous software industry, for example, in Brazil, might harm the Brazilian economy. If you actually read the argument that Jonathan was making at the time, it's a good academic argument. What made it controversial was that it was the Chief Operating Officer of Sun saying it.
GM: To what extent is Sun now committed to opening up everything that it can?
SP: We're completely committed to open-sourcing every thing that we're able to. Jonathan Schwartz asserted that as our position about two years ago. We're well on the road to fulfilling that commitment.
GM: Given this commitment to free software, and the Open Source community, wouldn't it be more sensible for Sun to join Eclipse rather than pushing NetBeans on its own?
SP: The deal here is once again how you view open source. Open source isn't something you join; it's something you do. And, Sun doesn't want to join the Eclipse community, just like IBM doesn't want to join the OpenOffice.org community. Why would we want to join a community that isn't making any code we want to use in a product?
[Eclipse] has significant disadvantages for Sun in the way that IBM decided to set it up. If you want to join the board, you have to pay out a very large sum of money, you have to commit a certain number of engineers to work only on that, at the direction of the Eclipse community, and you have to guarantee to produce products that use the Eclipse core code within a year. And, for us to fulfill those requirements, we would need to drop NetBeans. And, NetBeans is a big part of our tools development.
GM: Finally, what's your vision of the world where open source is a major part of computing?
SP: I actually think that we're in the middle of a pivot point in the way society functions. I believe the World Wide Web as the vehicle for popularising the Internet is producing something that is as impactful as the Industrial Revolution. And, I think during the next decade, we will see that process of changing how absolutely everything works rolling out in front of us.
Pre-World Wide Web, most things that happened in the world were done on a hub-and-spoke basis where you'd have, for example, government in the middle and citizens on the end of the spokes. Or, you'd have industry in the middle and customers on the end of the spokes. I think the introduction of the World Wide Web has changed the basic topology of society from hub-and-spoke to mesh.
Because the software industry is so closely connected to the World Wide Web, it's been one of the first to be impacted. So I see open source as an inevitable consequence of the switch to a meshed world. It's, in my view, the dominant way that software is developed in a participation age. The way you make money is not by locking people in with a license at the beginning, but rather by providing the capabilities people want once they're running things.
In the meshed world, what helps you be successful in a business is influence. And, you get influence not by power but by being valuable. My vision is that we're switching over to this new world of influence instead of control, of value instead of power, of participation instead of distribution.
So, we can expect to see a rolling tide of change where the principles of the meshed society begin to be worked out in other areas, like politics, like journalism, like the way families function, like the way money is handled, represented and stored. All of these things will gradually fall under the influence of the meshed society. And, I think being at the forefront of working with that meshed society is going to serve Sun and the people in the Open Source communities very well.
Glyn Moody writes about free software and open source at opendotdotdot.blogspot.com.
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
|Trying to Tame the Tablet||May 08, 2013|
- Using Salt Stack and Vagrant for Drupal Development
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Home, My Backup Data Center
- New Products
- RSS Feeds
- New Products
- Reply to comment | Linux Journal
3 min 30 sec ago
- This is the easiest tutorial
6 hours 18 min ago
- Ahh, the Koolaid.
11 hours 56 min ago
- git-annex assistant
17 hours 56 min ago
- direct cable connection
18 hours 18 min ago
- Agreed on AirDroid. With my
18 hours 28 min ago
- I just learned this
18 hours 33 min ago
19 hours 3 min ago
- not living upto the mobile revolution
21 hours 54 min ago
- Deceptive Advertising and
22 hours 30 min ago
Enter to Win an Adafruit Prototyping Pi Plate Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Prototyping Pi Plate Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- Next winner announced on 5-21-13!
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.