Simon Phipps has always been in the room where it happens.
A computer scientist, he was one of the earlier open source advocates. Best known for his work on the release of the Solaris operating system and Java programming language under open source licenses while at Sun Microsystems, he’s served in various capacities for organizations including the MariaDB Foundation, the GNOME Foundation, OpenJDK, and OpenSPARC. Twice president of the Open Source Initiative (OSI) where he now serves as Standards Director, he also has a seat on the Alma Linux OS Foundation Board.
Wearing a T-shirt featuring a velociraptor riding a velocipede and gesturing precisely as if conducting a large mental orchestra, Phipps recently talked over video chat to Open.Intel’s Editorial Director Nicole Martinelli about reputational vampires, the most important debate in the open ecosystem and why we’re in the era where every desktop is a Linux desktop. Their conversation has been edited and condensed for clarity.
Photo courtesy Simon Phipps
Q: You were at the dawn of corporate open source, with the release of Java and StarOffice and later OpenSolaris. There were no clear models for how this should work - you and the team “invented” it as you went along.
A: We had to make up a lot of things, but some things fell into place easily. The legal stuff fell into place, open source licensing was just like commercial licensing as far as compliance is concerned.
We already had a compliance process for commercial licensing, so we just had to understand how open source licensing was like commercial licensing. We had to frame it with a set of parameters that we could track through the inbound to outbound process of our software business.
Actually, I've never thought that open source license compliance is terribly onerous – I'm always a little suspicious of anyone who does.
I assume that anyone who finds open source licensing onerous is trying to evade the terms of one of the licenses. And that assumption has proven to be well founded in many, many cases.
Q: So, in the early days, compliance was straightforward. Was the community work hard? A generation later, marketing people still hit false notes talking to “customers” in open source communities.
A: There are several reasons why community is hard. The first is the instinctive corporate equation of community with customers.
Then there’s the complete failure to look beyond the use that you decided for the software and assume that everyone uses it the same way. That's one of the things that lies behind this dreadful movement to lock software down to a corporation with licenses that place restrictions on field of use.
We can discuss whether that's fair game in their market, but it absolutely stops me from picking up that cool scheduling algorithm and using it in my game. Or, you know, taking that display framework there and using it in whatever I'm doing over here, which is completely unrelated to the use that you're putting it to.
Corporations need to remember that it's not all about them.
They want to believe it's all about them and their customers. That's a very bad habit: to believe that just because you use the software for this, that doesn't mean everyone uses it for that. And it doesn't mean everyone wants to use all of it. They may well only want to use a part of it.
Q: How has the corporate attitude to open source shifted?
A: When corporations started using open source, the free software world was largely a hobbyist world. There was a sense that open source was about desktop-equivalent software, rather than about enterprise server software, and that it came into the enterprise very much the way that desktop software came into the enterprise through a departmental level adoption and moving upwards.
That’s changed. Today, open source is how software gets made for the enterprise and, if anything, the desktop has become irrelevant.
The desktop is now the Linux desktop as far as I'm concerned. Not because you're running Linux on your Windows PC, but because all the software you're running on your PC is using a copy of Linux on some server somewhere to do what it does. I bet you that even this Microsoft Teams call we've got here is actually running on Linux in Azure somewhere.
Q: It’s highly possible, yes.
A: As it turns out, we've been in the era of the Linux desktop for about 12 years now.
People are too short-sighted to see that -- they see the brand name on the frame and forget that everything inside the frame is running on Linux.
Q: What role should corporations play in the open ecosystem today?
A: Often they still don’t understand that open source inhabits a holistic space. This was a big challenge we found at Sun in the 2000s, making people realize that it mattered what people thought about what we were doing as a company beyond the scope of that particular community.
A great example of this was when Santa Cruz Operation (SCO) sued IBM for intellectual property infringement over putting their Unix ideas into Linux. That lawsuit ran for a couple of decades, with zombie tangents still in courtrooms today.
I discovered that Sun’s OEM division was about to announce a big deal with a mobile company that turned out to be the fundraising wing of SCO. On the campus, that deal was being discussed in a boardroom far from the open source office in the software division. The deal was connected with Java and with Solaris but what the mobile people were doing over there appeared completely unrelated to open source. I managed to stop that deal from happening but if Sun had done that deal with SCO, our name would have been totally rubbish in the space where we were building and recovering our reputation.
Corporations need to understand that in the open ecosystem it's not all about you.
Your reputation is a holistic reputation, it's not restricted just to the open source part of your business.
Q: Is it a license question then?
A: Licensing is not going to be sufficient – dictatorships, for example, typically act with legally obtained materials. Just saying, “Don't do evil” doesn’t work - it turns out that evil often isn't illegal.
What needs to return into that equation, though, is the recognition that people use open source to get a network effect.
What makes the network effect work is the ability for people to use the software or build on the software without having to think too deeply about it.
As soon as you apply a whole load of licensing or compliance steps that mean that people have to go through an onerous process or worst of all, seek, seek permission from their boss or from their legal department, that completely kills the network effect.
And if it was the network effect that you were relying on to push the project into viability, then guess what? The project is never going to be viable. It'll be ethically pure, but no one will ever hear about it because it will never go anywhere.
That whole debate has many moving parts and is difficult because as soon as I say, “But what about the open source network effect?”
People look at me and say “Well, but don't you care about the children?”
I do, but I'm also aware that if I want things to get better, I have to develop the software. I have to draw people into developing the software. I do that by driving adoption of the software. I have to frame the restrictions on what happens or they aren't even restrictions. I have to frame the norms about what's done with the software in a way that doesn't impact the adoption network effect.
Because if I harm the network effect, it will never get adopted.
So I think that's the most important, most interesting debate right now, because I don't often hear people who have all the insight.
It’s like a blackberry with many, many little cells that all have to hold together to make it the right fruit. There are lots of people who are fixated on the thorns or the stems but they don't see the whole fruit.
I'm watching that debate with great interest. The solution is to frame the ethical requirement in terms of incentives and benefits rather than in terms of restrictions and rules, but I don't really quite know how to express that in a concrete way yet.
Q: Are current licenses strong enough to do that? And, if not, how do we create licenses that create or shape norms?
A: I heard this from Eben Moglen first: “An open source license is the constitution of a community.”
The primary way to understand an open source license is as a set of community norms that the community abides by to develop their software. A good open source license never needs enforcement because it already expresses the norms of the community. It's the constitution.
That aspect of licenses as the consensus of the community means they are what we agree about as boundaries for what we're doing. In that sense, licenses are still the ideal tool because a license is essentially a set of statements of truth that give me permission in advance to do what I please.
As soon as they become statements that restrict what I can do, or where I have to seek permission or, perish the thought, where I must buy a royalty license or something. As soon as that happens, I'm out of the space of the license that gives me the confidence to proceed and I'm into the space of “I have to go talk to purchasing.”
That was the very thing that made open source succeed: getting out of that space where the first discussion was, “I've gotta go and talk to purchasing and get a demonstration from sales.”
Licenses are still highly relevant. But when they are used in the role of Inflicting controls or imposing restrictions, they completely fail.
The whole point of open source licenses was to give you permission in advance. It wasn't to restrict you. So, if you can frame what you're doing in a license as a set of permissions, then it's all good.
Stay tuned for part 2, where Simon Phipps talks ethics, open source organizations taking on big tech, and reputation vampires.
This is the first post in a two-part series conducted by Open.Intel’s Editorial Director Nicole Martinelli.