Recordings by Linux

On Git

leo — Sat, 07 Aug 2010 17:43:14 +0000

Speaker(s) Linus Torvalds

Language spoken English

Date of Recording Thu, 2007-05-03

Player-image:

In 2005, Linus Torvalds, the creator of the Linux kernel, sat down for two weeks to prototype his second major contribution to the Free Software and Open Source world and to the history of computing in general: Git.

This software allows programmers to collaborate on their projects´code in a number of new methods all together. Two years later, Torvalds is invited to speak at Google Tech Talks. He explains the personal, social and technical stories of how the design principles of “Git” emerged in the first place and answers many questions by the programmers of Google Inc.. His talk contains a lot of humourous banter within the Free and Open Source Communites. It has been viewed over 600.000 times online (update December 2011: over 840.000 times; update February 2015: over 1.300.000 times; update December 2016: over 1.670.000 times; update July 2018: over 2 million times) making it one of the most influential media files ever that deals with the inside world of todays programmers. It may proove to be just as interesting for social anthropologists and media philosophers alike.

Additional information

Source on Google Tech Talks: http://www.youtube.com/watch?v=4XpnKHJAok8

License:

License ‘open’.

The transcript is retrieved from
https://git.wiki.kernel.org/index.php/LinusTalk200705Transcript

You are also able to watch the video of this talk at Youtube:
http://www.youtube.com/watch?v=4XpnKHJAok8

00:00 Andrew Morton (also one of the core Linux developers, employed by Google): Thank you, for coming everybody, some of you probably already have heard of Linus Torvalds, those of you who haven’t, you are the people with Macintoshes on your laps.

He is a guy who delights being cruel to people. His latest cruel act is to create a revision control system which is expressly designed to make you feel less intelligent than you thought you were.

Thank you for coming down today, Linus. I’ve been getting e-mails for the past few days from people saying “where is Linus, why hasn’t he merged my tree — he does not love me anymore”. And he walked in my office this afternoon, “what are you doing here?” Thank you taking the time off. So Linus is here today to explain to us why on earth he wrote a software tool which, eh, only he is smart enough to know how to use.

[applause]

Linus Torvalds: 00:54 So I have a few words of warning which is I do not actually do speaking very much, partly because I do not like speaking, partly because over the last few years everybody actually wants me to talk about nebulous visions for the next century about Linux, and I am a geek and I actually prefer talking about technology.

So that’s why I am not talking about the kernel, because it is just too big to cram into a one hour talk although apparently Andrew did that two days ago. I am instead talking about git, which is the source control management system that we use for the kernel.

I am really really really bad at doing slides, which means that if we actually end up following these slides, you will be bored out of your mind. And the talk will probably not be very good anyway, so I am the kind of speaker who really enjoys getting questions, and if that means that we kind-of veer off in the tangent, you’ll be happier, I’ll be happier and the talk will probably be more interesting anyway. I don’t know how you do the things here at Google talks, but I am just saying, don’t feel shy as far as I am concerned. If your manager will shoot you, that’s your problem.

[shows “Credits” slide]

02:22 I want to give a few credits before I start.

I credit CVS in a very very negative way. Because I, in many ways, when I designed git, it’s “what would Jesus do” except that it’s “what would CVS never ever do”-kind of approach to source control management. I’ve never actually used CVS for the kernel. For the first 10 years of kernel maintenance, we literally used tarballs and patches, which is a much superior source control management system than CVS is, but I did end up using CVS for 7 years at a commercial company, and I hate it with a passion.

When I say I hate CVS with a passion, I have to also say that if there any SVN users (Subversion users) in the audience, you might want to leave. Because my hatred of CVS has meant that I see Subversion as being the most pointless project ever started, because the whole slogan for the Subversion for a while was ‘CVS done right’ or something like that. And if you start with that kind of slogan, there is nowhere you can go. It’s like, there is no way to do CVS right.

So that’s the negative kind of credit.

03:55 Positive credit is BitKeeper. and I realize that a lot of people thought there were a lot of strife over with BitKeeper, and that the parting was very painful in many ways. As far as I am concerned, the parting was amicable, even though it looked very non-amicable to outsiders. And BitKeeper was not only the first source control system that I ever felt was worth using at all, it was also the source control system that taught me why there is a point to them, and how you actually can do things.

So Git, in many ways, even though from a technical angle it is very very different from BitKeeper, which was another design goal, because I wanted to make it clear that it wasn’t a BitKeeper clone, a lot of the flows we use with git come directly from the flows we learned from BitKeeper. And I do not think you use BitKeeper here inside Google? As far as I know, BitKeeper is the only commercial source control management system that actually does distribution, and if you need a commercial one, that’s the one you should use for that reason.

I’d also like to point out that I’ve been doing Git now for slightly over two years, but while I started it, and I made all the initial coding and design, it’s actually been maintained by a much more pleasant person, Junio Hamano, for the last year and half, and he’s really the person who actually made it more approachable for mere mortals. Early versions of git did require certain amount of brainpower to really wrap your mind around. It’s got much much easier since. There’s obviously the way I always do everything is I try to do everybody else to do as much as possible so I can sit back and sip my Piña Colada, so there has been a lot of other people involved, too.

That’s the credits. With those out of the way…

[shows the “Content” slide]

06:11 So this slide is now one day old. I didn’t actually do the slides last night because last night I was out carousing and eating Sushi, but the slides will talk about implementation of a reliable, high performance, distributed content management thing, and the key word here is actually the “distributed” part. I will start off trying to explain why distribution is so important. If we never get past that point, I will actually be happy. If we never get to actually what git’s implementation internally is, it’s fine.

I am not also trying teach you how to use git. There is this thing called “google.com”, what you do is, it has, you may have seen it, it has this thing you can type things in, and you type “git” and you press the “I’m feeling lucky” button, and you’ll actually get the homepage, the homepage has tutorials, it has the user manual, they are all in HTML, if you actually want to learn to use git, that’s where you should start, not at this talk.

But as mentioned, if we actually start veering off topic into other tangents because of questions, it’s all good.

[shows “Content Advisory” slide]

07:35 I already gave you kind of a heads-up warning on this, I use the term SCM, which I consider to mean “source code management”, that is revision control. Some other people think SCM means “software configuration management” and see it as a much bigger feature including release management and stuff like that; that’s not what I am talking about, although git is clearly relevant in that setting, too.

CVS, we already went there.

You can disagree with me as much as you want, but during this talk, by definition, anybody who disagrees is stupid and ugly, so keep that in mind. When I am done speaking, you can go on with your lives. Right now, yes, I have strong opinions, and CVS users, if you actually like using CVS, you shouldn’t be here. You should be in some mental institution, somewhere else.

So before actually I go and talk about the whole distribution thing, which I think is the most important part, I’ll talk a bit about the background because it invariably comes up, because people if they’ve heard about git, a lot of the things they’ve heard about is the background for doing git in the first place.

[shows “Background” slide]

09:01 One piece of background information is I really am not a SCM person. I have never been very interested in revision control, I thought it was evil, until I met BitKeeper, I actually credit that to some degree for why git is so much better than everything else, it is because my brain did not rot from years and years of thinking CVS did something sane.

I needed a replacement for BitKeeper. The reason for that was BitKeeper is a commercial product, but BitMover and Larry McVoy allowed it to be used freely for open source projects, as some of you may know, the only restriction was that you were not supposed to reverse engineer it and you were not supposed to try to create a competing product. And I was happy with that, because quite frankly as far as I am concerned, I do open source because I think it is the only right way to do software, but at the same time I would use the best tool for the job, and quite frankly BitKeeper was it. However, not everybody agreed with me. They are ugly and stupid, but they caused problems and it resulted in the fact that Larry and I had several telephone conversations, which ended up saying “ho, we’d all be much happier if we just part ways and don’t make this any worse”; so we did. And I made the Linux 2.6.12-rc2 release, about 2 years ago, and said “I’m not going to touch Linux until I have a replacement for BitKeeper for doing source code maintenance”. And one of the replacement options was going back to tarballs and patches, but nobody really really liked that anymore. So I actually looked at a lot of alternatives. Most of them I could discard without even trying them out. If you’re not distributed, you are not worth using, it’s that simple. If you perform badly, you are not worth using, it is that simple. And if you cannot guarantee that the stuff I put into an SCM comes out exactly the same, you are not worth using. Quite frankly, that pretty much took care of everything out there.

There are a lot of SCM systems that do not guarantee that what you get out of it again is the same thing you put in. If you have a memory corruption, if you have a disc corruption, you may never know. The only way you know is you notice that there is corruption in the files when you check them out. And the source control management system does not protect you at all. And this is not even uncommon. It is very very common.

The performance issue — one of the things I kind-of liked was a system called Monotone, which actually I think there was a talk at Google about them some time ago, I am not sure, it had a lot of interesting ideas, but the performance was so horrendously bad, that, I tried it for a day and realized that I cannot use it.

The end result was that I decided I can write something better than anything out there in two weeks, and I was right.

[shows “Distribution” (cheesy graphics) slide]

12:24 So, now we get to the distribution, and this is the worst slide of them all, and I am not very proud of it, but the problem is that distribution is really really important but when I try to make slides about it, I could not do it. And a part of it is my obvious artistic talents, which are on display for all of you, but a part of it is that it is really hard to explain.

So before I even start, I’d like to know, how many people are used to the notion of a truly distributed source control management system?

[audiences raise hands]

13:01 Are most of you kernel developers? No? OK, so there were maybe ten hands coming up.

Being distributed very much means that you do not have one central location that keeps track of your data. No single place is more important than any other single place. So for example this is why I would never touch Subversion with a ten-foot pole. There is a massive subversion repository and it’s where everybody has to write. And the centralized model just does not work when,… let’s look at a few of the cases.

[shows “Distribution” (bullets) slide]

13:47 I say it’s so much more than just off-line work, but the off-line work part is actually maybe the most obvious thing, which is that you can take a truly distributed source control management system, you can take it on a plane and even if they don’t offer wi-fi and satellite hookups, you just continue working, you can look at all of your logs, you can commit, you can do everything you would do even if you were connected to a nice Gigabit Ethernet directly to the backbone. And that is really important. It is doubly important when you have hundreds or thousands of people working on the same project, and they may not be literally disconnected but in practice they aren’t really well connected either. So part of distribution is this off-line work theme, even if it is not completely off-line, it is important to be able to do everything you want to do from any location without having to be able to access the server. What that basic fact actually results in is that you effectively have a lot more branching, because everybody who has a complete repository and who can do commits on his own, will effectively has his own branch, even if he does not realize it. Even if you think of your project as just having a single branch, every single time you disconnect your laptop and start working with it, you are on your own branch. And this is really really important and it is very different from anybody who is used to CVS where branching is considered something that only true gurus do. How many of you have ever used CVS?

[audiences raise hands]

OK, everybody. How many of you have really done a branch and ever merged it in CVS?

[audiences raise hands]

Good job. I mean, it wasn’t everybody, but it was actually more than I expected. How many of you enjoyed the experience?

[laughter]

15:58 Oooh, OK, so there were a couple. It is considered hard. In CVS when you merge a branch, I’ve done it, as little as possible but I’ve had to do it. What you do is you plan ahead for a week, and you basically set aside one day for doing it. Am I wrong? I am not seeing a lot of people saying “No, it was easy, and I liked it”. It’s horrible.

If you are distributed, you have to realize that every single person has his own branch. It’s not horrible, it’s not something you even have to set up, it just is. In fact, in git, we like branches so much that a lot of people just have 5 or 10 or 15 of them, just because once you realize that you have to have a special branch anyway, you might as well have many and one of the branches you do some experimental work on, and one of the branches you do maintenance on. So branching is much more inherent when you do distribution.

One of the other things that, to me, is important is that by being distributed, you also automatically get to be slightly more trustworthy. I have a theory of backups, which is I do not do them, I put stuff up on one site and everybody else mirrors it, and if I crash my own machine, I don’t really care, because I can just download my own work right back. And it works beautifully well, and I do not have to have an MIS department. I hardly suggest everybody else do the same. But this only really works in a distributed environment. If you use CVS, you can’t do this, if you use… what do you use here? Perforce? … Perforce. Eh … I’m sorry. I’m sure it’s better than CVS.

[whispers] A tiny bit.

[audience laugh]

18:04 So that’s part of it. One of the really nice things which is also, maybe you do not have this issue inside a company, but we certainly have it in every single open source community I’ve ever seen that uses CVS or Subversion or something like that is that you have this notion of “commit access”. Because you have a central repository, which means that everybody who is working on that project needs to write to that central repository. Which means that, since you do not want everybody to write to the central repository because most people are morons, you create this class of people who are ostensibly not morons. And most of the time what happens is that you make that class too small, because it is really hard to know if a person is smart or not, and even if you make it too small, you will have problems. So this whole commit access issue, which some companies are able to ignore by just giving everybody commit access, is a huge psychological barrier and causes endless hours of politics in most open source projects.

If you have a distributed model, it goes away. Everybody has commit access, you can do whatever you want to your project. You just get your own branch, you do great work or you do stupid work, nobody cares, it’s your copy. It’s your branch. And later on if it turns out that you did a good job, you can tell people, “hey here is my branch, and by the way it performs 10x faster than anybody else’s branch, so nyah nyah nyah, how about pulling from me?” And people do. And that’s actually how it works, and we never have any politics, that’s not quite true – we have other politics, but we do not have to worry about “commit access” thing. And I think this is a huge issue, and that alone should mean that every single open source system should never use anything but a distributed model. You get rid of a lot of issues.

One of the things that commercial companies, distributed model actually help also with their release process. You can have a verification team that has its own tree. And they pull from people and they verify it and when they verified it they can push it to the release team. And say, “hey we have now verified our version”, and the development people they can go on playing with their HEAD, instead of having to create tags, branches or whatever you do to try to keep off each other’s toes, again you keep off each other’s toes by every single group can have its own tree and track its work and what they want done. So distributed is really really central to any SCM you should ever use.

So get rid of Perforce, now.

[applaud]

21:16 It’s sad, but it is so so true. And that was my only real slide about distribution. And I’d love to get questions, because we are now moving into other areas.

Audience: 21:36 So how would you do it? If you had this monstrously awesomely big codebase and you wanted to use this without stopping business for 6 months, how would you do it?

LT: Stay by the mic, because I could not quite make out your question,… OK, he went away.

How would you do this? So, an example of actual distribution is, you have a group of five people working on one small particular feature. And that means that for a while that feature will be very very broken, right? Because nobody actually creates perfect code the first time around, except me, but there is only one of me, right? So what happens is they want/need to have their own tree, that they can work in, without affecting other people. You can do this in many different ways. In CVS one of the most common ways, because branches are so painful, is that you do not actually commit. You never commit until it passes every single test. And then you have for example at your company, you have a very strict committing rule saying “you will never ever commit until it’s passed the whole test suite, and by the way the fact that the test suite takes two hours to run, tough”.

You cannot afford to commit. And this is something that happens at every single company. I bet it happens even here at Google. You probably have a strict testsuite and you are not supposed to commit unless it passes, and then in practice, people make one-liner changes and ignore the test suite because they know the one-liner changes can’t possibly break. This happens. This is a horrible horrible model. It just means that you make huge commits, because you commit something after you worked on it for two weeks, and you have three people working in the same sandbox because before they commit they can’t see the changes that the other people made, this is common, it happens everywhere, it’s scary.

The other alternative is to use branches even in a centralized environment, but branches always end up being pretty expensive to do so you cannot do them for experimental features. You do not know beforehand if it’s something that’s gonna take one day or two weeks, but most of the time most programmers say “hey, I can do this in 48 hours”. And it turns out, nah, no you couldn’t. But because you feel you can do it in 48 hours, creating a branch, even in systems that are better at creating branches than CVS, is a big pain. So you don’t do it because you think you can get it resolved and you’re back to case number 1, but if you decide to create a branch, you will affect everybody else’s repository, because in a centralized environment, branches are global. So you’re kind of screwing with everybody else but at least you are not screwing with their main HEAD branch. You are adding stuff to their repositories but hopefully in a way that they won’t notice. But it does make everybody’s repositories bigger.

So either way, you can’t win.

In contrast, in a distributed environment what you do is, you have five people, they pull the current HEAD, which is hopefully good and tested and they start working on it and they start committing on it and you don’t need to wait for two weeks until your commits are stable, because your commits are always local. And what happens is within that group of five people, you can pull from each other. That’s what distributed means, there is no central location, it means everybody is the same and you can merge between yourselves, so not only can you commit every single line if you want to, without having to run the two-hour testsuite, but you can then communicate by pulling and merging each other’s work and one person finds a bug and commits it and tells the other four people “hey, my repository has fix for this”, and then when that group is done two weeks later, they can tell their manager, “hey we have done this, can you ask the main group to pull and they will get this new feature, and by the way we tested it over two weeks, and it works, and it performs this much better because we have actually been able to time it before we even ask anybody else to look at it”. And that is a hugely better model for doing development. And this is the model that the kernel uses. It turns out that in many places we do not need all that power, even in the kernel. So people usually don’t pull within one group, but it does happen for example the networking people sometimes affect the NFS people and the fact that they can synchronize actually helps. So this is a real practical advantage.

Somebody else has a question.

Audience:

It feels like the politics has just been moved to like an indirect political question. Everybody has an access and they are all playing with their branches in their sandbox, but at the end of the day, there has to be merging and resolving unless you have 80 billion flavors of every Linux kernel.

LT: Absolutely. So in practice you will never see, oh, there will be a thousand or maybe twenty thousand different branches, but in practice you won’t ever see them because you won’t care. You will see like a few main branches, maybe you’ll see only one. In the case of the kernel, a lot of people, they only really look at my branch. so even though there are lot of branches you can ignore them. What happens is that the way merging is done is the way real security is done. By a network of trust. If you have ever done any security work, and it did not involve the concept of network of trust, then it wasn’t a security work, it was masturbation. I don’t know what you were doing but trust me, it’s the only way you can do security, and it’s the only way you can do development. The way I work, I don’t trust everybody. in fact I am a very cynical and untrusting person. I think most of you are completely incompetent. The whole point of being distributed is I don’t have to trust you, I do not have to give you commit access. But I know that among the multitude of average people, there are some people that just stand out that I trust, because I’ve been working with them. I only need to trust 5, 10, 15 people. If I have a network of trust that covers those 5, 10, 15 people that are outstanding, and I know they are outstanding, I can pull from them. I do not have to spend a lot of brainpower on the question. When Andrew send me patches, he actually does not use git, it’s some kind of defect, but other than that, he is a very solid person. When he asks me to pull, he does it by sending a million patches instead, I just do it. Sometimes I disagree with some of these patches, but at some point, trust means, … never having to say you’re sorry? … I dunno … It basically means that you have to accept other people’s decisions. And the nice thing about trust is that it does network. That’s where the network of trust comes in. I only need to trust a few people that much. They have other people, they have determined, hey, that guy is actually smarter than I am, that’s actually a really good measure of who you should pull from. If you have determined that somebody else is smarter than you, go for it. You can’t lose. Even if it turns out that you pulled crap and somebody else starts complaining, you know who you pulled from and you can just point to that other person and say “hey, I just pulled, go to him, he knows what he is doing”. That’s how I work, that’s how probably most of my lieutenants work. I pull the networking changes from one person, he gets them from many other people that he’s worked with over time, so this is how it all comes together, it does not have to come together to one point. In the kernel it comes together to one point largely I think for historical reasons, and actually I’ve always tried to kind of encourage people to have more trees, so we do have vendor trees, we do have -mm tree, we have multiple one points, and it happens to be that my one point is getting maybe more attention than it always should.

Even if it doesn’t come down to one point, it means that you can take these thousands of branches, and ignore 99.9% of them. And you know, that hey, there are five branches that are really interesting to follow because I am interested in those subareas. And it all works very naturally.

One of the nice things about this whole network of trust is it’s not just easy to do technically, it’s actually how every single person in this room is very fundamentally wired to work. It is how we think. We do not know 100 people. We have 5, 7, 10 close personal friends, well, we are geeks so we have two, but that’s basically how humans work is that we have these people that we really trust, it’s family, it’s close friends, and it really fits, you don’t even have to have a mental model, it fits how we are wired up. So there’s huge advantages to it with this whole model of network of trust.

Audience: Do you know of any companies that are using distributed systems internally? It seems like there might be a risk of kind-of balkanizing the code base, as in people not being in the same sandbox don’t contribute back.

LT: So quite frankly there aren’t that many distributed systems. There is BitKeeper, it is clearly being used at commercial companies, we might have somebody in the audience who actually knows but, what … [comment from audience], so HP is using things like BitKeeper for the printer project. I am sure there are lot more companies. In the open source world, there are two distributed systems that are worth looking at right now. One of them is obviously git. And you really should pick that one. But the other one is Mercurial, which actually has pretty much the same design. There are huge differences in implementation and there are some differences in the detail, but it boils down to a very similar model. Git just does it better. Everything else, it’s either centralized, or it’s too unstable or too slow to use for anything big.

Audience: Is there an advantage for a company to have everybody playing in the same sandbox?

LT: I think a lot of companies think that there is an advantage to that. I know that inside companies, I do not think that a lot of companies use git knowingly, in the sense that it is a company decision. I know several companies who use git internally, not knowing that they do so, because they actually have their main repository in Subversion, and a lot of developers then import it into git because git can actually merge things for you. So you can take a Subversion tree, import into git, let git do the merge, which would be a major headache to do in Subversion, create a merge commit, and actually export it back to Subversion, and nobody else even knew you used git. It’s kind of sad, but we have cases of people talking about doing exactly that inside companies. Git has not been around in a form where a lot of people would be comfortable using it for more than a half year or so. We have had so huge improvements to the user interfaces that realistically a year ago at commercial companies a lot of people would just have said it’s too hard to use. I think we are way past that hump. Git is much easier to use than CVS, really. Most people tend to … eh, it’s easier to use than anything else. It’s just, … get over it. You do not have to use all the powerful tools, some of them might be things you would want to explain and introduce to people only after they got over the initial hump of understanding what distribution really means, but the basic stuff is really easy to do.

Audience: One characteristic of a centralized system is that it’s the original developer who has to resolve any merges, who has to fix merges, how do you do that in git? And how do you minimize merge conflicts?

LT: Thank you for asking me the question. Did I tell you to ask that question?

One of the really nice parts of git is that (a) git does make things more,… much easier to merge than a lot of other systems. Merging a branch in CVS tends to be really painful. I merge,… one of my main statistics is that the kernel is actually one of the biggest open source projects. We have 22,000 files. We’ve used git for two years. During those two years, we have averaged 4.5 merges a day, every single day. That’s not something you do with something where merging is hard. So git makes merging easy. But you will inevitably have cases where two maintainers send me requests to “please pull my stuff” and I pick one of them at random, usually because their mail happened to be first in my mailbox, and I pull their stuff, and another person had made changes that, it does not have happen that often but it does happen, made changes that clashed so much that, I said “I could fix this up, but I really don’t want to”. I did not write the code, it’s not my area of expertise, it’s networking or something like that, I can’t really judge it, I can’t test it, so asking me to resolve the merge is just crazy, it’s not how you should do things.

Ok, the Windows machine flaked out again.

So what happens is, remember, distribution means nobody is special. So instead of me merging, I just push out my first tree, that did not have any merge issues, and I tell the second person, “hey, I tried to pull from you, but I had merge conflicts and they weren’t completely trivial, so I decided you get to do the honors instead.” And they do. And they know what they are doing because it’s their changes. So they can do the merges and they probably think I am a moron because the merge was so easy and it is obvious I should have taken their code, but they do the merge and they update their tree, and say “hey, can you pull from me now”, and I pull from them and they did all the work for me. That’s what is all about: they did all the work for me. So,… and I take the credit. Now I just need to figure out the step 3: profit.

That’s kind of another thing that comes very naturally from being distributed. It’s not something that is special to git. Git makes merging easier than anything else, but git does it exactly because git is distributed.

Audience: I do not entirely understand why you think it is necessary to have a distributed system to have,… it seems like you get a lot of the good effects, at least for a place like a corporate, for open source development it seems very useful for everybody can work on their own but, when you really have a centralized corporate tree, then a centralized system with really cheap branches wouldn’t that give you pretty much the same effect? Or is it just impossible to do?

LT: I will argue that centralized systems can’t work, but it is clearly true that if you are in a tightly controlled corporate environment, centralized systems work better, and it is unquestionably true that people have been able to use centralized systems for the last 35 years. Nobody is really arguing that centralized systems cannot work. They cannot work as well as distributed systems. One of the issues you tend to have is centralized systems inevitably have problems when you have groups in different locations. It tends to work really well if you have a really beefy backbone fibre and I guess for Google you probably do have some kind of network going, I dunno, and maybe it is not as big of an issue as it is for other projects, but trust me, not having to go over the network for everything is a huge performance saver. I do, … this is, … oh, I cannot show you a demonstration, and it’s not a very interesting demonstration anyway, but this is a laptop that is 4-5 years old. It’s like a Pentium-M 1.6 GHz thing. I could show you me doing a full diff of the kernel on that laptop in just over a second. On my main machine, it just takes less than a tenth of a second. That’s the kind of performance you simply cannot get if you have to go over the network. We are talking a couple of packets, going over the network, and you just blew the performance. So if you have a decentralized system and if you are used to having something like commit or diffing the whole source tree taking 30 seconds, maybe 30 seconds does not sound that bad to you. Trust me, when you are used to it taking a tenth of a second, 30 seconds sounds pretty bad. So there are huge performance issues, even if you have a good network. Never mind the fact that most people do not have a good network. The other thing is, branches, even if you make them technically very cheap to create, just the fact that you created them and everybody sees them means, because everybody will see them since they are centralized, basically means that you don’t want to make branches willy-nilly. You will have namespace issues. What do you call your branch? Will you call it “test”, Oh, by the way there are 5000 other branches called test1 through 5000, so now you have to make up all the naming rules for your branches because you have a centralized system that has a centralized branch namespace, which is kind of inevitable when you have a centralized system. How does that work in a distributed environment? You call your branch “test”, and it’s that easy — well actually you shouldn’t call it “test”, you should basically name your branches the way you name your functions, you should call them something short and sweet and to the point — What is that branch doing. Git gives you by default one branch that is called “master”, it’s short and sweet and to the point: it’s the master branch. But you can make a branch that is called “experimental-feature-x”, and it will be obvious. But this is something you simply cannot do in a centralized environment. You cannot call branches experimental-feature-x. You have to make up stupid idiotic names. I worked for a company that had nice, as nice as you probably can make them, scripts around CVS, that helped you make branches, you could actually make branches with a simple command, it did not take that long, it picked a name for you, exactly because it would pick the number, so you give it a basename, and you would say “this is my branch doing so-and-so”, and it would call your branch “so-and-so-56”. And it would tag where you started that branch, because in CVS you need to do that too, and you needed to… it took a while, but it worked. You can do these things in centralized systems but you do not need to. If your system is decentralized, it just works. And that is how it should work. So, I’m not saying, I am not going to force you to switch over to decentralized, I’m just going to call you ugly and stupid. That’s the deal.

Anyway, now we are on the Performance slide.

Audience: Can I ask a question?

LT: Yeah.

Audience: Two questions, actually. One is, how many files would git take, and the second one, let’s say you have a humongous tree under git, would it be possible to check out a part of the tree?

LT: Great questions. Those questions actually kind of dovetail into a different issue, even though they are performance related. One of the things that git is really special about, and this is special even with regards to things like Mercurial which otherwise is fairly similar, git tracks your content. It never ever tracks a single file. You cannot track a file in git. What you can do is you can track a project that has a single file, but if your project has a single file, sure do that and you can do it, but if you track 10,000 files, git never ever sees those as individual files. Git thinks everything as the full content. All history in git is based on the history of the whole project. This has implications for performance. When you use CVS, it’s perfectly fine, although it’s stupid, to have one huge repository that has a million files in it. Because at the end of day, CVS actually thinks of all those million files as a single file and you can actually ask CVS to update only that one file, because CVS really thinks in those terms. And that is actually true for pretty much everything else, too. It is actually even true for BitKeeper, that is one of the mistakes in BitKeeper.

The problem of thinking in terms of single files is that quite often, especially if you are high-level maintainer like me, I have 22,000 files to track, I do not care about one of them. I might care about a subcollection of them that contains maybe 1,000 files, I might care about the USB subsystem. But I never care about a single file. So git tracks everything as a collection of files, and if you ask for the history of a single file, git will literally start from the global history and it simplifies it. It is a very efficient system, you would normally not even realize that it does that, but it does mean that if you try to track a million files in one repository, when you then ask for a single-file history, it’s going to be slower. So it has a different scaling properties than a lot of other systems for this very fundamental design reason. We have used big repositories. We’ve imported things like the whole SVN history of, maybe not the whole — something like 3/4 of the SVN history of the whole KDE project. And the KDE people are, eh … I shouldn’t call them, … I won’t, I like KDE, but trust me. But they put every single component in one repository. Not very smart.

So what you ended up with is that you had a repository that took I think 8GB under the CVS tree, and SVN blew it up to like 3x that size, maybe it wasn’t quite 8GB in CVS but it was big. It was more than 4GB. Git would actually compress it down to something like 1.3GB. So git is actually very efficient at taking this project and just smashing it together and most things actually perform very well, but certain things did not. The things that do not perform very well if you put a million files in one repository is initial clone. When you get it, you get it all. You put it in one repository, git thinks it is one thing. Don’t do that. If you have multiple components, do them as separate repositories, you can actually have what we call superproject that contains pointers to other projects, the user interfaces there are somewhat lacking, but you keep separate projects separate. Then you avoid the problem of “you have to get it all”. Because with git you do have to get it all.

Audience: What about shared code?

LT: If they are all shared code, what you can do with git, if you actually have a lot of shared stuff, since git internally uses a content addressable filesystem, if there are identical files with identical contents, it will actually use the exact same object for them. And save you a tons of space. And you can have these shared objects and still have them as separate entities. You can still have them in separate repositories that just have a shared filesystem backing the data. You can do that. If you actually have shared code in the sense that you for example have a library, that is used by five different things, that is when you use the superproject support where you have one git repository that just tracks all the other git repositories, and it may contain stuff like shared build infrastructure, too, but then the individual pieces are individual. This is like CVS modules. In CVS modules are not really individual but that’s because in CVS a directory is kind of a thing on its own anyway, so CVS module is a combination of this and just tracking them all, but you can basically think of it as CVS modules. And we do support it but I do have to admit that that code is fairly recent and that’s one area where our user interfaces right now are definitely lacking.

There was probably some part of your question that I completely forgot.

Audience: Can you have just a part of files pulled out of a repository, not the entire repository?

LT: You can export things as tarballs, you can export things as individual files, you can rewrite the whole history to say “I want a new version of that repository that only contains that part”, you can do that, it is a fairly expensive operation it’s something you would do for example when you import an old repository into a one huge git repository and then you can split it later on to be multiple smaller ones, you can do it, what I am trying to say is that you should generally try to avoid it. It’s not that git can not handle huge projects, git would not perform as well as it would otherwise. And you will have issues that you wish you didn’t not have.

So I am skipping this issue and going back to the performance issue. One of the things I want to say about performance is that a lot of people seem to think that performance is about doing the same thing, just doing it faster, and that is not true.

[shows “Performance” slide]

That is not performance is all about. If you can do something really fast, really well, people will start using it differently. One of the things I wanted to make sure is that merges go really really quickly because I want people to merge often and merge early, because as it turns out it becomes easier to merge. If you merge every day, suddenly you never get to the point where you have huge conflicts that are hard to resolve. So if you actually make branching and merging easy, you actually avoid a whole class of problems that you otherwise have a really really hard time avoiding. So for example, let’s go back to one of the things where I think the designers of subversion were complete morons. Strong opinions, that’s me, right? There are a few of them in the room today, I suspect. You are stupid.

[laughter]

Subversion for example, talks very loudly about how they do CVS right by making branching really cheap. It’s probably on their main webpage where they probably say branching in subversion is O(1) operation, you can do as many cheap branches as you want. Nevermind that O(1) is actually with pretty large O I think, but even if it takes millionths of a second to do branching, who cares? It’s a wrong thing you are measuring. Nobody is interested in branching, branches are completely useless unless you merge them, and CVS cannot merge anything at all. You can merge things once, but CVS then forgets what you did, you can never ever merge anything again without getting horrible horrible conflicts. Merging in subversion is a complete disaster. The subversion people kind of acknowledge this and they have a plan, and their plan sucks too. It is incredible how stupid these people are. They’ve been looking at the wrong problem all the time. Branching is not the issue, merging is. And merging they did not do squat for, five years after the fact. That is sad.

So performance is important, but you need to look at what matters.

Performance for making a branch under git, it’s literally you create a new file that is 41-byte in size. How fast do you think that is? I don’t think you could measure it. You could, well, if you use Windows, probably you could measure it, because file… [audience: laughter] but whatever, it is so fast you cannot really measure it. That’s creating a branch. Nobody cares. It’s not an issue. That’s not it. The only thing that matters is how fast can you merge. In git, you can merge… I merge 22,000 files several times a day, and I get unhappy if a merge takes more than 5 seconds, and all of those 5 seconds is just downloading all the diffs, well not the diffs but its the deltas between two trees, the merge itself takes less than half a second. And I do not have to think about it. What takes longer than the merge is, after every merge by default git will do a diffstat of everything that changed as a result of that merge because I do care about that. When I merge from somebody, I trust them but on the other hand, hey they might have stopped using their medication, so I trust them but, let’s just be honest here, they might have been Ok yesterday, but today might not be a good day, so I do diffstat and git does that by default, you can turn it off if you really want to but you probably shouldn’t, it’s fast enough anyway, the diffstat usually takes, if it’s a big merge, the diffstat usually takes a second or two. Because creating a diff and actually doing all the stats on, how many lines changed, that actually is much more expensive than doing the merge itself. That’s the kind of performance that actually changes how you work. It’s no longer doing the same thing faster, it’s allowing you to work in a completely different manner. That is why performance matters and why you really should not look at anything but git. Hg (Mercurial) is pretty good, but git is better.

I think I am running out of time, we’ll see if we have any, … oh, Ok, this one is still interesting.

We never got to the implementation part, you really don’t care, I’ll say so much about implementation is, the implementation is really simple. The code, the data structures are really really really simple. If you then look at the source code and realize it’s maybe 80,000 lines mostly in C, and it’s a kind of C I write, most people don’t understand, but I comment it. The source code may sometimes look complicated because we are very performance centric, I am. I really care, and sometimes to make things go really fast, you have to use more complicated algorithms than just checking one file at a time. When you are doing 22,000 file merges, you do not want to check one file at a time, you want to check the whole tree in one go and say, “Ah they are the same, I do not have to do anything”. So git does things like that and that is kind of blows the source code up a bit, because doing it well is complicated, but the basics are really really simple.

And one of the basics is this trust and reliability thing. Every single piece of data, when git tracks your content, we compress it, we delta it against everything else, but we also do a SHA-1 hash, and we actually check it when we use it.

If you have disc corruption, if you have RAM corruption, if you have any kind of problems at all, git will notice them. It’s not a question of if. It’s a guarantee. You can have people who try to be malicious. They won’t succeed. You need to know exactly 20 bytes, you need to know 160-bit SHA-1 name of the top of your tree, and if you know that, you can trust your tree, all the way down, the whole history. You can have 10 years of history, you can have 100,000 files, you can have millions of revisions, and you can trust every single piece of it. Because git is so reliable and all the basic data structures are really really simple. And we check checksums. And we don’t check some UDP packet checksums that is a 16-bit sum of all the bytes. We check checksums that is considered cryptographically secure. Nobody has been able to break SHA-1, but the point is, SHA-1 as far as git is concerned, isn’t even a security feature. It’s purely a consistency check. The security parts are elsewhere. A lot of people assume since git uses SHA-1 and SHA-1 is used for cryptographically secure stuff, they think that it’s a huge security feature. It has nothing at all to do with security, it’s just the best hash you can get.

Having a good hash is good for being able to trust your data, it happens to have some other good features, too, it means when we hash objects, we know the hash is well distributed and we do not have to worry about certain distribution issues. Internally it means from the implementation standpoint, we can trust that the hash is so good that we can use hashing algorithms and know there are no bad cases. So there are some reasons to like the cryptographic side too, but it’s really about the ability to trust your data. I guarantee you, if you put your data in git, you can trust the fact that five years later, after it is converted from your harddisc to DVD to whatever new technology and you copied it along, five years later you can verify the data you get back out is the exact same data you put in. And that is something you really should look for in a source code management system.

One of the reasons I care is we actually had for the kernel a break-in on one of the BitKeeper sites, where people tried to corrupt the kernel source code repository, and BitKeeper actually caught it. BitKeeper did not have a really fancy hash at all, I think it is only 16-bit CRC, something like that. But it was good enough that you could actually see clumsy attempt, it was not cryptographically secure but it was hard enough in practice to overcome that it was caught immediately. But when that happens once to you, you got burned once, you do not ever want to get burned again. Maybe your projects aren’t that important, my projects, they are important. There is a reason I care.

This is also one of the reasons, to go back to distribution angle a bit, when you do, Google, for example, Google code you have your source repositories that you help people maintain and I think you do so under subversion, and I would never ever trust Google to maintain my source code for me. I am sorry. You are not just that trustworthy. The reason I really prefer distributed systems is I can keep my source code behind three firewalls on a system that does not allow ssh in at all. When I am here I cannot read my e-mails because my e-mail goes onto my machine and the only way I can get into that machine is when I am physically on that network. So maybe I am a cuckoo, maybe I am a bit crazy, and I care about security more than most people do. But the whole notion that I would give the master copy of source code that I trust and I care about so much I would give it to a third party is ludicrous. Not even Google. Not a way in Hell would I do that. I allow Google to have a copy of it, but I want to have something I know that nobody touched it. By the way I am not a great MIS person so disc corruption issue is definitely a case that I might worry about because I do not do backups, so it’s Ok if I can then download it again from multiple trusted parties I can verify them against each other that part is really easy, I can verify them against hopefully that 20 bytes that I really really cared about, hopefully I have that in a few places. 20-byte is easier to track than 180MB. And corruption is less likely to hit those 20 bytes. If I have those 20 bytes, I can download a git repository from a completely untrusted source and I can guarantee that they did not do anything bad to it. That’s a huge thing and that is something when you do hosted repositories for other people if you use subversion you are just not doing it right. You are not allowing them to sleep well at night. Of course, if you do it for 70… how many, 75,000 projects? Most of them are pretty small and not that important so it’s Ok. That should make people feel better.

I have a few more slides, I think we are over time, I am not even going bother showing them. They are not that interesting, I think.

I talked a bit about this whole content vs individual files, git tracks content.

[shows “Content Management” slide]

It means that git is really, the only example command line in the whole presentation, gitk is a graphical viewer of the history of a git project, It’s a tcl/tk script that is really only doing viewing of stuff that git is really good at showing you, and this is the kind of command line I use as the top-level maintainer. I want to be able to say, “What changed since a particular version,” maybe “since the particular date”, I can do that easily, “in those two directories”, or “in those two directories and that file”, and what this would show me is the global history as it pertains to those parts of the repository. It is more expensive to compute than the global global history. But if my laptop is actually connected to the A/V system I could show you even on that laptop it comes up in seconds; it is expensive but we are that good. This is something that is really really unique to git. Nobody else can do it. It’s a hugely important feature. Maybe it is not so important for individual developers because individual developers often do think in terms of single files, but it is important for the people who merge stuff. It is important for people like me and people I work with directly because they never basically care about a single file, and they do care about these kind of features. Somebody sends a bugreport, which, bugreports are not usually very good. but maybe the bugreport is good enough that you can pinpoint, “Ok SCSI subsystem”. That’s the command line. You cannot say which file, but you can do this and say “Ok that would cut it down from 15,000 commits we’ve had since last week, it will cut it down to 50”. That’s a huge deal. That is something that nobody else can do. I guarantee you.

So that’s the reason you would want to use git. That’s what it boils down to. It’s safe, it’s so fast that you can do things that nobody else can do, it does things nobody else can do even slowly, and it’s distributed.

So go on spread the word.

We have one more question I guess. What is the timing like, I dunno… Quickly

Audience: So the reason to switch from Perforce is really scalability and performance. Otherwise people would just keep using it.

Would it be exchanging one set of scalability/performance problems with another set of scalability/performance problems?

LT: I already mentioned the fact that I do not know how you maintain stuff in Perforce but when and if you do switch over to git what you want to make sure is because of this content model you need to do it at sane content boundaries. And the content boundaries usually are actually pretty self-obvious, they really are. You have the compiler, you have the main source, you have the documentation, well you probably have the documentation spread out but you may have, something like user visible documentation or maybe Google doesn’t but a lot of companies have separate set of documentation they give to customers and they have documentation that goes into each individual packages. So one of the things you do have to think about with git is that you want to make sure it is in somewhat sane hierarchy. Git can easily handle largest projects, you can have 10,000 files and that’s not a problem, the kernel is 22,000 files. We’ve done with test with 100k and it’s fine. It’s faster than anything else. With million files, I suspect other systems would be faster at some things. And that is the kind of situation that I do not want you to get into. But if you do the basic setup correctly, git will be basically faster at anything, pretty much everything, than anybody else would. I am very confident about git performance. One of the things we don’t necessarily do really well is “CVS annotate”. People use “CVS annotate” a lot. I’m told it sucks under Perforce, too, so you probably don’t use Perforce version of “annotate”, I am not sure. But CVS users are used to “CVS annotate”, it’s one operation that CVS can do faster than git because CVS does track things one file at a time, git doesn’t.

Git has “annotate”, but it will actually find, you can ask it, if you moved a function from one file to another, git will literally tell you the history of that function even across that move. Not a file move. A function within a file, it will go and dig back and say “Hey those two lines actually came from that other file five years ago”. Again this is something nobody else can do and it boils down to the same thing, it’s the contents that matter, it’s not actually the files. but it makes it much more expensive operation so if you go back five years, maybe it takes 30 seconds. On the kernel it takes a second for any file I have, we started from no history two years ago, because we just made the decision “let’s not make it more complicated than it needs to be”, so right now we only have two years of history in the kernel. We have more histories in other projects, we have done timings on them, so we’ve done timings on importing the KDE and things like that with more history. There are performance issues, but most of them are git is one or two orders of magnitude faster, so most of them are the good kind. And if you find something, we actually have a really really good community. The git mailing list is fairly high signal-to-noise, it does get a fair amount of e-mails, but it actually is a very pleasant mailing list. So if anybody is interested, read the sources first, but start looking at the mailing list archives. We have our flames, we have our pointless discussions, but most of them are actually very good.

Downloadfile:

linus-torvalds-2007-05-03-git_tf.ogg

On Git

leo — Sat, 07 Aug 2010 17:43:14 +0000

Speaker(s) Linus Torvalds

Language spoken English

Date of Recording Thu, 2007-05-03

Player-image:

Additional information

Source on Google Tech Talks: http://www.youtube.com/watch?v=4XpnKHJAok8

License:

License ‘open’.

The transcript is retrieved from
https://git.wiki.kernel.org/index.php/LinusTalk200705Transcript

You are also able to watch the video of this talk at Youtube:
http://www.youtube.com/watch?v=4XpnKHJAok8

He is a guy who delights being cruel to people. His latest cruel act is to create a revision control system which is expressly designed to make you feel less intelligent than you thought you were.

[applause]

[shows “Credits” slide]

02:22 I want to give a few credits before I start.

So that’s the negative kind of credit.

That’s the credits. With those out of the way…

[shows the “Content” slide]

But as mentioned, if we actually start veering off topic into other tangents because of questions, it’s all good.

[shows “Content Advisory” slide]

CVS, we already went there.

[shows “Background” slide]

The end result was that I decided I can write something better than anything out there in two weeks, and I was right.

[shows “Distribution” (cheesy graphics) slide]

So before I even start, I’d like to know, how many people are used to the notion of a truly distributed source control management system?

[audiences raise hands]

13:01 Are most of you kernel developers? No? OK, so there were maybe ten hands coming up.

[shows “Distribution” (bullets) slide]

[audiences raise hands]

OK, everybody. How many of you have really done a branch and ever merged it in CVS?

[audiences raise hands]

Good job. I mean, it wasn’t everybody, but it was actually more than I expected. How many of you enjoyed the experience?

[laughter]

[whispers] A tiny bit.

[audience laugh]

So get rid of Perforce, now.

[applaud]

21:16 It’s sad, but it is so so true. And that was my only real slide about distribution. And I’d love to get questions, because we are now moving into other areas.

Audience: 21:36 So how would you do it? If you had this monstrously awesomely big codebase and you wanted to use this without stopping business for 6 months, how would you do it?

LT: Stay by the mic, because I could not quite make out your question,… OK, he went away.

So either way, you can’t win.

Somebody else has a question.

Audience:

Audience: Is there an advantage for a company to have everybody playing in the same sandbox?

LT: Thank you for asking me the question. Did I tell you to ask that question?

Ok, the Windows machine flaked out again.

Anyway, now we are on the Performance slide.

Audience: Can I ask a question?

LT: Yeah.

Audience: Two questions, actually. One is, how many files would git take, and the second one, let’s say you have a humongous tree under git, would it be possible to check out a part of the tree?

Audience: What about shared code?

There was probably some part of your question that I completely forgot.

Audience: Can you have just a part of files pulled out of a repository, not the entire repository?

[shows “Performance” slide]

[laughter]

So performance is important, but you need to look at what matters.

I think I am running out of time, we’ll see if we have any, … oh, Ok, this one is still interesting.

I have a few more slides, I think we are over time, I am not even going bother showing them. They are not that interesting, I think.

I talked a bit about this whole content vs individual files, git tracks content.

[shows “Content Management” slide]

So go on spread the word.

We have one more question I guess. What is the timing like, I dunno… Quickly

Audience: So the reason to switch from Perforce is really scalability and performance. Otherwise people would just keep using it.

Would it be exchanging one set of scalability/performance problems with another set of scalability/performance problems?

Downloadfile:

linus-torvalds-2007-05-03-git_tf.ogg

The Free Software Movement and the Future of Freedom

Volker E. — Wed, 19 Mar 2008 15:40:00 +0000

Speaker(s) Richard Stallman

Language spoken English

Date of Recording Thu, 2006-03-09

Player-image:

“The best thing is if you can make some Free Software, the next best thing is if you don’t make any software, and the worst thing is if you make some proprietary software.”

Richard Stallman explains the ethical principles behind the concept of Free Software and the GNU project.

Additional information

Location: Multimedia Institute of CARNet, Zagreb

License:

Audio Source: mjesec.ffzg.hr

Image Source: www.archive.org (detail of a video still)

The transcription is based on the work of Ciarán O’Riordan.

Copyright (C) FSFE.
Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.

00:00 Richard Stallman: What is Free Software? Free Software means software that respects the user’s freedom. Software available to you but without respecting your freedom is called proprietary software or non-Free Software.

Proprietary software keeps users divided and helpless. Divided because each user is forbidden to share with other people, and helpless because the users don’t have the source code, so they can’t change anything, they can’t even tell what the program is really doing.

But Free Software, which I believe is translated [into Croatian] as slobodni softver, is software that respects the user’s freedom. What do I mean by this? Because it’s never enough just to say “I’m in favour of freedom”, the crucial issue is always: what are the essential freedoms that everyone should have?

01:18 There are four essential freedoms for the user of a program.

Freedom zero is the freedom to run the program as you wish, for any purpose.
Freedom one is the freedom to study the source code of the program and change it to do what you wish.
Freedom two is the freedom to help your neighbour. That’s the freedom to make copies and distribute them to others, when you wish.
Freedom three is the freedom to help your community. That’s the freedom to distribute or publish modified versions, when you wish.

With all four of these freedoms, the program is Free Software. If one of these freedoms is substantially missing - is insufficiently available - then the program is proprietary software, which means it is distributed in an unethical system and therefore should not be used and should not be developed at all.

02:38 Please note that the majority of software, nearly all software, is neither free nor proprietary, it is custom software developed for one particular user. Now, if that one particular user has all these freedoms, say, if that user has the full rights to the software, then you might say in a trivial sense that it’s Free Software. There’s only one user and that user is free. No user has been subjugated; no one is being mistreated in this way. Of course there are always other ethical issues that might enter the situation. There are many ethical issues in life, but in this one particular ethical issue, at least in that case, nothing wrong is being done.

But why are these four freedoms essential? Why define the term Free Software this way?
03:40 Freedom two is essential on fundamental ethical grounds, so that you can live an upright, ethical life as a member of your community. If you use a program that does not give you freedom number two, you’re in danger of falling at any moment into a moral dilema. When your friend says “that’s a nice program, could I have a copy?” At that moment, you will have to choose between two evils. One evil is: give your friend a copy and violate the licence of the program. The other evil is: deny your friend a copy and comply with the licence of the program.

04:28 Once you are in that situation, you should choose the lesser evil. The lesser evil is to give your friend a copy and violate the licence of the program.

[laughter]

Now, why is that the lesser evil? The reason is that we can assume that your friend has treated you well and has been a good person and deserves your cooperation. The reason we can assume this is that in the other case, if a nasty person you don’t really like asked you for help, of course you can say “Why should I help you?” So that’s an easy case. The hard case is the case where that person has been a good person to you and other people and you would want to help him normally.

Whereas, the developer of the program has deliberately attacked the social solidarity of your community. Deliberately tried to separate you from everyone else in the World. So if you can’t help doing wrong in some direction or other, better to aim the wrong at somebody who deserves it, who has done something wrong, rather than at somebody who hasn’t done anything wrong.

However, to be the lesser evil does not mean it is good. It’s never good - not entirely - to make some kind of agreement and then break it. It may be the right thing to do, but it’s not entirely good.

06:11 And the only thing in the software field that is worse than an unauthorised copy of a proprietary program, is an authorised copy of the proprietary program because this does the same harm to its whole community of users, and in addition, usually the developer, the perpetrator of this evil, profits from it.

Once you have thought about this and understood the nature of the dilema, what you should really do is make sure you don’t get into the dilema. There are two ways of doing this. One way, the way that the proprietary software developers perhaps prefer, is: don’t have any friends.

[laughter]

07:10 The other way is: don’t use proprietary software.

If you are carrying a portable tracking and surveillance device, please switch it off. They have already tracked you here. They already no that you are listening to me. And if they want to listen to what I am saying, they don´t need to use your telephone The recording will be posted as soon as it comes out

All of a sudden - strange. Maybe this contains some kind of listening device.

[laughter]

08:17 If you don’t use proprietary software, that means you never put yourself at risk of the dilema happening to you. If a friend asks me for a copy of a program, I will never be in that dilema because I can always legally say yes because I only accept copies of Free Software. If someone offers me a program that’s attractive to me, on the condition that I not share it with you, I will say no, because I want to be in a condition where I have nothing to be ashamed of.

09:08 The most essential resource of any society is not a physical resource, it’s a physo-social resource. It’s the spirit of good will; the spirit of helping your neighbour. It’s no accident that the World’s major religions for thousands of years have actively promoted the spirit of good will. Because if they can increase the level of this spirit by a little bit, it makes life better for everyone.

So what does it mean when powerful social institutions say that it’s wrong to share? What are they doing? They’re poisoning this vital resource, something that no society can afford. No society has too much spirit of good will. No society can afford to burn off some of it.

10:06 And what does it mean when they say “if you share with neighbour you’re a pirate?” What are they doing? They’re trying to equate helping your neighbour with attacking ships. And nothing could be more wrong than that because attacking ships is very very bad, but helping your neighbour is admirable.

And what does it mean when they impose harsh punishments of years in prison on people who help their neighbours? How much fear is it going to take before your neighbours are too scared to share with you, or before you’re too scared to share with them.

10:57 That level of fear, that terror campaign, is what the developers of non-Free Software are trying to impose on people all around the World. And I use the term “terror campaign”, not just to show how strongly I disapprove of it, but because so far, in at least two countries, the developers of proprietary software have threatened people with being raped for having unauthorised copies. And when they start threatening people with rape, I think that qualifies as a terror campaign. I believe we should end their terror campaign. We should not allow it to continue.

That’s the reason for freedom number two, the freedom to help your neighbour. The freedom to make copies and distribute them to others.

12:00 Freedom zero is necessary for a completely different reason. That’s the freedom to run the program as you wish for whatever purpose. It may be shocking but there are proprietary programs that don’t give you even this meagre freedom. They restrict how much you can run the program or when, or how, or for what jobs, for what purpose.

Obviously, this is not having control of your own computer. So freedom zero is necessary to have control of your own computer, but it’s not enough because that’s only the freedom to do or not do whatever the developer already chose for you.

To really have the control of your computer, you have to take those decisions away from the developer so that you can make them. For that you need freedom number one, the freedom to study the source code of the program and change it to do what you want. If you don’t have that freedom, you can’t even tell what the program is doing.

13:17 Yesterday I was told that Ceauşescu decided to have all telephones in Romania built for listening purposes - government listening purposes. Today, proprietary software developers do something similar. Many non-free programs contain malicious features designed to spy on the user, restrict the user, or even attack the user.

Spy features are quite common. One non-free program that spies on the user that you might have heard of is called Windows XP. When the user of Windows XP, and I won’t say “you” because you wouldn’t use a program like this, when the user of Windows XP searches her own files for some word, Windows sends a message saying what word was searched for. That’s one spy feature.

Then, when Windows asks for an upgrade - an update - to download the latest changes - it sends a list of all the software that’s installed on the machine. That’s another spy feature.

It was not easy to find out about these spy features. I don’t think Microsoft tells people that they’re going to be spied on in this way. They probably put something in the licence saying “you agree to let us collect whatever information may be necessary for whatever blah blah blah”. And the users don’t even bother to read this, and if they did, it wouldn’t tell them anything.

In fact, some clever research was needed to discover that Windows was sending the list of programs installed because it sends that list encrypted.

15:36 But spying on the user is not limited to Windows. Windows Media Player also spies on the user, in fact, it does complete surveillance, reporting every site that the user looks at.

But please don’t think that this kind of malice is limited to Microsoft. Microsoft is simply one among many developers of user-subjugating software. RealPlayer does the same thing. It does complete surveillance of the user, reporting every page that the user looks at.

And the Tivo does the same thing. 16:23 And the Tivo was an interesting case because many in the Free Software community applauded the Tivo when it came out. The Tivo actually uses a lot of Free Software; it contains a GNU/Linux system in it.

So people said “Oh, how great! They’re using our software, they’re benefiting from us, we should be happy”. Unfortunately, the Tivo also contains non-Free Software and it spies on the user. It reports exactly what the user watches.

17:03 So, this shows us that it’s not enough, our goal has to go beyond just that they use Free Software. The goal has to be that they not use non-Free Software, that we not use non-Free Software. If you want to maintain your freedom, you have to reject any program that’s going to take it away and every non-free program takes it away.

To get a computer that uses some Free Software, partly Free Software, doesn’t mean that that computer is respecting your freedom. It’s only partly respecting your freedom.

Malicious features go beyond spying. For instance, there is the functionality of refusing to function. Where the program says “I don’t want to show you this file, I don’t want to let you copy some lines from this file, I’m not going to print this file for you, because I don’t like you enough”. This is also known as DRM - Digital Restrictions Management, the intentional feature of refusing to function.

And then there are back doors. There was a non-free program that was liberated a few years ago, and when the users then could see the source code they discovered that it had had a back door for years.

They couldn’t tell while the program was proprietary. They couldn’t tell there was a back door. Only when it was free could they see that there was a back door, and, of course, they took it out.

Now, one proprietary program that you might know of by name that has a back door is called Windows XP. You see, when Windows XP asks for an upgrade, Microsoft knows the identity of the user, so Microsoft can provide that user with an upgrade designed specifically for him. And what does that mean? It means that that user is completely at Microsoft’s mercy, Microsoft can do anything whatsoever to him.

There is a piece of Microsoft server software which in 1999 was discovered to contain a back door installed for the US National Security Agency. 20:16 You can’t trust non-Free Software. You see, non-Free Software gives the developer power over the users and with this power comes the possibility of using it in many specific ways against those users. Some developers of proprietary software do this. And others don’t. Of course, you can never tell which one - which class any particular developer falls into except when you discover a malicious feature. Then you know. But aside from that, you don’t know.

20:59 But let’s suppose we’re talking about one of the programs whose developers do not put in malicious features - because there are some developers, they sincerely try to write a program which will run in a way that serves the user.

They’re still human, so they make mistakes. All programmers make mistakes. Their code still has bugs. All non-trivial programs have bugs. The user of a non-free program is just as helpless against an accidental bug as she is against an intentional malicious feature. The user of a non-free program is a prisoner of his software.

21:56 We, the developers of Free Software, are human too. We also make mistakes, and our programs also have bugs. The difference is that when our programs have bugs or features you don’t like, you can fix them because we have respected your freedom to fix them, to change the code. Whatever we’ve implemented that you don’t like, you can change because we respected your freedom to do so.

22:40 But freedom number one is not enough. Freedom number one is the freedom to personally study the source code and then change it to do what you want. This is not enough because there are millions of computer users that don’t know how to program. They can’t directly exercise this freedom. But even for programmers like me, freedom number one is not enough because there’s just too much software - there’s too much Free Software. No one person can study it all and master it all and personally make all the changes that she might want.

It’s beyond the capacity of one human being.

So the only way we can fully take control of the software we use is to do it working together, cooperating, and for that we need freedom number three, the freedom to help your community, the freedom to distribute or publish modified versions when you want.

With this freedom, together we can take full control of the software. So Free Software is software that develops democratically under the control of its users. Not in the strict sense of democracy that everyone votes and then people make the program do something according to the vote and everyone gets it. It’s better than that. Instead, if you have a free program and a lot of people want it to make progress in this direction, they will do a lot of work and publish their improvements, so the program will make a lot of progress in this direction.

Whereas, if only a few people want progress in this direction, they can still do it, they can still make the program develop in that direction but it will be limited by the amount of effort that people want to put in. And if most people don’t like that change, they’ll just use their own version. The main version will be one that goes in this direction, but the other people who want something different, they’ll be free to have their own version which makes progress in their direction.

If there are a million people who want a certain change in a Free program, then by chance, a few thousand of them will know how to program, and sooner or later, a few of them will make that change and publish their modified version and then all those million people will switch and thus we can see that only programmers can directly exercise freedoms one and three but every user can directly exercise freedoms zero and two - the freedoms to run the program and copy the program - and the non-programmer users indirectly get the benefit of freedoms one and three. They can’t use these freedoms directly, because that means programming, but when other people exercise these freedoms, the non-programmers also share in the benefits. 26:11 So these four freedoms are essential for all users, including the non-programmers, who are the majority of society.

Suppose there were just a thousand users who want a certain change in a free program, and suppose nobody in that thousand knows how to program, they can still get the benefit of these freedoms. Here’s how:

One of them can make an announcement and get in touch with the others, get them to respond, and then once they’re in touch, they can start an organisation.

The purpose of this organisation is to raise money to make the change they want. The organisation says to join you must pay 100 dollar. So, these thousand people, we assume they really want this change, so they all join and the organisation has 100,000 dollars with which it can hire, perhaps, a couple of programmers for a year, and that is a way to make quite a big change.

If they only wanted a small change, maybe they could charge ten dollars to join.

To actually make this change, the organisation has to pay programmers, which means first they have to find people to hire, they ask some programmers “when could you make this change and what would you charge?” and then they could ask other programmers “when could you make this charge and what would you charge?” and then they can hire whoever they wish.

Which shows that Free Software means a free market for all kinds of support and services. By contrast, proprietary software usually means a monopoly for support because only the developer has the source code, so only the developer can make any change. This means that users that want a change, have to beg the developer. “Please make the change that we want”. Sometimes the developer says “pay us and we’ll listen to your problem”, and if the user does that, the developer says “thank you, in six months there will be an upgrade. Buy the upgrade and you’ll see if we’ve fixed your problem and you’ll see what new problems we have in store for you”.

28:59 But with Free Software, anyone that has a copy, can study the source code, master it, and begin offering support - in a free market. Thus, those users that really value good support can expect in general to get better support through the free market for support for Free Software than they can get through the monopoly for support for proprietary software.

29:32 And this also shows us something paradoxical: usually when there is a choice between products to do a certain job, we say there is no monopoly, but when there is a choice between proprietary software packages to do a certain job, there still is a monopoly, in fact there is more than one monopoly. This is a choice between monopolies because the poor user who chooses this proprietary program will be stuck afterward with this monopoly for support. But if that poor user chooses this proprietary program, he’ll be stuck with this monopoly for support. So there’s no escaping monopoly.

And this is an illustration of a broader principle. 30:29 It’s a mistake to equate freedom to “the freedom of choice”. Freedom is something much bigger than having a choice between a few specific options. Freedom means having control of your own life. When people try to analyse freedom by reducing it to the freedom of choice, they’ve already thrown away nearly all of it and what’s left is such a small fraction of real freedom, that they can easily prove it doesn’t really matter very much. So that term is very often the first step in the fallacious argument that freedom is not important.

31:23 To be able to choose between proprietary software packages is to be able to choose your master. Freedom means not having a master.

31:39 So, now I’ve explained the reason for freedom number three - the freedom to help your community, the freedom to distribute or publish a modified version when you wish. And thus I’ve completed explaining the reasons for the four freedoms. If a program carries all four of these essential freedoms, then it is Free Software, and that means it is being distributed in an ethical system. If one of these freedoms is substantially missing, then the program is proprietary software and that means you shouldn’t use it and it shouldn’t be developed at all, not this way.

32:25 Developing a proprietary program is developing temptations for people to give up their freedom, and this is not a positive contribution to society. This is the place where people are making a mistake when they try to compare Free Software with proprietary software in terms of how much software could be developed. That’s like saying: “is it better to make guns or houses and food? Well, let’s see how much we could make of one or the other each. Oh, we can make more guns, then make guns.”

It is getting the whole question wrong. When people say: “could we make more proprietary software or could we make more Free Software”, they’re getting the whole question wrong. Because, 33:36 the best thing is if you can make some Free Software, the next best thing is if you don’t make any software, and the worst thing is if you make some proprietary software.

33:44 I’m all in favour of the principle that it’s good to reward people who do things that contribute to society and it’s good to punish people, one way or another, if they do things that harm society. This means that people who develop Free Software that’s useful deserve a reward, and people who develop proprietary software that’s attractive deserve a punishment.

Although it is good to reward and punish actions that contribute to or harm society, we can’t just say “I’m going to do whatever is rewarded and it’s up to society to make sure they only reward good things”. 34:32 Our responsibility as ethical beings is to do right, whether it’s being rewarded or not. And that’s why I made a decision long ago that I would develop Free Software or no software. I will not develop bait for people to give up their freedom. It’s better if I did nothing.

35:03 I reached these ethical ideas in the year 1983. More or less. Of course I had been learning about these issues for many years before that. But in 1983 was when I decided that what I wanted to do was make it possible to use a computer in freedom as part of a community.

How could this be possible? In 1983, it was impossible, and the reason is that the computer won’t do anything without an operating system and in 1983, all the operating systems for modern computers were proprietary. In fact, the user had to sign a non-disclosure agreement even to get the executable version. And the source code was not available to ordinary users.

So the second step in becoming a computer user, after buying the computer itself, was to explicitly betray the rest of your community. So what could I do about that? I was just one man believing in an idea that most people would have thought was ridiculously radical. I had no political skill. Not much fame - outside of the circle of editor developers. So what could I do to change this. I didn’t think I could convince governments to change their laws or convince companies to change their practices. But there was one thing I was very good at and that was developing software. Particularly operating system software. 37:10 And when I put that together, I realised I could solve this problem without convincing anybody in particular by developing another operating system that would be free. And then we could all switch to it and live in freedom. We wouldn’t have to convince any other developers to change, we could just turn our backs on them. If someone else wouldn’t respect our freedom, we just wouldn’t use his software.

I had discovered a way of making a political change in society, through technical work. And when I realised that this path was possible, and that it required exactly the kind of work that was may main skill, I realised that I had been elected by circumstances to do this job.

It’s as if you see someone drowning, and you know how to swim, and it’s not Bush…

[laughter]

…then you have a moral duty to save that person. I don’t know how to swim, but in this case the job that needed doing was not swimming, it was writing a lot of software. And for that, I had a chance. So I decided that I would develop a Free Software operating system, or die trying. Of old age presumably.

[laughter]

Because, at the time, the Free Software movement that I was starting, had no active enemies. There were plenty of people who disagreed, but they just laughed. No one was actively trying to stop us from developing a free operating system. The obstacle was just that it was a lot of work, and nobody knew if we would ever reach that point. But, when you’re fighting for freedom, you mustn’t wait until you know you’re going to win before you start to fight because if that’s you’re policy, you’re always going to miss the opportunities.

40:07 So, this decision lead me to other decisions, technical design decisions. What sort of system should it be? Well, back in the 1980s there were many different computer architectures and they kept introducing new ones. I knew it would take years to finish an operating system, and by that time the computers could look different. So that meant the system had to be portable. Otherwise, it would probably be obsolete before it was finished.

But there was just one successful portable operating system I knew of and that was Unix. So I decided to follow the design of Unix, figuring that way I would have a better chance of completing a system that would really be portable and usable. Furthermore, since Unix was popular, it was useful to make the system upward compatible with Unix. And that way, the many users of Unix would be able to switch easily.

41:14 So I decided to do that, and that lead to an interesting consequence. You see, Unix consists of hundreds of different separate components that communicate through interfaces that were more or less documented. And the users use those same interfaces to communicate with these pieces.

So to be compatible with Unix, you have to keep the same interfaces, more or less, and replace each piece compatibly. Which meant that all the initial design decisions were already made. These pieces could be replaced by many different people. For each piece, a different group of programmers could work on it, and they could work on each piece separately. Which eliminates one of the biggest problems of a large programming project which is the difficulty of having so many people talking to each other.

By making the decision to be compatible with Unix, which was important to make the system easy to switch to, it had already been chopped up into separate parts for us. Hundreds of parts.

The only thing we needed in order to start working, was a name. In the community of programmers who shared software in the 1970s, that thought me that Free Software is a good and ethical way of life, we programmed for the joy of it.

Many of us were students, and many of the rest were paid to do this work, but that was secondary. The main reason we were programming was because it was tremendously fascinating fun. Because we were doing this in a spirit of joy and fun, we had lots of other practices that were designed to have fun. For instance, we would often give our programs funny names or even naughty names - mischievous names. And we had a particular custom which was, when you’re developing a program that is inspired by another program - perhaps compatible with it - you could give your program a name which was a recursive acronym saying that this program is not the other one. It’s a funny way of giving credit to the original program which was an inspiration.

For instance, in 1975, I developed the first Emacs text editor, an extensible programmable text editor. You could actually re-programme the editor while using it. And this was so attractive that it was imitated about thirty times. And some of them were called “something Emacs”, but there was also Sine, for Sine Is Not Emacs, and Fine, for Fine Is Not Emacs, and Eine, for Eine Is Not Emacs. And Mince, for Mince Is Not Complete Emacs, and version two of Eine was called Zwei, for Zwei Was Eine Initially.

So you could have lots of fun with recursive acronyms. For lack of any better idea, I looked for a recursive acronym for something- Is Not Unix, but I tried all twenty-six possibilities, but none of them was a word in English, and if it doesn’t have another meaning, it’s not funny. So what was I going to do? Well, I thought, I could make a contraction, and that way I could have a three letter recursive acronym.

I tried every letter, ANU, BNU, CNU, DNU, ENU, FNU, GNU! Well, gnu was the funniest word in the English language. Given an intelligent, meaningful, specific reason to call something gnu, I could not resist.

Why is the word gnu used for so much wordplay? Because according to the dictionary, it’s pronounced “noo”. The “g” is silent. And the temptation to say gnu instead of “new” anywhere is almost irresistible to people who like wordplay. There was even a funny song inspired by the word gnu when I was a child. With so much laughter already associated with the word, it was the best possible name for anything.

However, when it’s the name of our operating system, please do not follow the dictionary. If you talk about the “new” operating system you’ll get people very confused - especially since we’ve been working on it for twenty-three years now, so it’s not new anymore. 47:14 But it still is and always will be “gnu”, no matter how many people pronounce it “Linux” by mistake.

So, how did that mistake get started? During the 1980s, we developed one piece after another of the GNU system. At first it was slow because there was just me and one other person, because of course, the goal was not to have a system written by me, the goal was to have a Free Software operating system as soon as possible. So of course I recruited other people to help as well as I could. Starting in 1983, before I actually began writing anything, I began asking other people to join in. And over the years, each year, more people joined in and started contributing to GNU.

48:15 And so by 1990, we had almost all of the pieces. But one of the large, essential components was still missing, and that was the kernel. So in 1990, the Free Software Foundation - which I had started at the end of 1985 in order to raise money to contribute to progress in Free Software - hired someone to begin developing a kernel. I chose the design of the kernel, and that was all I was involved with. I didn’t write it. I chose a design which I hoped would enable us to get the kernel finished as soon as possible. Namely, I found a microkernel, which had been developed by a government funded project at a university and I said, well let’s use that as the bottom layer, and on top of that we’ll develop a collection of user programs, each one to do a particular kernel service, and they’ll communicate by message passing, which is the feature that the microkernel implements for you.

This is the way, also, that people thought was the cleanest possible way to design kernels back in 1990. Well, it took many many many years to get this kernel to run at all, and it still doesn’t run well, and it looks like there may be fundamental problems with this design, which nobody knew about back in 1990.

Fortunately though, we didn’t have to wait for it because in 1991 a college student in Finland developed another kernel using the monolithic, traditional design, and he got it to barely run in less than a year. This kernel, which was called “Linux”, initially was not Free Software, however, in 1992, he changed the licence and adopted a Free Software licence, namely the GNU General Public License which I had written to use as the licence for the pieces of GNU that we were developing.

Thus, although Linux was not developed for the GNU project, it was Free Software at that point in 1992 and thus the combination of the almost-complete GNU system, and the kernel Linux formed a complete system. A system that you could actually install in a bare PC, and for the first time it was possible to run a PC in freedom. The goal that we had set out for in January 1984 had been achieved.

The development of Linux was an important contribution to the Free Software community. That was the step that carried us accross the finish line. Before that, we had many useful programs that people could install on top of a non-free operating system. Once we had the last missing piece, we had something you could install replacing the non-free operating system.

52:09 However, the confusion of thinking that the entire system was Linux, that it had all been developed by the college student in 1991 has been extremely harmful to the Free Software movement ever since because it broke the connection from our software to our philosophy.

Before that time, there was no complete free operating system, but there were many important parts of one and people would install them on top of non-free operating systems because they were not only free but also usually better. And when they did so, they realised they were installing these GNU programs, so they thought of themselves as fans or enthusiasts of GNU, and when they saw the articles that were in some of these packages, explaining the philosophy of Free Software, the same philosophy that I’ve been telling you today, they would think “Oh, this is the philosophy behind GNU, and I like GNU, I should read this.” This didn’t mean they would all agree with us, but at least they would pay attention to the arguments. They would give it serious consideration. So we had a chance to convince them, and if we did convince them, then they would feel a motivation to contribute to Free Software, to contribute to GNU. So the software spread the philosophy, and the philosophy extended the software.

Once people started using more-or-less the entire GNU system, and thinking it was Linux, then, using the GNU system no longer lead people to our philosophy - that I’ve told you today, the philosophy of the Free Software movement - instead it lead people to look at the philosophy of the developer of Linux.

He has never agreed with the ideals of the Free Software movement. In fact, he likes to call himself apolitical.

But, as often happens when people say they are apolitical, in fact, they are espousing and promoting a particular political point of view and his political point of view is that the developer should have total power, the developer can simply decide whether you have freedom or not and that it’s always wrong to disobey the developer. That is, it’s always wrong to violate any software licence. That’s the view he has stated in the past.

And when people think that the whole system is his work, they tend to look to him for guidance in these ethical questions as well. So we see the unpleasant situation that a system which is mainly our work is leading people to follow views that are the opposite of ours because the system is incorrectly attributed to somebody else. And this is why I pay attention to the issue so much. This is why I ask you, please call the system GNU+Linux or GNU/Linux. Please don’t call it Linux. It’s not just unfair to the system’s principal developers if you call it by a different name, it also leads people not to think about freedom.

And that’s really dangerous because history shows us that freedom is never guaranteed to be secure. And we don’t have to look very far back in history. Just look at the history of the United States in recent years to see how people can lose their freedom. Life always keeps handing you opportunities to lose your freedom. Someone says “give me your freedom, and I’ll give you this… or that… I’ll protect you… or I will take care of you” or whatever. If you don’t appreciate your freedom, if you don’t appreciate it very strongly, you will lose it. A fool and his freedom are soon parted.

In order for people to defend their freedom, they have to value their freedom, they have to appreciate it. And in order for people to appreciate and value their freedom, first they have to know what it is. In other areas of life, most people have heard of human rights. That doesn’t mean defending them is easy, but at least we don’t have to start by teaching people what the concept means. We don’t have to start by explaining to people what freedom of the press means because they’ve never heard of it before. 58:15 The concept of freedom of the press has had centuries to be developed and spread around the World.

But computing is new. It’s only been about ten years that a large number of people in most wealthy countries have been using computers. And it’s only been a few decades that there have been computers. So the ideas of what the human rights are that go with the use of software are just being developed. The Free Software movement says that there are four essential human rights for the user of software. This is a new idea. Most people who use software have never thought about the question of what human rights a software user should have. They have simply accepted what they have been told, which is, the human rights which a software user is entitled to are: none at all.

That’s what the developers of proprietary software give them. That’s what they see almost everybody accepting. That’s what they have done. And they have never heard anyone say that there is another idea.

So we actually have to start with step one, which is to tell people what it means to have freedom as a user of software. And then we can hope that people will value these freedoms enough to defend these freedoms so that maybe we can stay free. The future of our community depends on what we value, more than anything else.

And that’s why it’s so important today to teach people about the ideals of the Free Software movement. It’s not enough just to teach people to use Free Software. Of course I hope that they use Free Software, because it’s a shame if they’re using non-free, user-subjugating software. But just to use Free Software is not enough if we want to have freedom that will last for many years. If we gave everybody that uses computers freedom tomorrow, but they didn’t know what that freedom was, five years from now, many of them would have lost it because someone would have said to them “I’ve got a nice program that will make things easier, would you like it? Of course, you have to promise not to share it, and I won’t let you see what’s inside, but it’s a nice program, don’t you want it?”

A person who has not learned to think that there is something wrong there might say yes. And that means her freedom is partly gone. So, it’s not enough just to give people freedom. We need to teach people to recognise it as freedom so that they can learn to value it and then defend it and not let it go. That’s what we need if we want to have freedom not just tomorrow but permanently.

62:06 Many people suggest a two stage solution. They say, first, let’s teach people to use Free Software, and then, once they’re using it, we’ll teach people to appreciate the freedom.

Well, this two stage solution might work well, if it were properly tried, but when people propose this, almost always they go and work on stage one. In fact, I’ve come to recognise that this two stage solution idea is really an excuse to work on stage one and ignore stage two. Stage two is what I work on. So if you really believe in a two stage solution, come join me and work on stage two because the problem is that so much of our community has focussed on stage one, and so much of our community has talked about practical benefits while ignoring freedom, that in fact, at this point, if you start using the GNU/Linux system, you may not hear anyone talk about freedom for years. In other words, our community has not just begun to forget about the goal of freedom, it has almost completely forgotten. With the result that now it is a struggle to teach people in our own community about the freedom which is the reason why we built this community.

Of all the operating systems in history, all except one were developed for commercial reasons or technical reasons. GNU was developed for the sake of freedom. The users need to know this. And I would like to ask you to join in helping to teach them this. This is why I dedicate myself now to spreading these ideas of freedom. There are more than a million contributors to Free Software now. The community doesn’t need me that much as a programmer, and besides, I’m getting older, I probably can’t do it as well as I used to. But there are not a million people teaching the users to appreciate the value of freedom and the value of specifically the freedom to cooperate in a community. This is where we urgently need more people.

Especially since today, we have something we didn’t have before: enemies. Powerful enemies. Rich corporations that think they should rule the World, and almost do.

We face many kinds of obstacles today. For instance, many hardware products do not come with specifications.

65:48 In 1984, when I started writing GNU, this idea was almost unheard of. Almost unthinkable. Of course when you buy a computer there’s manual that tells you exactly how to use every thing in the computer. How could they possibly sell you a computer and not tell you how to use it?

But nowadays that’s what some hardware manufacturers do. And it’s hard to write a free driver for some input-output device when you don’t know what commands to give to it. Of course, the manufacturers say “oh, this is no problem, we support Linux”. They call the system Linux. And they hand you a driver and they say “Just use this driver”. The only problem is that it’s not Free Software. It’s a binary only program. So you can’t change it. You can’t study what it does. So that’s not acceptable.

What we have to do is, on one hand, reverse engineering to figure out how to make free drivers. And on the other hand, pressure these companies to cooperate with us.

So that we can make Free Software that really uses the computer’s hardware. This computer has a modem that doesn’t work. It’s a lose-modem. Well, the term they like to use is “winmodem”, but I don’t want to refer to Microsoft Windows as a win, because that’s term of praise. So I call it a lose modem.

It’s a modem that only works with Windows because part of the job has to be done in software and we don’t know what that software is supposed to, and I think some aspects of it are patented anyway.

So, I’m told that some of these lose-modems now have Free Software support. I don’t know the precise details. Today, all of the major 3D video accelerator chips fail to work with Free Software because the specifications of the chip are secret.

This is an area where our community could exert tremendous power. With tens of millions of users, if we were organised, if we could say to one company: “We’re going to boycott you until you start cooperating with us, and when you start cooperating, then we’re all going to buy from you and we’re going to boycott them”.

We could make them start treating us decently. But we’re not organised and most of the people in our community have never heard the idea that there is an ethical issue of freedom here. So we waste the market power that we have.

And the problems get worse than this. 69:31 There is an effort going on right now, a conspiracy of major companies, to change the design of computers in the future so that it will be impossible to write Free Software to do many important jobs.

This is known by them as “Trusted Computing” and by us as “Treacherous Computing”. Their plan is that software developers will be able to trust your computer to obey them instead of you. From their point of view it’s trusted, from your point of view it’s treacherous. So which name you choose is a matter of what side you’re on.

I’m on the side of the users who should be able to control their own computers. So I call it Treacherous Computing. This is a very dangerous plan, and it’s not clear how we can stop it. We just have to keep on fighting it out and hope that something will go wrong with there plan, because sometimes something goes wrong.

And there are the laws that are passed that prohibit some Free Software. For instance, in the US there are two such laws already. One of them is called the Digital Millennium Copyright Act, and it essentially gave publishers the power to write their own copyright laws.

The idea is that if publishers publish something in encrypted format or any other way designed to restrict the user, then anything that helps the user escape to freedom, is illegal. Thus, for instance, DVDs were designed to restrict the user. The video on a DVD is stored in an encyrpted format, and initially this encryption was supposed to be secret so that it would be impossible ever to write Free Software to watch a DVD. But people figured it out, and the result it that a few people wrote a free program to watch a DVD. This program is now censored in the US. The United States practices censorship of software. So, if you are in the United States, and I’m sorry for you if you are because you would not have much in the way of basic human rights especially as a foreigner, but one right you nominally still have is if you buy a DVD, you have a right to watch it. But the Free Software that you could use to watch it is illegal to distribute. Even telling people where they could find it from outside the US is illegal. Really Orwellian censorship.

And I’m sad to say that the European Union has adopted a directive that is pretty similar. It doesn’t go quite as far. It only prohibits the commercial distribution of such software. That might let us barely squeak by except that just about every country, maybe every country, when implementing this directive has gone further than necessary, has made it more strict than the directive requires. Taking the side of some mega corporations against their own citizens. So this becomes a sort of picture in the the small of how democracy is endangered by the European Union, and how democracy is sick all around the World. A government of the people by the people for the people wouldn’t adopt restrictions like this. Wouldn’t criminalise millions of their own citizens on behalf of companies, usually foreign companies. You have to ask: who are these governments really working for? Do they represent their own people, or are they the satraps of someone above?

This law only applies in limited areas of what you can do in software. It applies to having access to published works. Even though this is a narrow subfield of the software field it can still be tremendously important. For instance, if millions of people want to watch DVDs on their computer, and they can’t do this with Free Software, in fact they can’t legally get a program to do this on a free operating system, many of them might use non-free operating systems and non-Free Software just for that reason alone. So even though it’s just one application out of the thousands that software can have, it can be very important in practice.

76:10 The other law that prohibits many kinds of Free Software can actually apply to any kind of software, and that’s patent law, which I spoke about yesterday [http://www.archive.org/details/Stallman_Danger_of_Software_Patents]. Patent law is a threat to all software developers. Patent law means that you can write a program and then you can get sued because of the code that you wrote yourself. Copyright law can’t do this. If you write the code, you or your employer have the copyright. Which means nobody else does. So there’s no danger someone else can sue you for copyright infringement because of the code that you wrote. But patents are totally different from copyright.

Patents cover ideas, techniques, features, methods - not the code itself. And when you write code, you are implementing lots of different techniques, methods, features, ideas. Any one of them could be patented by somebody. In fact, fifty of them could be patented by fifty different patent holder and then they could all threaten to sue you, separately.

All software developers are threatened by this, but most software developers are only trying to have some successful products. We are trying to serve all of the user’s computing needs in freedom. Our goal is that all software should be free, that all users should be able to do whatever they want to do and keep their freedom.

78:59 Our goal is to provide people with Free Software for every job so that nobody ever faces the choice: either I keep my freedom or I do this job with my computer today. You know it’s sort of sad. This shows how little people value their freedom. People find themselves, they have some reason to do a certain job, it’s attractive, it’s appealing, it might make some money. And just for that they give up their freedom. So sad.

Since we can’t expect most people to value their freedom enough to say “I’m willing to not do this job because my freedom is more important to me than doing this particular computer use”, our goal is to give them a free program that will do that job. And then they have an easy choice. They can reject the non-free program and use the free program instead.

Every time there is some job that Free Software can’t do, that’s a big problem.

79:34 But these two laws are not enough. New ones are being considered all the time. For instance, WIPO, the World “Intellectual Property” Organisation, is now working on a treaty that would make it illegal to make any receiver for digital television that’s encrypted, that the users can modify.

In other words, for the first time, the idea would be to actually single out the fact that something is Free Software as a reason to prohibit it. This is how much they hate our freedoms.

So today it’s not enough just to write software and have fun. Of course we still need people to do that, and we have many people doing that, but we need also to organise politically to keep our freedoms, to organise against the frequent campaigns to take away one freedom or another. And the European Union has been generally very willing to adopt directives taking away its citizens freedom on behalf of the movie companies and the record companies.

We have a big fight on our hands and there’s no way of telling whether we can win. And that means we have to fight. I hope that you will help in this fight. […]

82:06 It’s vital for schools to use Free Software exclusively. The reason is: schools have a mission to teach society to be capable, to educate people to be parts of a capable, free society. Teaching students to use proprietary software is teaching dependence. It’s training them to be dependent on specific powerful companies. Giving those companies more power over society. Whereas, teaching them to use Free Software, is directing society onto the path towards freedom and strength. So schools must stop teaching proprietary software.

But there’s an even stronger reason for this. And even deeper reason. And that is, for moral education. Schools have to teach children the spirit of good will, the spirit of helping other people around them in society. So every class should have a rule: children, if you bring software to class, you can’t keep it for yourself, you must share it with the other kids, and if you won’t share it, you can’t bring it here because the way we do things is we help each other.

The school, in order to teach this properly, has to follow its own rule. It has to set a good example. This means the school must bring only Free Software to class.

84:05 So, sometimes people have accused me of having a holier-than-thou attitude. I don’t think that’s true. When I encounter somebody who is not doing all that he could do to encourage our freedom, I don’t look to attack that person, I look to encourage that person to do more.

However, I do have a holy attitude, because I’m a saint. It’s my job to be holy.

[Stallman dons a robe and puts a 16-inch disk on his head]

[applause and laughter]

I am Saint IGNUcius of the Church of Emacs. I bless your computer my child.

Emacs started out as a text editor, which became a way of life for many users because they could do all there work on a computer while never exiting from Emacs, and ultimately it became a religion as well. Today, we even have a great schism between two rival versions of Emacs, and we even have saints. But fortunately, no Gods. Instead of Gods, we worship an editor.

To be a member of the Church of Emacs, you must recite the confession of the faith, you must say: there is no system but GNU, and Linux is one of its kernels.

[laughter]

The Church of Emacs has certain advantages compared with other churches I won’t name. For instance, to be a saint in the Church of Emacs does not require celibacy. So if you have been searching for a church to be a saint in, you might consider ours. However it does require living a life of moral purity. You must exorcise any evil proprietary operating systems that possess any of the computers under your control, and then install a wholly/holy free operating system, and then only install Free Software on top of that. If you make this vow and live by it then you too will be a saint and you too may have a halo - if you can find one because they don’t make them anymore.

Sometimes people ask me whether it is a sin in the Church of Emacs to use the other text editor vi. Well, it’s true that vi vi vi is the editor of the beast, but using a free version of vi is not a sin, it’s a penance.

[laughter]

And sometimes people ask me if my halo is really an old computer disk. This is no computer disk, this is my halo. But, it was a computer disk in a previous existence.

[laughter]

So, thank you, and now, I will answer questions for a while.

[applause] […]

89:40 Q1: I’m interested in your opinion on the relationship between Mono and GNOME.

Richard Stallman: Mono is a free implementation of Microsoft’s language C#. Microsoft has declared itself our enemy and we know that Microsoft is getting patents on some features of C#. So I think it’s dangerous to use C#, and it may be dangerous to use Mono. There’s nothing wrong with Mono. Mono is a free implementation of a language that users use. It’s good to provide free implementations. We should have free implementations of every language. But, depending on it is dangerous, and we better not do that.

90:42 Q2: What is your view on other licences, other than the GPL? Such as BSD style licences?

Richard Stallman: Well, there’s no such thing as “BSD style licences”. There are two different BSD licences, and they’re both Free Software licences, but there’s an important difference between them. If you use the term “BSD style”, you are overlooking the difference. For more information, see www.gnu.org/philosophy/bsd.html. It explains the issue.

However, both of those licences are Free Software licences. Both of them grant the four essential freedoms, which means they’re both basically ethical.

One of them has a significant practical drawback, and the other does not. I convinced Berkley to change its licence to get rid of the practical drawback. And by the way, the reason that the BSD developers started making their code free was at least partly due to the visit that I paid to them in 1984 or 1985, because I wanted to be able to use some of their code in GNU. So I asked them, because at that time, BSD existed, it was a version of Unix, and you had to show them an AT&T source licence in order to get a copy of BSD.

So I told them: you are effectively donating your labour, your work, to a company. It’s not even a charity, and you’re donating to it. Why don’t you separate your code from AT&T’s code, and that way you could make your code free. I did this because there were parts that I knew were their work, and I figured this way we would get to use them in GNU and we would more quickly have a free operating system.

The website www.gnu.org is the place to look for information about GNU and Free Software. There is also a site fsf.org for information about the Free Software Foundation.

93:08 Q3: As part of a community that develops a piece of software, there is a problem with some of the users of that software, they simply develop it further but they do not release their source code.

Richard Stallman: What does this program do?

Q3: This program is an emulator for an MORPG

Richard Stallman: In general, there is nothing wrong with a person adapting a program, and using it privately…

Q3: But they released only binaries. The software is licenced under GPL.

Richard Stallman: Oh, well then they’re violating the licence. The developers need to talk to a lawyer, and you can sue them.

Q3: The problem is that they are scattered all around the World.

Richard Stallman: Well, that doesn’t necessarily matter. Don’t take a defeatist attitude. A few of the main developers, instead of talking about how hopeless it is, should talk to a lawyer, for instance, the Software Freedom Law Centre. For instance, when they do this to the Free Software Foundation, we make them comply.

We vigorously enforce the GNU General Public License, and the reason we do it is that when people are violating the GPL, that generally means that some users are losing their freedom. So to protect their freedom, we enforce the licence. We use the same weapons, namely copyright law, that other people use to take away others freedom, except we use this to defend people’s freedom, and that’s what makes it legitimate.

95:12 Q3: So, we should be able to fight all of these kids all around the World using this weapon?

Richard Stallman: I don’t know, are these kids? They are all kids?

Q3f: They are mostly kids.

Richard Stallman: Then it will be easy.

[laughter, applause]

95:36 Q4: […] about freedom number three […] people seem to think […] they think they have the obligation to distribute the modification.

Richard Stallman: Well that’s why I say: the freedom to distribute modifications when you wish. I put in the “when you wish” to try to correct that confusion. There’s just so many things I need to say, and there wasn’t time for them all. I left out a lot of things. You’re right, it’s just that there are many other misunderstandings I didn’t correct today. There’s too much to be said to fit, I just do the best I can. You’re right, but what can I do. […]

96:55 Q5: Does your halo [a large, old computer disk] contain proprietary software?

Richard Stallman: Not any more. And once there are fingerprints on it, I don’t think anything’s going to be able to read it. […]

97:17 Q6: The rumour has it that you do not support Creative Commons licence any more.

Richard Stallman: Well, the thing is, it’s meaningless to talk about Creative Commons licence. The bad thing about Creative Commons is that it has produced a broad series of licences that have nothing in common. In fact, if you look at these licences and determine what is the freedom that is common to all these licences, the answer is: nothing.

This is a problem because the reason why I would want to support such a thing is because it recognises the important freedoms, and initially, when Creative Commons got started, all of its licences recognised a certain minimum freedom which is also the freedom that I believe everyone is entitled to for works of art and opinion, namely, the freedom to non-commercial distribute exact copies of the work. That is, at the time I believed, the minimum freedom that everyone should always have for all kinds of works.

Larry Lessig has sort of convinced me that there is another essential freedom, which is, what he calls, remix. Which is the freedom to take parts of various works and change them and put them together into another work that is quite different overall and makes a different point, and so on. But in the US, that’s usually going to be fair use, so I didn’t see a need to talk about that so much.

But in any case, the initial Creative Commons licences all recognised the freedom to non commercially distribute exact copies of the whole work. But then, they developed some more licences which don’t give you that freedom. In fact, there’re some licences which give me no freedom at all, because I’m in developed country, and that probably applies to you too.

Because of that, those licences I consider unacceptable. There is no legitimate use of those licences. However, the problem is, Creative Commons functions in a way that encourages people to lump it all together. They don’t encourage people to look at these different licences and think about them individually. Instead they promote the brand “Creative Commons”. So you’ll see lots of people saying “Let’s use a Creative Commons licence for this”, or “please contribute to our project, we’re using a Creative Commons licence”. And they think they have told you something substantial, and many people read that and they think that they have been told something substantial, and in fact, they have been told nothing - about what freedoms users will have in using that work.

This is why I can’t support Creative Commons at all. Because the way they’ve set it up, you either support all of it or none of it, and for me that means it has to be none of it.

I’ve asked them to split it up into two activities with different names and different brands. And then I could support one of them and not the other. I would be glad to do that if they made it possible to do that.

101:23 So what this shows is a basic philosophical difference between Creative Commons and the Free Software movement. Creative Commons may have been in some sense inspired by the Free Software movement, but it isn’t similar to the Free Software movement. The Free Software movement starts by saying: these are the essential freedoms, everyone should have these freedoms, we’re going to work to establish and defend these freedoms. Creative Commons doesn’t say anything like that. Creative Commons talks about helping copyright holders exercise their power flexibly. A totally different philosophical orientation.

So it’s no surprise that they don’t have a list of essential freedoms. At the beginning, I thought they effectively did. It’s true they didn’t explicitly say “This is the freedom we intend to defend”, but from their actions, it looked like they were defending it, and I thought that was good enough. But because it was not really their intention, they changed their practices, and now, even in a purely practical sense, they don’t defend this minimum freedom, and that’s a terrible thing.

103:01 Q7: Do you know of any organisation that - unlike Creative Commons - does support this way?

Richard Stallman: Not really. There are some “free culture” organisations, which are trying to go even further and they’re trying to encourage the making of art that is free in the full sense of the same four freedoms.

Q7: [Media Foundation?] is one that I know of. They use exclusively free software, free file formats - also important.

103:50 Q8: Maybe an unholy question: Shoul not the Free Software be just more expensive than the none-free one, because it’s just more worth?

Richard Stallman: I don’t know what that would mean, sorry. To ask whether software is cheap or expensive, is actually making a number of hidden assumptions. In the proprietary software world, because people are forbidden to copy the program, usually, there’s only one place from which copies can be legally obtained. So, you can then ask, how much does that one source of copies charge for a copy. So it’s a meaningful question, although the answer might be: this much today over here and that much tomorrow over there. There’s not necessarily an answer to that question.

But with Free Software, because people have freedom, everyone is free to make copies. So there are many places you can get a copy, and any one of them could offer to give you a copy or could offer to sell you a copy. So there is no one price.

But Free Software is an issue of freedom, not price. The price question is secondary. People are free to buy and sell copies, but that’s just because people should be free. The price issue is not what I care about.

[End of session, applause]

Downloadfile:

richard-stallman-2006-03-09-free-software-movement-and-future-freedom_tf.ogg

The Free Software Movement and the Future of Freedom

Volker E. — Wed, 19 Mar 2008 15:40:00 +0000

Speaker(s) Richard Stallman

Language spoken English

Date of Recording Thu, 2006-03-09

Player-image:

“The best thing is if you can make some Free Software, the next best thing is if you don’t make any software, and the worst thing is if you make some proprietary software.”

Richard Stallman explains the ethical principles behind the concept of Free Software and the GNU project.

Additional information

Location: Multimedia Institute of CARNet, Zagreb

License:

Audio Source: mjesec.ffzg.hr

Image Source: www.archive.org (detail of a video still)

The transcription is based on the work of Ciarán O’Riordan.

Copyright (C) FSFE.
Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.

01:18 There are four essential freedoms for the user of a program.

Freedom zero is the freedom to run the program as you wish, for any purpose.
Freedom one is the freedom to study the source code of the program and change it to do what you wish.
Freedom two is the freedom to help your neighbour. That’s the freedom to make copies and distribute them to others, when you wish.
Freedom three is the freedom to help your community. That’s the freedom to distribute or publish modified versions, when you wish.