Contribute and be proud of defending Software Freedom from monopolist control! We are intervening in the Apple vs. EC case: Find out more.

Åtvaring: Denne sida har ikkje blitt omsatt endå. Her ser du den originale versjonen av sida. Du kann hjelpa til med omsetjingar, eller andre ting.

GPLv3 logo

Transcript of Ciarán O'Riordan at the 5th international GPLv3 conference; 22nd November 2006

See our GPLv3 project page for information on how to participate. And you may be interested in our list of transcripts on GPLv3 and free software licences.

The following is a transcript of Ciarán O'Riordan's presentation made at the fifth international GPLv3 conference, organised by FSIJ and AIST in Tokyo, Japan. From the same event, there is also a transcript Richard Stallman's talk.

Transcription of this presentation was undertaken by Ciarán O'Riordan. Please support work such as this by donating to FSFE, joining the Fellowship of FSFE, and by encouraging others to do so.

The speech was made in English. See also:

Presentation sections

  1. Introductory remarks
  2. Why non-lawyer comments are sought
  3. Why tivoisation must be prevented: freedom
  4. Why tivoisation must be prevented: preventing a catastrophe
  5. Could we use market pressure instead?
  6. Comparing licence improvement with legislative lobbying
  7. Legal maintainability - can the Linux kernel relicense?
  8. FSFE's contribution to the process
  9. Closing remarks
  10. Conclusion

The Presentation

(go to menu) [Section: Introductory remarks]

Ciarán O'Riordan: Good morning. I want to talk about the Linux kernel, GPLv3, and Digital Restrictions Management. This is an issue that has gotten a lot of attention in the press. The Linux kernel developers have a very loud voice. One of the reasons is that for most people, the operating system made by combining GNU and the Linux kernel is called "Linux". So, often, the work of the GNU project is attributed to the Linux developers. This is one of the reasons we ask for the operating system to be called "GNU+Linux".

They have a loud voice, but the process has been designed to make sure that everyone has an equal voice in the process. So although we hear more from some developers than others, they all get treated the same. The portal gplv3.fsf.org was set up to collect comments, and this has not been used by the Linux kernel developers. Instead they have mostly spoken amongst themselves and have spoken to the press. This makes it harder to respond to their concerns.

For people who haven't seen it, I want to show the gplv3.fsf.org comment portal.

[NOTE: people reading the transcript online can see that comment portal at http://gplv3.fsf.org/comments/]

When you visit the site, you get to see a copy of the licence, and you can see the different parts of the licence have different colours. When you click on one of the coloured pieced of text, you will see, like in this example on the right hand side, you will see the comments that have been made about that part of the licence. Then, if you highlight a part of the licence, and press 'c', you will get a small box like this where you can type in your comment. So, to make a comment, you have to first identify what part of the licence you have an issue with, and then you have to attach your comment to that part of the licence.

We can see from the first draft that the parts that have more comments get darker and darker. The Digital Restrictions Management part was the darkest in the first discussion draft. Other parts that collected a lot of comments were parts about patents.

It was mentioned yesterday that people in Japan haven't commented so much because they were shy about commenting, so one thing I wanted to point out is that you can do this anonymously. To make a comment, you have to make an account on gplv3.fsf.org, but you don't have to use your real name, you can use a pseudonym.

It was also pointed out yesterday that now is an important time to comment on GPLv3, but I don't think anyone mentioned the reason. The reason is that the third discussion draft is due to be published quite soon. It was meant to be published on November 23rd, but I think that will now be delayed because of the Microsoft/Novell deal. It should be published within the next few weeks, or few days. So if you want your comment to be considered while the third draft is being worked on, please submit it now. The third draft may be the last discussion draft before the final version is published in early 2007.

(go to menu) [Section: Why non-lawyer comments are sought]

Some people have been put off from commenting because this looks like a project for lawyers. We actually have lawyers to translate normal language into legalese. So this is a process that we hope that developers, users, and distributors will take part in, and we have a team of lawyers to translate into the necessary legal language.

The public process for commenting is the only process for commenting. This is the way that comments are collected. There is no backdoor, or secret meetings about GPLv3 besides the public process. When I want to make comments, I don't talk to Richard directly about this, I submit my comments to the website there. I think I've made five comments on the last draft, you can see them there, my user name is "ciaran".

If you find that the text is unclear, then this is also a valid comment you can make. Or if you have a comment and you're not sure if it makes sense, then it's still valuable to submit that to the site because then the people who are researching the comments can look at the parts where people are not sure if they understand the draft and they can decide that this is something that they have to make simpler.

We would like the licence to be simpler, and be shorter as well. Before this process began, a lot of people were saying that the GPL should be a lot shorter. They wanted it to fit on one or two pages. However, when we opened up the licence and asked people what parts should be removed, nobody was able to point out the redundant parts that we didn't need.

When you submit a comment to the website there, it gets submitted to four discussion committees. There is one committee of companies, large distributors, there is one committee of lawyers, one committee of large Free Software projects, and another committee of individuals that have shown an interest in this area.

Each comment is discussed by these committees from their perspective and then they collect these comments into issues and pass these on to Richard. The four committees, combined, have approximately one hundred and thirty people in them, so there is enough people to deal with all the comments.

This is one of the reasons why we are now updating the GNU GPL. Ten years ago, we could not have organised a process like this because ten years ago there were not that many Free Software users and Free Software wasn't as global. Now we can do this with a global Free Software community and access to tens of lawyers or hundreds of lawyers, it's quite beneficial for us to ask them for their comments.

One complaint from the Linux kernel developers, or one Linux kernel developer in particular, was that the committees were not being listened to. A journalist from Newsforge contacted the committees and they were quite enthusiastic, saying that they were being listened to. (LINK)

I discussed the comment system there because one of the problems that we've had is that the press have not reported the existence of the comment system. They have explained the controversies, and the hype and the disagreements, but they rarely mention when they explain these things that if people have an opinion or if people disagree with what is being done, they can use a comment to voice their disagreement. This is something that I wanted to highlight, and I hope that you will highlight, because there are many people who know about, for example, DRM being handled by the Linux kernel, but they don't know that they can make their voice heard, that they can make a comment.

Another mistake that has been made often in the press is to talk about the DRM issue as if it's a binary issue, a Yes or a No issue. One clarification that has to be made about this is that GPLv3 does not regulate DRM, it only regulates tivoisation, which is a specific case, which Richard explained yesterday (LINK), of DRM. This is also a mistake that myself and others have made when explaining this. We often talk about DRM, when we should be talking only about tivoisation.

(go to menu) [Section: Why tivoisation must be prevented: freedom]

Tivoisation has been tackled by the two drafts of GPLv3, and there has been no discussion about not tackling it. Some people have wondered if the process is unresponsive because they are asked for comments, but not tackling DRM is not an option. There are two reasons why GPLv3 will certainly tackle DRM or tivoisation.

The first is that Free Software is designed to give you freedom to adapt the software to your needs. People have pointed out that when Tivo distribute their computer, they give you a copy of the source code, and although you can't run modified versions on the Tivo, you can run modified versions on another computer. The reason this is insufficient is because Tivo contains spyware. If you receive the Tivo, and you want to remove the spyware, it's pointless to do this on another computer because what you want to do is you want to remove the spyware from your Tivo so that when you use your Tivo, it doesn't spy on you.

(go to menu) [Section: Why tivoisation must be prevented: preventing a catastrophe]

The second reason why GPLv3 will tackle tivoisation is to prevent a potential catastrophe. For Free Software to resist and continue being developed, the World has to have programmable computers. Free Software has evolved in an environment where people can reprogram their computers. If computers were mostly replaced by non-programmable computers, this would make it difficult or impossible for people to develop Free Software. This sounds hard to imagine, but it is currently happening with television. Television is being phased out and is being replaced by digital television which cannot receive analogue signals or have analogue output. Another example is the DVD consortium. This is where a group of companies have made an agreement to restrict the use of a certain type of computer. This is one way that a cartel or a consortium could effectively replace the programmable computers of the World with non-programmable computers.

A second way that this catastrophe could happen is if the Tivo model, which has proved financially sustainable by the Tivo company, is copied by other companies. It could happen that one by one, companies move to a Tivo style model.

Those are the two core reasons. There is also a third issue. It is not a core reason, but it is a benefit. By prohibiting tivoisation, we guarantee more contributors to our Free Software projects. We will probably lose the contributions of Tivo, but this is not a big problem because we were never dependent on Tivo. They contribute a very very small part, a minute part of the operating system. And in return, we will gain developers because the developers of Free Software are people who have computers running Free Software who make small improvements or large improvements. Currently, people who buy Tivo computers are not contributing small improvements or large improvements because they can't modify their Tivos. So by Tivo making computers non-programmable, they are making people non-programmers.

The actual words that implement the anti-tivoisation provision are quite small. The second discussion draft says that you can distribute the software...

...provided you also distribute any encryption or authorization keys necessary to install and/or execute modified versions...
(From Section 1, paragraph 4)

[Time: 880 secs]

This has a very limited scope. This will only affect people who are distributing hardware-plus-software systems, so it's probably safe to say that it will not affect anyone in this room.

(go to menu) [Section: Could we use market pressure instead?]

It has been suggested that we could tackle tivoisation through other channels. One suggestion was that we should fight tivoisation by market pressure: if we don't like tivoised devices, we shouldn't buy them. This is good advice, however, the Free Software community doesn't have examples of doing this successfully before. We certainly can't rely on this defeating tivoisation. If we do rely on it, we will be sure to fail. Market pressure is something that the Free Software community has to figure out how to do effectively. We now have tens or hundreds of millions of users of the GNU+Linux operating system, we could exert quite large market pressure but we are not doing it because we are not organised in this way.

For some hardware problems, we have to use market pressure. Sometimes it's the only option we have, but in the case of the Tivo, because we developed the software running on the Tivo, we are Tivo's business partners. We don't have to stay back as a third-party, we don't have to act only as consumers, we are partners in the development of their project.

(go to menu) [Section: Comparing licence improvement with legislative lobbying]

Licences can only do so much. Our licences can only place requirements on people who distribute our software. We should do what we can with our licences, because there is also one benefit in that licences are in a way easier to improve. They're easier to improve than market pressure is, and they're also easier than lobbying for legislation. For this I'll use the example of software patents.

In Europe, there was a directive, a proposal to change the law, to make software patents exist for all the EU member states. I think this proposal began in 1998, and it was worked on by Free Software Foundation Europe, and Foundation for a Free Information Infrastructure, and other groups. They worked on it from 1998 until 2005, and that proposal was rejected. There were many nights that we slept inside the parliament on the floor, and there were many weekends that we worked, and this happened for seven years. Although we got a significant result, we haven't finished the problem. There is a new proposal now to introduce software patents into the EU.

I'm just giving that example to show the scale of effort needed to tackle software patents by lobbying. Our licence cannot make that problem go away, we have to continue lobbying, however, when we can make life a little bit easier for ourselves without a seven year struggle, then we should try that.

Because the GNU GPL has been so successful, we haven't changed it in fifteen years. This is because of a combination of genius and pure good luck. Updating our licences is not something we think about very much, but we should start thinking of it in the same category as using market pressure or lobbying for legislation change.

The legal environment that Free Software exists in is not very helpful for us. It was not designed in a way to help us. One of the few benefits that it gives us is that we can determine the terms for distributing our software. After developing this software, which we spent twenty-five years doing, what we get in return is that we can set the terms for distribution. This is one way we can help ourselves, and it's something we should use.

(go to menu) [Section: Legal maintainability - can the Linux kernel relicense?]

During the debate over should the Linux kernel use the GPLv3, one side question that people raised was: can the Linux kernel change its licence?

The answer is that it's going to be very difficult. The Linux kernel has hundreds of copyright holders, and to relicense, all the copyright holders are going to have to either give permission or have their part of the kernel removed. This is quite difficult but it is possible. It is possible because most of the kernel developers are still contactable, and if they give their consent, they can change the licence for their parts of the kernel.

For some of the kernel developers who are not contactable, their software may have to be removed, but this does not have to happen immediately. By changing the licensing policy of the kernel, and then by waiting one year or two years, a lot of the old software that was in the kernel, which has the licensing problem, will be removed because code is often rewritten in the Linux kernel.

After waiting one year or two years, it will probably be found that very little code has to be removed. This process is similar for all Free Software projects that have a similar licensing situation to Linux. Linux is a good example because it's probably the messiest example, it's the example with the most difficulty.

Should the Linux kernel developers go to this amount of effort to move to GPL version 3? One answer is that we hope that they will like the GPLv3 so much that they will decide it is worth this effort, but even if they don't like GPLv3, they should improve the legal situation so they can change to another licence. It doesn't have to be GPLv3, but they should get the project into a state where the licence can be updated. The reason for this is that we never know what a court will say about the GPL. It has been enforced in the USA and in Germany in courts, but we don't know what will happen in other countries. If tomorrow there was an absurd court ruling, or a court ruling which the Linux kernel developers disagreed with, they would have to have a way to fix the licence.

So whether they want to move to GPLv3 or not, I think it would be good if they got to a state where the have legal maintainability, so that they can move to another licence and then our job is to make GPLv3 as good as we can make it and hope they choose that licence.

(go to menu) [Section: FSFE's contribution to the process]

In the process, the work that FSF Europe has been doing has been largely about documenting. Documenting, and spreading awareness, and participating in community discussions. This is quite important because updating our licence is a completely new project for the Free Software community. We have never done this together on a global scale before, and that puts us in the disadvantage that we have very little experience, we have few experts, and we don't have a body of discussion that people can read to become experts or to read the arguments, for and against, about this issue.

So one thing that FSF Europe has been doing is to make transcripts of the events like this event. The four previous events, all have transcripts made from them (LINK), at least of Richard's talk. Sometimes we have transcripts of Eben Moglen's talks, and we have transcripts of Richard's talks from other events.

We have also undertaken writing articles about GPLv3, and trying to constantly document the current state of the discussion so that anyone can join the discussion without having to start at the start. We want to document the current state and the current arguments so that people can see what is being discussed and what progress has been made so that people can start at the state-of-the-art, people can start with the current status of the debate and try and progress the debate.

[Time: 1550 secs]

(go to menu) [Section: Closing remarks]

I wasn't able to check this morning but I think there are unofficial Japanese translations of the first two discussion drafts of GPLv3. And I also think there are Japanese translations of the change rationale for each - these are documents explaining the reasons for the changes. You can find those translations on the GPLv3 wiki. On gplv3.fsf.org there is a wiki were people have collected articles and translations and transcripts, and people also use that wiki to discuss difficult situations or situations that they are not sure the GPLv3 tackles. If you have an issue with GPLv3 you can use that wiki to discuss this with other people who are considering that same problem, however, do remember to make a comment on the commenting system that I showed earlier. This is also true when the GPLv3 is discussed on discussion forums and on mailing lists. It's very useful to discuss it, but do remember to submit a comment to the web forum so that it can be reviewed and discussed and researched by the four committees with one hundred and thirty people.

That's mostly what I wanted to say. I was quite impressed with how this conference has been, so I wanted to add a "well done" to Niibe and to the Free Software Initiative of Japan, and to AIST, just to say that it has been a well-organised conference.

(go to menu) [Section: Conclusion]

To close on the important information. At the top of the screen is Free Software Foundation Europe's GPLv3 page: fsfe.org/activities/gplv3 and that's where you can find the transcripts that we've made and links to audio and video recordings and a timeline and a general explanation of what's happening with GPLv3.

I'd encourage you all to read draft 2 of GPLv3, and if you have a comment, submit it. When you see the commenting system, you might see that somebody else has already submitted a commented about the same issue, so it may not be necessary to make a comment.

Also, while you participate in other mailing lists - technical mailing lists or other mailing lists that don't discuss GPLv3 - it would be quite useful if you raised the issue, just to make sure everyone is aware of what is happening. We don't want anyone to be surprised in January or when GPLv3 is released. We don't want anyone to say "Oh, I wish I'd known, I wish I could have changed one part". We need your help in that way to spread awareness. As I mentioned earlier, the press are not doing a complete job on this.

The last thing is that I would ask you to support organisations such as FSF Europe and FSIJ because these organisations exist to help you work on these issues. And they also exist to work on them directly, so if you do not want to work on these issues, you can support these organisations so that they can work on them for you or so that they can help other people to work on these issues. The important thing is to make sure that enough people are working on it.

That's the summary of my presentation, thank you.

(go to menu)
Q1: If tivoisation is prohibited, what happens when firmware integrity is required?

Ciarán O'Riordan: I think there are two issues there. One is: what would happen if someone modifies the firmware and then brakes the device because the firmware was modified. In this case, it would be reasonable for the hardware distributor to void the warranty if the software is modified. That would be ok. We don't expect hardware distributors to offer a warranty after we modify the software.

The second issue of device integrity is regarding voting machines or medical devices or other regulated pieces of hardware.

The issue of voting machines is not really an issue because the GPL only requires that freedom to modify is given to people after you distribute the software. However, when a government uses the software on many voting machines, this usually does not count as distribution because only one legal person, namely the government, is using the software. So the government can use ten thousand voting machines without having to give the source code or permission to modify to people working in the voting centres, or anyone actually.

The other example there is medical devices, and this also applies to telephones and other devices that talk over radio signals. The issue is: how do you prevent the person from making the hardware do something that is not permitted by law.

For example, there is a regulation for what band a telephone can receive information from. If that has to be regulated, then that software can be put in ROM or other unmodifiable memory. This could be abused by other projects who might put everything in ROM, but it is unlikely. For example, the Tivo are unlikely to put an entire GNU+Linux operating system into ROM because [that's] making it impossible for them to fix bugs in the system. Companies will probably find that it is only profitable, only practical, to put the smallest amount of code necessary into ROM. So for telephones, the software which sets the signal that the telephone transmits and receives by, that part of the software could be put in ROM - Read Only Memory - a very small part of the software. And the rest of the software could be modifiable. That would be ok, that wouldn't break any regulations.

For medical devices, where it might happen that the entire software must be unmodifiable, they can put the harddrive, or put the device, behind a locked door. The people who have been complaining about medical devices have not been manufacturers of medical devices. I think that's because manufacturers of medical devices know that this isn't a problem because usually you do not have physical access to the software on a medical device because it would be inside a metal box, or it would be inside a locked room, or it would be unmodifiable for physical reasons.

(go to menu)
Q2: What about when a company distributes voting machine software to the government. Distribution occurs, so aren't the passwords etc. published, thus reducing security?

[Time: 2210 secs]

Ciarán O'Riordan: Ah yes, this is something I should clarify. If a company distributes software to the government, the company will be obliged by the GPL to give the government source code plus any passwords or encryption keys necessary for the government to run modified versions. That's what the GPL says. The GPL does not say that the company is required to publish source code or publish passwords or encryption keys.

So the company can give the software to the government, and the government can contract with the company to only give the [source code,] encryption keys and passwords to the government. So, the government can control of the software and the company can have control of the software. Or further, the government could enter a contract so that the government receives the source code and passwords and the government also receives the ability to change the passwords, so you can have a situation where the company complies with the GPL and gives everything necessary to the government, and the government can have exclusive control over the software because they can use [DRM] privately. They can set up the restrictions to only apply to themselves.

If the government later wants to distribute the software to another person, then the government will be required to give the other person source code for the software and whatever passwords the other person needs for their copy of the software. The government will not be required to pass on passwords that the government needs because when you distribute the software, the requirement is that the recipient has the ability to modify [their copy], you don't have to give the recipient the ability to modify your copy. The password needed to modify your copy and the recipient's copy can be different.

(go to menu)
Q3: The patent licence in the current draft of GPLv3 is not written in the same way as the patent licences of other licences. Can you explain the reasons for this or say what the lawyers think about this?

Ciarán O'Riordan: As far as I know, this was actually suggested by the lawyers. The patent provisions in the first draft were similar to the patent provisions in the Mozilla Public License, they were a patent licence. When you distribute the software, you give a patent licence for the required patents.

In draft 2, this was changed to a covenant not to sue, which in practice is the same as a patent licence, however, the lawyers, as far as I understand, decided that this was more likely to work the same in every country because the idea of a patent licence has more precedent and has more case law which could change the meaning in different countries. This covenant not to sue should be more the same across international boundaries.

(go to menu)
Q4: What do you think about server-side programs, such as spreadsheets and word processors that people use through their browsers? Do you think service providers should disclose some information? Or it is outside of your interest?

Ciarán O'Riordan: This is something that we still have to wait to see how it pans out. We [speakers and attendees] were actually discussing this last night. At the moment this is not a big problem. It's similar to the web services problem in the late 90s. In the late 90s, during the dot.com boom, people were worried that Free Software might lose if Free Software was run on servers as a service instead of run on desktop machines.

For example, if someone wanted to modify the GNU Image Manipulation Program, "GIMP", to edit photographs, they might set up a website to edit photographs and in that way they could make improvements to their copy without having to distribute their improvements. During the dot.com boom, people thought this was a business model. And a few years later, they learned that it wasn't.

In the late 90s, this looked like it might be a big problem. And then we waited a few years, and then it wasn't a big problem. The issue of server-side spreadsheets or word processors is a new issue and it might become a big problem, and maybe we'll have to do something about it, or it might stay a very small problem.

If we have to do something about it, it may happen that we have to modify the licence, however, I can't think of something right now that would be very helpful in the licence. Maybe we will have to do something outside of the licence. Like the way we boycott DRM'd hardware, and like the way we lobby against laws that create software patents, server-side programs could be a problem that we have to fix outside of the licence. But for the moment, I think it's safe that the GPL version 3 doesn't need a provision about this right now.

I should add: if you do think there is something that the licence could do, and that the licence should do, please make a comment to gplv3.fsf.org.

(go to menu)
Q5: A footnote to your last answer. One group that I'm aware of that is worried about this server-side closing of the sources is the Worldforge project - they're developing online role-playing games. Of course, most of the code for a game like that lives in the server. They were hoping that GPLv3 would help them, but it hasn't so far.

Ciarán O'Riordan: It could be that there is nothing that GPLv3 can do to address that, but if there is something, I'm sure we'd welcome the suggestion, but maybe we have to do it by installing or using good practices in our community. Maybe we have to teach people not to become dependent on services on a server that cannot be replicated on your own computer or on a server that you set up. That's something we have to look at from other angles as well.

(go to menu)
Q5b: I agree that also, in the GPLv3 process, it's too late...

Ciarán O'Riordan: Oh, it's not too late. The discussion drafts are still being modified. The two big issues are patents and DRM or tivoisation, and both of these are being reworked for the third discussion draft. It was planned that we would spend one year talking about GPLv3, and we're ten and a half months into that year, but things are still quite open for change.

As Richard mentioned yesterday, the patent provisions are being rewritten in response to the Microsoft/Novell deal. The tivoisation part is being rewritten. In draft 2 it was part of the definition of source code. In draft 3, it will be part of the requirements for permission to distribute. So we are not too late at the moment.

With the third discussion draft being worked on right now, this week or next week - probably this week - is a really important time to submit comments about that, and please do.

[Q&A session ends; applause]

Further information