Software Governance and Automobiles - Session 1c
Security, TiVo-ization, and FOSS Licenses, by Daniel Patnaik
EBEN MOGLEN: Daniel has worked in the legal department of Audi AG for eighteen years, and at present he’s an in-house counsel in charge of providing legal advice to technical, purchasing, production, and quality assurance departments. His experience in open-source software dates back to 2004, which except for people like Mark and me is the Stone Age, and currently he and his team advise the various departments of Audi on all open-source matters, including compliance. Previously, Daniel was part of an exchange program with VW, which could have used your skills, as you know, for a longer period, and from 2005 to 2008, he was in Dubai, UAE working on supporting sales. So, the global automobile industry and its relationship to free software… The greatest expertise available is his, and therefore skepticism too, I believe. The question is we have these ideas, now it’s time for the automobile industry to kick the tires. Would you mind doing so for me, please? Thank you. Please welcome Daniel Patnaik.
DANIEL PATNAIK: Perfect. Thank you very much, ladies and gentlemen, hello–thank you for having me here. First of all, I would like to start with an excuse. Please excuse my English. My English is not as good as Eben’s and maybe Mark’s English. I am a native German lawyer, and so forgive me if I’m lacking some English words. I’m trying to do my best. I also have to state that whatever I am going to present today is a statement of me personally. It’s not an official statement of my employer, Audi AG, but, however, you can and will see how I understand things and, of course, how we in the automotive industry see some of the points which have been raised here by Eben and by Mark. I think it’s a very, very interesting topic, and we are deeply working on it, but there are a lot of challenges, which were already highlighted by both of you, which is absolutely right. We are in a very complex matter and very complex area, and I would like to give you an industry view, a view of how that can be seen from the automotive industry perspective.
For all of you who are maybe not so familiar with TiVo and the TiVo case, TiVo, from my point of view, is a term for a security measure which is in due course already widely used in commercial products, not only the automotive industry but any other industry, which shall prevent a special software which is maybe signed or not signed from running on a specific system.
So, that means the user cannot–he may change software–but he cannot install such a modified version of a software component. This, however, and this is, in general, in a kind of a conflict is, however, required by open source license.
In this case, as I have put up here, the hardware checks of a software for an expected signature are there and if the system notices that there is a change it shuts down, if it finds out that there’s not a match. So, whatever has been checked before isn’t there or has been modified. This can be done by using build-in routines, which may require those checks in a hardware.
The term TiVo-ization, as I have it up here, is derived from a specific case–the TiVo case. TiVo and Linux… I think the general topic there was a digital video receiver. It contained Linux, which was under the GPLv2 license. The source code for the system was available but it contained a technical blocking device which prevented users from running any modified version of a software, and the Free Software Foundation took up the case, complained that the users at the end were prevented from using or from exercising their freedom to change, to alter and to exercise, at least, their right to do changes and operate it in the system.
The third aspect that I want to touch here is, yes, that was the case, but in the automotive industry I think we have security and safety issues. We want to prevent that we have, kind of, manipulation. Why is that important to us? It’s important to us because we want to safeguard our products and, therefore, we have, of course, signature checks through Secure Boot, Chain of Trust–and this is widely used–without a possibility to release signature checks.
And I think the topic in the later part of the day today, which talks about autonomous cars–and this is what I’ve put up here as a small picture, illustration–this is a little bit of the trend, and I think Mark and Eben have been touching on that as well. This is the trend we see. Imagine autonomous cars with a software modified by users. So, this is just a general, a very flashlight, here.
You can think now that autonomous cars are coming to the cities and are being tested. We are reading a lot about what’s happening. Now, also, the countries, the cities, and the states, are trying to regulate and try to get permissions–who can use it and who can do it–but now imagine not only the car manufacturer will do a certain software algorithm to do that kind of, to produce that kind of software but also maybe a customer, a user, will work on that and then ultimately run his car on that kind of software and at the end of the day, the car is on the roads and some difficulties might occur, which then start from personal injury to even more dangerous issues.
So this is the trend in a very highly abstract way that we see, but I also want to go and dive more into the deep what that means at the end of the day. And, of course, if you have questions, please always raise your hands and we can ask you.
I put up this nice, very uncomplicated, slide here. It looks very highly dense with information, but I think I’m just going to explain to you what it means, and, of course, it starts with open source software. We try to cluster software a little bit in that way. Of course, everyone can do the clustering in their own way. This is the way that I see the things–or we see the things–and, but of course, there are different ways to cluster software and to look at it.
So, we have said open source software can be differentiated in strong Copyleft, limited Copyleft, and without Copyleft, and I have listed the different, the major, and the most important open source licenses here from GPLv3 to GPLv2 up to BSD and Apache.
Now, if you look at all of those open source licenses, we can look at the… Maybe I’ll start with the green part, and whatever is green here–whatever is in the green box–has a explanation–I shouldn’t walk away too far from my microphone, so you can all hear me.
So, if you look at the green part, we can find out, and if you look at the licenses, you’ll find out that most licenses which are marked with a green frame, that those licenses do not collide with the TiVo case or TiVo-ization. There are no specific TiVo-ization clauses, wording, which is seen in GPL or other non-Copyleft licenses.
Implementation of the system with hardware, and, therefore, signature checks is possible. So, I think this is also a very important message that there is already software out there which allows both things. First of all, signature checks but also using open source software. So, that’s an important point, and if you see very up there in the high part is GPLv2, which, from my perspective, allows signature checks but, nevertheless, using open source software.
Now, if you come to the yellow part, which is GPLv2.1 or GPLv3, for example, with the runtime exception. Here we can see that we might have a diversity of interpretations for some of the open source licenses. There is no specific, if you look at the GPLv2.1, there’s no specific provision in the license which relates to the TiVo-ization of a software. But, as I have stated it up here, the wording relates and refers to exchange Exchange means that the customer needs to be in a position to exchange, to alter, to change, the code.
The exception provision here is liberating from the strong requirements of GPL. You could possibly understand that this could be interpreted in the way that includes the TiVo-ization issue, but that’s all part of interpretation. It’s not a very clear understanding, at least from my side, what that means at the end. But there’s a possibility of interpretation towards TiVo-ization.
And then the top part, which are the red licenses, which I have listed here, including GPLv3, where it’s clearly stated that TiVo-ization is prohibited in any new version of the license, which is, as I have stated here, it’s GPLv3, it’s GPLv3 or LGPLv3, which clearly and verbally interdicts TiVo-ization. A license-compliant implementation of a TiVo-ized system is only possible, from my understanding, if we have a release of the possible signature keys.
So, this is a way of how you can cluster the open source–free and open source–software licenses, and you can have a view on what that means on how this relates to TiVo-ization.
Often discussed–that’s how I start my next slide–is LGPLv2.1, where you have seen if you remember from the page before, it’s in the yellow corner. What does it mean if you talk about and if you see and look towards a exchangeability and the TiVo-ization issue? What does–and, maybe, it also relates a little bit to other licenses as well, LGPLv2.1 states that the system shall operate properly if the user exchanges and modifies the LGPL components. I’ve put down, also, part of the license–I don’t know if you’re able to read it, it’s a little small, but it’s highlighted in the yellow part here, and I can read it out so you can read it and you can understand it: so that the user can modify the library and then re-link to produce a modified executable containing the modified library or, which is then (6.B), will operate properly with a modified version of the library if the user installs one.
So, TiVo-ization, if you make a security check, at the end of the day prevents an exchange of software components so that the user is not able to exchange LGPLv2.1 components in a TiVo-ized system and gets a running system, yet, at least from my point of view, I have not seen a specific clause interdicting TiVo-ization as it is–as I have said and mentioned before on the slide before–was inserted for version 3.1 of the GPL. There’s no specific jurisdiction or law cases on the specific topic up to now, so, from my point of view, it’s a question of interpretation of the license text: if GPLv2.1 interdicts TiVo-ization or not.
So, what are the different ways of interpreting that license or the exchangeability of the license? I have listed here four ways of interpretation. You can have a very panicked interpretation and say, “Okay, we have to avoid…”–and this is up to a company policy, of course, well, then, your company’s or your organization’s. You can have a very panicked interpretation and say, “Okay we have to avoid all possible risk and interdict the use of open source software, Copyleft components, LGPL, or even GPL entirely.” That means you are not going to implement GNU and Linux-based operating systems, possibly, as LGPLv2.1 or, even, GPLv3 components are included. I put it here, is that maybe outdated? That’s what also Eben and Mark have talked about. Linux is widely used in industry, so, as you said, if you’re too strict on that you might lose the path to innovation. So, that’s absolutely the right point. That’s why I put it here as a call-out.
You can also have a–this is maybe the next level–a conservative interpretation. There is a potential legal risk for non-compliance because of the way of interpretation of that clause. You can avoid implementation of such a software in your TiVo-ized systems or in technical construction for… Or, you can just avoid using it entirely or you can use technical construction for exchangeability. I think these are ways to cover this if you have a conservative interpretation.
Or you can go to the liberal interpretation: you can say there’s no explicit wording or case-law interdicting TiVo-ization, so you can say that implementation is possible, especially if it’s unavoidable from a technical point of view. So, these are two ways in the middle.
And you can say to have an indifferent interpretation: you can say that up to now most of the legal claims based on a Copyleft issue were not touching TiVo-ization, so the compliance with Copyleft was the main goal. So you can say, “Okay, I’m indifferent on that”, so what I put up here, it might be risky if you look at the original case, Linux v. TiVo."
So, I think you have two very extreme positions, the panicked interpretation and the very indifferent interpretation where they say, “Who cares?” I think these are not the right ways to look at it. Therefore, and that’s why I’ve framed the both positions here, it’s probably more going towards positions two and three, and you have to look at the legal risks and how you may find a way to cope with it.
The area of conflict which we have been touching already this morning, with regard to TiVo-ization, is that–and this is probably not only applying to the automotive industry–is that developers want to secure a software against manipulation. As Eben also mentioned, you want to protect your intellectual property and implement certain technical features without showing everything to your competitors. That’s important for us.
But, on another point, which is also important, there’s a legal need for compliance with implemented open source components and the underlying software licenses because of potential claims. There might be a claim for damage, a claim for callback–because you have to bring back your product in order to rectify, to exchange, to bring it into license compliance, and for a product which is sold around the world, which is distributed heavily, this can be quite a high danger. It could be very cost-imminent, and the cost could be very high.
Sometimes, and this is the third point, a liberal or conservative interpretation regarding the license provisions is possible, so you have to really look at the specific case. So, the safest option, the legally safest option, if someone says, “OK, Daniel, what is your interpretation or what is your recommendation if I take a very safe option?” And I would say, “Yes, do not use that if we have TiVo-ized system–so, a secured system.” This could be really the legally safest option, but this is really the question, whether this brings us forward, as Mark and Eben rightly mentioned.
You can also say, “I can make sure the user is able to exchange the respective open-source component with modified versions of the library and still get a work that will operate properly and to be able to execute modified versions.” How can you do that? You can put libraries, and I think it goes a little bit into what Mark and Eben pointed out, you can put libraries in a separate file system and include them from the signature checks, Secure Boot, Chain of Trust, or else you can give the user the possibility to obtain the signature keys–this is also another possibility. You can offer your code as an object code so the user can make a separate but working version of the software that is then at the end, not limited by the delivered hardware.
So, there are ways to do that. And that is all an issue which relates to your understanding of software compliance. So I mentioned here the four aspects, at least from my point of view as I mentioned it already: so, you have the security of the system, you have a technical need for a component, you have the protection of intellectual property or know-how, and you have the potential interpretation of licenses. Those are the four components which ring around open-source compliance, and you have to find your way of interpreting a way forward.
So, on the next slide, I put up an attempt for a solution for combining TiVo-ization with free and open source software compliance. So, on the left part, which I put in a red box, I showed a system: for example, you have a partition 1, which represents a file-system combining proprietary and public components–a library. You have an observer which is monitoring a protection by signature, as I mentioned it before, during the runtime–for safety and security reasons. In case of a mismatch, that’s exactly what we’re talking about, the observer may block the access to and the interaction with the library if protection for partition 1 is activated.
What does it mean as a result? This means a non-compliance in the case of a FOSS license with interdicting of TiVo-ization, as the system will not work with modified versions of the lib file or the library. So at the end of the day, I want to show, this is not possible here if you want to use it in a way as I’ve put it up here in the red box.
How could it maybe work or how can it work? You have a component, as I have mentioned, “lib,” which is placed in a separate file system partition instead of inclusion, as in the red box, including it into partition 1 where it is needed. You can protect the partition lib by deactivating, on request of the user, allowing the exchange, and even if you look at the protection for partition lib and this is deactivated, the rest of the system, including partition 1 continues to be protected by the observer. I think, and I don’t know if we have to discuss that a little bit further… I think that goes a little bit into whatever, Mark, you have been talking about.
So, that might be a possible solution. This might avoid TiVo-ization issues and provide free and open software compliance while still maintaining, and this is a point that I want to stress, still maintaining security by checking protection status if technically possible.
So, the next slide I want to talk about the coverage of the TiVo-ization requirements. What does it mean to operate properly or execute modified versions? If TiVo-ization is interdicted, the user must be able to get a work that will operate properly, be able to execute modified versions of the original software system, containing the free and open source software license component.
As a matter of fact, there is no definition to the extent of this requirement, and maybe we can discuss that a little bit more, and I would like to open the discussion on that part as well.
So, at the end the whole thing is subject to interpretation. Should the software containing the free and open source software component and the combined code still work? Is there a need for a whole and better system to still work? Or do all interaction of the software still have to work? And I put it up in that picture here.
We’ll start with a very narrow interpretation and, then, if you can open it up, window by window, and go from the library and the work itself that uses the library can go to the process, can go a step ahead to do the processor, it can also go to the hardware unit, it can go to the delivered systems–the computer network in an office–but you can also go to the, probably most and wide interpretation, or set of picture, which is the system and the external services.
So, where is the frame? Where is the area where you look at it? Is it… If you look at the smallest interpretation or the smallest window, where, as I mentioned it here as point (1)–the library and the work–of course you can say that if you’re able to exchange your components then maybe your library and your work will work, but maybe not the entire hardware, and I mentioned examples here under 4… So, maybe not the entire hardware unit, the computer or its peripherals, or the car, but the software, as is, or as you or the user looks at, he, that might work.
So, that’s also a way of interpretation, and I would like to open the discussions on that, but you can also have that a little bit later–looking at it to understand, okay, how would you interpret the license in that way?
So, this brings me already to the end. I think, and I hope, that I showed you that security and safety is really of high importance for the car industry. We are in a very highly regulated market where the governments and the bodies look to the car because it’s not a thing… The car is not something you just put in your pocket or you can use in your private environment at home, but a car is something which drives on the road and can be of a high danger to your body and your life, so it’s heavily regulated.
Whenever, and I’m also very open on whatever I’ve been, as Eben mentioned already, I’ve been following the whole discussion since 2004, and I always tell also the people in my organization that we cannot hold up all of that. We have to be on the track. I won’t be part of the whole system because otherwise we might lose, as Eben said, we might lose the track to innovation. So, I don’t want to hold back the whole thing, we have to be part of it.
I also agree that GPLv3, we shouldn’t hold that up, we should look carefully how we can do that, how we can make it operate properly in a car, but I think–I don’t want to prevent technological innovation out of our cars, and because I can also take, as I said the very safe way and say, “Okay, GPLv3 is absolutely not permitted in our cars,” but just as a general rule I don’t want to do that. Right? Because, at the end of the day, I have to go to our board and say, “Okay, this innovation, we are not able to bring that innovation to our cars because there’s just a general rule which says, okay, it’s not allowed.”
So, I think we have to take a very differentiated approach to the topic and look at it case-by-case in order to be on the very top part of the innovation–to look at it and not to prevent innovation. And I think the more that people are able to look at a software the more that innovation will be there. Though there might be developers, very smart people, in our company, they might have a certain view on a technology or a software, but there might be even smarter people out there, and I think this is something we should use, and I’m trying to encourage my people in our organization to do that.
So, thank you very much for listening to me, and I hope for a fruitful discussion.
MOGLEN: Thank you, Daniel. What I think I would like to do is to get all the voices into the discussion, and then we can take all the questions from multiple angles.
I should just clarify before we move on that nobody ever sued TiVo about anything, what happened in this history was that TiVo made a digital video recorder for home use, which did, indeed, as you say lock down the entire software stack in the box and we made GPLv3 in the knowledge of the existence of that business model for the production of appliances, which it was the case that my client, Mr. Stallman, did not like.
So, we began making GPLv3 with a requirement that users be able to install modified versions of GPL software, and my client made anti-TiVo-ization the label under which that operated, which, of course, put a particular company in the headlights. I don’t think that Donald Trump learned about tweeting at Amazon from Richard Stallman, indeed, I don’t think Donald Trump has every learned anything from Richard Stallman, but to be a lawyer for a guy who is singling out particular companies raises certain difficulties.
I found myself one day in conversation with the general counsel of TiVo, Max Ochoa, he no longer works at Tivo, and Max said, “Look, you know, if you guys would agree to drop all this anti-TiVo-ization stuff, we would stop encrypting the movies on the hard drive.” And I said, “Gee, Max. That won’t help, we’re not the free movie foundation. It’s the Free Software Foundation. What we’re concerned about is peoples’ ability to modify the software in the device so they can fool around with making it work better for them.” “Oh,” he said, “We could never permit that because then there wouldn’t take the program guide.” I said, “You mean that Andrew Tridgell in Australia is going to modify his TiVo and he will decide to do without the program guide. That’s one guy. Aunt Sally will never do it.” “No,” says Max, “You don’t understand. We lose so much money on each piece of hardware we sell that if they don’t take the program guide, even if one user doesn’t take the program guide service from us, then we’re out of business.” I said, “Well, Max, look, here’s the problem that we have: we make free software, and we do the very best we can, we give it to everybody to use for whatever reasons they want in any way they please, and we don’t charge them. You’re asking me to accept a terrible tax on our business model so that you can sell table-top super-computers below cost. This is not actually a really good outcome for either one of us. Selling hardware below cost is not a good long-term business, and putting us into deep trouble…”
So that’s really in the end what TiVo-ization was about for TiVo. It was securing a service monopoly connected with hardware sold below cost–a twenty-first century business model that isn’t very good and that BMW or Audi would never accept. Nobody will ever lose money on selling the car so that they can make a service for it. They want services, I grant you, but the car must be profitable.
So, my question, really, I think will turn out to be, what is it that is the stake in locking down all the software in the car, and can we help? What I think we have now seen is that what Mark and I are talking about is a version of your partitioning structure on steroids, meant to work one-thousand times better for you, and that we are really saying that we now have technology on the shelf for you that would allow you to achieve the kind of control that you want in a very highly potentiated way, so that you could both protect the things you need to protect and allow tinkering with the things that it wouldn’t hurt you to allow, and, then, all of a sudden, the licenses would cease to mean very much to you because you would have the level of control that you would need over the technology in order to have the level of control you need in your business.
But the problem is TiVo-ization is an all-or-nothing idea–I lock it all down or I let it all out, and what we really need is very fine-grain stuff, and it’s not in the language of the licenses, it’s in the packaging of the software.
That’s where I think the conversation is at this moment, which is why we really need Jeremiah because Jeremiah is the person who lives exactly in the middle of that discussion.
Previous: 1b-shuttleworth | Next: 1d-foster | Contents