 My name is Nikoi Smith. We're going to talk today about GPL v2, GPL v3, and a particular provision called installation information in one of those licenses. So just a warning here, I am a lawyer. I'm not going to legalize this too much, but when we are talking about licenses, you do need to talk a little bit about legal things. Hopefully this will be understandable to those of you who aren't lawyers or don't have legal training. So I want to talk about two different licenses. First of all, GPL v3, which is the most recent version of the GPL license, was issued in 2007, and a particular provision in it related to a thing called installation information. What it is, why it's in there, what you have to do with regard to that provision, what you don't have to do with regard to that provision. We'll talk about GPL v3 first. Then I'm going to talk about GPL v2, which I think most of you are probably familiar with. It's the older version of the GPL license been around for 30 years or so. And talk a little bit about whether this concept of installation information is something that exists in that license. And then in the end, I'm going to talk about why you should even care about this. There is some interesting debate going on live right now about this particular hot topic, which means I think you ought to care a little bit about this is important. Okay, so let's start with GPL v3. There is a provision in GPL v3 called the installation information provision. I have reproduced it here. It is a requirement akin to the source code obligations of GPL that says you must provide the listed things that I've highlighted here. Any methods, procedures, authorization keys or other information required to install and execute modified versions of the code. So that's from GPL v3 section 6. There's also a limitation on this requirement that relates to user products. And I'm going to talk about what that means a little bit later because it's limited to that. But first I want to talk about the requirement itself. So this requirement was put into GPL v3 at the time it was drafted to address a thing that's been called or was called at the time Tivoization. And for those of you who were around when the debates over GPL v3 were happening are probably familiar with this term. What exactly is Tivoization is a interesting question about which you may have some debate about what it means. But it was often discussed in the mid aughts when this license GPL v3 was being drafted. It was a big deal and why it was a big deal I will talk about a little bit later. Now Tivoization was called that because the Tivo product which was a DVR device which still may make them now but was very prevalent back in the 2000s had a feature that the Free Software Foundation found objectionable or obnoxious. What exactly the feature is is something that's a little bit hard to decipher historically. But as best as I've been able to determine they were had GPL v2 code on their devices. But there was some sort of lock in the hardware that prevented you from modifying that code and reinstalling it on the device. So check some or some sort of key in the hardware that prevented you from reinstalling modified versions of the code that ran on their device. And I've got a link to a discussion about that in the foils here which was the best replication I could find of what the actual technical problem was. But the installation information requirement was put into GPL v3 to address that particular practice. Essentially they wrote a bunch of different requirements that said if you put things in your hardware that prevent the reinstallation of modified code then you have to provide information to the user so that they can reinstall the modified code. In the case of Tivo it was apparently some sort of key. So if you have a key that prevents reinstallation of modified binaries then you have to provide to the user that key so that they can install it themselves. The provision that was put in GPL v3 seems to be to me to be a fairly comprehensive list of all sorts of things that somebody might need or desire in order to modify code and reinstall it onto a device. So essentially they were sort of providing a laundry list of things that they wanted to make sure were being provided so the end user could take the source code, modify and reinstall it on the device. Now let's talk a little bit about this installation information requirement because it's not as straightforward as you may think on first blush. It does say you have to provide this thing called installation information that allows you to reinstall modified code onto the device but there are actually a lot of exceptions to that requirement and I'm going to go through those in detail here so you understand when this requirement applies and when it doesn't. The first exception here is that it only applies to a thing called a user product and what is a user product is something that you probably want to have a discussion with a lawyer about because it's not entirely clear what it is and it is tied to some statutory requirements in a law called the Magnus and Moss Warranty Act. So interpreting what is a user product is probably or might require some reference to that statute and any cases that have been determined to interpret that statute. But bottom line is most of the things that people are installing code on are probably user products. There may be some large industrial machines that probably wouldn't fall within that definition but most of the folks in this conference are probably working with things that would be called a user product. Okay. Now it only applies if you're offering that user product for sale or for a long-term lease. Now there may be transactions where it wouldn't fall within that requirement. It's not a sale or a long-term lease but you're probably going to have to talk to a lawyer about that as well. So if you give it to somebody temporarily, maybe that's not a sale or a long-term lease in this installation information requirement does not apply but again you probably want to talk to a lawyer about that and most transactions that you're going to do with user products you're probably going to have to provide the installation information for under GPLV3. There's also an exception that says if nobody has the capacity to modify the code on the device then you don't have to provide the installation information. So if you as the product manufacturer do not have any ability to modify code on the device yourself then you don't have to enable the customer to be able to modify the code on the device. Now in most cases that's not going to apply because I think most product manufacturers want to be able to do updates of codes on their devices and if that's the case you have the option of modifying the code. You have to allow your users to have that option as well. There's also a couple of strange provisions in here that say well you have to give people the ability to install modified binaries on their devices but you can do other things to discourage them from doing that like voiding the warranty that they have on the product or by cutting off access to a network that they may get access to through their device but only if it's potentially interfering, the modifications are interfering with that network. Again these are provisions that are in there but I'm not sure that it's something that a lot of companies are going to want to avail themselves of so in most cases they're probably going to have to provide the installation information. So what I've got here and what I've kind of put together for my own ease of understanding this is what I call the grand unified flow chart for deciding these things so how do you decide whether you have to provide the installation information or not on a particular device well if you go through this flow chart it should give you the answer. Note the first yes no question is whether the binaries are GPLv3 or not if they're GPLv2 I'm going to talk about that a little bit later but if you're dealing with GPLv3 this flow chart kind of gives you how you make a decision about whether this installation information is something you do or optionally don't have to provide for your device. Okay so that's GPLv3. Now I'm going to talk about GPLv2 which is a much more interesting issue. GPLv3 is really just sort of a mechanical process of understanding how the license works when you have to provide this information and what is the information that you have to provide. GPLv2 is a different question altogether and one for which there is quite a bit of debate currently ongoing. So in GPLv2 are you required to provide installation information? In my opinion you don't. However there is a dissenting view on that point which I will highlight for you in a minute here and an ongoing debate about that particular question. So this is the text of GPLv2 and this is the text that in general requires you to provide source code. I think most of you know that under GPL you're required to provide the source code if you distribute any binaries. There is a provision in the section on source code that I've highlighted here that requires you to provide the scripts used to control compilation and installation of the executable. So there is some language in here about installation but it's not quite as comprehensive as the language that we described before in GPLv3. So there is a question here which is GPLv2 says you have to provide the scripts used to control compilation and installation of an executable. Is that the same thing as what GPLv3 requires which is any methods, procedures, authorization keys or other information required to install and execute modified versions of a covered work? That's the kind of interesting debate that's going on right now on this question. Interestingly enough, if you go to the FAQs maintained by the Free Software Foundation which I think most of you know, the Free Software Foundation is the entity that created the GPL. It says GPLv2 is different than GPLv3 with regard to installation information. It says GPLv2 doesn't use the term installation information. It does mention scripts and then it says that requirement to provide scripts is part of but not all of what is installation information under GPLv2. GPLv3's requirement about installation information is stronger. So I think you have to read this statement by the Free Software Foundation that GPLv2 requires a subset of the information that's called installation information in GPLv3. So you have this big category of information. GPLv3 says you have to provide. GPLv2 has a subset of that information that you have to provide but not all of it. And that's of course coming from the website that the Free Software Foundation maintains. Now, GPLv2 does require you to provide scripts. So that is a specific requirement in GPLv2. What is a script? Well, I'm sure many of you are familiar with scripts because you work in programming. I pulled out here a technical dictionary definition of a script which is something that I think would be potentially useful if you ever got into a debate about what GPLv2 required you to provide. So in this technical definition, a script in computing is a list of commands executed by a program or scripting engine to automate a process. I think that's probably a generally well understood and accurate definition of what a script is in computing. So GPLv3 has all these other things, methods, procedures, authorization keys, or other information. I think if you look at GPLv3, you'd probably say, well, methods or procedures as required in GPLv3 probably defines things that might include a script but probably include other things beyond scripts but that an authorization key or other information as required in GPLv3 probably doesn't include a script. So GPLv3 is much broader in its application than GPLv2 and I don't think one can interpret the use of the term script in GPLv2 to encompass an authorization key. That's in my opinion, I think probably just data and not necessarily a script as required in GPLv3. Okay, so that's sort of a fairly shorthand but detailed explanation of a interesting analytical problem that GPLv2 provides as it relates to what GPLv3 clearly requires. Why does this all matter? Well, it matters because some people for whatever reason don't want to give installation information to their customers. And I think I've listed here a couple of industries where I've been made aware that certain companies within that industry do not wish to provide to customers installation information. Automotive is one of the ones you hear most about. Telecom is another one where you often hear that they're providing locked down code and their customers have the ability to modify it. I think you're also seeing it possibly in Biomed and Embedded or IoT where they're saying, I'm more than happy to give you the source code but I don't want you modifying that source code and reinstalling it on my device. So some of these industries have actually put in place policies that say if we're going to install code on our devices, it shouldn't be GPLv3 because GPLv3 is going to require us to provide this installation information and we don't want to do that with our device. So they say, however, GPLv2 doesn't have that requirement and in fact at the time the complaint about GPLv2 is that where people were able to Tivoize their code, they were able to lock it down. So I'm going to be willing to put GPLv2 code on my device because I don't believe I have an obligation to provide the installation information. Now, very recently within the past year or two there has been a debate about whether what I just presented to you is a correct interpretation of the lay of the land. Is it correct that one can install GPLv2 code on a device and not provide the required information so that the end user can modify the code and reinstall it on the device? And this debate has been kind of been going on between two entities or an entity and a person. The entity is the Software Freedom Conservancy. Some of you may be familiar with them. They've been involved in a lot of different initiatives about software compliance or free software compliance and in some cases have actually done some enforcement of free software licenses. So in March of this year they put out an article which I've snapshotted here and which if you want to read it you can go to their site softwarefreedom.org where they put out a position that essentially says although I will let you read it to make sure you understand completely what they say, hey, if you're distributing GPLv2 code you still have an obligation to provide the information necessary for somebody to modify and reinstall that GPLv2 code on the device that it's shipped with. Now I read that article and I didn't think that that was completely accurate and a completely accurate assessment of both what the license actually says as well as the history of the installation information requirement that was put into GPLv3 in the mid-2000s and the reason why I thought that was because I was heavily involved in the discussions at the time when GPLv3 was being drafted and I recall debating quite a bit with representatives of the Free Software Foundation about that particular provision, what it meant, what the exceptions to it were and why it was being put in there in the first place. So I wrote an article in this journal called Journal of Open Law, Technology and Society in which I came in with a contrary view to the view that the Software Freedom Conservancy has about this particular topic. And if you read the article it essentially says, you know, GPLv3 and GPLv2 have quite different requirements for things like keys or installation information. Here is both the text of the licenses as well as the history of the discussion around GPLv3 which I think shows that they are quite different and there are reasons why they are quite different. I won't go into a lot of details with this because it's an extremely detailed article. It's got lots of footnotes and references to the history. If you're interested in legal authorship, feel free to read it. If not, get your lawyer to read it because they'll appreciate it more maybe than you would. So here I've boiled down on this slide essentially what I think the debate is. So in March of 2021, Software Freedom Conservancy was talking about GPLv2 and they were saying, you know, if you get GPLv2 code, you have the absolute right to receive the information necessary to install a modified version of that work. And that includes scripts, interface definitions, and then they add in something that's not in the license, other material that is used to control compilation of an installation device. I saw that and didn't think that I agreed with that position and thought that they were trying to read some stuff from GPLv3 into GPLv2. So I wrote the counter article and said, hey, that's not really consistent with what the license actually requires and it is certainly inconsistent with the history of the debate about Tivoization that happened in the 2000s. So that was kind of my response to them saying I don't necessarily agree with the opinion that you've expressed about how GPLv2 works. Well, they came back shortly after I published my article and came back with a sort of a counter article essentially saying, you know, I'm wrong and this is exactly how this should be interpreted and here's our interpretation of the history at the time and here's our interpretation of what Tivo did and what Tivoization is. Again, if you're interested in this debate and you want to read these articles, they're available on the Free Software Freedom Conservancy website. I'd encourage you if this is a topic that interests you to read them all. Read the two articles from Software Freedom Conservancy. Read the article that I wrote in this journal called Joltz. See what you think or better yet, turn it over to your lawyer and put your lawyer things because it's a lot of debate about legal issues and license interpretation. Okay, why is this important or why are we having this debate now? Well, it's interesting because the installation information requirement that was put into GPLv3 in the mid-2000s was a pretty controversial measure. There was a lot of press about this particular provision. A lot of people expressing different opinions about whether it was or was not a good idea. The most interesting discussion really related to the Linux kernel and a debate about whether putting this requirement into GPLv3 would or would not encourage re-licensing or a change of license on the kernel from GPLv2 only to GPLv3. In the end, I think most of people here know that the Linux kernel has remained under the same license throughout GPLv2 only. It did not convert to GPLv3. I think this was one of the factors at the time as to why it didn't convert to GPLv3. There was a lot of concern about this installation information requirement and what it would mean for the kernel. And I include here a quote from Linus from the time that there was a debate going on about GPLv3 and the Tebowization Clause or what became the Installation Information Clause. And he basically said, well, he said a lot of things at the time about this. Most of them were relatively unenthusiastic about this installation information requirement. But essentially said, you know, that's really a hardware issue. If you've got lockdown hardware, that may or may not be good. And if you don't like lockdown hardware or you can't modify the code on it, maybe you don't want to buy that hardware. But there may be circumstances where lockdown hardware makes sense and you wouldn't want to prohibit that in every circumstance. I think that's a distillation of what he was saying at the time. He said some other things as well, and I'm not going to discuss in my article, but that was kind of one of the big debates that was being had about this installation information requirement. Now, there was a period of time before this year, before 2020, where there was some messaging being put out to a couple of different industries, particularly the automotive industry, which as I said has been sort of reluctant to adopt GPLv3 because they don't like this installation information requirement. There was some messaging being put out that said, yeah, you can live with this GPLv3. The installation information requirement is not something that should cause concerns for you. You can work around it and still address concerns that you have about things like safety, et cetera. I don't know that that has got a lot of traction. I'm not sure that the automotive industry has decided that it would be a good idea to take away their concerns about GPLv3 code and their products, and for the most part, I think GPLv3 has not made its way into a lot of automotive applications. And this was kind of a problem that was foreseen at the time GPLv3 was being drafted. There were a lot of people, including, I think, Linus, who was telling the Free Software Foundation, you know, if you're going to come up with a new license, it's a good thing, but this installation information thing is not a good thing and probably ought not to be in there. He said that publicly in a couple of different places. There were a lot of people or there were some people that were debating privately with the Free Software Foundation that this was a bad idea and it would fact the installation information requirement was going to impede the adoption of GPLv3 as a license because a lot of people were going to say, I don't really want to have to require people to give away keys or maybe circumstances where the code ought to be. So that was sort of the debate at the time. What has happened now and what we're seeing now, particularly within the past year or two, is some folks in the copy left world saying, hey, if you have decided that you don't want to put GPLv3 into your product because you don't like this installation information requirement, well, you know what? That's a requirement in GPLv2 also. So you are going to have to do exactly what you don't want to do if you're going to install GPLv2 code on your device. Essentially saying you ban GPLv3 from your products. Well, guess what? You got fooled or you made a wrong choice because GPLv2 has got the same requirements. You're going to have to do it for that as well. Now, as far as I know, this is mostly an academic debate. So you've got an article that I wrote on this topic and you've got some articles that the Software Freedom Conservancy wrote on this topic where there's this sort of two contrary positions being expressed about whether GPLv2 is essentially the same for installation information or if there's a big significant difference between the two. It's an academic debate which is going on in public in various journals or various blog postings. Certainly if this is an issue that's important to wherever you work or whatever project you worked on, you work on, it would be it would behoove you to understand what the debate is about because certainly it would be behoove you to understand how GPLv3's installation information requirement applies. As I showed in the flow chart, there may be an exception that applies to you but I think in most cases you probably do need to provide the installation information. But if you're using GPLv2, you need to understand that there are some people coming around and saying GPLv2, GPLv3, it doesn't make a difference you can't lock it down. Is this a precursor to something else? I don't know but I can imagine a time will come when somebody is going to say, I have GPLv2 code. You are using it in your product. Here is a blog posting that says that you are required to provide all information necessary to allow your customers to modify and reinstall that code and I'm going to insist as the author of that code that you do so. When that happens you may find yourself in a bit of a dilemma because you may have assumed that you didn't have to do that and in fact the two licenses were different yet here you have an author of some GPLv2 code saying I take a contrary view I've got somebody who's writing that says that my contrary view is correct and I'm going to demand that you treat the GPL2 code on your device exactly the way that you would have to have done with GPLv3 even though you specifically excluded GPLv3 from your products. Is that going to come to a head at some point? Will it become a real problem for companies? I don't know but you should be aware that the debate that's going on may in fact result in actual claims that one needs to do something that one previously thought that you didn't have to. Okay so that's GPLv2, GPLv3 and the debate that's currently going on about those two licenses that interest you read the literature, talk to your lawyer see what you think is the most persuasive case or which of the positions you think makes more sense in view of what the licenses say and what the history of the development of the licenses was. There's a final plot twist that I want to mention here which is some of you may be aware that the Biden administration put out an executive order over the summer on right to repair which has been an ongoing debate in a couple of different industries mostly in the farm equipment industry for a number of years where people are saying I'm not able to make repairs on the device a device that I have purchased because the manufacturer has put impediments in front of that and the Biden administration having heard those complaints put out an executive order and said that the FSTC ought to look into whether there ought to be rights to repair for consumers for devices or products that they purchase. Now, does this apply to this question about GPL v2? I don't know. I think it's probably a little bit more intended to be focused on particular industries like agricultural equipment but there could come a time when somebody goes to the FTC and says, you know, the right of repair ought to include the right to modify and reinstall any open source code on a device and therefore any technical impediments that prevent me from doing that takes away my right to repair and the FTC should look into it. Now, I don't think so but this may become part of the debate. So be aware that even though there's these two academic papers and these two discussions that are going on, there's like a third player up here which is U.S. government which may have ultimate sway on this particular question. Okay. So that's all I've got on this topic. It went pretty fast and quick through it all. It was fairly dense in terms of all the material and talking about license provisions. I hope that gives you an understanding of what the question is and what the debate ongoing is now. So I have some time for some questions, a few minutes. Any questions on this? Yes. Conservancy. Yes. Yes. Yes. I don't think so. Here's the thing with open source enforcement which a lot of people don't realize that a percent of it happens under the table, not like in a sneaky way but you see somebody sued somebody for a GPL violation. That's one out of a hundred cases. What really happens in most cases is somebody like the Software Freedom Conservancy or somebody else will go to the person and say to them privately I think you're doing something incorrect. You're not following the license and I would like you to correct that. Let's figure out a way to do that and I think in a lot of cases there's a discussion that happens and that gets corrected and there's no lawsuit that gets filed. So whether or not Software Freedom Conservancy or anybody else has ever gone to an entity and say you can't lock down this GPL v2 code, I do not know, but it's possible. As far as I know there's not been any lawsuits. I haven't seen anything on their website that says that they have actually taken action. Any other questions? He's dissenting from me. It's an interesting question. Is there a majority or minority view on this? There's two people debating it. What everybody else thinks about this? I don't know. I tend to think that probably the folks who are locking down GPL v2 code would be more on my side of the debate now but that's a small subset of people. The interesting question is the Kernel community, where do they come down on this? I'm pretty sure the Kernel community had a lot of different opinions on the time it was being drafted. There were a lot of people that said I kind of like it. There were a lot of people who said I don't like it. If you were to pull them and see which one was the majority or minority, I don't know. I don't mean to say by saying dissent means anybody's in the minority or majority because I don't know. Right now it's just two people Yes. Maybe you can explain a little bit more what you mean by estoppel is a defense. So the question was I'm supposed to be repeating these questions. I didn't do it for the first couple of questions. Would estoppel be a defense in this case? Estoppel is a legal doctrine that says essentially says if you didn't take action on a particular thing for a long period of time people would do it in the future. A little bit like a Statue of Limitations kind of thing, but different. I suspect that that would be a defense that would be raised. But lawyers raise pretty much every defense they can, right? We're trying to get the client out of the problem. So yeah, somebody would raise estoppel. Would that be a dispositive defense? Probably not. I think the debate would really be focused on what the actual language in the license says. And there might be some focus on what was said about the interpretation of the two licenses like the thing that the Free Software Foundation has said about that. I think those would be probably more persuasive to a judge than just saying, well, nobody enforced this for however many years. But it certainly would be something I suspect the lawyers, the defense lawyers would raise as a potential defense. Yes. Yeah, it's an interesting his issue was about regulatory requirements. For example, radios. The FCC says you can't operate, if you sell a radio it's got to operate with insert power and bandwidth parameters and you can't have it operating outside of that. Would this potentially come into play? I think if you review what the Free Software Foundation and other people say about this, they'd say well, you have to comply with whatever laws exist wherever you are. Even if the license maybe allows you to do that. So even if you get the source code and it says you already have the ability to cut the power or change the bandwidth if the FCC says you can't do that, you can't do that. Now, how that comes into the product manufacturer is an interesting question. I thought about it, I remember thinking about this many years ago and I think the FCC had some wiggle room on that but it could very well be that you decide to say I'm not going to put at least GPLV3 in my radio because somebody is going to be able to now, are they going to say am I going to put GPLV2 because I can lock it down and they can't? Well, I think they might unless somebody comes to them and says GPLV2 requires you to allow them to be able to adjust the power and bandwidth requirements as well. Then we get into this interesting debate about what's the interpretation of the license. Now, would the FCC say GPLV3 is bad, GPLV2 is okay? I don't know that they would get into that but it's an interesting question. Which I think would at least counsel you not to put GPLV3 code on the device. It might counsel you not to put GPLV2 if you are worried that the interpretation the software freedom conservancy says is the correct one or that they will attempt to force you to do that which may mean you wind up having to put GPLV2 at all. Any other questions? Yes. Yeah, it's an interesting question. So the kernel commitment basically said we as the authors of the kernel or we as important authors of the kernel despite the fact that GPLV2 has some fairly harsh termination language we are going to not force that we are going to force it in consistent with GPLV3. So that's more we are going to make GPL more liberal. I think if you were to say what your example would be is we are going to try to put the installation information requirements into GPLV2 I think you are making it more conservative. So that's something they could do we hereby say that we reject the software freedom conservancy interpretation and we adopt the McCoy Smith interpretation as being the canonical interpretation of this license. I think they could do that whether they would or not I don't know because I don't know whether you could get a consensus on that. It's a little bit ambiguous to me on how the kernel community feels about this particular thing I think a lot of them don't like this installation information requirement but I'm not sure how strong they are now if there was an enforcement case filed you might see something like this. I mean the termination provision thing came out after some unfortunate enforcement actions that they found offensive. So if you saw some enforcement actions that they found offensive on the kernel parts of the kernel or GPLV2 in general you might see if they could get a consensus. Yes. I think that the issue has only sort of been joined in the past six months really. Now, would survey be of interest? I don't know there may be some people here from the Linux foundation who might be interested in doing something like that. Yeah, I think most of them would say what? I got better things to worry about than this debate between these two people. Several people. I think you probably wouldn't get a lot of response to that survey unless there were an enforcement action where they said uh oh they're now saying that the kernel has to be non-lockdownable. That's going to cause a problem with some of the people who are using it. That means some companies are going to move away from the kernel. Think about this and take the decision. So I got one more minute. Any more questions? I'll get an extra minute back. Thank you very much for your time and for the good questions.