FSFE
/
fsfe-website
29
30
Fork 85
Code Issues 62 Pull Requests 14 Wiki Activity
fsfe-website/campaigns/gplv3/tokyo-ciaran-transcript.en....

909 lines
37 KiB
HTML
Raw Blame History

<?xml version="1.0" encoding="UTF-8" ?>
<html>
<head>
<title>GPLv3 - Transcript of Ciaran O'Riordan from the fifth
international GPLv3 conference, Tokyo, Japan; 2006-11-22</title>
</head>
<body>
<div class="image right">
<a href="gplv3.html"><img SRC="/graphics/gplv3-logo-red.png"
ALT="GPLv3 logo" /></a>
</div>
<h1>Transcript of Ciarán O'Riordan at the 5th international
GPLv3 conference; 22nd November 2006</h1>
<p>
See our <a href="gplv3.html">GPLv3 project</a> page for information
on <a href="gplv3#participate">how to participate</a>. And you may
be interested in
our <a href="http://wiki.fsfe.org/Transcripts#licences">list of
transcripts on GPLv3 and free software licences</a>.
</p>
<p>
The following is a transcript of Ciarán O'Riordan's presentation
made at the <a href="http://gplv3.fsij.org/">fifth international
GPLv3 conference</a>, organised by FSIJ and AIST in Tokyo, Japan.
From the same event, there is also
a <a href="tokyo-rms-transcript">transcript Richard Stallman's
talk</a>.
</p>
<!-- <p>Video and audio recordings are available:</p> -->
<!-- <ul> -->
<!-- <li>Audio: <a href=""></a></li> -->
<!-- <li>Video: <a href=""></a></li> -->
<!-- </ul> -->
<p>Transcription of this presentation was undertaken
by Ciarán O'Riordan.
Please support work such as this by <a href="/help/donate">donating
to FSFE</a>, joining <a href="http://fellowship.fsfe.org/">the Fellowship
of FSFE</a>, and by encouraging others to do so.</p>
<p>The speech was made in English. See also:</p>
<ul>
<li><a
href="http://gplv3.fsij.org/#Resources">http://gplv3.fsij.org/#Resources</a>
- all recordings from the event</li>
<li><a
href="http://gplv3.mex.ad.jp/sdogg/sd_ogg_2006_1122_1000_drm.ogg">The
recording of Ciaran O'Riordan's talk</a></li>
</ul>
<h2>Presentation sections</h2>
<ol>
<li><a href="#introductory-remarks">Introductory remarks</a></li>
<li><a href="#non-lawyer">Why non-lawyer comments are sought</a></li>
<li><a href="#tivoisation-and-freedom">Why tivoisation must be prevented: freedom</a></li>
<li><a href="#tivoisation-and-catastrophe">Why tivoisation must be prevented: preventing a catastrophe</a></li>
<li><a href="#market-pressure">Could we use market pressure instead?</a></li>
<li><a href="#lobbying">Comparing licence improvement with legislative lobbying</a></li>
<li><a href="#legal-maintainability">Legal maintainability - can the Linux kernel relicense?</a></li>
<li><a href="#fsfe">FSFE's contribution to the process</a></li>
<li><a href="#closing-remarks">Closing remarks</a></li>
<li><a href="#conclusion">Conclusion</a></li>
</ol>
<ul>
<li><a href="#q1">Q1: What about governments and voting machines?</a></li>
<li><a href="#q2">Q2: Won't passwords be public if a company
distributes to the government?</a></li>
<li><a href="#q3">Q3: Why was the current patent licence written that way?</a></li>
<li><a href="#q4">Q4: Will GPLv3 address web services?</a></li>
<li><a href="#q5">Q5: For example, online role-playing games?</a></li>
<li><a href="#q5b">Q5b: Is it too late for more changes? No.</a></li>
</ul>
<h2>The Presentation</h2>
<p>
<span id="introductory-remarks">(<a href="#menu">go to menu</a>) [Section: Introductory remarks]</span>
</p>
<p class="indent">
<span style="font-weight: bold;">Ciarán O'Riordan</span>: 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 &quot;Linux&quot;.
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 &quot;GNU+Linux&quot;.
</p>
<p class="indent">
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.
</p>
<p class="indent">
For people who haven't seen it, I want to show
the <a href="http://gplv3.fsf.org/comments/">gplv3.fsf.org</a> comment
portal.
</p>
<p>
[NOTE: people reading the transcript online can see that comment
portal
at <a
href="http://gplv3.fsf.org/comments/">http://gplv3.fsf.org/comments/</a>]
</p>
<p class="indent">
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.
</p>
<p class="indent">
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.
</p>
<p class="indent">
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 <a href="http://gplv3.fsf.org/comments/">gplv3.fsf.org</a>, but you
don't have to use your real name, you can use a pseudonym.
</p>
<p class="indent">
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.
</p>
<p>
<span id="non-lawyer">(<a href="#menu">go to menu</a>) [Section: Why non-lawyer comments are sought]</span>
</p>
<p class="indent">
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.
</p>
<p class="indent">
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
&quot;ciaran&quot;.
</p>
<p class="indent">
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.
</p>
<p class="indent">
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.
</p>
<p class="indent">
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.
</p>
<p class="indent">
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.
</p>
<p class="indent">
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.
</p>
<p class="indent">
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.
(<a
href="http://trends.newsforge.com/trends/06/08/04/2218206.shtml">LINK</a>)
</p>
<p class="indent">
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.
</p>
<p class="indent">
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
(<a
href="http://fsfeurope.org/campaigns/gplv3/tokyo-rms-transcript#tivoisation">LINK</a>),
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.
</p>
<p>
<span id="tivoisation-and-freedom">(<a href="#menu">go to menu</a>) [Section: Why tivoisation must be prevented: freedom]</span>
</p>
<p class="indent">
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.
</p>
<p class="indent">
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.
</p>
<p>
<span id="tivoisation-and-catastrophe">(<a href="#menu">go to menu</a>) [Section: Why tivoisation must be prevented: preventing a catastrophe]</span>
</p>
<p class="indent">
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.
</p>
<p class="indent">
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.
</p>
<p class="indent">
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.
</p>
<p class="indent">
The actual words that implement the anti-tivoisation provision are
quite small. The second discussion draft says that you can distribute
the software...
</p>
<blockquote>
<p>
...provided you also distribute any encryption or authorization
keys necessary to install and/or execute modified
versions...<br /> (From Section 1, paragraph 4)
</p>
</blockquote>
<p>
[Time: 880 secs]
</p>
<p class="indent">
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.
</p>
<p>
<span id="market-pressure">(<a href="#menu">go to menu</a>) [Section: Could we use market pressure instead?]</span>
</p>
<p class="indent">
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.
</p>
<p class="indent">
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.
</p>
<p>
<span id="lobbying">(<a href="#menu">go to menu</a>) [Section: Comparing licence improvement with legislative lobbying]</span>
</p>
<p class="indent">
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.
</p>
<p class="indent">
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 <a href="http://fsfeurope.org/">Free Software Foundation
Europe</a>, and <a href="http://www.ffii.org/">Foundation for a Free
Information Infrastructure</a>, 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
href="http://blogs.fsfe.org/ciaran/?p=49">a
new proposal now</a> to introduce software patents into the EU.
</p>
<p class="indent">
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.
</p>
<p class="indent">
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.
</p>
<p class="indent">
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.
</p>
<p>
<span id="legal-maintainability">(<a href="#menu">go to menu</a>) [Section: Legal maintainability - can the Linux kernel relicense?]</span>
</p>
<p class="indent">
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?
</p>
<p class="indent">
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.
</p>
<p class="indent">
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.
</p>
<p class="indent">
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.
</p>
<p class="indent">
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.
</p>
<p class="indent">
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.
</p>
<p>
<span id="fsfe">(<a href="#menu">go to menu</a>) [Section: FSFE's contribution to the process]</span>
</p>
<p class="indent">
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.
</p>
<p class="indent">
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
(<a href="/campaigns/gplv3/#transcripts">LINK</a>), 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.
</p>
<p class="indent">
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.
</p>
<p>
[Time: 1550 secs]
</p>
<p>
<span id="closing-remarks">(<a href="#menu">go to menu</a>) [Section: Closing remarks]</span>
</p>
<p class="indent">
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 <a href="http://gplv3.fsf.org/wiki/index.php/Main_Page">the GPLv3
wiki</a>. 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.
</p>
<p class="indent">
That's mostly what I wanted to say. I was quite impressed with how
this conference has been, so I wanted to add a &quot;well done&quot; to Niibe
and to the Free Software Initiative of Japan, and to AIST, just to say
that it has been a well-organised conference.
</p>
<p>
<span id="conclusion">(<a href="#menu">go to menu</a>) [Section: Conclusion]</span>
</p>
<p class="indent">
To close on the important information. At the top of the screen is
Free Software Foundation Europe's GPLv3 page:
<a
href="http://fsfeurope.org/campaigns/gplv3/">fsfeurope.org/campaigns/gplv3</a>
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.
</p>
<p class="indent">
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.
</p>
<p class="indent">
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
&quot;Oh, I wish I'd known, I wish I could have changed one
part&quot;. We need your help in that way to spread awareness. As I
mentioned earlier, the press are not doing a complete job on this.
</p>
<p class="indent">
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.
</p>
<p class="indent">
That's the summary of my presentation, thank you.
</p>
<p id="q1">
(<a href="#menu">go to menu</a>)<br />
<span style="font-weight: bold;">Q1</span>: If tivoisation is
prohibited, what happens when firmware integrity is required?
</p>
<p class="indent">
<span style="font-weight: bold;">Ciarán O'Riordan</span>: 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.
</p>
<p class="indent">
The second issue of device integrity is regarding voting machines or
medical devices or other regulated pieces of hardware.
</p>
<p class="indent">
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.
</p>
<p class="indent">
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.
</p>
<p class="indent">
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.
</p>
<p class="indent">
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.
</p>
<p id="q2">
(<a href="#menu">go to menu</a>)<br />
<span style="font-weight: bold;">Q2</span>: What about when a company
distributes voting machine software to the government. Distribution
occurs, so aren't the passwords etc. published, thus reducing
security?
</p>
<p>
[Time: 2210 secs]
</p>
<p class="indent">
<span style="font-weight: bold;">Ciarán O'Riordan</span>: 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.
</p>
<p class="indent">
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.
</p>
<p class="indent">
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.
</p>
<p id="q3">
(<a href="#menu">go to menu</a>)<br />
<span style="font-weight: bold;">Q3</span>: 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?
</p>
<p class="indent">
<span style="font-weight: bold;">Ciarán O'Riordan</span>: 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.
</p>
<p class="indent">
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.
</p>
<p id="q4">
(<a href="#menu">go to menu</a>)<br />
<span style="font-weight: bold;">Q4</span>: 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?
</p>
<p class="indent">
<span style="font-weight: bold;">Ciarán O'Riordan</span>: 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.
</p>
<p class="indent">
For example, if someone wanted to modify the GNU Image Manipulation
Program, &quot;GIMP&quot;, 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.
</p>
<p class="indent">
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.
</p>
<p class="indent">
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.
</p>
<p class="indent">
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
<a href="http://gplv3.fsf.org/comments/">gplv3.fsf.org</a>.
</p>
<p id="q5">
(<a href="#menu">go to menu</a>)<br />
<span style="font-weight: bold;">Q5</span>: 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.
</p>
<p class="indent">
<span style="font-weight: bold;">Ciarán O'Riordan</span>: 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.
</p>
<p id="q5b">
(<a href="#menu">go to menu</a>)<br />
<span style="font-weight: bold;">Q5b</span>: I agree that also, in the GPLv3 process, it's too late...
</p>
<p class="indent">
<span style="font-weight: bold;">Ciarán O'Riordan</span>: 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.
</p>
<p class="indent">
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.
</p>
<p class="indent">
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.
</p>
<p>
[Q&amp;A session ends; applause]
</p>
<h2 id="further-information">Further information</h2>
<ul>
<li>For general information, links, and a schedule, see
our <a href="gplv3.html">GPLv3 project</a> page</li>
<li>Many more transcripts can be found at
the <a href="gplv3.html#transcripts">transcripts section</a> of our
GPLv3 project page</li>
<li>You can support FSFE's work, such as our GPLv3 awareness work,
by joining <a href="http://fellowship.fsfe.org/">the Fellowship of
FSFE</a>, and by encouraging others to do so</li>
<li>You can also support us by <a href="/help/donate">making a
donation</a>, and by encouraging others to to so</li>
</ul>
</body>
</html>
Reference in New Issue View Git Blame Copy Permalink