GPLv3 and Mobile Phones

[Dave Crossland]

Hi,

I thought this blogpost from the FSFE might be of interest to the list
and also relates to the question I asked earlier about how the
openmoko relates to the FSF philosophy:

http://fsfe.org/en/fellows/greve/freedom_bits/back_from_gplv3_conference_in_tokyo_japan

-- 8< --
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.
-- 8< --

-- 
Regards,
Dave