Software Governance and Automobiles - Session 1a
Welcome, by Professor Eben Moglen
EBEN MOGLEN: I thought it was worth having a meeting about software in cars, out of cycle and in a sort of heightened emphasis, because of course, well, you know, Volkswagen just did the world’s first top-down massive corporate re-organization over software issues in cars, right?
The automobile made the twentieth century. It was the machine that did the work of the twentieth century–it changed the way human beings occupied space, it changed the way planning of the built-environment in every respect was done, it altered the forms of industrial activity that constitute what we now call the supply chain without thinking too hard about what an extraordinary re-engineering of economic production the supply chain is, and it changed the nature of human work so significantly that we came to call an entire theory of how labor is organized and how work is done and how the economy’s production is owned, “Fordism,” because the automobile re-engineered all of the structures of society.
Somewhat to my surprise, since I’ve been fooling around with computers since I was a kid in the early 1970s… Somewhat to my surprise, the machine which is going to define the twenty-first century is also the automobile. And there’s kind of an irony about that, in a way. But, of course, the automobile that we’re talking about is of a very different thing. Part of whose job, apparently, is to ensure the uninterrupted flow of attention to the platform company and part of whose job is, apparently, to enable human beings to learn the skill that in the twentieth century human beings acquired for the first time, which was the ability to control enormous hunks of steel, weighing tons, moving on uncertain surfaces at speeds that no human being had ever experienced before the automobile came along and forced them to drive it. The nature of the human nervous system in the developed economies and, in fact, everywhere on Earth is now built around skills that at least we think or we say we think people are about to lose.
The nature of the automobile’s relationship to the human race in the twenty-first century is going to be just as complex and just as re-determinative of everything as it was in the twentieth. And part of the reason that’s true, after all, is that automobiles and computers have merged and it’s all going to be about software. It already is.
The first time I rode in a Tesla, I thought to myself, “Gee, you know, this is a really great laptop. I’m not absolutely certain how I feel about it as a car, but as a workstation it’s really great.” And we now know that this is already the condition of the car–no matter whether a human being or software is driving it, the car is now a network attached appliance with enormous complexity that also contains all the same forms of liability and danger that it had before, or almost all of them. It may no longer have a tank full of explosive fluids in the near future but almost everything else.
So, here we are. We’re on the cusp of a thing that has happened to the most important artifact in the economy, and we now perceive that it is again going to change how human life is lived at every granularity, and now it’s a software issue.
Now, of course, part of the reason that we would get together to think about a thing like that–at least, that I would want to bring us all together–is to think about software in a particular configuration, that is stuff that people are allowed to study and understand and share and improve.
Without the free software part of this, indeed, the whole thing becomes to me a very unpleasant nightmare–one of those nightmares leftover from the twentieth century science-fiction that Richard Stallman and I and Mark for that matter and other people grew up reading, which taught us about something terribly important, namely the unanticipated consequences of technology.
That the automobile was what shaped the twentieth century is true, but it’s also true that human beings shaped the automobile. Not just the human beings who designed it, manufactured it, created the supply-chain for manufacturing it, brought government into a system of building roads for it to run on–people changed the automobile because when it got into their hands they made adaptations to it.
All the human interaction after market, if you like, with the technology of the automobile is why automobile technology was as important in the twentieth century as it was because it was adaptable technology in the hands of people who did everything with it. Whether you’re looking at a guy tinkering with an auto-rickshaw in an Indian city or you’re looking at adaptations of the motorcycle or the use of the Rolls Royce for carrying sheep around Scottish aristocrats’ estates, the adaptation between the machine and its social use at the point of use was crucial to the success of the automobile as a transformative technology. We’re now thinking about a world in which the software that really defines what automobiles are–how they function, how people use them–we’re now thinking about a world in which that software either is or is not subject to human understanding at the point of use and adaptation.
Without adaptation, user innovation and the power of the technology to adapt itself to every corner of the human race falls away. With adaptation, on the other hand, go a whole lot of other sets of problems: problems of knowing what the software is in a vehicle at any given time and who put it there and what it’s meant to be doing and what it’s actually doing–note that’s not a problem that’s only involved in capturing user innovation, hence the re-organization of Volkswagen. There can be a lot of questions about who put the software in and what it’s supposed to be doing and how do you know. There can be regulatory questions about that. There can be liability questions about that. There’s lots of room for the legal system to be concerned with that, and so suddenly I find myself in my usual corner, standing in a law school thinking about software and the rules that govern it, wondering about the engineering of software in cars.
This is the crucial moment in which a whole bunch of stuff happens that is path dependent. It occurs now. It occurs between now and the middle of the next decade, and then we live with an awful lot of the consequences that follow from that, both with respect to the generative capacity of this technology and also with respect to its downsides.
Today, we want to talk then, this wonderful bunch of people who have come to be together on this. We want to talk about the question, how do you govern software in cars? How do you know where it comes from, who put it there, at what version it is, what maintenance has been applied? How do you secure it? How do you maintain it? How do you use the technologies of software governance that the open-source world knows things about. not just to govern software in cars but to govern software in cars which allows users flexibility, access, understanding, and the ability to modify in ways that are beneficial not just to them but to the society and its technology base as a whole.
The premise is that there are ways to govern software in cars. Even though we are currently in a chaotic situation that has put some companies in existential danger, it is possible to do a better job. Maybe it is even possible to do a better job in ways which give users rights, in which case that would be a very good outcome, because if users don’t have any rights, then however you’re governing it–to quote an old friend of mine, Richard Matthew Stallman–it might be slavery.
So, that’s the premise of the day, and we’ve got a bunch of different ways of coming at the problem.
This morning I want to start with the part which is in some ways dearest to my concerns, which is what you do when users do have rights, when software in cars is software that people have a right to install modified versions in/of–and how do you govern that so as to produce an environment in which you optimize for users’ ability to modify and discover and innovate and change while also preserving the social values that we understand we have to have from the proprietary interests of the vehicle manufacturers and their tier-one suppliers to the nature of the regulatory interest in what is running in cars to the safety and security and liability concerns of everybody who touches the vehicle in the course of its manufacture and distribution.
Mark Shuttleworth and I have been doing some thinking in recent months about our particular corner of that problem–what to do with the right guaranteed to users to be able to install modified versions of software in user devices created by the license GPLv3, which Richard Stallman and I made in the middle of the last decade, and which is, at least from my point of view, still a good platform, if you like, for understanding how software ought to be made and distributed so as to be respectful of the rights of users.
And so Mark and I have spent some months trying to think about a particular question: how can we govern user-modifiable where user-modifiable means legally guaranteed to be user modifiable software in automotive context in way which is sensitive to and realistic about what the balances are that have to be struck and which attempts to use technology in a way that strikes those balances so that we can guarantee all the various elements of that complicated balance that we want to guarantee.
So, in some sense, the generation of all this was that work, the effort that Mark and I were on to try and figure out how to use particular technologies of FOSS to create new technical capabilities to provide some sort of initiative that would allow us to get to consensus about how we use user-modifiable that is guaranteed to be user-modifiable software in cars.
The questions that arise from that aren’t just our questions. We’ve been noodling about this in a way that, of course, Canonical Software has an interest in, and that, of course, GPLv3 has an interest in, but I think it would also be fair to say that from our point of view the entire industry has an important interest in.
Next: 1b-shuttleworth | Contents