LFCS: GPLv3 and automobiles

Given that Linux is finding its way into almost every embedded computing setting imaginable, it is not surprising that it can increasingly be found in automobiles. But the automotive setting has some unique challenges of its own. How does automotive computing mix with the requirements of free software licensing, and of version 3 of the GPL in particular? A panel discussion at the 2013 Linux Foundation Collaboration Summit examined this question.

The panel was moderated by Karen Sandler, the director of the GNOME Foundation; the participants were Matthew Garrett (a developer with Nebula), Greg Olson (a senior partner at Black Duck's Olliance Consulting), Bryant Walker Smith (Stanford Law School) and Richard Fontana (Red Hat's licensing counsel). Together, they brought a wide variety of perspectives to the discussion.

The first question — does the GPL make sense in vehicles — was quickly redirected to a similar question: do the anti-tivoization provisions in GPLv3 apply to vehicles? If those provisions do apply, then the owner of a car with GPLv3-licensed software would have not just the right to the source, but also the right to replace the running software in the vehicle. This question is relevant because those provisions do not apply to every distribution of GPLv3-licensed code; they are, instead, restricted to "user products", defined in the license text as:

Richard thought that whether a vehicle was a "user product" depended on the specific vehicle in question. An army tank probably would not qualify, but a non-commercial vehicle sold to an individual probably would. So, for the purposes of this discussion, chances are that distributors of GPLv3-licensed code in vehicles would be required to allow the recipient to replace that software.

None of the panelists was 100% convinced that it made sense to apply the anti-tivoization provision to cars, though. Matthew stated that he did not want software that he had written to be in charge of any vehicle in which he was a passenger; he felt even worse about software written by most others. Richard said that concerns about safety and product liability were discussed during the drafting of GPLv3. He could imagine an exception to the requirements for safety-critical products, but that exception does not exist now. That said, it makes sense, he thought, for the owner of an automobile to be able to modify the software inside it, just like that owner is able to modify the hardware.

Matthew agreed that a lot of innovation can come from letting people play with automotive software. University students on closed courses, for example, should be able to play at will. He also noted that, under GPLv3, a device with replaced software need not operate in exactly the same way as it did before. The classic example is a media player that loses the ability to decrypt DRM-protected content if it is not running an officially-blessed software build. Perhaps a car with owner-supplied software could illuminate an indicator to show that it is operating in a non-certified mode.

Greg stepped back a bit to say that there have been many discussions around GPLv3 in his dealings with the GENIVI consortium. Automobile makers, he said, are "dead set against it." The problem is that automobile manufacturers are already pursued by an army of lawyers filing lawsuits in response to accidents. So manufacturers have adopted a highly defensive position; they maintain tight control over their supply chains and know exactly what they are building into their cars. Anything that threatens to compromise that control seems quite scary; the instinctive reaction is to say "no." He would like to see the door opened to GPLv3-licensed software, he said, because it is a better license. But that requires a much higher degree of clarity around the anti-tivoization provisions in this setting.

One possible mechanism that automakers could employ is some variant of the secure boot idea, whereby a car would simply refuse to operate with modified software. When asked if this would be consistent with GPLv3, Richard demurred, saying that he would have to study the issue. An alternative would be to detect modified software and put up some sort of visible indication that the car was no longer certified (or under warranty). In addition, there may eventually be legal rules about driving such a car on the public roads. Rules along these lines, Richard said, would be entirely consistent with GPLv3.

A member of the audience raised the question of experimental aircraft, which are surprisingly easy to fly in the US (until one wants to start carrying passengers). Could a similar legal regime apply to automobiles? Richard responded that there is a problem with the GPL, in that it doesn't say clearly how its requirements interact with local regulatory regimes. He expressed hope that, perhaps, this issue could be clarified in a future update to the license. Bryant added that the situation is a bit different, in that there are no real standards around automotive software; it is all a matter of self-certification by the manufacturers. The big problem is that there is no clarity currently; a better understanding of what the rules are, he said, is more important than any specific resolution.

Greg pointed out that automotive software modifications already exist: replacement engine control ROMs are available for a wide variety of automobiles if one knows where to look. Does it make sense to forbid other software modifications? Matthew added that one of the best ways to get people to do something is to attempt to prohibit it. A prohibition on automotive software modifications will just drive that activity underground, away from all regulation and with no framework to determine the liability for any resulting accidents. Controlled modification, he said, might lead to a better situation for everybody involved.

Somebody else asked: might the aversion to the GPLv3 just be a means by which automakers are trying to maintain tight control over their supply lines? Bryant responded that it is more a matter of acceptance of the status quo. Driving is actually an extremely dangerous activity, but most of us accept that most of the time. But we are less accepting of deaths resulting from drunk driving; the situation may be similar for deaths resulting from software modifications.

Greg pointed out that the nature of the industry is such that manufacturers will always control their supply lines in a fairly strict manner. It is the manufacturers who specify the tests and acceptance criteria for components, and they are the ones on the line if something goes wrong in the end product. Manufacturers are not averse to innovation in the supply chain, he said, and they want to have "compelling electronics" that will help them to sell cars. Their only real concern is civil liability.

What about systems where "infotainment" is separated from control? Perhaps user-modifiable software could get telemetry data and control the sound system, but it would be isolated from the systems responsible for operating the car. Greg brought up scenarios like the sound system suddenly raising the volume to 120dB, causing a crash; GPS misdirection was also mentioned. One need not get into the control system to incur civil liability, he said.

As the session wound down, Richard observed that the whole discussion was, from his point of view, a little strange. Adoption of GPLv3 has been limited so far, he said, and alternatives to most GPLv3-licensed projects exist. It would be a different discussion if GPLv3 were dominant, but it's not. He also claimed that there is not much demand from consumers to be able to make modifications. When demand is low, the industry will not take it seriously. So, he said, GPLv3 can be ignored in the automotive industry for now.

---

(Log in to post comments)