Transcript: SESSION III: Automotive FOSS
November 2, 2018
Jerome Greene Hall, Columbia Law School
Session Description:
“Where Are We Going With Cars?” - As manufacturers and Tier One suppliers move rapidly towards FOSS adoption in vehicles and components, traditional suspicion of copyleft meets the realities of a new form of software supply chain. Experiments in autonomy are demonstrating both promises and problems in the new automotive software ecology. An update from multiple viewpoints: where are we going, and who is in charge of how we get there?
Presented by The Software Freedom Law Center and Columbia University Law School with Andrew Sinclair of Canonical USA, Ltd., Jeremiah Foster of GENIVI and Luxoft, Leilani H. Gilpin of MIT, and Daniel Patnaik of Audi and moderated by Eben Moglen, Professor of Law at Columbia Law School and Founder of the Software Freedom Law Center, and Mishi Choudhary, Legal Director of the Software Freedom Law Center.
See event page for further information.
Transcript
EBEN MOGLEN: The most complicated and interesting place in the world for software right now is inside automobiles, and it’s going to stay that way for a little while longer, as the great revolution in automotive technology sets in. Whether that’s actual autonomous driving or it’s just a whole lot of computers in cars, there’s no question that the automobile is the frontier of challenge for all the wonderful things we’ve learned to do with software and screens and such.
I thought this was worth an entire conference last spring because the thing that most interests and consumes me in this discussion about automotive software is automotive software governance. That is, how the hell do we know what software is in a car, in the many computers that constitute the network inside the vehicle? And if we don’t know software is in a car, then we don’t know what’s going to happen out there. “Carnage on the nation’s highways,” as Sandra Day O’Connor once said, and so on.
And so, I really wanted to concentrate attention on the problems of governing software in cars. That’s a subset of the problem of governing software in the age of the cloud. One of the things my friend Dirk Hohndel has been talking about in the last year is the ways in which containerization has been very harmful to software governance because everyone just whips it up inside their container factory and ships it out the door in twelve milliseconds. Nobody really knows what’s in it, or whether it’s compliant with rules, or, even more importantly, whether it will work.
We got very accustomed to non-atomic updating in software distributions a generation ago, and we, we rolled our Debian tree or our Rail tree together, and then we threw in some other stuff that wasn’t from the tree, and we did all kinds of backdating and what have you, and we didn’t really know what bits we were running, and we still don’t. Notwithstanding all the skill of the distribution makers, it can be very hard to tell what is the fixed state of one computer, let alone a network of computers moving down a highway at seventy-five miles an hour or so under something like do-it-yourself autopilot control. This is obviously just a proving ground for the improvement of software governance.
It is just one of the many ways in which the automobile and the revolution of software in the automobile is going to have to pull the quality of technology along behind it – which is hard, because the world’s automobile manufacturers are not software companies, and they’ve never been software companies before, and leadership in software technology is never a goal they have set themselves or thought that anybody would ever set for them. But regulators and consumers and all sorts of commercial suppliers or would-be suppliers to the automotive companies want the manufacturers, the OEM’s, to become software experts.
They want them to figure out how all this stuff can be made to work together and how it can be governed in some rational way that state regulators and inspectors and other people making smart roads and smart vehicles can deal with. This is a good challenge for the world of FOSS. We specialize in heterogeneity and adaptability. We specialized in mixed supply chains of corporations and students. We are good at all kinds of things that should make it possible for us to be major improvers of the technology in automobiles, and we are major sufferers from the fact that we don’t look like the automotive industry as it has always known itself. We don’t fit neatly into the tiers of supplier-hood, and we don’t fit neatly into the world of parts moving towards the vehicle in a hierarchically oriented kind of way.
And we really do like the right to tinker and repair. We really do insist on the right to tinker and repair in all sorts of other social contexts. And we think that the right to tinker and repair is crucial to our ability to make software improve. And none of that is exactly what vehicle manufacturers think. So, I thought it was worth a conference next spring. I think it’s going to be worth a conference next spring. It was certainly worth the work of writing a paper with Mark Shuttleworth, which is work, I will admit, but work well done.
I think this is the place where we ought to have the most challenging time trying to figure out what free software engineering now most needs. The cloud? Oh, that’s just, you know, you throw billions of dollars’ worth of hardware together with a lot of free software, and you provide a lot of services. It’s a no-brainer compared to how you make an automobile explain itself with respect to what is in it and whether it can work together and whether there is some little gremlin of a botched rollback which you should be thinking about in deciding whether your car is safe to drive.
We have, I think, the best of the best to talk about this this afternoon. We having winnowed it out and had a conference or two already. I think this is the very best team that we could have to try to figure out with us what it is that the big issues are. I’m going to introduce speakers in the order of their participation. And I’m going to start with Daniel Patnaik, who offers us the opportunity to listen to what an automotive lawyer thinks about all these subjects. It’s highly valuable. We has a moment of great to me in the April conference after Daniel had finished speaking, and Jeremiah Foster, who is a man who, after all, has taught software with a lot of automobile companies. Jeremiah stood up, and he said, “You know, this is the first time in a – however many years it was – that I’ve ever had a face-to-face conversation with an automotive company lawyer.” And that just struck me, and that struck me as a terribly important moment. Daniel Patnaik has worked in the legal department of Audi AG for eighteen years, that is, he’s a real automotive company lawyer, not a ringer, not an impostor. And he is now one of the lead in-house counsels within Audi, at present in charge of providing legal advice to technical, purchasing, production, and quality assurance departments. His open source experience goes back fourteen years. That is, he’s an old-timer for us, and he has dealt with open source matters, including compliance, at Audi for some years now. So, not just an automotive company lawyer, accessible, really present, and willing to talk about things, but as deep expertise as exists about open source in the automotive manufacturer world. I don’t need to say very much, except would you tell us how it looks these days?
DANIEL PATNAIK: Of course, maybe we start the presentation?
EBEN MOGLEN: Yeah, please.
DANIEL PATNAIK: Okay, thank you very much for the opportunity to speak to you today as we did already in spring this year. I’m happy to continue our discussions on the topic. What I want to talk about is copyleft in the supply chain, I want to give you an update where we stand, and I want to open an issue which I also touched in spring a little bit is the TiVo issue. How can we deal with that in the automotive industry? What are ideas to think about? I would like to start with the challenges. Challenges, as you can see here, on one chart, not as sophisticated as Eben did just before, but maybe summarizing it a little bit in a condensed form.
We start from the technical need for a component. So, the developers come to me, come to us, and they want to bring a fantastic solution to the car for the customer. They have a technical need. They develop something, they work together, or they ask a supplier to handle that and provide that back to the OEM. That’s the starting point. Of course, there is an issue of protection of IP. Of course, we want to be aware, be ahead of our IP. We want to know, and we want to protect that know-how. We have, on the other sides, going to the left sides, of course, very important issues. This is the security, the security of a system, of a car, not only in terms of safety but more in terms of security. Is everybody, anybody, able to do things, or do we have a secured system.
And then we are in the conflict of having potential different interpretation of license. As we have heard in the morning, I think in a very perfect way… We have heard of ambiguity. So, that means a license can have many meanings. And this is also a topic I see in my daily practice and where we struggle when we talk to our engineers as of how do we understand and how do we have to implement things. Now, looking way far ahead, we are today not there. We are starting with different levels of autonomy in the car, but, once we have those cars on the roads, and we’ll touch that a little bit later as well, and we have codes in the cars which give the customer the freedom to make modifications, then I’m just imagining an autonomous car driving around with the software which was modified by the user.
That’s something where you can see that this is really a challenge where we need to work on, where we need to get a common understanding how this can be done, mitigating security but also, here, in that case, safety, on this other side, the freedom by the user. So, how are we handling the challenges? To give you an update, here, from top to down: first of all, we have started to elaborate terms and conditions over the last year. Clearly speaking here, we have opted for a very liberal approach. We don’t have a general prohibition of licenses. I don’t like blacklists. I prefer to say we work with a best practice list to see where we have good experience, but I don’t like blacklists because I don’t want to limit our technical guys toward solutions. If they come up with a solution which is maybe under a difficult license, then I would like to understand what it’s all about. But if I would from the very beginning start and say no because the solution is under a certain license, then I would limit the business, and I would like to support the business, and that’s what my team’s doing.
What I have stated here, it’s all about transparency. What I would like to have is transparency, and this is something we are trying to achieve through the terms and conditions. So, already, in terms and conditions, I note on that I would like to have the transparency. How do we do that? And this is the second bullet point. It’s the Audi Open Source Diagnostics. We have developed that, I think, already eight years ago, with one of our daughter companies, Audi Electronic Ventures, where we have set up a tool which, first of all, is obligatory to the persons using its own developers, but it’s also our suppliers, that they say what software stake they’re using, under what license that is, and want they want to do. Is it something they want to alter, they want to distribute, and/or they want to bring it where? It could be Audi cars; it could be Audi apps; it could be just software behind which is used on our desktops. That’s something we developed some years ago, and that helps us to get that kind of transparency because we oblige all our suppliers to fill in data into our Open Source Diagnostics, and that’s how we get that.
And with that information, then, at the end of the day, we can, the lawyers can then better understand and better evaluate whether this is of a high risk or we need to change something, even structural-wise. And, something which we are still in the process of organizing is establishing checkpoints along the Software Build Process. I have put a small picture here. So, the checkpoints we would like to establish are very early. Let’s start here. This is the hundred-percent software, so software is hundred-percent clear, and you’re probably not able to change it so easily, and this is a very late stage. I would like to get here in the software ordering process. And already here, I would like to understand from the company what software are you going to use. And if this is not clear at that moment, of course, then, finally, here, somewhere in the software build process (so this is the software development), somewhere here I would like to have that checkpoint. And, then, finally, on the last point again, hundred-percent software, this is a confirmation. What was planned fulfilled? Did we make changes? Was there maybe alteration? Did we have to add any other software? This chart should show you the supply chain. The red, top arrow shows the contractual side. So, we as an OEM (and, therefore, this is in the small box), our main contact is the Tier 1. Now that Tier 1 might have a Tier 2, 3, 4, and you can see there are multiple ways to do it. It can go left or right, down and up.
This could be, as Eben just said, a container and could be having multiple sub-tiers. At the end of the day, we have a Tier 1, and he’s the responsible person on our side, because to him we have a contractual side. He might have contracts with others, but that’s how we follow the line. And then, in the deliverables, where we say we want to have information about what software is in, then it goes the way around. It goes from Tier 5 to the Tier 4 and so on to the Tier 1. And he, then, finally provides the package to us.
If you look at the Audi Open Source Diagnostics, which I’ve just touched a minute ago, this slide should show, again, here, there might be different software modules from the Tier 3 to the Tier 2 or Tier 1. And, at the end of the day, what I like to see and understand, finally at the end of the day, is how do all the open source modules look like. Again, that gets aggregated in our tool, and then we have that transparency where we need. I admit that currently we’re still always very at the end of the software build process. I, as I said, I want to drag everything to the front. And to David, we are looking at, also, the open chain very closely, and, hopefully, we will be there also shortly.
Now, apart from that, I wanted to touch the TiVo issue. I don’t know how deep I have to go into the TiVo issue. It’s a term for a security measure. It’s a meanwhile widely used technique in commercial products to prevent software which is not signed from running on a system. And that poses problems which we can see in a moment. So, again, here is the area of conflict: the developers need to secure software against manipulation–as you see in the autonomous car could pose a security risk. They want to protect the IP and implement certain technical features. Now, of course, there is a legal need for compliance with the components because of potential claims, whatever.
And, sometimes, a liberal interpretation regarding license provisions is possible. So, what would be the options? Option one would be a very safe option. Do not use LGPL2.1 or GPL 3.0 in TiVo-ized systems. This could be a very easy and safe option. As I said in the beginning, I don’t want to hinder technology coming into our cars [or] into our systems. So, the other option would be to make sure the user is able to exchange the respective open source component with modified versions, of a library, for example, and still get the whole thing to work in a proper way, “operate properly,” as I wrote down here, to be able to execute modified versions.
On the next slide, you can see how that could be possibly made. It’s just an idea, what we are thinking, how to solve that problem. So, on the left-hand side, you could see that we have that “.lib” included in Partition 1. And, then, of course, if that software is secured and after the change by the end-user, by the customer, you find out that it was changed, and then the whole thing doesn’t run, that would make it noncompliant in the case of the FOSS license because of the TiVo issue, which was implemented in GPL 3.0 or LGPL 2.0.
The solution we are thinking on, and that goes a little bit into, also, I think, Eben’s direction or thoughts, is to maybe separate components. “.lib” is placed in a separated file system partition instead of including it into that part over here. It could be deactivated upon request of a user, allowing exchange. And so, even if the protection for a partition “.lib” is deactivated, the rest of the system, including Partition 1, could be continued to be protected by the observers. So, that could be a solution.
But if we then look at what does it mean for the system, if the TiVo issue is interdicted and the user must always be able to get a program to run properly, then what does it mean? To what extent does the system have to be able to run properly? Do we go to the smallest part of it which could be a part of the interpretation? Or does the entire system? So, the entire car has to run. To make an example, if we have something in the rear seat entertainment, there is also open source software involved. Does it mean that the rear seat entertainment has to work? And, if there is a change, and maybe not secured anymore, does it mean that, of course, the customer could make alterations? So, maybe this, the last part, could be affected but not the entire car. So, these are the challenges, and I just wanted to bring up the issues.
I don’t have a solution right now. We are thinking about solutions, as you have seen. It’s not that easy, as you can understand. I wanted to bring up those questions, and that should be my part for the moment.
EBEN MOGLEN: I actually think that it might be a good idea to have responded directly to that, since this is, after all, what we have been trying to think about ourselves. And Leilani can wait just a moment, so just jump in. I’m not even going to introduce you; go ahead.
ANDREW SINCLAIR: Alright, I’m Andrew Sinclair. I work at Canonical. We are a supplier of Linux operating system Ubuntu. And as a supplier, we supply everybody that might need an operating system. As Eben pointed out, there’s been a lot of momentum and traction in data centers and cloud computing. That’s often running. And I think now we’re at a point where there’s a new market, which is, really broadly speaking, just new devices that didn’t used to have to computers in them that now do. And so, that’s certainly cars.
There’s always the example of the thermostat, you know, a device that didn’t use to have any computing capabilities and now does. Cars are having more and more computers in them to do everything in the car, and all those computers form networks in cars that do all kinds of things: operate the vehicle, but also provide you a map, and provide you music streaming and internet connectivity and everything. And wherever you have a computer, you have software; you have an operating system.
Whenever you have an operating system, if it’s in a new computer, it’s most likely software because it’s most likely Linux, because there’s not likely to be–If you’re going to launch a new car that has forty computers in it, there’s a lot of economic benefits to using a free software operating system on some or most of those computers. You have the benefits of the user innovation that comes out of the free software development model. You have the benefits of being able to see what’s going on in those computers. There’s the end-user freedoms. Cost–you’re not paying a royalty to somebody for each of those computers every time you ship a car or every year that that car is operating or every month that that car is pinging a server somewhere to download music or maps.
And so, we’ve found that there’s basically a new class of customers for us that have slightly different interests and requirements for what they’re doing. And, in particular, I would say there’s an interesting in security, verification, trusted computing. These are things that are particularly present in an automotive context where the computers aren’t–Not to downplay, you know, that you can’t have problems in a data center, but here you have a device that weighs a couple tons and is barreling down the road, and there’s people trying to cross the street. This is a really, a really physical manifestation of computing, and that code and the verification of that code and the trustworthiness of that device I think really matters to a lot of people in a really tangible way that maybe was, is significant in other computing environments, but it’s just really obvious in an automotive context.
And so, one thing that Canonical’s done and been in interested in doing to supply into this market, the market of automotive but also of IOT generally, new, next-generation devices generally, is to create a system where, well, it’s what Eben was referring to as software governance, the concept that there are multiple components, multiple systems working in concert with each other, and that there is a mechanism for those components to validate and trust each other and to report on each other so that you can have a system that has those benefits: verification, trust, et cetera. And that leads to safety, which, what I think is particularly relevant in the automotive context.
Maybe something to ponder is how consistent or inconsistent is that with free software principles which are about openness and user rights to modify. The example of the autonomous car that’s been user-modified coming down the road, I hate to say it: I’m not sure that scares me more than just a driver coming down the road. There’s already a human there that’s making up their own mind about how they think, where they think that car should be going. And I guess you hope that, I don’t know, maybe the difference is that there’s some instinctual save-humankind instinct when you’re driving, and when you’re writing or modifying software, that you may not think all the way through the consequences of that modification.
But I think that there is a balance that we need to investigate and find where car manufacturers can have the benefits of the economics, where users and consumers can have the benefits of the other great things about software under free software licensing, and do that in a way that doesn’t have negative consequences. The kinds of questions that we get from suppliers–You know, on your chart, Daniel, of the tiers of suppliers, we tend not to be the one that’s directly providing software to the OEM. And so, one thing that we encounter is a…It’s nice to hear that Audi doesn’t have a blacklist against licenses, but there are manufacturers that do have those blacklists, and those lists are relayed through the supply chain. And we have this kind of problem where have this just lack of conversation with, between, someone like Canonical, an upstream supplier of a very low-in-the-stack operating system, or operating system components, and a customer who’s sort of behind a veil, behind a couple other suppliers, that we think we have a really good solution for and a really good licensing model for. But their suppliers, the tiers in the middle think that one of their roles is to just kind of relay, “Well, that doesn’t meet the spec; that’s GPLv3; that’s… that’s… doesn’t meet the spec. The spec requires no GPLv3.”
And so, I’m really interested in finding a way to have a discussion with the industry about that. I really appreciate that you’re looking for ways to actually incorporate that software and do it in a way that takes all the benefits of the licensing model that it’s under and also reduces any risks that are perceived by the OEM. So, it would be great to kind of investigate how we can get more OEM’s thinking that way and listening to their developers who are interested, I think, in the economic benefits of free software, but also balance their interests with the development, (It’s more of a development model than a licensing model, I think, the free software development model.) and get all those benefits.
EBEN MOGLEN: So, before we go any further, let me just try and apply that directly to what Daniel was talking about. This was the motivation of the work that Mark and I did last winter. If you’re trying to answer Daniel’s questions about how do we deal with user-modified software in an autonomous vehicle, and how do we deal with the kind of containerizing or isolating that he was pointing to in his chart, what would happen if we looked at the way we package software generally as the arena of solutions for his problem? And here, the interest that I took in snaps as a form of software distribution had two pieces to it.
Suppose we were to begin packaging free software generally in distribution structures which provided for acid kind of changes so that everything is only itself. It doesn’t have any side effects. It can’t be modified once installed without going through the modification system, and it can be rolled back. A structure like snaps in which every package has its own read-only code repository and local data located in one specific place no longer risks all the various interaction difficulties that we experience when we upgrade a single package or a few packages in a distribution like Debian or Fedora or any of the other distributions packaged as we usually aware. And Daniel’s diagrams show the need for some monitoring entity checking the state of software at all times. What if that monitoring entity were both smart enough and correctly hooked together so that there was fine granularity in permissions about what individual programs can do.
Snap packaging was just an example, important to Canonical, but from my point of view important as a general advance in packaging, that allowed us to achieve those two goals without asking the OEM to do anything because the operating system supplier has already decided to change the way packaging works. Now we have a kind of granularity in both knowing what versions of software are installed and being able to roll them back automatically at the package management level. GPLv3, when we wrote it to provide for a requirement for users to get installation information to allow them to modify the versions of GPLv3 programs running in their computers… GPLv3 Section 6 provided for the statement that if the network on which the computer is resident would be made unsafe or inoperable by a particular modification, the network services can be denied to that modified version.
Richard and I had primarily cellular telephone networks and other similar things in mind in 2006, when we wrote that language. But we left it general for precisely the sort of situation of a specialized network of computers, which is the situation of the contemporary automobile. The idea was, if you’re going to endanger the safety of the network with a modification, then maybe that modification should not be allowed to talk to the vehicle network. This allows us the kind of granularity at the package management level in which we can say, “Oh, great, so you’re…Really? Get another one with a not dead battery in it; that would be the correct solution, thank you.”
Now what we’re doing is saying you have a vehicle entertainment system; and you also have driving control; you have breaking, and you have steering and you know. If you modify the media player in the car under GPLv3, the media player might have a slightly different set of privileges on the network now that you’ve modified it. The manufacturer-provided entertainment system might actually interact with breaking and steering control for some reason or other. But let’s hope not, and the modified version certainly won’t able to because the snapd or equivalent software governance daemon inside the car won’t let it. If we create the layer at the package level, then what we have already is all the facilities that the manufacturer would need to have once the whole operating system is supplied to it.
It now has enough control that it can even do things like have GPS decide which software should be running. If you’re over here on your own property, do whatever you want. Once you’re on a smart road, you have to be running manufacturer software because otherwise the smart road might fail. And that can be decided on the basis of physical location or any other set of inputs inside the vehicle, which say what software should be running. I think the important point about the fact that you’re not a tier-one supplier mean that whatever’s going to happen has to be very general. This is going to come through one set of negotiation between one OEM and one component supplier; it’s not going to happen in the form of a bilateral negotiation between Audi and Bosch; it’s going to have to be something which works for everybody, which is as good for Toyota as it is good for VW. And that means that we might want to look at the layers of software provision which are the domain of experts in software provision, regardless of whether they manufacture spark plugs or injectors or anything else. If we did the software provision incorrectly at the operating system level, maybe we could solve this problem for cars, which is a very hard problem in general of software governance. Maybe, at that point, IOT microwave ovens wouldn’t seem quite as daunting a problem as they seem now.
That, I think, is sort of the technical progress that I would hope somehow that we can make. But, of course, all of this is done by hand-waving instead of by research, so this is where I want to get Leilani involved. Leilani Gilpin is a PhD student in Electrical Engineering and CS at MIT working for my very favorite MIT professor, Jerry Sussman, and is particularly engaged at the moment in a one explanatory artificial intelligence project, namely “The Car Can Explain!”, which is a Toyota Research Initiative Project being conducted at MIT. Leilani’s research is about the question, “How do you get the car to tell you what it’s doing?”, which is of course a very important outgrowth of the question of, well, “How did that software get in the car in the first place?” So, from the point of view of somebody who wants to try and make these systems actually transparent enough that they can say what they do, what do you think is the way software has to get into the car in order for that to be possible?
LEILANI H. GILPIN: Great question. So, I just wanted to sort of start by saying the project I’m working on has been open source since day one. Our goal has always been that people can use it and people can contribute to it, and that’s always been a goal of ours. And I sort of wanted to highlight the fact that there’s a huge disconnect between the systems that we’re building now and the systems that would actually help society and these sorts of software governance by design that we’re trying to make. I wrote a few notes this morning because I was feeling pretty inspired.
Julia Angwin had said that can’t solve a problem until you correctly diagnose it. And, unfortunately, the sort of diagnostic systems that we have in the car now are just not that good. We keep adding more and more complexity to these vehicles to make them more autonomous, to make them smarter, and we’re inherently adding more ways that they can fail. And it’s extremely rare that these failures are single-point-of-failure, or that they’re local. And so, what we really need is we have to think about the incorporation of how these parts work together. And if we want to know how these parts work together, we need to know what they’re actually doing. We need to know what they’re doing in software; we need to know what the mechanical systems are doing; we need to know what the data looks like, and, unfortunately, we don’t really know any of that because all of, the majority of, the software is proprietary.
The majority of the mechanical systems are sort of distributed throughout the world, and we don’t really know what they’re doing, and the data is private. So, a lot of the big problems that I see is that we’re trying to build these explanatory systems but we don’t actually know what these things look like. And so, for us, our research relies on having data. Our research relies on having access to the mechanical parts of the car. And it relies on knowing exactly the data look like. So, if you heard me speak last spring, I was saying how everything we do is simulated, but we really need to work towards real-world examples, and we really need to force these mechanisms to explain. And so, that has been sort of the focus of my research, is that developing these explanations that can actually be used for society and for policymakers and for people working in the government so that they actually know what’s going on. But we can’t do that without open software.
EBEN MOGLEN: Assuming, just for a moment, that we could see all the software in cars, would we then understand what is going on? Is visibility the primary limitation?
LEILANI H. GILPIN: I would say it’s one of them. So, again, it’s so many intertwined systems working together. It’s the network. It’s the software. It’s the mechanical systems. It’s, you know, what was the latest software update that was pushed, or was it pushed back, or is there a wire broken. And so, I think having transparent systems would be wonderful and would be a huge step forward. We really need to think about, you know, sort of open software and these open mechanisms by design so they’re designed so that we can sort of augment them. We can know what they’re doing. We can force them to explain.
EBEN MOGLEN: Daniel, how far is that consistent with that constant protection of IP motive throughout the supply chain?
DANIEL PATNAIK: A challenge again. Of course, I can understand that there’s important to understand. Probably this will be also something evolving. The more and more open source software gets into the cars, also, let’s day, drivetrain, bumper system, that could evolve. At the moment, you are right. This is proprietary. It’s probably also proprietary because it’s also differentiating and against competitors in order to say we have a certain setup which others aren’t able to do; therefore, our cars is more sporty, more premium, than others. So, going to that, our area will be real challenge safeguarding IP competition. But I can understand, maybe, it has to go into the direction that we have to define areas where there needs to be more openness, maybe also for the regulator. And then, I think, this can be a match.
EBEN MOGLEN: So that’s the good of society part. Isn’t it, Leilani, right? I mean, if we’re going to have the good of society, then society is eventually going to have to speak on these subjects. And it’s going to have to say, “This is what manufacturers have to do in order to build responsible products.” So, is there going to be a sort of list of, “If we’re going to have explainable technology in cars, this is what the regulators are going to have to provide for?” Is one output of this research the kind of direction for policymakers that Max was talking about in the morning? Are we going to have research clarity about what it is the rules have to provide?
LEILANI H. GILPIN: Exactly. With all of these areas, I think there’s just like a big disconnect between what the technical community is doing and what policymakers, or sort of what we, say is good for society, right? And we just did a sort of large-scale review paper where we’re looking at sort of the state-of-the-art explanatory methods, and we defined that there are really two things you need to have a truly explainable system that can build trust. And one is that you need the explanations to be interpretable. You need humans to be able to understand what they’re doing, and that’s not a technical expert, right? Just having a system that explains for a software engineer is really great, but that’s not going to build the trust of a customer. But then you also need that explanation to be complete. You need it to be true to the model, true to the data, true to the software that it’s looking at. So, a lot of these explanatory methods will sort of use a proxy model that’s easy to explain. So, they’ll fit it to some sort of linear system, but that’s not actually what the model is doing.
And so, I think, taking that one step further, so having explanations that are interpretable and complete, but you also want them to cater to what policymakers want. So, you want them to tell a coherent story. And so, that’s the last thing that we’re looking at, is that you can’t just sort of provide explanations without background. You really need to make sure that you look at what you had done, what you were doing, and what you’re doing moving forward.
EBEN MOGLEN: Okay, Jeremiah, table is set. I have to say that Jeremiah Foster is from Boston because this week really matters, whether you’re a Red Sox guy or a Yankees guy. He lives in Connecticut, at the border between two cultures. Jeremiah is the community manager for GENIVI and then Open Source Technologist at Luxoft. Luxoft is the promise of open source in cars, the only operation of its kind in the world, as far as I know. And, therefore, Jeremiah is the expert at making trouble about this.
We have been talking about GPLv3 cars since there was GPLv3. What do you think?
JEREMIAH FOSTER: Indeed.
EBEN MOGLEN: Where are we now?
JEREMIAH FOSTER: Well, you know, your conferences tend to have wonderful, rhyming themes, or the theme works through everything, and I think again we’ve come to it, today: peace in our time. And I think one of the masterful things that we’ve done in our community is that we have a stable API in the Linux kernel. And that’s enabled things like containers, which are just a stable API, but in userland, let’s say, or controlled by cgroups and namespaces, et cetera. And as [someone] says, you know, people just jam a lot of software goo in there, and it’s a wonder that it works at all; we have no idea if it’s compliant – probably not – whatever.
It does work, amazingly enough, because it’s going against this rock-hard stable API. And where we have a fascist in charge of our program (Okay, he’s a reform fascist), but, you know, you’ll get Linus very upset in you break backwards compatibility. Rightly so, he’s right. So, when you talk about software packaging, when you talk about containerization, that is a perfect place for GPLv3 to interact with that stable API. And so, I think there… I think there’s consensus, as you say. We can use GPLv3 software; we can allow users to modify it, but we also have to have the safety preconditions. And now that we have this kind of introspection into the vehicle, or if we can build around those systems like the snap daemon, like containerization, then I think we can achieve that. So, I think it shouldn’t be controversial anymore, you know? And it’s as Daniel says: Let the engineers innovate. License be damned, it’s orthogonal, you know? The license issue really should be an ortho– a separate issue. Use what works.
EBEN MOGLEN: In your view, is the race to autonomous operation getting in the way of some things that we might do in the engineering if we weren’t running towards automotive computer driving?
JEREMIAH FOSTER: I see why you say that. I mean, they say it’s a trillion-dollar market, mobility as a service or autonomous vehicles. I would say there seems to be a parallel track, fortunately, with advanced driver assistance, or ADAS, technologies. So, were seeing a lot of that autonomy come in, already, to a lot of vehicles. You know, Toyota has great lane change, and Mercedes has sort of in-traffic following, and those kinds of things. You know, Volvo has City Safety. So, hopefully “no” is the short answer to the question, but, yeah, I think that there are certainly companies that are going to do the moonshot and try and surpass all the OEM’s. I don’t know if they’ll be successful. It might happen.
EBEN MOGLEN: And I worry about the kind of environment proposed by the shared mobility principles in which software governance is just so hard to do, that the only people who should be allowed to own self-driving cars are Lyft and Uber, right?
JEREMIAH FOSTER: [laughing] Yeah.
EBEN MOGLEN: –The idea that idea that a self-driving car is such a software maintenance problem that “Don’t try this at home.” “Don’t plan to own one; we will,” right? That model of transportation as a service is being driven in part by the idea that we’re not good enough at software to allow the car to continue to remain the domain of individual liberation that it has been since Henry Ford. And that, again, seems to me to be an outgrowth of the idea that autonomous operation is the objective of all engineering. If we could first make cars smarter without making them autonomous, maybe we would pay attention to some of those software issues in a different way, right?
JEREMIAH FOSTER: Got to go.
EBEN MOGLEN: That’s an instinct on my part, not as it is in your world, a technical reality of daily life, but it does feel, in a way, as though the completeness of autonomous operation is the enemy of some lower-level, low hanging fruit of technical improvement in software in cars.
JEREMIAH FOSTER: No question, and I think it’s driven by a venture capital regime for a lot of software companies. You know, it’s like, “Okay, if we can get our hands on our billion dollars, we’ll be able to put one of the Big Three out of business,” but it just ain’t so, because, first of all, it’s going to take a lot of infrastructure. And second of all, cars companies are saying, “Okay, you people think only you can do mobility as a platform? Hold my beer.” And they’re going out, and they’re making software. And you know what? They know a heck of a lot about GPL; they know a heck of a lot about licensing; they know a heck of a lot about supply chain that maybe Uber might never know. You know, all that just-in-time stuff, I mean, for heaven’s sakes, building cars is wicked hard.
EBEN MOGLEN: One of the things I experience in my relation with the European Commission is that the Commission wakes up in a cold sweat on alternate nights, Monday/Wednesday. On Monday night, they wake up in a cold sweat at the prospect of the Google car, and on Wednesday, they wake up in a cold sweat on the prospect of the Apple car. And they worry about the destruction of this great European manufacturing industry that the automobile has been by a smartphone on wheels that will be not a European production at all. If the regulators are worrying about that, that functions in my view as a kind of apocalypse on one side. That, the fully autonomous operation feels like is the apocalypse on the other side We should be taking this a little slower. We should be perfecting some elements of the automobile’s relationship to software before that moonshot you keep talking about, which is going to be some highly integrated, vertically contained, highly containerized, you-can’t change it, it’s-an-appliance platform, which gives all sorts of telemetry to whoever it is. Who owns the data, which maybe is, from my point of view as a theorist about freedom and technology, the biggest problem of all, right?
The modification I want to be able to make to that software is the modification which gives me the telemetry data or which puts it in my Safe-and-Solid box somewhere and allows my identity, as I have invested it in my car because people have been investing identity in automobiles since automobiles…to give me the control over that identity which the image of the car as personal freedom always presented. I think we are at risk of destroying that very valuable idea of the automobile as personal freedom on the basis of software engineering we could have done better. Comments, questions, involvement from the many knowledgeable people who are here? Sean.
AUDIENCE MEMBER: So, I know that software has bugs, and I know that–surprise!–I know that–software can be tampered with, right? And you all are thinking very hard about how to deal with updates and patches and anti-tamper mechanisms and so on. The issues that I’m worried about is side-channel attacks. So, specifically, there is a car manufacturer who is not, or a company that’s not someone on this stage, that’s using ultrasonic tones coming from speakers and then picked up by a microphone in the vehicle to do things in the vehicle. And it seems to me that that kind of attack is something that we’ll never get around if we have digital components controlling the logic that actually drives the vehicles. So, if you could just comment on that, and I’m especially, obviously, thinking about autonomous vehicles. Thank you.
JEREMIAH FOSTER: Well, you know, I won’t speak for Daniel, but security is taken very, very seriously by OEM’s, super seriously. And they have complete and comprehensive programs. This ultrasonic stuff, I think I saw that article, too. Hopefully, when you architect these systems, the breaking system is not connected to the media player, as we mentioned before, and that, the breaking system, is usually a single wire; it’s just a CAN bus. Yes, they do obfuscation for security. It’s not particularly secure at all, but, you know, those things shouldn’t be susceptible to those attacks. Part of its simplicity is, will make it vulnerable to attacks, but look at it from a carmaker’s perspective. This works. They know how to use it. It’s been around for decades. It’s not going away. So, yeah, obscure side-channel attacks, I don’t know how you’re going to defend against that at this point.
ANDREW SINCLAIR: Well, just one thing to add: One shift that’s happening in the automotive is the over-the-air updates and the availability of those. So, just like there’s vulnerabilities exposed daily in other computing systems, when those vulnerabilities are exposed, if you have a system that can be updated quickly, you can at least patch the vulnerability with something like an over-the-air update. That’s a big change in the industry, where there’s a lot of manufacturers where, if you need an update to your car, you need to drive it into the service center for that manufacturer and schedule an appointment, and that’s way too late, right? If the vulnerability exists today, I can’t wait two weeks to have it patched. So, I think that’s a natural… That is a natural progression to just having more software in cars and more networking in cars. And these systems that support the authentication between components can really help mitigate that problem, and it may not reduce… It may not eliminate it, but it can help reduce the risk.
AUDIENCE MEMBER: So, if possible, I’d like to hear some expansion on this idea that using snapd or a similar enclosed containerization technology is an acceptable and safe pattern to use to put GPLv3 license code into regulated, controlled, locked down hardware computer components, IOT components. Many of us have been looking for ways of being able to handle GPLv3 in these kinds of environments without it costing a huge amount of liability or a huge amount of IP risk or a huge amount of development costs. Does anyone have anything to say about that?
EBEN MOGLEN: Well, in that great big pile of paper that people got for Continuing Legal Education credit is our paper, Shuttleworth’s and mine, on the subject, which you can also find at softwarefreedom.org and maybe other places if Mark also is choosing to publish it. The concept is already fully communicated, right? There’s a little more detail there, and I’m continuing to work on a set of ideas about software governance and packaging, for which snapd is meant, for which snaps are merely an illustration. But the basic principle is that the license allows the necessary discriminations on a network to protect the network’s safety and operation, so that there may at the end be a judgement call that might one day reach court about whether the manufacturers’ signed assertions about what a modified program is allowed to do or beyond what the license permitted them to limit.
But generally speaking, where we are talking about safety and security, I’m content that the license is drafted in such a way that modification of network access at the fine-grain, functional level is an appropriate mode of compliance with the license. So, we may, then, have eliminated a legal risk issue because you treat the modified version of the software slightly differently than you treat the unmodified version of the software. It’s also terribly important from my point of view that packaging be of a kind which eliminates side effects in the tree, from the installation of patches or modified versions. It’s all very well to talk about an over-the-air modification of the car in order to provide a security fix, but it’s really necessary, (a) to be absolutely certain what that patch is and to be able to roll it back if it turns out to break the car. There have been many a patch Tuesday on which many valid patches turned out to be a little hard to operate in a computer which had turned itself off and wouldn’t turn itself back on again. So, acidity in the system, the ability to roll back, the ability to avoid side effects in software installation, is a big part of why I think this works from a liability perspective with respect to safety or security. Yeah, I do think, I hope, that cars are here a model for the solution of a lot of general problems. I want to do whatever can be done to address the preservation of the right to tinker and the right to modify and the right to experiment in the real world, in the most complicated place possible, which is why it seemed to me the car was the place to start. Is that responsive? Or did you have more you wanted… Okay, thank you.
DANIEL PATNAIK: Let me just add one thing, and this comes back to the discussion in the morning. We could wait until a court rules on that, but I think it’s important to have this as a community understanding with Eben and Mark Shuttleworth and myself. I had a little bit here in slides. I communicated solutions to establish that as a community understanding. That will be, I think, a good result.
EBEN MOGLEN: I think that’s absolutely right. I don’t think this is going to turn out to be matter of litigation. I don’t think anybody’s ever really going to court to say, “You infringed the copyright of my GPLv3 program, because when it’s running in a car, you decided to limit access to the moving mirrors around when you are changing the music being played. Yeah, you make think that’s a clever change, and you can run it in your driveway, but you can’t run it on the road.” And as we get more smart road technology and the question of the relation between the car and non-car parts of the network becomes more important, we’re surely not going to wind up trying to adjudicate whether it was an infringing modification of VLC to say, “No, you know, you can’t shut down the smart road you can’t turn the lidar off; there’s a whole lot of stuff you’re simply not allowed to do. You’re just a media player, for heaven’s sake.” So, I think we’re going to get pretty easily to common sense about that in law if, as you say, we have otherwise good industry-wide understandings, principles of how to do this, and those are going to be desirable for manufacturers because they’re going to hold regulators at bay.
The problem of the regulators’ anxiety is a problem that the manufacturer wants to resolve, all manufacturers want to resolve, by saying, “No, no, you don’t have to worry about it. We have really excellent, self-governing principles. We really understand the building materials that we use. You don’t need to ask us about the steel in the car. We look after the steel in the car just fine ourselves. That, I think, is going to be the force which is going to bring people to the table to get to these good, common answers, because Leilani is right that, you know, the regulators are going to demand this, and if regulators around the world are demanding it, even to the extent that they want to help their local manufacturers live strong and do well, they’re still going to need the kind of technical understandings that we’re talking about. Alright, one more question, if there is one. Yes.
AUDIENCE MEMBER: Alright, so, this question is for Daniel. There are efforts by car companies to collaborate among themselves for autonomous driving. So, for example, the Audis and BMW’s and Fords can talk among themselves on the road. The cars can talk to the cars of our mother companies for the purposes of autonomous driving.
DANIEL PATNAIK: Yes, I think this will be the future. Of course, right now, everyone is developing the cars in a way, in a two, three-layer system in order to have… Maybe they have to have maps. Then they will have their lighters and everything. We have a central fusion set of data where we do a kind of our own maps, so we have different types of layers, so if one fails, then the others can jump in. So, by that, you are able to drive autonomously throughout the city. But of course, in the future, and also the other car manufacturers are working on is that we have a common respondence and interaction between the cars. I think this will be another layer to make everything more clear, more safe in the future. That’s what we are talking about, and the companies are talking with each other at the moment, always within the boundaries of the laws.
JEREMIAH FOSTER: And there’s also a number of initiatives. For example, in the commercial space, the European car companies purchased Here, which has mapping technology. So, that’s a significant investment they’re making to share or at least standardize parts of those maps. The Linux Foundation will have an initiative on it. And Linaro, which is sort of a version of the Linux Foundation but that produces software-based systems, called for an open source, autonomous driving platform. So, there’s a clear industry need across the domain of the automotive industry. Whether it’s going from Silicon all the way up to car manufacturers, there’s an understanding that autonomous vehicles probably must be open, or must have the degree of transparency, so that they can actually interact, so that regulators can understand, so that, you know, people are safe. It’s quite simple, but there’s a lot of that happening behind the scenes.
DANIEL PATNAIK: And, and just to add it, because I was handling the Here deal also on the Audi side (funny enough), the map thing works like that, that maybe an Audi car will find out that there’s a hazard, something, either it’s ice on the street, it will send that back to a server. And the server’s, then maybe used in another car, who then goes to same direction and find out the car will warn him, then, beforehand, and say," There’s a hazard; there’s ice on the street." That’s what… That will be one of the layers. There will be more layers also to come.
EBEN MOGLEN: Alright, thank you very much.