At last week's GPLv3 conference, the topic of embedded GPLv3
software came up a few times. Below is something of a summary of
those discussions.
Georg Greve
blogged about
the conference, so I'll avoid repeating what he covered.
Suffice to say, it was an event the organisers can be proud of, and
Tokyo is a lovely and interesting place.
I think the issue of GPLv3 in embedded software falls into two
categories: warranties, and regulated hardware.
The warranties issue is quite simple. If a hardware vendor wants to
say that installing modified software voids the warranty, that's ok
with GPLv3. GPLv3 says that if the software is modified, it must be
able to interact with the same online services. Warranties are not
an online service, so the warranty can be changed or voided when
modified software is installed and that won't violate GPLv3.
The more complex issue is with regulated devices such as mobile
phones, wireless cards, voting machines, and medical devices. If a
company decides to produce mobile phones, how can they use GPLv3'd
software if they are required to prevent customers from transmitting
or receiving signals outside of the permitted ranges?
With GPLv2, they could have built the phone to stop functioning if
it detects that the software has been modified. This is what has
become known as
"tivoisation".
This solves their regulatory problem, but it means that the GPL has
not done its job of ensuring the recipient has the freedom to modify
the software.
It may seem that these two goals are fundamentally incompatible, but
they are not. A solution is that the phone manufacturer can put the
part of the software which sets the signal transmission/reception
into unmodifiable memory (ROM - read-only memory), and the remaining
majority of the software can go in modifiable memory. Thus, the
phone will not be used to break regulations, and the recipient has
the freedom to modify most of the software, with the exception of
the small part which it would have been illegal to modify anyway.
This is not immune to abuse. Phone manufacturers could put all of
the software in unmodifiable memory. If they do this, we are no
worse off, and no better off, than we are today. However, it seems
more likely that they will opt to split the software between
modifiable and unmodifiable, because that way.bugs can be fixed, and
software updates can enable new services, etc.
So the deal is, if they want to retain the ability to modify the
software, they have to let you modify it too. The second example of
wifi cards is the exact same.
The third example is medical devices. This issue is quite similar,
just with different hardware sizes. People have asked how certified
medical devices could ever be allowed to have modifiable software.
Maybe it's interesting to note that I haven't heard of a medical
devices manufacturer raise this issue. Maybe they know that this
isn't an issue. GPLv3 just prevents tivoisation. Do we have any
evidence that current medical devices use tivoisation?
But that's a side point. To answer the question directly, again the
device manufacturer can use unmodifiable memory. Memory can be made
unmodifiable by putting it into a ROM chip, but for medical devices,
there is also the possibility of putting a lock on the box, and/or
put the box in an area not accessible to non-certified people. I
suspect that this is already the case and that even doctors and
hospital IT departments do not have access to the firmware of X-ray
machines etc.
And then the fourth example is voting machines. For this, the two
key issues are when does distribution occur, and the difference
between publication and supplying to the recipient.
If a government develops software for use on electronic voting
machines, and if it produces a thousand voting machines and sends
them to each region of the country, will the government have to give
the source code, passwords and/or encryption keys to the staff at
the voting centre? According to GPLv3, these things have to be made
available to anyone you distribute the software to, but, according
to copyright law, AFAIK, no distribution has occurred. This is just
the government using the software on multiple machines. The
government has not distributed copies of the software to the voting
centres.
The second case is where a company develops the software and
supplies it to the government. Here, distribution does occur
between those two parties. However, the company only has to make
the passwords and encryption keys available to the government. If
the company has a second customer, it can set up the hardware to use
different passwords or encryption keys. The government could event
make a contract with the company saying that the company cannot give
the passwords or encryption keys necessary for the government's
system to anyone else. Or further, the company can give the
government (or any recipient) the ability to change what password or
encryption keys are necessary. So even when distribution occurs,
the use of DRM for security purposes is not restricted.
If there's a case I didn't cover, please email me:
ciaran-at-fsfe-dot-org. And if you have a comment on the licence,
please submit it to
the gplv3.fsf.org comment
system.
From the Tokyo event,
here's my
explanation in other words.
There's also
a transcript
of Richard Stallman's talk from last week's event.
--
Ciarán O'Riordan,
Support free software: Join FSFE's Fellowship
