Does GPLv2 Also Require Installation Information?

Hello.

P. McCoy Smith, a well-known open source license attorney in the United States, recently published an article titled Does GPLv2 Require ‘Installation Information’ in JOLTS (Journal of Open Law, Technology & Society) (JOLTS).

In March 2021, the SFC (Software Freedom Conservancy) (SFC) blog published a post titled “Understanding Installation Requirements in GPLv2,” arguing that GPLv2 also requires the provision of installation information. This article analyzes that claim and explains, with detailed grounds, the view that GPLv3’s ‘Installation Information’ requirement does not apply to GPLv2.

This translation renders the original text while adding background explanations wherever possible to improve readability and help readers understand the content.

If you find any errors or have additional comments, please feel free to contact me at haksung@sk.com.

Thank you. :)

Abstract

One of the key features added in GPLv3 (GNU General Public License version 3) is the requirement to provide ‘Installation Information’ in addition to source code when distributing software. This was newly added to GPLv3 to address a loophole in GPLv2 (Tivoization). Recently, however, a claim has been raised that this installation information requirement should be considered to apply to GPLv2 as well.

This article reviews the historical basis for including the ‘Installation Information’ requirement in GPLv3 and explains that this requirement is newly applied in GPLv3, not GPLv2. It also arrives at the same conclusion through an analysis of the GPLv2 text.

1. Introduction

GPLv2 (GNU General Public License, version 2)¹, released by the FSF (Free Software Foundation) in 1991, adopted a Copyleft (or Reciprocal) licensing approach. The Copyleft approach requires disclosure of source code in a specified manner at a specified time, and requires the same license to be applied when the software is redistributed. This is considered the best means of ensuring that software remains “free,” a view still widely held today². Here, “free” means the following³.

• The freedom to share modifications
• The freedom regarding what users can do with the code
• The freedom for users to modify the code as they wish

Nevertheless, in 2005 the FSF recognized the need to revise the license to address legal⁴ and technical⁵ issues that had not been considered⁶ when GPLv2 was released. Accordingly, the FSF began a large-scale, multinational collaborative effort from 2006⁷ through 2007 to create a new version of the GPL, and released GPLv3 on June 29, 2007⁸.

2. GPLv3’s ‘Installation Information’ Requirement

GPLv3 added numerous features to address the problems and concerns raised during the 15 years GPLv2 was in widespread use. Among these, the most notable (and also most controversial⁹) are (1) the provision defining ‘Installation Information’ and (2) the provision specifying the circumstances under which installation information must be provided when ‘conveying’¹⁰ software licensed under GPLv3. Understanding the extent to which GPLv3’s ‘Installation Information’ requirement includes, and does not include, elements required under GPLv2 requires a detailed review of the language and history of both licenses.

GPLv3, Section 6¹¹ (which specifies the obligations that apply when GPLv3 code is “conveyed in Non-Source Form”) defines the disclosure obligations specific to ‘Installation Information’.

“‘Installation Information’ ... means any methods, procedures, authorization keys, or other 
information required to install and execute modified versions of a covered work ... from a 
modified version of its Corresponding Source. The information must suffice to ensure that the 
continued functioning of the modified object code is in no case prevented or interfered with 
solely because modification has been made.”

What is notable about GPLv3’s definition of ‘Installation Information’ is that it specifically mentions ‘authorization keys’ and ‘other information’. This was included to address specific instances of abuse of GPLv2 software that concerned the FSF when the process of creating GPLv3 began¹².

The detailed requirements of GPLv3’s ‘Installation Information’ obligation, and how and when GPLv3 requires the provision of installation information, are beyond the scope of this article¹³. Nevertheless, a general understanding is needed of what similarities might support the argument that the installation information obligation also applies to GPLv2, what evidence demonstrates that the installation information obligation is unique to GPLv3, and through what process this content came to be adopted. It is therefore important to understand the historical background behind the addition of the ‘Installation Information’ obligation to GPLv3, the specific language added to GPLv3, and how that language differs from the obligations stated in GPLv2.

3. Historical Background of the ‘Installation Information’ Requirement: ‘Tivoization’

Around 2006, when GPLv3, the new version of the GPL, was proposed, the FSF expressed concern about a practice that could potentially undermine the concept of ‘software freedom’. The FSF named this practice ‘Tivoization’¹⁴, and at the time, the FSF considered that TiVo, a DVR (digital video recorder) company, was infringing on users’ freedom.

In the mid-2000s, certain TiVo DVR hardware devices had a GPLv2-licensed Linux kernel installed. These devices included a mechanism to verify the version of the Linux kernel to be installed on the TiVo hardware device. This validation mechanism used a checksum or cryptographic hash function to compare against the kernel version installed on the device, and refused to install any version of the Linux kernel whose checksum or cryptographic hash¹⁵ did not match a specific value. In this way, TiVo devices allowed only TiVo — as the hardware manufacturer and the sole party with the necessary information about the embedded checksum or hash value — to install authorized versions of the Linux kernel on the device. If a user of a TiVo device (e.g., a customer who purchased the device) obtained the source code of the kernel installed on the device, modified that kernel, and tried to reinstall it, the checksum or hash would differ for the modified kernel, so the modified kernel could not be reinstalled or executed¹⁶.

Accordingly, in 2006 the FSF considered the inability to reinstall a modified version of GPLv2 software on an existing device to be an infringement of the freedom users should have over software, and did not hesitate to describe this practice in highly disparaging terms.

      “A tyrant is a malicious device that refuses to allow users to install a different operating system or a modified operating system. These devices have measures to block execution of anything other than the ‘approved’ system versions.”¹⁷

4. Historical Analysis: The Relationship Between GPLv3’s ‘Installation Information’ Obligation and GPLv2

Although the FSF had long opposed the practice of ‘Tivoization’ (preventing the reinstallation of modified binaries), during the drafting of GPLv3, statements by the FSF’s President, General Counsel, and Executive Director also made clear that this practice could be permitted under GPLv2.

      “[T]he Tivo itself is the prototype of [T]ivoisation. The Tivo contains a small GNU/Linux operating system, thus, several programs under the GNU GPL[v2]. And, as far as I know, the Tivo company does obey GPL version 2. … [T]he trouble begins because the Tivo will not run modified versions, the Tivo contains hardware designed to detect that the software has been changed and shuts down.”¹⁸

      “TiVo is a provider of hardware and software …. Our concern with them is that they have rights as users, but they should respect the rights of the users to whom they sell. Having a personal video recorder … which won’t run software if you modify the box … is not user-respecting conduct. (TiVo) complied with GPL 2 by the skin of its teeth.”¹⁹

      “TiVoization is described by Peter Brown [Executive Director of FSF in 2006-07 during drafting of GPLv3] as circumventing GPL2 ‘in spirit, not technically.’”²⁰

This difference (between GPLv3, which prohibits ‘Tivoization’, and GPLv2, which permits it) was the decisive reason why Linus Torvalds, the author of the Linux kernel, decided not to change the license to GPLv3 and to keep it ‘GPLv2 only’.

      “’The FSF is trying to make some things no longer permissible under the GPLv3 that the GPLv2 left open, and I just happen to think that those things were better off being left open.’”²¹

      “‘I don’t think the GPL v3 conversion is going to happen for the kernel, since I personally don’t want to convert any of my code.’ … ‘I think it’s insane to require people to make their private signing keys available, for example. I wouldn’t do it,’ [Torvalds] said.”²²

      “[If] you can not install or run your changes on somebody else’s hardware … it in no way changes the fact that you got all the source code, and you can make changes (and use their changes) to it. That requirement has always been there, even with plain GPLv2. You have the source. The difference? The hardware may only run signed kernels. The fact that the hardware is closed is a hardware license issue. Not a software license issue. I’d suggest you take it up with your hardware vendor, and quite possibly just decide to not buy the hardware. Vote with your feet. … [I]t’s important to realize that signed kernels that you can’t run in modified form under certain circumstances is not at all a bad idea in many cases.”²³

Torvalds’s view on GPLv3’s ‘Installation Information’ requirement was shared by several major kernel developers, as shown below²⁴. Torvalds maintained a consistent position even a decade later, which is one of the reasons the Linux kernel continues to maintain a ‘GPLv2 only’ license to this day²⁵.

      “I give you source code, you give me your changes back; we’re even. … That’s my take on GPL version 2 and it’s that simple. … Version 3 extended that in ways that I personally am really uncomfortable with. Namely I give you source code, that means if you use that source code, you can’t use it on your device unless you follow my rules. And to me that’s a violation of everything version 2 stood for. And I understand why the FSF did it, because I know what the FSF wants, but to me it’s not the same license at all. So I was very upset, and made it very clear, and this was months before version 3 was actually published.”²⁶

In the process of creating and releasing GPLv3, the FSF made clear that, unlike GPLv2, GPLv3 was adding content that could prevent ‘Tivoization’.

      “There are several primary areas where version 3 is different from version 2. One is in regard to [T]ivoisation."²⁷

      “The Tivo includes some GPL-covered software. …[Y]ou can get the source code for that, as required by the GPL … and once you get the source code, you can modify it, and there are ways to install the modified software in your Tivo and if you do that, it won’t run, period. Because, it does a check sum of the software and it verifies that it’s a version from them and if it’s your version, it won’t run at all. So this is what we are forbidding, with the text we have written for GPL version three. It says that the source code they must give you includes whatever signature keys, or codes that are necessary to make your modified version run.”²⁸

The FSF has made clear (consistently from when GPLv3 was first proposed to the day this article was published) that GPLv3 in fact contains a definition of the ‘Installation Information’ requirement that is broader than any requirement contained in GPLv2.

      “GPLv2 did not address the use of technical measures to take back the rights that … GPL[v2] granted, because such measures did not exist in 1991 [when GPLv2 was written], and would have been irrelevant to the forms in which software was then delivered to users. … GPLv3 must address these issues: free software is ever more widely embedded in devices that impose technical limitations on the user’s freedom to change it.”²⁹

      “Does GPLv2 have a requirement about delivering installation information?…

      “GPLv3 explicitly requires redistribution to include the full necessary ‘Installation Information.’ GPLv2 doesn’t use that term, but it does require redistribution to include scripts used to control compilation and installation of the executable with the complete and corresponding source code. This covers part, but not all, of what GPLv3 calls ‘Installation Information.’ Thus, GPLv3’s requirement about installation information is stronger.”³⁰

Richard Stallman appealed to software developers to “upgrade” their licensing policy to GPLv3 to address the existing problems with GPLv2, and cited the newly introduced installation information requirement as the first reason developers should switch to GPLv3.

      ““Keeping a program under GPLv2 won’t create problems. The reason to migrate is because of the existing problems which GPLv3 will address.

      “One major danger that GPLv3 will block is tivoization. Tivoization means computers (called “appliances”) contain GPL-covered software that you can’t change, because the appliance shuts down if it detects modified software. The usual motive for tivoization is that the software has features the manufacturer thinks lots of people won’t like. The manufacturers of these computers take advantage of the freedom that free software provides, but they don’t let you do likewise.³¹

5. GPLv2’s Source Code Disclosure Obligation

One of the most notable features of a Copyleft license such as GPLv2, released in 1991, is that any individual or entity that distributes³² code licensed under the terms of GPLv2 has an obligation to provide the ‘source code’³³. GPLv2’s Section 3 specifically defines the components of ‘source code’ that must be provided when code under GPLv2 is distributed in object or executable code form³⁴.

“The source code for a work means the preferred form of the work for making modifications to it.
For an executable work, complete source code means all the source code for all modules it 
contains, plus any associated interface definition files, plus the scripts used to control 
compilation and installation of the executable.”

The explanation of the obligation to provide source code can generally be understood in connection with common knowledge of what ‘source code’ means in computer programming.

      “Source Code: … The form in which a computer program (software) is written by the programmer. Source code is written in some formal programming language which can be compiled automatically into object code or machine code or executed by an interpreter.”³⁵

GPLv2 also includes two other items that fall within the license’s definition of ‘source code’.

• ‘associated interface definition files’
• ‘scripts used to control compilation and installation of the executable’

To understand how GPLv2’s disclosure obligation differs from GPLv3’s disclosure obligation, it is necessary to review the meaning of these provisions.

6. Textual Analysis: GPLv3’s ‘Installation Information’ Obligation and GPLv2’s Source Code Obligation

As discussed above, GPLv3’s disclosure obligation for distributing executable code includes both ‘Corresponding Source’³⁶ and ‘Installation Information’³⁷.

“[A]ll the source code needed to generate, install, and (for an executable work) run the object 
code and to modify the work, including scripts to control those activities.”

“[A]ny methods, procedures, authorization keys, or other information required to install and 
execute modified versions of a covered work ... from a modified version of its Corresponding 
Source.”

GPLv3’s original draft included the obligation to provide authorization keys within the definition of “Corresponding Source”³⁸. However, there was opposition to defining data such as authorization keys together with source code, and accordingly the FSF moved the authorization key requirement to a different section.

      “We have moved the technical restrictions provisions from section 1, where they formed part of the definition of Corresponding Source, to section 6, where they are presented as a condition on the right to convey object code works. Some critics of the provisions in our earlier drafts focused on what they regarded as an inappropriate equation of cryptographic keys with source code. Placing the requirements in section 6 should make their purpose and reasonableness more evident.”³⁹

Thus, during the draft revision stage of GPLv3, the FSF recognized and acknowledged that the ‘Installation Information’ requirement is a separate obligation beyond the ‘Corresponding Source Code’ obligation that existed in GPLv2 and was also included in GPLv3.

GPLv2’s source code disclosure obligation is as follows⁴⁰.

“For an executable work, complete source code means all the source code for all modules it 
contains, plus any associated interface definition files, plus the scripts used to control 
compilation and installation of the executable.”

To the extent that anything within GPLv2’s ‘corresponding source code’ requirement resembles GPLv3’s ‘Installation Information’ requirement, it would be the two separately specified items below.

• ‘any associated interface definition files’
• ‘scripts used to control compilation and installation of the executables.’

‘Interface definition file’ is a term commonly used in computer programming (GPLv2 does not provide a more detailed definition of this term). It can be interpreted as a separate file containing attributes and definitions of a particular software’s programming interface⁴¹. This requirement in GPLv2 does not appear to impose an obligation to provide authorization keys, checksums, or other information necessary to permit the installation or execution of a modified binary. Instead, it requires the disclosure of information necessary to understand the interface of the distributed binary (because this is difficult to determine from the disclosed source code alone).

By contrast, the second item — scripts used to compile and install the executable — is clearly material related to the installation of a GPLv2-covered executable. However, this requirement concerns the term ‘script’ itself, in the sense commonly understood in computing.

      “A computer script is a list of commands that are executed by a certain program or scripting engine. Scripts may be used to automate processes on a local computer …. Script files are usually just text documents that contain instructions written in a certain scripting language. … [W]hen opened by the appropriate scripting engine, the commands within the script are executed.”⁴²

      “Script[:] … a sequence of instructions or commands for a computer to execute … especially … one that automates a small task (such as assembling or sorting a set of data).”⁴³

An installation script⁴⁴ is generally a small, simple program used to automate the process of installing a particular program on a particular device⁴⁵.

Therefore, from the standpoint of textual interpretation, there appears to be no doubt that GPLv2’s obligation to provide ‘scripts used to control … installation of the executable’ cannot be interpreted as including the provision of checksums, hashes, authorization/signing keys, or other numerical data needed to install GPLv2 executable code. Such data does not fall within the ordinary scope of a ‘script’.

A more interesting interpretive question would instead be a case where firmware embedded in the hardware device itself runs an installation program that validates the executable in some form (for example, a feature that restricts installation by determining that the executable is invalid if it has been modified). Even in such a case, however, given that both the FSF and Linux kernel developers consistently maintained, over a long period during the drafting and release of GPLv3, the position that any form of installation validation (such as the use of PROM-loaded information, as with TiVo) was permitted under GPLv2, it would be difficult to argue that such an immediate check performed by firmware would trigger an obligation to provide installation information under GPLv2’s ‘scripts used to … installation of the executable’ requirement.

7. Backporting the Installation Information Requirement to GPLv2

Some attempt to backport the entirety of GPLv3’s ‘Installation Information’ definition into GPLv2’s source code obligation, but such an effort produces results that are historically and textually incorrect. Suppose the complete ‘Installation Information’ definition were included in GPLv2’s Section 3. The moment one does so, a dilemma arises. GPLv3’s ‘Installation Information’ requirement is limited in its application to a specific type of product, namely a ‘User Product’⁴⁶. The obligation to provide ‘Installation Information’ under GPLv3 applies only to ‘User Products’ and does not apply to other products⁴⁷.

“If you convey an object code work under this section in, or with, or specifically for use in, 
a User Product ... the Corresponding Source conveyed under this section must be accompanied by the 
Installation Information.”

GPLv2, by contrast, contains no definition or limitation on the type of product to which the source code obligation applies. Source code must be provided under the GPLv2 obligation regardless of whether the product is a ‘User Product’ or not. Therefore, if GPLv3’s complete definition of the ‘Installation Information’ obligation were merely a restatement or clarification of GPLv2’s existing disclosure obligation, GPLv3 would have narrowed the circumstances under which that disclosure obligation could exist. The result would be that GPLv3 applies to a narrower range of software than GPLv2, thereby narrowing its scope in terms of ‘software freedom’. This interpretation is the exact opposite of what GPLv3 was originally intended to achieve.

       “As a free software license … this license [GPLv3] intrinsically disfavours technical attempts to restrict users freedom to copy, modify, and share copyrighted works. Each of [the licenses] provisions shall be interpreted in light of this specific declaration of the licensor’s intent. We wish courts all over the world to understand that our intent [in creating GPLv3] is to maximise freedom, not to restrict it, and that everything should be so understood when effect is given to its terms”⁴⁸

Stated differently, GPLv3 can maximize freedom in line with its original intent only if the ‘Installation Information’ obligation itself extends ‘freedom’ beyond GPLv2’s disclosure obligation. Otherwise, since GPLv2’s obligation is not limited to a specific product type, GPLv3 — which imposes the obligation only on User Products — falls into the interpretive dilemma of having narrowed the scope of ‘freedom’.

8. GPLv2’s Textual and Historical Revisionism

As explained in detail above, textual analysis and a review of the historical record make it clear that GPLv3’s ‘Installation Information’ obligation does not exist within GPLv2’s source code obligation, and that it cannot be backported to GPLv2 in any way. Despite this fact, there have recently been efforts to alter the historical record and reinterpret GPLv2’s requirements so as to equate GPLv2’s source code obligation with GPLv3’s ‘Installation Information’ requirement.

       “GPLv2 §3 requires that the source code include ‘meta-material’ like scripts, interface definitions, and other material that is used to ‘control compilation and installation’ of the binaries.”⁴⁹

       “GPLv2 included a clear obligation to provide ‘the scripts used to control … installation’ that function for the GPLv2’d works. GPLv2 assures, to the purchaser of an embedded product, their absolute right to receive the information necessary to install a modified version of the GPLv2’d works. … The GPLv2 was designed to assure bug-fixing. Furthermore, the drafters knew that, on embedded systems and devices, you need to know how to install those fixes. Scripts can be technical [artefacts] like shell scripts, but can also be merely a recipe and/or guidance — written instructions that explain how to succeed at install.”⁵⁰

As shown in these statements, an effort is currently underway to fold GPLv3’s concept of the ‘Installation Information’ requirement (information, recipes, guides, instructions, etc. for installing and executing an executable) into GPLv2, so that GPLv2 would also require the provision of a ‘script’ for installation. All such efforts are not only counter-textual to GPLv2’s actual requirements but also ahistorical. Again, GPLv2’s drafters acknowledged that GPLv2 could not require TiVo to provide the information necessary to reinstall a modified executable on a TiVo device⁵¹.

9. Conclusion

• The text of GPLv3 and the historical record make clear that GPLv3 was specifically designed to add the provision of ‘Installation Information’ — a new requirement not found in GPLv2.
• This historical record also makes clear that, under GPLv2, distribution without providing installation information (such as authorization keys or other hardware-embedded information that could prevent the installation of a modified version of GPLv2 code) was entirely permitted, and that GPLv2 required only a narrow category of information (installation scripts).
• All efforts to backport GPLv3’s ‘Installation Information’ requirement to GPLv2 are ahistorical and produce the counterintuitive result of making GPLv3 more restrictive of ‘freedom’ than GPLv2. This was never the purpose for which GPLv3 was created in the first place.
• Those who assert this counterintuitive result would in effect be advising developers who love software freedom to prefer GPLv2 over GPLv3, a result contrary to every purpose for which GPLv3 was created and released.

Whether this ahistorical and textually unsupported interpretation of GPLv2 remains merely a theoretical debate, or is ultimately decided by a court as a result of compliance litigation, remains to be seen. The many statements made during the drafting of GPLv3 (as detailed above), together with the actual language of GPLv2, will serve as the basis for any determination of the scope of GPLv2’s source code obligation.

About the author

P. McCoy Smith is Founding Attorney at Lex Pan Law (www.lexpan.law), a full-service intellectual property law firm in Portland, Oregon, U.S.A., that has a sub-speciality in free and open source licensing, as well as Founder at Opsequio (www.opsequ.io), an software licence compliance consultancy. As a member of GPLv3 Discussion Committee B, he was an active participant in the debate over, and revision of, the ‘Installation Information’ requirement in that licence.

• ←Previous
• Next→