![[RSS]](/static/img/feed-icon-14x14.png)
Conservancy Blog
Displaying posts tagged licensing
Understanding Installation Requirements in GPLv2
by on March 25, 2021
According to our Principles, we always begin discussions with GPL violators privately. Many of these discussions are ongoing at any time. Recently, we received many questions about GPLv2's requirements regarding installation of modified versions of GPLv2'd software on the device on which the software was distributed. GPLv2 was drafted in anticipation of future uses of the software, and includes specific license text regarding installation:
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.
Unfortunately, we find that GPL violators often ignore (sometimes inadvertently) this part of that license text, which has always been of great importance: “the scripts used to control … installation of the executable”.
When a system is 100% FOSS “by design”, meeting this requirement is easy. We applaud the many community-oriented commercial projects that build their own hardware and give their users complete software freedom, such as the LulzBot Mini 3D Printer. We wish that all companies would follow that example and grant customers universal software freedom. Unfortunately, that is currently not realistic, even in the medium term.
Copyleft advocates have always contemplated that some companies will choose to ship proprietary software on the same device as the GPL'd works. Indeed, GPLv2 foresaw this possibility and permits that “mere aggregation” — as long as compliance is achieved for the GPLv2-covered works included on the device.
Indeed, GPLv2 was drafted as a forward looking license. Great care and attention was given to what the future might bring in software, and assure that in the future, GPLv2 defended software freedom adequately. In 1991, the year of GPLv2's drafting, one did not need to look that far ahead to see that general-purpose computers would find their way into devices other than servers, desktops and laptops. It was common, for example, in 1991 to have printers with full computers inside to handle various functionality of those printers. Famously, even back then, software freedom activists were quite frustrated that printer companies and their licensees would not liberate the proprietary software on these printers. Such activists, aware of this problem, sought to fix bugs in this printer software. They demanded source code for their printers, not because they sought to build their own printer from scratch and use that software, but because they wished to modify that source, fix the bugs, and reinstall the liberated printer firmware. This problem was well understood at the time of GPLv2's drafting, and GPLv2 was clearly drafted with this issue and use-case in mind.
To that end, 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. Meanwhile, rules for the legitimately proprietary works remain the prerogative of the licensors of that software. Since we have often been asked, we want to communicate this point with complete clarity and transparency: we would never require that any of the proprietary software on the device continue to function (or even be present) on the device after installation of a modified version of the GPLv2'd works on any device. However, installation of the GPL'd works must succeed and operate in a useful and functional fashion on the device.
Installation is where the proverbial rubber meets the road with software freedom. Of course, we honor the esoteric value of the freedom to study, and that right is important. But much more important, and a key reason that the GPLv2 was created, is the software freedom to reinstall a modified version. That means the right to fix bugs, the right to try out your improvements, and the right to remove privacy-disrespecting anti-features. It's the right that our community needs the most. 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 artifacts like shell scripts, but can also be merely a recipe and/or guidance — written instructions that explain how to succeed at install.
We know that other software freedom organizations share this view. Conservancy is spearheading the ongoing effort to make this clarity widely known. Below is a simple statement of this position, phrased in other words:
The GPLv2 does not have any specific requirement for preservation of the ability to reinstall proprietary-software-centric vendor-provided firmwares (even if such firmwares contain some GPLv2'd works) on embedded systems, provided that the downstream user (i.e., the consumer with the device) can build, install, run, and (repeatedly and successfully) reinstall a firmware containing at least the copylefted components (such as Linux+Bash).
Not only is this consistent with what the license text says and requires, but it is also consistent with GPL's general policy goal. In our GPL compliance discussions, violators sometimes argue that, in order to install a modified version of the software received on a device, the user should build a new device themselves from scratch (instead of installing those GPLv2'd works on the device they have already). We don't believe that the original intent of the GPLv2 requirements for “the scripts used to control … installation of the executable” included that expectation, nor is that position supported by the license text. GPLv2 was written in a time after embedded devices already existed, and the intent is clear.
Our position is by no means controversial, but we do expect some will seek to argue it is controversial. We encourage you to consider their motives, funding sources, and licensing models. For our part, we published this policy statement to clarify repeated questions that companies distributing devices with GPLv2 software have recently raised in our GPL enforcement actions for Linux, BusyBox, and other software. We look forward to continuing the (sadly) long road toward compliance with these companies, in accordance with The Principles of Community-Oriented GPL Enforcement. We greatly appreciate the work that both individual contributors and companies put into their software and communities. It is our obligation, as copyleft activists, to ensure that GPLv2's rules apply fairly to everyone.
Finally, we encourage others to link to this statement when discussing GPLv2's “the scripts used to control … installation of the executable”.
On Elastic, its fork, MongoDB, and the SS Public License
by on January 29, 2021
Now that Elastic adopted SS Public License, folks have been asking us if Conservancy's view on the SS Public License has changed. It hasn't, and our previous two blog posts on MongoDB's license change and Copyleft Equality are still relevant. The only statement we'd like to add is:
To our knowledge, there is no individual nor organization who has yet agreed that they will run a project under the SS Public License and be themselves bound by the SS Public License. That license remains a disingenuous proposal until it's put to use in an “inbound=outbound” licensing configuration.
(Both Elastic and MongoDB require inbound contributors to give them special licensing rights.)
Meanwhile, on the orthogonal issue of whether a forked project should choose a non-copyleft or a copyleft license, we refer everyone to this excellent old keynote from Martin Fink about how copyleft makes project governance better and easier.
17 USC § 1201, DMCA Exemptions and Software Freedom
by on December 16, 2020
We at Conservancy spent much in the last week preparing our Long Comments in our DMCA exemptions requests for this round. When we announced these exemption filings, many of our Supporters asked us to “back up and explain” what this whole process is and why Conservancy participates. These are excellent questions and so we provide below a simple explanation of the DMCA exemption process, why it exists, and why FOSS-friendly organizations like us chose to participate in what is ultimately a flawed process.
The provisions of the DMCA were designed to support DRM with the power of civil (and in some cases, criminal) law. Media companies, seeing that digital distribution of content would likely become the standard, sought an iron grip on their business models and gain absolute control of their copyrighted works — making it effectively impossible for FOSS to exist for reading books, watching movies, or listening to podcasts or music. The law is morally wrong because it it seeks to criminalize publication of some software techniques and knowledge, and, moreover, the law creates “chilling effects” for everyone in the USA who might consider writing FOSS that is on the edges of such the law's technological restrictions. We saw just in the last few months how organizations like the RIAA can use the DMCA to harm FOSS projects. Since the law has been enacted, DRM has become ubiquitous. Those who write FOSS that even comes near the job of circumventing DRM live in fear.
The dangers of such regulation are obvious to most FOSS activists and technologists. However, to people less savvy about technology, the purported “compromise” struck in the DMCA can seem perfectly reasonable. 17 USC § 1201 prohibits “circumvention [of] technological measures” put in place to stop acts that were otherwise illegal. To those not well versed in copyright policy, this would of course seem no different than other updates to laws for the digital area — such as assuring existing crimes in real life were also crimes when committed over the Internet. For those of us who understand technology and software, the compromise is not reasonable; DMCA made a digital action a crime that had never been a crime when done in analog — publishing technological know-how to improve and repair devices that we own. The DMCA ultimately gave carte blanche and the force of law to ubiquitous DRM.
The main part of the statute that accomplishes this is 17 USC § 1201(a)(1)(A). Ostensibly, §1201(a)(1)(B-C) provide limitations that rein (A) back. Take a read
of these sections and then follow along here in parallel. (A) uniformly forbids “circumvention of” a DRM measure implemented by a copyright holder. (B) tells us that we, the public,
can come forward once every three years to to identify technological measures we
should have the right to circumvent. If we can prove (per (C)), that
there are legitimate non-infringing activities that we could imagine
engaging in by circumventing the technology restrictions and we can convince the
Copyright Office that those circumventions would indeed
legitimately aid in non-infringing uses of the DRM'd copyrighted works, then — and only then —
can we circumvent a technological measure that effectively controls access to a work
. That's the basics of the
exemption process.
For a more detailed understand of how the process works, there are three videos from the Copyright Office:
- A Legal Overview of § 1201 (PDF slides only).
- The Triennial Rulemaking Process for §1201 (PDF slides only).
- Streamlined Petitions for Renewed Exemptions (PDF slides only).
Basic Overview of 17 USC §1201
- First, §1201 is primarily concerned with so-called “Technological Protection Measures” (generally abbreviated “TPM” in DMCA policy circles). A TPM is defined broadly to include any access control, including scrambling, encryption, password protection and the like.
- §1201 prohibits circumvention of a TPM implemented for access controls to a copyrighted work.
- §1201 prohibits dissemination of information (both commercially and non-commercially) that explains how to circumvent a TPM put in place for either access controls, or copy prevention of work. (The statute and the Copyright Office use the pro-DRM term, “trafficking”, for such activity. We use the term “dissemination” to avoid supporting that propaganda.) If you've heard us and others talk about how the DMCA squelches Free Speech (or are familiar with the phrase “chilling effects” that we activists have argued are produced by DMCA's mere existence), this is the part of §1201 that relates to those issues.
- Exemptions to these rules exist. The law itself has some permanent exemptions, listed in §1201(d-j). These permanent exemptions are useful but certainly don't permit unbridled development of FOSS software that might be considered a circumvention technique.
- All other exemptions are temporary. The exemption process happens every three years — hence the term “Triennial Rulemaking”. There is a rulemaking process occurring right now, and here's a summary of how that works:
The Triennial Rulemaking Process
- A temporary exemption is only granted for uses of copyrighted works that are otherwise non-infringing (i.e., only §1201 restrictions cause infringement, and there must be no infringement due to any other part of the copyright act).
- The Copyright Office Exemptions are never permitted to the
“dissemination prohibitions”, only for use and access. (Only Congress can
change anything regarding actual dissemination of circumvention techniques. This is particularly troubling
for many reasons, including that the
- Exemption applicants must show that there is current adverse impact due to TPMs for the public regarding the non-infringing uses that the exemption would allow. (Alternatively, the applicant, may show that there will be such adverse impact within three years.)
- Hypothetical and theoretical arguments are not accepted. Applicants must show that specific people will (or soon will) suffer adverse effects when unable to engage in real-world non-infringing uses that are directly prevented by a specific TPM and that circumvention would enable those non-infringing uses to resume and/or continue.
- The Rulemaking process itself proceeds as follows:
- The Office issues an NPM, which is the standard method by which any Administrative Branch agency announces a process where new rules will be made.
- Round1: Petitioners make an initial filing to indicate that they'll apply for an exemption and its primary impetus. These are short, and were filed on 2020-09-08 for the 2021 Rulemaking.
- Petitioners and others can then make supportive public comments. Those are what were due on Monday (2020-12-14) for the 2021 Rulemaking. (We'll have follow up blog posts about our filings throughout this week and next.)
- Round 2: opponents may file objections and disagreements. We'll of course expect to see lots of software-freedom-unfriendly vendors making arguments against our filings during that period, and we'll point our blog readers to any filed in opposition of our exemption requests.
- Round 3: reply comments from the Petitioners (and neutral comments from others) are allowed.
- Finally, Round 4: public hearings occur, which are optional. Conservancy participated in the public hearings in the 2015 year Rulemaking when we successfully requested the exemption for “smart” TVs.
- Note, finally, that there is an expedited process for renewal of temporary exemptions, which Conservancy also participated in for the TV exemption originally granted in 2015 and renewed in 2018.
For many activist organizations, the question often becomes whether to participate in or boycott this process. The process places the burden on underfunded activist organizations to make a case just to permit what are ultimately extremely narrow areas of activity. (Remember that the Copyright Office's position is that exemptions are never granted for circumvention dissemination, only access, so the temporary exemptions are both narrowed in that scope and narrowed to specific types of devices or activities.) Conservancy, like EFF, used to be among those who boycotted this process. Reforms — which were sought by CDT, EFF, Public Knowledge, Public Labs, and other organizations — in recent years have improved the process, but it remains time-consuming and painful. However, given that there is no viable political will or path to seek repeal of the DMCA, we're stuck with this process. Just as copyleft is designed to utilize the general copyright system — which most FOSS activists (at least) find problematic or (in many cases) oppose outright — we must similarly work, with regard to this specific part of the Copyright Act, within the system to find our way through. Conservancy has focused our filings in the process on those areas that most directly impact software freedom, and we look forward to telling you more about them this week.
Meanwhile, the dangers we face from the parts of the DMCA that cannot receive exemptions are real. People have been put in prison for “trafficking” under this statue; a company can, as Adobe did, simply phone the FBI to get someone arrested. Companies like Sony can drag in the Feds into civil cases to apply pressure for demand of unreasonable settlements. As long as we live in a regime willing to tolerate this kind of policy, we have to make use of the process we have to improve the odds that FOSS developers and researchers don't face both civil and criminal penalties.
Public Drafting Process for the DMCA Cooperation Pledge
by on November 30, 2020
In my blog post two weeks ago, I proposed — in light of increased DMCA takedowns against FOSS projects (and relatedly, increased enforcement of 17USC§1201) — that we ask for-profit copyright holders to agree to a pledge similar to GPLv3§8¶3. Simply put, proprietary copyright holders should be equally as reasonable as GPL copyright holders are and give FOSS projects 30 days to negotiate and discuss copyright infringement allegations before triggering a de-facto injuction with the DMCA.
I admit that I thought it unlikely that any for-profit companies would even be willing to discuss the possibility of making such a pledge; my proposal was more thought experiment than actual policy. I was however pleasantly surprised to receive positive feedback from at least four companies as well as interest from another non-profit organization who is excited about the idea.
After both internal discussion and external discussion with these parties, we feel that now that the project has moved from thought experiment to real potential policy, that we should move the discussion public. It's just in our DNA at Conservancy to act transparently and welcome stakeholders into public discourse about policies. Moreover, these sorts of industry pledges and assurances have historically been drafted in secrecy by a few companies and then put forward as a fait accompli to the FOSS community. We'd like to change that tendency in this process.
Today, we created a Git repository and a mailing list for this project. We welcome anyone interested in the proposal of this pledge to join the mailing list and propose a patchset or just generally write up suggestions. Folks participating need not and do not in our view bind their company to the pledge; rather, we're looking for wide input on what the text needs to say to make it most likely that organizations will agree to the pledge.
