"
To me it’s being – I think it’s very interesting and, I mean, when I say it’s – what drives, motivates me is the fun part. I mean, part of being fun is that it should be difficult enough to not be trivial. So, fun doesn’t mean that it’s frivolous; it just means it’s interesting and exciting.
...
Well, I mean, it’s really not a democracy at all and some people call it a meritocracy which is not necessarily correct either. It’s – I have a policy that he who does the code gets to decide, which basically boils down to there’s a – it’s very easy to complain and talk about issues and it’s also easy for me to say, ‘You should solve it this way.’
But at the end of the day, the only thing that matters is actual code and the technology itself and the people who are not willing to step up and write that code, they can comment on it and they can say it should be done this way or that way or they won’t, but in the end their voice doesn’t matter. The only thing that matters is code.
And it turns out people are lazy, so most people are much happier just arguing and quite often you only have one set of – one example code and there’s not a lot of real choice there. You – there’s not a lot of people who are competent enough to really do kernel programming and also not lazy enough that they actually get the job done.
So, occasionally it turns out that we have two pieces of code that actually do the same thing or similar things in different ways and then you get to the situation where somebody has to choose and quite often it’s me and that can cause some social issues with that too. It’s actually fairly unusual.
...
Well, one of the – my favorite theories that the whole organization doesn’t really exist and that it’s largely self-organizing. And what that means is we do not have any strict – when there is no rules about who is really a maintainer and even when we have a maintainer’s file that says, “This person is in charge of that sub-project,” that’s really more of a hint than anything else. It means that, okay, if you have problems in this area or if you have a patch in this area that you want to push, that person is probably the right person to approach.
...
And because it is self-organizing, it means that usually it evolves as time goes on. So, people might start out being not very central, but as more and more they show they’re good at a certain area, they kind of gather more and more trust and get more and more connection and become more central without really having a – without there being in place any way to make them central in a kind of official way.
...
...community tends to also be – become a – not just to see it as one entity, but you also see people as being inside and outside and that used to be especially – I think most companies have slowly started to learn, but it used to be a huge issues where companies kind of were talking about “How do we interact with the community?”
And there the community ended up being some external entity when the real answer always ends up being you don’t interact with the community, you just act as a member of this non-existent community. You really – you don’t interact with it, you are part of it.
...
And it – as a result of that, we now have multiple layers of where a code goes in, where it doesn’t immediately go into my tree. If there is something that is experimental, it gets developed in some external tree and then usually goes through, for example, (Andrew Morton)’s tree and can sit in that tree for a year until people say, “Okay, it worked out in those trees. It hasn’t gotten a lot of wide testing yet because it’s been in specialized trees, but everything looks good so let’s push it to the main tree.”-- Linus Torvalds
Linus Torvalds - Part IJanuary 2008
SourceJim Zemlin: So, I wanted to start out by asking you the first question. What is it like being a part of The Linux Foundation?
Linus Torvalds: To me, what I’ve been doing for the last four years has basically been finally doing Linux full-time. Before that I always had – I had a so-called real job that supported me and the family and then Linux was kind of a hobby and although my employers knew about Linux and supported it, but it was not my official job.
So, about four years ago I basically said I needed to do it full time and I was ready to just go at it alone and just take a break from Transmeta and, instead, found this company that was willing to support doing what I needed to do anyway.
So, as far as I’m concerned, The Linux Foundation is my way of not having to worry about all the details about feeding my family and doing what I wanted and needed to do.
Jim Zemlin: Great. What motivates you to work on Linux?
Linus Torvalds: Well, it used to be the technology was just – I was interested in just how the hardware worked and the interactions between hardware and software and that’s still a large part of it, but largely it’s also now just the social side.
So, it’s just a lot of fun working with people; even though, I mean, I sit in my basement all day long and actually don’t meet anybody at all, but what I do is essentially communicate and it is very social: reading email from people, answering them, telling them that they’re being difficult. Although I don’t – I just say it in that polite manner or that they’re doing a good job and trying to push people in the right direction.
Jim Zemlin: You’ve often been quoted as saying, ‘Linux is just fun,’ and that’s what really motivates you to do this.
Linus Torvalds: Right.
Jim Zemlin: Do you see Linux, the development of Linux as something of a greater cause?
Linus Torvalds: No. No, not to me; I mean, to other people it is. I mean, it’s actually one of the things I found to be interesting is how people use Linux in ways that I didn’t start out designing it for and sometimes use it for things that I really don’t care about personally that much.
And all the usage where people use Linux for third world countries and helping humanity, some people think that’s why I got into it and, no, that’s not why I got into it and the credit should go to projects like OLPC that use Linux to try to better the world in a bigger picture.
To me it’s being – I think it’s very interesting and, I mean, when I say it’s – what drives, motivates me is the fun part. I mean, part of being fun is that it should be difficult enough to not be trivial. So, fun doesn’t mean that it’s frivolous; it just means it’s interesting and exciting.
Jim Zemlin: Let’s talk about the part that “difficult enough to be not be trivial.” So, there’s a technical aspect to…
Linus Torvalds: Right.
Jim Zemlin: …being difficult. There’s a social aspect and a collaborative aspect to being difficult as well. Which do you find more challenging? Is it just different?
Linus Torvalds: They’re all, I mean, they’re all changing and they’re just different in sometimes the technology itself can be really challenging; the technical side is seldom frustrating. So, the technical sides are often easier in that sense that I don’t get frustrated. Okay, we’ve had a bug and we’ve hit our head against a technical bug for a couple months and, yes, that can be – feel slightly frustrating at same – but at the same time, you always know that it’s something that you are going to solve and you’re just – I never worry about that.
The social side is maybe a bit more difficult in the sense that that can be really frustrating and sometimes you don’t solve the social problems and people get upset and I think that’s very interesting too. I mean, it’s not – if it was – if everybody was easy and everybody was all pulling in the same direction, it wouldn’t be as fun and interesting.
And it’s different and also it changes from time-to-time. Sometimes we concentrate on technical problems and then occasionally, happily fairly seldom, there comes like this perfect storm of social issues that start up and one flame-war perhaps brings out some other issues that people have had and have been kind of simmering under the surface, so.
So, it’s not like you have this constant technical and social issues; they tend to come and go.
Jim Zemlin: Let’s look a level deeper at the social interaction because open source is often described as this sort of democratizing process that, you know, everyone has a say, there’s this grand consensus, but at the end of the day, needs to be some sort of decisiveness when it comes to making decisions. How do you deal with that?
Linus Torvalds: Well, I mean, it’s really not a democracy at all and some people call it a meritocracy which is not necessarily correct either. It’s – I have a policy that he who does the code gets to decide, which basically boils down to there’s a – it’s very easy to complain and talk about issues and it’s also easy for me to say, ‘You should solve it this way.’
But at the end of the day, the only thing that matters is actual code and the technology itself and the people who are not willing to step up and write that code, they can comment on it and they can say it should be done this way or that way or they won’t, but in the end their voice doesn’t matter. The only thing that matters is code.
And it turns out people are lazy, so most people are much happier just arguing and quite often you only have one set of – one example code and there’s not a lot of real choice there. You – there’s not a lot of people who are competent enough to really do kernel programming and also not lazy enough that they actually get the job done.
So, occasionally it turns out that we have two pieces of code that actually do the same thing or similar things in different ways and then you get to the situation where somebody has to choose and quite often it’s me and that can cause some social issues with that too. It’s actually fairly unusual.
Jim Zemlin: But you’re willing to make those decisions when you need to, right?
Linus Torvalds: Right. And actually, the technical issues are fairly easy in the sense that if I end up doing – making the wrong decision, we can undo it. It happens. I mean, people just say, “Okay, it maybe have looked like the right decision, but that was completely off-the-wall wrong.”
And we just switch over and it can be slightly painful at times, but as mentioned, it’s not that common to have – to make big decisions in the first place and most of the time the decision isn’t the wrong one.
Jim Zemlin: Step us through the organization of the development process itself. You know, who are the people who are at the center of the project and how does the project expand out in terms of the participants who work on the Linux kernel?
Linus Torvalds: Well, one of the – my favorite theories that the whole organization doesn’t really exist and that it’s largely self-organizing. And what that means is we do not have any strict – when there is no rules about who is really a maintainer and even when we have a maintainer’s file that says, “This person is in charge of that sub-project,” that’s really more of a hint than anything else. It means that, okay, if you have problems in this area or if you have a patch in this area that you want to push, that person is probably the right person to approach.
But even that is a fairly soft thing and in the end what ends up happening is that it’s more like a social network where some people just have more connections than other people have and a patch is not a problem; reports tend to move along the edges from the originator through all the people who have the most connections eventually up to me and/or other few other kind of core people who have a lot of connections to a lot of different areas.
Jim Zemlin: So in many ways, participating in a meaningful way in the development process is a lot about having trusted relationships?
Linus Torvalds: Right.
Jim Zemlin: Including the different participants?
Linus Torvalds: Right. It doesn’t matter at all who you work for pretty much because nobody really cares and there might be some politics going on but in the end what happens is people know – they’ve seen other people do work over the last months or years, in some cases decades, and they know that, “Okay, I can trust this person. When he sends me a patch, it’s probably the right thing to do even if I don’t understand quite why” and you kind of build up this network.
And because it is self-organizing, it means that usually it evolves as time goes on. So, people might start out being not very central, but as more and more they show they’re good at a certain area, they kind of gather more and more trust and get more and more connection and become more central without really having a – without there being in place any way to make them central in a kind of official way.
Jim Zemlin: So, let’s talk a little bit about community, then, from this aspect of trust and I’d like to start by asking you a question about the term community itself. People throw the term community – you know, “Don’t do that. It will upset the ‘community’” or “The ‘community’ doesn’t accept this particular practice.’”
What – how do you define community? I mean, what is the way you look at that?
Linus Torvalds: I actually – I try to avoid using the word community because it’s misleading in so many ways. It’s misleading in the sense there is no one community; it’s everybody tends to have their own issues that they care about and they may – may or may not have anything to do with another person who’s ostensibly in the same community.
So, one misleading thing is thinking that people kind of share ideals and goals and that’s not true. It’s quite often the case that people have completely different goals; you have commercial vendors who have their very clear commercial goals and you have individuals that in the open source, so-called community, you often find individuals who really don’t like commercial entities, especially not the big ones. So, quite often the goals are very different.
And the other thing is, community tends to also be – become a – not just to see it as one entity, but you also see people as being inside and outside and that used to be especially – I think most companies have slowly started to learn, but it used to be a huge issues where companies kind of were talking about “How do we interact with the community?”
And there the community ended up being some external entity when the real answer always ends up being you don’t interact with the community, you just act as a member of this non-existent community. You really – you don’t interact with it, you are part of it.
Jim Zemlin: That’s something that I’d like to expand upon because a lot of times at the Foundation, corporations will come to us and ask, “How do we participate in the community? How do we work with the community?” and our response, similar to yours, is “You can be a part of the community.”
What advice would you have for corporations who have goals in participating in – let’s not use the word community, development goals?
Linus Torvalds: Usually, I mean, the easiest way is to find a person who is already a member of the development process or maybe not a very central one, but really – central enough that he’s been involved and knows how things works and basically bring that person into the company.
Quite often people, I mean, companies have those kinds of people inside already, especially if you’re in a tech company and you have interest in something like the Linux kernel, the reason you have interest in the Linux kernel probably has something to do with the kind of people you have working for you.
So, there probably already are people inside the company who know how things work.
Jim Zemlin: But you talked before about trust and why trust is important in terms of the influence you have to some degree in accomplishing what you want in the community.
Sometimes corporations don’t think about it in that way. They think, “Hey, if I assign people to work on this and I just throw resources at it, I’m going to accomplish my goal.”
How can these organizations, if they assign staff, build that trust? What should they tell their people who are participating out there?
Linus Torvalds: I don’t know if there is an answer to that question. {Laughter} I – if you think about trust the way you think about trusting a personal relationship, you don’t get trust and you don’t even really build trust knowingly. The trust either comes or it does not come and it largely depends on your actions.
So, the way to build trust is not to think of it as building trust, but trying to make sure that your actions speak louder than whatever you’re saying and maybe what your internal strategy is doesn’t matter. What your external actions are is eventually what will either give you trust or not give you trust.
Jim Zemlin: Let’s talk about the kernel development process today and how it’s changed over time and let me kind of paint a picture for you and then I’m curious to hear what you have to say.
Many years ago it was a fun project that was used by companies in some cases, but it was not as widely-adopted as it is today.
Today you have this groundswell of mobile devices, of huge server implementations that are really critical to companies’ interest in industry; just this massive participation from a commercial sense.
If you look between now and then, how has the development process changed? Have the people changed? Is – what’s different now about what you’re doing than it was, let’s say, even three, four years ago when you were at Transmeta?
Linus Torvalds: I think the process is largely the same. There have been certain process changes that are purely technical in the sense that we have made some of the process more explicit and there are tools that support our particular way of doing things that did not exist five to ten years ago.
Another thing that has changed is the people involved have certainly been involved longer and are, perhaps, more aware of just how much they can screw up and care about it more than they – I’m thinking about me in particular. It was to some degree easier ten years ago when it was easy to just say, “Hey, we’ll try this and if it doesn’t work out, not a big deal.”
And we don’t have quite that amount of freedom anymore, we can’t just take completely experimental code and say, “Hey, let’s see how this works out.”
And it – as a result of that, we now have multiple layers of where a code goes in, where it doesn’t immediately go into my tree. If there is something that is experimental, it gets developed in some external tree and then usually goes through, for example, (Andrew Morton)’s tree and can sit in that tree for a year until people say, “Okay, it worked out in those trees. It hasn’t gotten a lot of wide testing yet because it’s been in specialized trees, but everything looks good so let’s push it to the main tree.”
So, we have changed that. A lot of that has actually happened on its own not so much because we foresaw the problems but because it just became the way we worked because it was clear that my tree can be quite as experimental which, in turn, motivated other people to kind of take up the mantel of experimental trees.
Jim Zemlin: In some ways what you’re describing sounds a lot like going from being single to getting married to having kids in that there’s sort of this increasing amount of a sense of personal responsibility.
Linus Torvalds: Right. I mean it – to some degree it definitely is about growing up and there are lots of similarities; there are probably lots of differences too, so {laughter} I don’t know if that – you can take that analogy that far, but.
Jim Zemlin: You don’t love the kernel community, do you?
Linus Torvalds: Well, some people I worked with, I mean, it – when you work with people for five or ten years, maybe you don’t love them that way but at least you trust them in a very real sense on a personal level.
Jim Zemlin: One of the things that’s happening—to continue to talk about community—is Linux is starting to be more important across the globe to – whether it’s from governments who see it as a strategic way to grow with a software industry, sort of use Linux as something that can do that or its mobile device manufacturers in Taipei or One Laptop Per Child, et cetera.
One of the things that people ask a lot about is why don’t we see more global participation in the development process itself? In other words, observers say this is very North American-European focused.
I’d be curious to hear your thoughts on: a) why don’t you see more of it; and, b) any ideas on how you can get more participation from folks from other geographies.
Linus Torvalds: Well, we’ve done some studies, six over the years just looking at where developers come from and one of the obvious things is people tend to come from not just populous countries, but countries with a very high density of Internet access and that is one of the reasons.
I mean, you can easily say that, yes, there’s a billion people in China, there’s a billion people in India, but China and India are not represented very well in the developer community.
But if you actually – instead of just looking at just number of people, you look at number of people who actually have good Internet access. China and India simply aren’t that big and that’s one of the issues is just connectivity.
Jim Zemlin: But proportionally, do they participate as much or is there still…?
Linus Torvalds: There are other issues too and clearly the language and cultural barriers are one of the big issues and something as simple as and maybe obvious as education.
So, the language barriers tend to be a huge problem for – well, actually, maybe more even the different cultural issues that – with Asian countries they have good penetration; some of them have huge penetration of Internet use, they have a obviously great education and they do not end up contributing a lot to open source, not the kernel, not to generally other projects either.
And that seems to be at least partly cultural and it’s really hard, then, for some of these people who have cultural barriers and a language barrier to then become actively involved. It does happen, but it certainly explains a lot of the reasons why Western Europe and the U.S. are the biggest development areas.
Jim Zemlin: Is this something that the kind of core kernel community thinks about, like, “How can we get more people involved? How can we make it easier and more accessible to get people involved?”
Linus Torvalds: It comes up every once in a while. I don’t think anybody really knows what the answer is. We’ve added some documentation. Usually the kind of initial “read me” kind of documentation: where to go to get involved, how to behave, so that’s available in a number of languages.
Whether that makes a huge deal or not, I don’t know. I suspect it doesn’t, but I also suspect that it may make people more likely to at least take a look at the project. Maybe it scares away people less when they see the project itself, at least tries to approach them. People in Asia might feel like, “Okay, I’m not fighting against this. I may have issues,” but at least they’re kind of aware of them and they’re trying to some degree. So, that’s one of the things we’ve been looking at.
That said, I mean, I actually think the cultural barrier is bigger than the language barrier and the reason I say that is especially South America has been pretty active, so it’s not that – and they don’t necessarily speak English all that much, but I think culturally they’re more closer to Europe and the U.S. which makes it easier to enter.
So – and the cultural differences I don’t think we even know how to really even approach.
Jim Zemlin: The – let’s talk a little bit more on the technical aspect of where the kernel is going. Earlier usage of the Linux kernel was largely on the servers. It obviously is used for desktop computing, increasingly in mobile and embedded computing.
As you see this, you know, more embedded and mobile devices use Linux, any impact on the kernel at all from a technical perspective?
Linus Torvalds: I actually expected more of an impact. It turns out the mobile devices have grown up so much that even a cell phone, even a fairly, like, middle-of-the-road smart phone today probably has more computing power than the first desktops that were used to run the Linux at. And that doesn’t seem to be stopping.
So, I think especially as far as the kernel is concerned, people worried about that more than I think it turns out you need to worry. The biggest issues on the mobile side tend to be not so much – well, there is still the kernel side; you want to make it smaller, you want to make it more efficient, but I think the thing that more people worry about is actually interfaces.
It makes more a difference that the way you connect to a mobile phone is different from the way you connect to a desktop. You have a very limited keyboard, you have touch screen issues, you have a very small screen and I think the bigger issues tend to be in things like the UI interfaces.
So, you have Qtopia and that seems to be big on the mobile side and the kernel hasn’t seen that much of that. It may be that I just think so and I’m insulated from some of the issues because there’s all these mobile kernel groups involved that I don’t interact with directly, but I suspect on the whole people worry less about the kernel than about user space.
Jim Zemlin: Well, let’s talk about that second half of the comment you made about there’s lots of these sort of mobile-specific kernel groups or Linux distributions out there. And, you know, one of the things that you hear people say is a reason they participate in the Linux development process and open source is because it’s that collective work that really reduces the cost and really allows them to work together effectively.
And by having, you know, sort of groups flaking off, , what can they do from just a best practice point of view in terms of if you’re a mobile device company in getting what you want into the mainline so that, you know, you can have it there indefinitaly so that it’s…
Linus Torvalds: I think the big problem in the mobile world tends to be that the whole market– is so used to being completely fragmentary. Everybody makes, , these one-off pieces of hardware; they’ve done it for the last few decades, they’re very used to basically writing throwaway code and starting entirely from scratch when the next generation is – comes out.
So, they may have generations of hardware for – that go on for many, many years and they support that generation, but then when they finally decide to do another generation, they basically start from scratch.
And when you come with that mindset, you sometimes – as far as I can tell, people don’t even understand the notion of trying to work with the process and trying to get integrated into the standard kernel or the standard utilities because that’s never how they worked before.
So, what a lot of these mobile manufacturers actually do is they pick one version, they usually pick a version that is fairly recent at the time they pick it and then they say, “Okay, this is the base.” And then for the next five to six years for that particular platform, they stick to that version and they enhance it for their own needs.
And when they then want to do their next version and next-generation hardware, they’re in the situation where the rest of the world has worked on something else for those few years and all their modifications are to a version that is now – has nothing to do with what the version is today in the rest of the world and they end up doing what they did before: they throw away their work entirely and start from scratch.
And this is not something I – I don’t think we can help with. I think that mobile market, to some degree, needs to grow up and grow out of that bad behavior.
Jim Zemlin: In some ways it’s a cultural issue not from ahistorical perspective and a geographic perspective, more from a business perspective.
Linus Torvalds: Yeah. It’s a technical cultural issue and technical and business practice cultural issue.
Jim Zemlin: One of the things you talked about was there’s an increasing complexity in how you interface with the kernel and device drivers is obviously a component of this.
I get asked a lot, which this probably won’t surprise you, why doesn’t the kernel have a stable device driver ABI?
Linus Torvalds: Well, there’s – the lack of an ABI is two-fold: one is we really, really, really don’t want one. Every single time people ask for a stable ABI, the main reason for wanting a stable ABI is they want to have their binary drivers and they don’t want to give out source and they don’t – certainly don’t want to merge that source into the stable kernel or the standard kernel.
And that, in turn, means that all the people who actually do all the kernel work and maintain the kernel are basically unable to work with that piece of hardware and that vendor because if there’s any bugs whatsoever, we can’t fix them.
So, all the commercial vendors—even the ones who used to accept binary drivers—have moved or are moving away from wanting to have anything at all to do with binary drivers because they’re completely unmaintainable.
So, there’s one of the reasons. Some people see it as political. There is probably a political aspect to it, but a lot of it is very pragmatic; we just can’t maintain it.
Jim Zemlin: This sounds like another one of those cultural issues where, you know, people were just used to supporting binary drivers and there’s benefit, perhaps, to that, but they don’t maybe even understand the benefit of sharing in the support.
Linus Torvalds: Well, it’s not so, you know, maybe so much the benefit; it’s the fact that when support is distributed. I mean, I end up not having to support most devices, but I end up being kind of the last stop support for when – when if s–t hits the fan and there’s a big problem, in the end it comes all the way up to me.
And when you have that kind of distributed support system when – where everybody ends up being involved at some point, you really can’t afford to have the situation where only a very small subset actually has access to the code that may be causing the problem. You need to have the code out there, not because of any social issues, but simply because you don’t know who’s going to be the one who has to fix it.
So, there’s a real reason why we need to be able to have source code which means that to all kernel developers, a binary interface is basically – it is only a bad thing. There is – there are no upsides whatsoever.
But there’s another reason which is that we actually do end up changing things in radical ways inside the kernel and that has led to the fact that even if we wanted to have a binary interface, we simply couldn’t or we could but it would then stop us from fixing stuff and changing how we do things internally.
And this is something you do see in other projects where, yes, they have binary interfaces for one reason or another—quite often because of commercial reasons—and that just means that they cannot fix their fundamental design. They sign up not just the binary interfaces, they also sign up to the exact design they had when they came up with that interface.
So, there’s – that’s the second major reason why a stable ABI is not going to make – in fact, that means that we don’t even guarantee a stable API; so, even on a source level we say, “Okay, this is the API and we’ll – if you have external drivers that use this, we’ll help you fix them up when we have to change the API. But we don’t guarantee that the same API will work across versions.” And it doesn’t.
Jim Zemlin: But by opening up, you’d obviously be able to work with those issues.
Linus Torvalds: Right. Immediately when people work with, like, source API and then we can say when somebody complains, “Hey, it doesn’t compile anymore. My external module here depended on that function and now it doesn’t exist anymore,” at that point at least we can fix it for them.
So, that’s not a huge deal. It does mean that people who maintain external modules, even with source available, they can’t assume that they can just recompile unmodified across many different versions.
Jim Zemlin: Why do you think more device manufacturers don’t open up their device drivers? And are there any culprits?
Linus Torvalds: There are certainly culprits. There are certainly specific vendors who end up having more problems than others. In fact, sometimes the same vendor may be very good in one area and very bad in another area.
Broadcom is an example of this. They are – they have actually been fairly good when it comes to high-end gigabit network devices, wired network devices, but only when it comes to wireless networks and other more consumer devices, they’ve been completely unable or unwilling to help us at all.
So, sometimes you have the same company acting very differently depending on which market they’re selling into. Certain markets, Linux is a big – for some markets, Linux is a big deal for them; in other markets, it’s not.
Sometimes it’s just – especially when we talk to Taiwanese vendors, one issue is – some of these hardware people, literally, they rev their hardware several times a year; they have 100 different versions of the chips. They have engineers who do drivers for Windows; they just don’t have the resources. they haven’t been able to become part of the Linux community, so they – sometimes we have issues. Finding documentation is really hard for them; maybe it doesn’t even exist internally in a form that they are willing to release.
So, sometimes it’s just a practical issue. Sometimes it’s just that they might want to help us, but their resources don’t end up being in that area.
Jim Zemlin: Have you seen that change as Linux becomes more of important part of industry, more people adopt it, that there’s a critical reason that, you know, they may not have time before but now they have to make time?
Linus Torvalds: It definitely is changing. I mean, it’s – it used to be that very few hardware manufacturers really actively tried to help Linux people write drivers. And now, at least, I’m personally getting the feeling that the companies that don’t try to help, at least with documentation and sometimes even with writing drivers themselves, are starting to even be a minority.
So, it’s definitely changing, but it’s still the case that – especially in certain areas we don’t have the kind of support that I wish we had.
Jim Zemlin: Let’s shift a little bit to issues that I know are near and dear to your heart: legal, legal issues.
Linus Torvalds: Oh, I love legal issues. {Laughter}
Jim Zemlin: I’d like to talk a little bit about licensing, maybe a little bit about patents. Let – tell us a little bit about GPLv3 and, you know, you’ve suggested that GPLv2 works great for you.
Do you imagine any point where you would say GPLv3 would work for you?
Linus Torvalds: Well, I may have strong opinions, but at the same time I’m not – or at least I claim that I’m fairly pragmatic, so I don’t care, per se, about one particular license or another. I want to pick the license that makes the most sense for what I want to do. And at this point in time, Version 2 matches what I think we want to do much, much better than Version 3.
And there’s always been a very clear tension between Linux and open source on one side and the FSF and free software on the other side where, to some degree, Linux was the project that made this whole split in—what should I call it?—approach.
In some ways, Linux was the project that really made the split clear between what the FSF is pushing which is very different from what open source and Linux has always been about which is more of a technical superiority instead of a – this religious belief in freedom.
So, the GPL Version 3 reflects the FSF’s goals and the GPL Version 2 pretty closely matches what I think a license should do and so right now Version 2 is where the kernel is.
Could there be something that happens to change that? Maybe.
Jim Zemlin: What would something like that be?
Linus Torvalds: Well, one of the – what used to be a huge advantage for the GPL was that there was one license and that one license version was basically Version 2. And that resulted in a huge bulk of source code that was all under the same license which meant that you could basically cherry pick, pick and choose and share code as much as possible.
And one of the things Version 3 did was it basically split this source base so that now there are certain projects that are Version 2 only, there are certain projects that are Version 2 or later and there are certain projects that are Version 3 or later.
And that means that now suddenly you can’t maybe share code simply because of license issues and that’s not something new; we’ve always had that. We’ve had that with other licenses. So, there used to be code that was licensed under the Apache license and that was not compatible with Version 2. [NOTE: This is now not the case and Apache is compatible.]
So, it’s not something new, but there is a clear advantage and there are network effects when it comes to licenses so that one – and, in fact, one of the few reasons I see why Version 3 might be useful is simply there ends up being tons of external code that we feel is really important and worthwhile that is under the Version 3 license. And then, in order to avoid the licensing compatibility, we – I suspect I could see the kernel people saying, “Okay, we’ll re-license to Version 3 not because we think it’s the better license, but because it opens up code to us.”
Jim Zemlin: Then, basically what you’re describing is a way that – you end up at the same place, albeit it for very different reasons; one is a philosophical reason and an idea of freedom—freedom meaning access to code from a liberty point of view almost—and then other from just a pragmatic, “Hey, we want to get things done. If there’s more code out there vis-à-vis this model, that’s something we’re interested in.”
Linus Torvalds: Yeah, so I always – I really want to have the Linux license choices be made on pragmatic issues. Clearly there is ideals that go hand-in-hand with those pragmatic choices, but I think licensing is too important to think that it’s not about practical issues as well as your idealistic issues.
Jim Zemlin: You know, a lot of times I talk to people and describe issues around licensing from the perspective of you have sort of on the far right Microsoft talking about how dangerous licenses are and then on the far left you have attorneys talking about how much time you need to spend examining licenses and that they’d be happy to perform that service for you.
What’s the real answer? I mean, is licensing any kind of big risk? I mean, is it any more of an issue as opposed to proprietary software licenses?
Linus Torvalds: Well, I personally think that license choices are really, really important. To me, like, the author’s choice of license under which he releases any code or, I mean, it doesn’t have to be code, it can be anything else, is almost sacred. I mean, it’s that – if somebody really came up with something really normative and really interesting, it’s up to him to choose how it should be used, within reason. I mean, clearly, like, there should be issues about greater good which is why copyright exists in the first place.
But that said, it is a personal choice and I don’t think it’s – I mean, once some person or company, for that matter, has made that choice, I don’t think there’s a lot of reason to them to start arguing about why or why not or trying to say, “Hey, this license is better than that other license.”
I don’t think there’s – I mean, that’s simply not relevant anymore.
Jim Zemlin: I’ll put you on the spot for a second, then, about the idea of personal choice and the license. From the kernel perspective, it’s a personal choice among a lot of people, is that right?
Linus Torvalds: Well, in some sense it started out as a personal choice of just one person, me.
Jim Zemlin: You.
Linus Torvalds: And once you have an existing project – and that’s different from somebody starting a new one. Once you have an existing project, the choice kind of changes. The initial choice is “Which license do I choose?” Once you get past that point is the choice becomes “Do I want to be part of this and do I want to participate considering that the license has been chosen?”
So, then you don’t chose the license anymore, then you choose the project. But it’s still a personal choice, but it’s a completely different personal choice.
Jim Zemlin: So, from that perspective, do you have an obligation to the broader kernel community or the people participating in it to be inclusive if a license choice would change or to…
Linus Torvalds: Well, not just an obligation.,it’s a legal requirement. I cannot change the license on my own anymore. I mean, because I have accepted code over the last 15 years by people who kind of accepted my original choice of the GPL Version 2, I’m not just, I think, ethically bound by those people’s choices, I am also actually legally bound.
I can’t just say, ‘Hey, now we’ll change license to some other license.’ A lot of people participated in development and sent me patches and they are still actually copyright owners of those patches or those changes. And if we actually want the change to the GPL Version 3, it’s not different than changing to any other license; we might – I mean, it is theoretically possible that people decide, “Hey, we want the change to the BSD license” or we want the change to some other license.
In practical terms, for that to happen, everybody who’s a copyright owner really has to agree or the ones who don’t agree, their code needs to be rewritten.
So, in practical terms, that’s not going to happen. The GPL Version 3 is much more likely just because then you are more likely to find people who either started off with Version 2 or later in the first place, so they always accepted Version 3 implicitly.
Or you’re just likely to have people say, “Hey, I accepted Version 2. Version 3 is not that big of a change; I’ll accept that too.”
Jim Zemlin: Do you feel like you’ll play a role as a leader with the legal and sort of moral implications included in that to say, you know, to help guide people on what your personal judgment is?
Linus Torvalds: Right. I do. And it’s one of the reasons I’ve spoken out against the GPL Version 3 before it was released and all the drafts because I wanted to make sure that as a leader in the kernel community I kind of told people want to expect from my standpoint that I was not happy with the drafts, but also explain why and maybe lead people to understand the issues like the people in the embedded areas for whom the Tivo-ization clause was a real downer in Version 3 shouldn’t be ignored.
And they’re a part of the community too – and there I used that community word again, but that it’s not just that the Version number has increased doesn’t necessarily mean that it’s automatically a better license.