One of the biggest differences between the GPL v3 and GPL v2 open source licenses is the GPL v3’s “User Product” clause. It requires manufacturers of User Products — defined as either “consumer product(s)” or “anything designed or sold for incorporation into a dwelling” — to provide “Installation Information” so that users of the User Products can update, modify, and/or reinstall the GPL v3-licensed software on those devices.
The intent of this clause is to protect users' freedom to update and/or modify the GPL v3-licensed software on their devices. But its presence also raises several thorny questions, including the precise scope of what qualifies as a User Product and what Installation Information is required. Many manufacturers have concerns about complying with the User Product clause without exposing their sensitive intellectual property.
But while there may not currently be definitive answers to these questions and concerns, there are some best practices that manufacturers and organizations can follow to satisfy the provision’s requirements.
This post is based on a webinar I recently conducted with FOSSA: “Compliance with the GPLv3 ‘User Products’ Clause and the Impact of SFC v. Vizio.” If you’re interested in this topic, I’d point you in the direction of the on-demand recording for a more in-depth discussion.
A Closer Look at the GPL v3 User Product Clause
As mentioned, the GPL v3 includes an installation information requirement for software distributed on a “User Product.” The clause reads as follows:
“If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information.”
The GPL v3 goes on to define a “User Product” as either a “consumer product” (any tangible personal property which is normally used for personal, family, or household purposes) or “anything designed or sold for incorporation into a dwelling.” This definition is somewhat vague (perhaps intentionally so), but is generally interpreted as applying to a wide variety of products, including home WiFi routers, televisions, smart appliances, and even cars.
Challenges with GPL v3 User Product Clause Compliance
The GPL v3 defines “Installation Information” as “methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product.” This information must be conveyed in a format that is publicly documented, and must not require a password or key to access, unpack, or read its contents. The information must also suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because a modification has been made.
What does this mean, in practical terms? Often, developers balance the provision of the Installation Information required by the GPL v3 against the competing goals of protecting their own intellectual property and ensuring that the installation of modified code does not result in the malfunction or misuse of their products. It may be challenging to convey the Installation Information in a format that meets all of the above criteria, especially because many User Products contain or use either proprietary or third-party closed-source code, or signing keys to prevent installation or execution of untrusted software. Must a developer provide the source code to that closed-source code or signing keys that permit the modified software to run with the closed-source code?
Though there are obstacles to maneuver, there are a few ways you can prepare for compliance with this clause.
Strategies for GPL v3 User Product Clause Compliance
Before diving into specifics, I do want to note that, as with most open source issues, there haven’t been any cases around this yet. And, so, we don’t have any guarantees that these approaches will work. But they are strategies that some open source license enforcers have publicly indicated are likely acceptable. And, in some cases, they are approaches clients have used to comply with the GPL v3.
The first step in any open source license compliance program is understanding what code and licenses you’re using. That’s certainly the case for GPL v3 User Product clause compliance as well. Software composition analysis tools like FOSSA automate license detection and make this process relatively straightforward.
From there, there are a few options that you might consider
1. Open source your product’s code
While it may not be a viable option for many companies, licensing the code for your product under an open source license may be an attractive option for certain companies or products. Doing so may lead to rapid adoption and improvement of your code.
2. Signing keys
The GPL v3’s definition of Installation Information includes all “methods, procedures, authorization keys, or other information” required to reinstall the GPL v3 licensed code on the User Products. Therefore, if your device requires software to be signed with a signing or other authorization key before it can be installed, you are required to provide one as part of the Installation Information. The GPL v3, however, does not require you to provide the same key that you use for your code.
What do I mean by that? If a signing key is required to install software on your product, the GPL v3 requires you to provide one, but it doesn’t require that key to be the same signing key that you use to identify code that is provided by you.
So, you could create a second key that permits third-party code to be installed on the device, but does not identify that code as being trusted code. The use of this secondary installation code could also limit or disable the operation of your closed source applications on the device if you choose.
Of course, you might be wondering whether this approach conflicts with GPL v3’s requirement that Installation Information permit the continued function of modified object code. The answer is that requirement refers to the GPL v3-licensed code — as long as the key allows the installation of and functioning of the modified GPL v3-licensed code on the device, the GPL v3 does not require you to permit your closed source applications to run with that open source code.
3. Require the device to go into “development” or “safe” mode before modified code can be installed.
By “development” or “safe” mode, we mean the status where a device is running, but in a very bare-bones fashion, without your closed source applications. Requiring the device to be in development mode before untrusted software can be installed can prevent the misuse use of your closed source code while still adhering to the GPL v3’s requirements that modified open source code be permitted to be installed and run. Then, if users want to go device again with the additional functionality of your closed source applications, they have to leave development mode and reboot into the “regular” mode (which runs only the developer’s trusted code).
4. Require permanent development mode.
With the previous option of permitting modified code to run only in development mode, you might be wondering: this is open source code, what if users are able to modify the GPL v3 code to permit it to run when the device is rebooted into “regular” mode?
If that is a concern, then you might consider permanent development mode. With this approach, installation of modified open source code on the device while in development mode permanently deletes your closed source applications. The user is free to install and execute its modified GPL v3 code and use the device, but without your proprietary functionality. Would that irritate open source license enforcers? Likely. But it complies with the GPL v3 and some have indicated that it is an acceptable approach to compliance.
Again, none of the foregoing strategies have been tested in court, but from our experience and public statements from certain enforcers, we believe they are acceptable strategies,