Trump's Social Media Platform and the Affero General Public License (of Mastodon)

by Bradley M. Kuhn on October 21, 2021

An analysis: Trump's Group has 30 days to remedy the violation, or their rights in the software are permanently terminated

In 2002, we used phrases like “Web 2.0” and “AJAX” to describe the revolution that was happening in web technology for average consumers. This was just before names like Twitter and Facebook became famous worldwide. Web 2.0 was the groundwork infrastructure of the “social media” to come.

As software policy folks, my colleagues and I knew that these technologies were catalysts for change. Software applications, traditionally purchased on media and installed explicitly, were now implicitly installed through web browsers — delivered automatically, or even sometimes run on the user's behalf on someone else's computer. As copyleft activists specifically, we knew that copyleft licensing would have to adjust, too.

In late 2001, I sat and read and reread section 2(c) of the GPLv2. After much thought, I saw how it could be adapted, using the geeky computer science concept called a quine — a program that has a feature to print its own source code for the user. A similar section to GPLv2§2(c) could be written that would assure that every user of a copylefted program on the Internet would be guaranteed the rights and freedoms to copy, modify, redistribute and/or reinstall their software — which was done by offering a source-code provision feature to every user on the network. The key concept behind the Affero GPL (AGPL) version 1 was born. Others drafted and released AGPLv1 based on my idea. Five years later, I was proudly in the “room where it happened” when Affero GPL version 3 was drafted. Some of the words in that section are ones I suggested.

We were imagining a lot about the future in those days; the task of copyleft licensing drafting requires trying to foresee how others might attempt to curtail the software rights and freedoms of others. Predicting the future is difficult and error-prone. Today, a piece of Affero GPLv3's future came to pass that I would not have predicted back in November 2007 at its release.

I invented that network source code disclosure provision of the AGPL — the copyleft license later applied to the Mastodon software — in 2002 in light of that very problem: parties who don't share our values might use (or even contribute to) software written by the FOSS community. The license purposefully treats everyone equally (even people we don't like or agree with), but they must operate under the same rules of the copyleft licenses that apply to everyone else.

Today, we saw the Trump Media and Technology Group ignoring those important rules — which were designed for the social good. Once caught in the act, Trump's Group scrambled and took the site down.

Early evidence strongly supports that Trump's Group publicly launched a so-called “test site” of their “Truth Social” product, based on the AGPLv3'd Mastodon software platform. Many users were able to create accounts and use it — briefly. However, when you put any site on the Internet licensed under AGPLv3, the AGPLv3 requires that you provide (to every user) an opportunity to receive the entire Corresponding Source for the website based on that code. These early users did not receive that source code, and Trump's Group is currently ignoring their very public requests for it. To comply with this important FOSS license, Trump's Group needs to immediately make that Corresponding Source available to all who used the site today while it was live. If they fail to do this within 30 days, their rights and permissions in the software are automatically and permanently terminated. That's how AGPLv3's cure provision works — no exceptions — even if you're a real estate mogul, reality television star, or even a former POTUS.

I and my colleagues at Software Freedom Conservancy are experts at investigating non-compliance with copyleft license and enforcing those licenses once we confirm the violations. We will be following this issue very closely and insisting that Trump's Group give the Corresponding Source to all who use the site.

Finally, it's worth noting that we could find no evidence that someone illegally broke into the website. All the evidence available on the Internet (as of 2021-10-22) indicates that the site was simply deployed live early as a test, and without proper configuration (such as pre-reserving some account names). Once discovered, people merely used the site legitimately to register accounts and use its features.

---

Update (2021-10-22): Some have asked us how this situation relates to our Principles of Community-Oriented GPL Enforcement, since we are publicly analyzing a copyleft violation publicly. Historically, we did similarly with the Canonical, Ltd., Cambium, Ubiquiti, and Tesla (twice!) violations. We do believe that “confidentiality can increase receptiveness and responsiveness”, but once a story is already made widely known to the public by a third-party, confidentiality is no longer possible, since the public already knows the details. At that moment, the need to educate the public supersedes any value in non-disclosure.

[permalink]

Tags: conservancy, GPL, licensing

How We Hired Our Last Employee: Equitable Hiring Processes for Small (and Large) Organizations

by Karen Sandler on October 15, 2021

Like many small organization that are overloaded with work, it's hard to make the time to conduct a proper hiring process, and no one on staff is dedicated to making sure the process goes smoothly. Because it is very important to our organizational values to make sure that our hiring is fair and also that we wind up with the best person for the job, we were very careful in how we designed our search.

We finished our last hiring a few months ago. I'm proud of the way we handled the process, and I think it resulted in the best hire possible for the position. As I describe the process below, you can see how we worked to respect our applicants, interview while minimizing bias, and select for skills that were essential for the actual work to be covered by the open position. (There's a TL;DR summary at the end! Perhaps the most interesting part is that we paid people who made it to the final round to respect their time and to defray their costs of participating,)

A neutral and realistic job posting

We thought hard about our job posting, including a detailed description of the role. We were clear that we were open to hiring from a variety of backgrounds and were willing to train less experienced candidates. We worked to eliminate any gendered language or anything that we thought would create heightened requirements for the job, which can reinforce bias in the process. Finally, we were open to feedback, and when folks suggested that we include a narrow salary range to bring transparency and lower stress for our applicants, we added that too.

You can see the job posting we just put up for an Outreachy related position where we once again are following these principles.

Happily, for the position that we already hired for, we received around 40 really solid applications for the position - a really high number for an organization like ours, especially since we only advertised the position in limited ways.

Initial screen by volunteer directors

After a very quick review of resumes to weed out the few applications that were spammers or otherwise not really targeted to our organization, we scheduled 15 minute screening interviews with two of our volunteer directors. We wanted to make sure that we added a layer of independent review that would otherwise be impossible in a small org like ours.

In order to make sure that we were comparing apples to apples, and giving everyone the same chance at success, the directors were given a set list of questions to ask. Because the role was about advocacy and communications, most of the questions were connected to explaining what software freedom is, and how the applicant became interested in it. The directors were also given a rubric to grade the interviews, both question by question and overall. The directors put their grades and thoughts about each candidate (along with any red flags) in spreadsheets so that we'd be able to access the information easily later. Spelling out what questions will be asked and how the responses willl be graded helps to eliminate bias that can come from an an interviewer and interviewee that "click" in ways that might be related to their background or shared experiences.

Anonymous exercise

After the screening interviews, the bulk of the applicants were asked to participate in an anonymous exercise. The goal of having an anonymous exercise is to overcome any biases we might have for or against particular candidates. Each applicant was assigned a random string, and they were instructed not to put any personal identifying information in their answers.

We designed the exercise to reflect actual tasks we'd expect the new employee to take on, while providing some opportunities to brainstorm some big picture topics that could come up in the position. Writing emails to our organization's Supporters and member projects are key components of the job, so we created short hypothetical situations (that encompassed typical problems we need to address) and asked the applicants to write mock email responses. Because the role also has a public press and event organizing component, we asked applicants to write the beginning of a website news item and tell us a few things they thought were essential to run a successful in person event.

To respect our applicants time, we kept the exercise bounded. We expected it to take an hour or less, and asked the applicants send us their responses after an hour and a half, explicitly adding a little bit of extra time in case they were interrupted during the process. We also scheduled the exercises at the convenience of the applicant at any time during normal east coast business hours, since being able to coordinate with staff in the US was an important part of the role. We offered flexibility for applicants who could not make time during the workday during their existing role or had other obligations they needed to schedule around.

Conservancy staffers graded the responses on an anonymous basis, scoring each exercise. When this was completed, the graders met to compare their results. At this point, there were five applicants whose exercises stood out from the group. We de-anonymized them and cross referenced them to make sure that their screening interview scores were also strong and all of them moved to the next round.

At this point, I should note that I was surprised by the results. Long-time software freedom activists, whose work we know and respect, wound up not making it to our final group, whereas our final applicants included people who were new to software freedom, had never been in a communications role or who we simply hadn't met before. This final group consisted of people who showed the skill sets most likely to succeed in the position, not people who were already part of our network.

Because the exercise was anonymous, it was also easier to explain to the other applicants why we weren't advancing them to the next round, and I think (hope!) that it made it easier to preserve our relationships with the applicants who are truly excellent advocates for software freedom in a variety of other contexts.

Paying the finalists

Because we are a small organization, adding another employee is a big deal. We knew that to do this job right we were going to need to take some time talking to them to figure out if they were the right fit for the role. We also know that not everybody does their best when put on the spot in an interview, and wanted to make sure that we allowed people the chance to know what we'd be asking and to prepare if they wanted to. We didn't want to take our applicants' time for granted, even though we are a small publicly supported organization.

Because of this, we decided to pay each our five finalists $500 to proceed with the rest of the interview. While $500 is not a huge amount, we thought it was a nice amount for a charitable organization to give to an applicant who would dedicate some time and thought to our hiring process, which would cover strategic thinking about our organization's mission and operations in our communications and other related areas.

Again, we used the same questions with all candidates, and we provided them in advance of the interview, offering the applicants the option of providing written answers or just discussing them on the spot, whichever they were most comfortable with. We were trying to avoid a gamification of the interview process, while still getting insight into the thought process of the applicants. These questions included difficult ones about the software freedom community and also about Software Freedom Conservancy. Now that we knew these candidates were very strong in their ability to write quick emails and website copy, the idea was to bring some of the most strategic problems that we'd be looking to include the new employee in tackling.

Conducting final interviews

This step looked like a more traditional interview. Bradley and I scheduled video chats with the remaining candidates. We first had the applicants tell us their answers to the questions we had sent in advance and used those as a jumping off point for relevant conversation.

While all five candidates were strong in these interviews, three candidates had a mix of skill sets that seemed like the best fit for the role. For these three candidates, we scheduled an interview with Conservancy's staff in its entirety. Again, with a small organization, the addition of another person is a huge chance in organizational dynamics. Feedback from all employees was essential to making this decision.

Choosing the final candidate

In the end, going through the interview process and learning more about the job convinced one of the final three candidates that they were not really interested the role we were hiring for, which they understood much better through our hiring process. It was a tough choice between the two remaining candidates, but we were able to have confidence in Pono as our choice due to feedback from staff, the comparisons made possible by asking the candidates the same questions and the grading from the previous two rounds. If we'd had the budget, we would have hired all three of these final candidates.

Feedback on the process

Each of the finalists were surprised that we were willing to pay them for their time. For some of the applicants, being paid to participate gave them the flexibility to devote more time to their interview preparation. We were happy we were able to show our appreciation for the impressive applicants who were willing to give us so much of their time.

We also got positive feedback on the anonymized exercise. Because the exercise gave insight into how some of the every-day work in the position would look, it made it easier for some of the candidates to decide if they wanted to actually work in that role. In addition to the benefit I mentioned above about the anonymization making it easier to explain who would advance to the next round, some applicants indicated that making it to the final round via an anonymous exercise gave them confidence that they were qualified for the position.

TL;DR

For future hiring, we'll be looking to bring the same concepts to the process. Namely:

• bring in an independent review of the candidates
• ask all of the candidates the same questions
• design an exercise that connects to the actual work the employee will be doing in the role
• judge the exercise responses on an anonymous basis
• keep the time required for applicants to invest in the interviewing process as minimal as possible
• pay applicants who are required to invest more substantial time in the process

Many thanks to all of Conservancy's staff who helped us with this process (Rosanne Dimesio, Bradley Kuhn, Sage Sharp, Brett Smith), and to Deb Nicholson who helped bring some of these concepts to our previous hiring process.

Outreachy is hiring for a community manager position and using some of the strategies listed above. If you or someone you know if interested in applying for the community manager position, check out the post here.

[permalink]

Tags: conservancy

"Anyone???"

by Karen Sandler on August 24, 2021

We often talk about how frustrating it is to obtain source code that is supposed to be available under copyleft licenses. We not only try to get source code for our own devices, but we also are inundated with requests from developers all over the world who seek source code to modify their technology in ways they should have a right to do. By the time someone sends a complaint to us, asking for our help, they've already tried and failed to ask the company to do the right thing. Usually they are simply ignored by the company but sometimes companies introduce all kinds of weird procedures in the hopes that if they make it just difficult enough that the requestors will go away.

We've seen these obstacles include all kinds of unreasonable forms, beyond a simple email address to make the request. A common requirement is that the request be sent to a particular paper address, by registered mail, and we've even seen the company specify particular kind of storage device to be included in the mailing. Companies erroneously try to require that requestors include personal information, including detailed information on the device and its purchase. It's hard work, but we're proud that we continue to apply pressure to these companies and never give up our quest to make sure everyone follows the rules so that developers can have access to the software on their devices that the GPL ensures. It also often feels like lonely work. But not today.

DevOps Engineer, ptrcnull (Patrycja), tweeted last week about a frustrating email she received from Umidigi, a Chinese smartphone manufacturer, which told her that if she wanted access to the source code she was rightfully requesting under GPLv2, she needed to come in person to Umidigi's offices in Shenzhen. And that (by the way) the office was only Chinese speaking.

Luckily, one of ptrcnull's followers, looped in Naomi Wu, a well known Chinese maker and hacker, who decided to go down to Umudigi's offices and take them up on the offer.

As a Cyborg Lawyer who spends a good portion of her time trying to compel GPL compliance, I nearly flipped watching Wu (who calls herself Sexy Cyborg) marching into Umidigi trying to find anyone who could help her get the source code. It's the physical manifestation of the kafkaesque experience that companies set up for those exercising their rights under GPL. I couldn't believe it when I clicked on it from a link in a mastodon toot from Harald Welte, who has also done quite a bit of GPL enforcement over the years.

Here's the video:

While Wu managed to get to Umidigi's offices in mere days from when the email was sent to push off ptrcnll, she's told that the person who wrote the email, Ben, is no longer with the company.

I look forward to seeing the full video, and have offered our assistance. I'm grateful to ptrcnull and Wu for doing this work and I'm happy to work on GPL enforcement myself, but it makes me wonder: How much could we accomplish if companies did what they were supposed to do? What would it look like if companies were true partners in compliance and encouraged their customers to tinker with their devices? How many people try to make source requests and give up when it's difficult? If we've been able to accomplish so much with copyleft, even in the face of corporate stonewalling, imagine what we could do if we could skip all of these tedious steps and get straight to collaborating.

[permalink]

Tags: conservancy, GPL, cyborg

"Tivoization" & Your Right to Install Under Copyleft & GPL

by Bradley M. Kuhn on July 23, 2021

Two schools of thought about the purpose of copyleft have been at odds for some time. Simply put, the question is: are copyleft licenses designed primarily to protect the rights of large companies that produce electronics and software products, or is copyleft designed primarily to protect individual users' rights to improve, modify, repair, and reinstall their software?

This debate quickly gets deep into complex policy questions. In the last few years, that general debate has slowly but surely focused almost entirely on the issue of users' ability to make effective use of FOSS on their own hardware by reinstalling their modified versions.

Historically, these nuanced policy questions about copyleft requirements have generally been discussed only in semi-public venues, and often fall prey to the tactic du jour: post-fact politics. I have realized in recent months that the failure to properly document and explain key historical narratives in copyleft history leaves software freedom activism at a disadvantage: well-resourced copyleft violators and their lawyers can use the ambiguity and confusion in the scant public record to spin false narratives and draw legal conclusions. While such legal conclusions should not be drawn (absent a Court ruling), companies have nevertheless pushed their views forward quite loudly recently. To use Herman and Chomsky's insightful phrasing, the incumbent power structures manufacture consent to their worldview to serve their interests, merely by being the loudest and most commonly heard voices.

Specifically on the issue of protections for the right to repair and reinstallation under copyleft licenses such as GPL, I am fortunate to have been a direct observer to many of the events that now serve as the connective tissue to build these false narratives about the GPL. However, I admit I have failed to write down and impart that knowledge to the general public in adequate measure, which has, in turn, inadvertently aided in promulgation of these false narratives. So, at least on the issue of “scripts used to control compilation and installation of the executable”, I hope this essay will serve as remedy. I, and everyone at Conservancy, all believe in intellectual transparency, and we strive to provide it wherever possible. The truth will out.

Installation Requirement Under GPLv2

Recent debates on this issue focus on the question of what is required to comply with the first two sentences of GPLv2§3¶2, which reads:

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.

Before explaining the historical understanding of these terms, I will, first of all, point out that any company or lawyer that seeks to do the bare minimum for compliance is likely not prioritizing users' rights to repair their software. In all compliance-related systems, bad actors seek a “race to the bottom”. Rules like GPL are similar to environmental regulations, workplace safety requirements, and the like. The more minimalistic the interpretation of the requirements, the more companies can profit from only doing the bare minimum.

Nevertheless, it has been the goal of organizations that advocate for software freedom — such as Conservancy ourselves or FSF — to state clearly our view about the minimum requirements as best we can. I often wonder if this strategy has been beneficial to software freedom. Sadly, the answer from the industry has primarily been to hear us clearly about the minimum requirements, and then work over time to lower the GPL compliance bar — even if it requires inaccurately quoting FOSS leaders and misleading the public about history. Most recently, industry has engaged in this bar-lowering process with GPLv2§3¶2 and installation information under GPLv2 generally. My hope herein is to fully explain the history of interpretation of GPLv2§3¶2 by pro-copyleft advocates, and explore the misdirection of arguments of those who seek to curtail users' rights to install modified versions of their GPL'd software.

FSF CLE Classes, 2003-2004

I began volunteering for licensing and GPL enforcement work for FSF in 1997, and officially worked on my first GPL enforcement action in 1999. I became an FSF employee that year, and worked there until 2005. I thereafter remained affiliated with the organization in various roles until my final affiliations ended with FSF in October 2019. Most notably, I was the Executive Director of FSF from 2001-2005. During that time, I led FSF's GPL enforcement and copyleft education measures, including the CLE classes (first taught in 2003-2004).

In preparation for teaching those courses, I began to write the tutorial which later became the Copyleft Guide. To begin that effort, I collected, curated, and verified interpretations and intent of the GPLv2 with Richard Stallman, Bob Chassell (a key but oft-forgotten leader of FSF during the 1980s and 1990s), and FSF's legal counsels. One of the many outcomes of that endeavor was that I wrote these words on 2003-05-09:

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.

In GPL enforcement actions at the time, during our “complete, corresponding source (CCS) checks”, we verified that the source code was not only complete, but that it corresponded to the binaries on the vendors' devices, and that we could install modified versions of the software. This was a standard part of any check to verify GPLv2 compliance. Passing this check was required, then and now, by FSF and Conservancy before distribution rights are restored after a violation.

That position was not controversial when I, along with then FSF counsel (Daniel Ravicher), taught it to lawyers in 2003 and 2004 on FSF's behalf. Nevertheless, today, many act as if this interpretation and intent of GPLv2§3¶2 is a recent and novel phenomena, rather than a long standing position held by all copyleft activists for at least 18 years. Today, most companies and lawyers argue (incorrectly, IMO) that users have no rights to reinstall their GPLv2'd software.

The 2003 TiVo GPL Enforcement Action

Even before teaching those CLE classes, as (then) FSF's Executive Director, I led the GPLv2 enforcement effort against TiVo. I've often seen those with only a passing familiarity with the subject jump to inaccurate conclusions about that enforcement action that tend to conveniently fit their policy agenda. I herein recount the entire history regarding the TiVo GPLv2 violation and how it led to the “tivoization” rhetoric. Since that rhetoric is often treated as dispositive truthiness that GPLv2 does not ensure the users' rights to repair by reinstalling their modified GPLv2'd software, we should examine the actual facts that back the rhetoric, and examine the conclusions that others make about GPLv2 based on it.

First and foremost, TiVo's GPL violation initially had nothing specific to do with GPLv2§3¶2. TiVo never raised any intention to not comply with that section. In fact, to my recollection, TiVo never disputed nor disagreed with FSF's interpretation on that section. The initial violation was a standard GPLv2§3(b) violation, wherein some distributions of the TiVo device had an offer for source that could not be successfully exercised. (At the time) acting on behalf of FSF, I contacted TiVo on 2002-06-11 to raise this issue, and, TiVo responded favorably and indicated they wanted to resolve the matter. As is usual practice in all GPL enforcement matters, I and my (then) team did our due diligence to verify full compliance, including any other potential issues under GPLv2. Eventually, my FSF colleague (David Turner) and I did a CCS check of TiVo's software. The procedures, criteria, and interpretations that Turner and I used then are exactly the same as the ones that Denver and I use today at Conservancy. To my knowledge (based on recent personal conversations with FSF staff), FSF still uses when these same procedures, criteria, and interpretations when FSF has the rare occasion to do GPLv2 enforcement these days.

Once the GPLv2§3(b) violation was resolved, Turner and I discovered — as has been true in nearly every one of the hundreds of GPL compliance matter that I've worked — that “the scripts used to control compilation and installation of the executable” were incomplete. When this was identified, TiVo's solution was to, in fact, agree with the interpretation that that such instructions are mandatory and must be provided and they provided them. To my knowledge, TiVo was in full compliance with the GPLv2, including the inclusion of instructions for installation as required under GPLv2. People were able to reinstall Linux on their TiVo boxes thanks to our enforcement action; community resources on how to take advantage of GPL reinstallation rights on TiVos (of that era) are still readily available! At the time⁰, TiVo was doing the right thing in providing what the GPLv2 requires — including the ability to reinstall GNU and Linux software onto the actual device. Keep in mind: this enforcement action, and the compliance achieved from it, occurred years before the GPLv3 process began.

Understanding The Tivoization Rhetoric

So, what did TiVo do that was so objectionable? What was the behavior that Stallman went to work drafting GPLv3 to prevent that TiVo was allowed to do under GPLv2? It's not, as others widely misreport, that TiVo forbade reinstallation “of the GPL'd software” itself. To my knowledge, TiVo never prevented such reinstallation. No one involved, including me, Stallman, TiVo, or anyone at FSF at the time believed that GPLv2 permitted TiVo to withhold the installation information for the GPL'd software itself. FSF demanded that TiVo provided its users the ability to reinstall Linux (and other GPL'd software, such as GNU bash). What TiVo later did, which some software freedom activists (including Stallman) found objectionable, was that TiVo designed the reinstallation process of that GPLv2'd software to cause the proprietary TiVo application to cease to function. I recall this being widely discussed when TiVo Series 3 was released in mid-2006, and my understanding was that all Series 3 devices had this particular anti-feature. (There were rumors that some of the Series 2 had this anti-feature as well, but not all models.) In other words, if you decided to modify your copy of Linux for the TiVo device and reinstall Linux, the TiVo userspace application would realize that cryptographic lockdown had been breached, and that proprietary software would no longer function. By exercising your reinstallation rights under GPLv2, you'd turn your TiVo DVR into a stand-alone server with some video processing equipment attached. You could use Kodi (which at the time had a different name) to turn that former-TiVo into a FOSS DVR, but your ability to use the proprietary DVR software from TiVo was lost — likely permanently.

Most have of course heard of the negative term “tivoization” that Richard Stallman popularized during the GPLv3 process — which was contemporaneous with the release of the TiVo Series 3. I nevertheless asked Stallman to not use that term — both then and many times since. I still disagree with Stallman's policy position on the narrow issue of preserving proprietary userspace functionality. Specifically, I just don't think it matters if, upon upgrading your copylefted software, that the proprietary software that was (to use GPLv2's terminology) “merely aggregated” alongside the copylefted software continue to function. I felt and still feel that it's actually better policy to break the (“merely aggregated”) proprietary software (as GPLv2 permits). My policy view is that this breakage inspires and encourages users to install a FOSS alternative for the userspace applications after they've reinstalled the FOSS operating system. Nevertheless, Stallman found this practice (using crypto lock-down to force the proprietary software to fail) illegitimate. He noted publicly that GPLv2 didn't prevent this behavior, and wanted (and wrote, as explained below) a GPLv3 draft that prohibited that behavior.

How Discussion Focused on Cryptographic Lockdown Generally

To this day, I'll remain frustrated that many pro-GPLv3 advocates, during the GPLv3 drafting process, saw fit to imply ideas that they had no basis to believe were true about GPLv2. We all knew, long before GPLv3 drafting began, that there was a clear installation requirement in GPLv2 — the word “install” appears prominently. The training materials that I developed for FSF (described above) were vetted through Stallman and FSF's legal counsel before using them to teach CLE classes. If anyone received a different impression, it was surely a miscommunication due to the aggressive “GPLv3 is much better” rhetoric of the time.

Meanwhile, much of the debate about cyptographic lockdown under GPL centered around the question of disclosure of specific authorization keys. It was said, probably correctly, that GPLv2 did not mandate disclosure of an any specific authorization key. What was often left unsaid (apparently in an effort to make GPLv2 seem weaker than it actually was) was what GPLv2 did still require: a functional installation method without disclosure of authorization keys. For example, it would, in my personal opinion, be entirely compliant with the GPLv2 to simply disable the secure boot chain, providing no path back to the vendor-provided cryptographically signed firmware¹, and allow the user to reinstall only the GPLv2'd components on the device — never to return to the stock vendor firmware. I suspect such restriction would be prohibited under GPLv3, since GPLv3 clearly requires not that you just give a viable install path (as GPLv2 does), but GPLv3 additionally requires disclosure of the authorization keys.

We can debate whether this copyleft expansion under GPLv3 was good policy. What is not up for debate is the simple concept that: more requirements added to a later revision of a licensing document does not change the intent or standing requirements in the older document. That's true even if the authors of the original document, for marketing or other reasons, choose later to denigrate their own past work. As it turns out, historically, we know what GPLv2 intended because its author, Richard Stallman, talked so extensively about what he sought to accomplish by creating GPLv2.

Going back to the early 1990s and contemporaneous with GPLv2's publication, Stallman himself has been quite fond of telling his experience with the broken MIT printer, for which he begged for the source code and didn't receive it. Stallman doesn't end this story with: “what I really wanted was to get the source code to that printer so I could build my own printer from scratch and then compile and make a fresh install of that printer software on a new printer”. No, Stallman was clear that his goal was to fix the bugs on the printer that MIT already had, using the source code for that very same printer. Stallman expected that the source code for the printer would include information sufficient for him to recompile and reinstall the software onto the very same device. Larger printers of that era were simply embedded devices of unusual size. They have only minor technical differences from the TVs, wireless routers, and dozens of other Linux-based embedded devices we have today. Computers are tiny today when they were large before, but their functioning and basic methods of operations have not changed. Install meant install then. Install means install now. And FSF, Conservancy, every software freedom activist and every legitimate copyleft theorist that I've ever met still agrees with this! The intent of the GPLv2 is clear and always has been: to allow reinstallation of modified versions of the GPL'd software into the same place where the binaries were installed when you got the computer in the first place, and to reap the benefits of that change. It's ludicrous to suggest Stallman meant anything other than that when he wrote GPLv2.

Recent Confirmation from FSF

Nevertheless, opponents of users' right to repair their software persist in their claims that GPLv2 doesn't intend this. We at Conservancy hear it regularly; GPL violators frequently send us a recently compiled dossier of curated comments by FSF — quoted (and some even misquoted) completely out context — that purport to “prove” that FSF does not want users to repair their embedded devices that contain GPLv2'd software. My affiliations with FSF had already ended by the time this dossier started making the rounds, so we did what any reasonable person would do: we asked FSF to clarify their opinion for us directly.

The opportunity to ask presented itself about a year ago, in May 2020, when Conservancy worked with FSF's Executive Director (John Sullivan), FSF's Licensing and Compliance Manager (Donald Robertson), and FSF's (then) legal counsel (Marc Jones) on a joint GPLv2 enforcement matter against a pernicious and intentional violator who had infringed the copyrights of GNU Bash and Linux. (The violator was using a GPLv2'd fork of Bash.) We took the opportunity then to reaffirm our joint understanding of this 18-year-old interpretation of the GPLv2 as part of that specific joint embedded device enforcement action. We discussed the matter at length and confirmed everyone's understanding remained unchanged from the prior FSF positions going back (at least) 18 years.

At the end of our discussions, on 2020-05-11, I wrote to Sullivan saying: “I just want to summarize what I believe was our mutual view on the phone call last Friday. If you could confirm that I have summarized correctly, we'll use the below as a basis of our response to [those who are currently inquiring about this issue]:”

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, and (repeatedly and successfully) reinstall a firmware containing only the copylefted components (such as Linux+Bash).

John replied on 2020-05-13 with: “Bradley, We suggest just a couple of small tweaks:”

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).

As you can see, Sullivan advocates inclusion of the term “run” (which admittedly I had accidentally failed to include in my original draft!). It was a great addition, and Sullivan's statement matched exactly the historical interpretation that FSF espoused when I worked there in 2003. Indeed, it read to me almost exactly what Chassell had originally taught it to me when I was volunteering for FSF in the 1990s. Furthermore, the quote from Sullivan above matches the position that I vetted with Stallman throughout my time at FSF, right up until the end of my affiliation with FSF in 2019. Thus, FSF's position, as stated above, on the question of installation under GPLv2 has remained consistent from 2003-2020.

This leaves me to wonder: how is it that so many people came to conclude that FSF's view was that the GPLv2 didn't speak to “install” at all? I can only speculate, but my view is that (a) people heard what they wanted to hear, (b) a few (but not most, or even many) Linux developers spoke widely that it was their personal view that installation information isn't required by GPLv2 (notwithstanding the obvious textual requirement), and (c) in their fervor to ballyhoo the GPLv3 as an improvement, some GPLv3 advocates chose to denigrate GPLv2 as “not good enough” — in an apparent effort to frighten pro-GPLv2 copyleft activists to rush away from GPLv2 as quickly as possible.

Stallman on GPLv3 Installation Information

In April 2012, I started an email thread with Stallman yet again about the term “tivoization”. I again urged him to stop using the term, because, in my view, what TiVo did for GPLv2 compliance was not bad for software freedom. I wrote to Stallman at that time to again remind him that upgrades of TiVo's Linux installation “can be done successfully” and (at least for TiVo product that FSF declared in compliance), the only offense was one that GPLv2 permits: merely disabling the proprietary components from working after reinstallation of the GPLv2'd components. At that time, Stallman informed me that he had indeed designed the GPLv3 to deal with this situation. Specifically, I asked him on 2012-05-05:

[so], these words in GPLv3: “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.” mean that the proprietary software that is not a combined work with the GPLv3'd work must also function?

Stallman replied on 2012-05-06 with:

Absolutely. And I wrote it specifically to do that!

Why This History Must Be Told

Generally speaking, long narratives of past events that have hitherto lived only in oral history usually have academic interest only. They make for great podcast or post-conference-dinner fodder, but they rarely make for good blog posts. Nevertheless, I've explained all this here in painstaking detail to counter the rising swell of opposition to users' right to repair their GPLv2'd software installations. Initially, these efforts to curtail the right to reinstall under GPLv2 have been done clandestinely — for example, by spreading the aforementioned misleading dossier. Recently, however, the effort has gone public.

In mid-July 2021, a lawyer named McCoy Smith, who tries to make his living (in part) representing GPL violators, published an article that makes outrageous and inaccurate claims about these long-standing positions held by both Conservancy and FSF. We at Conservancy don't fear transparency, and we urge you to read McCoy's response to Denver's article, as well as Denver's original article, and then reread this one that responds to McCoy's argument. You should decide for yourself who has the better argument, and decide whether or not we've adequately answered McCoy's outrageous and inaccurate claims. In our view, McCoy spins a false narrative about the differences between GPLv2 and GPLv3 regarding install, and provides specious evidence for this claim. I hope that the historical facts that I describe above clarify this issue.

A few of McCoy's fundamental arguments are easily disputed by the historical facts that I outlined above:

• McCoy accused me and Conservancy of “Historical Revisionism”, by claiming my words about GPLv2§3 were “a recent effort … to reinterpret the requirements of GPLv2”. I've shown above, using reliable and accurate revision history logs, that those words, which McCoy claims were recent, were written and published in May 2003.
• McCoy states that the objection to TiVo was regarding prohibition of reinstallation of the GPL'd binaries. I've confirmed above that during FSF's enforcement action against TiVo, TiVo agreed to allow reinstallation of the GPL'd binaries but caused the proprietary software not to function, and that FSF took the position that GPLv2 required reinstallation of GPLv2'd binaries to function.
• McCoy claims that GPLv2's original intent was never to allow installation. I've shown above that Stallman, the author of GPLv2, specifically knew about situations of embedded device proprietarization before GPLv2 was drafted, and, in contemporaneous and ongoing rhetoric, spoke clearly that he intended to preserve and advance users' right to repair their software by engaging in truly functional reinstallation of GPL'd binaries into the actual location.
• McCoy claims that FSF does not share Conservancy's position about installation under GPLv2. I've shown specific text written by FSF's Executive Director, which was also verified by FSF's legal counsel and FSF's Licensing and Compliance Manager as recently as May 2020 — wherein Conservancy and FSF are in full agreement. I can also further confirm that I spoke with John Sullivan on the telephone earlier this week, and he reconfirmed that he still agrees with the paragraph as written as correct policy for the situation.

Conclusion

I then quote my 2012 exchange with Stallman to point out clearly: the installation information definition in GPLv3 expands the requirements and does not reduce the existing installation requirements that we all saw as present in GPLv2 from its first publication in 1992. McCoy's article contains a simple logical fallacy: it assumes that since the installation information requirements in the GPLv3 are (in some respects) more expansive than those in GPLv2, that the requirement for installation information in GPLv2 are non-existent and/or are diminished merely through public discussion of GPLv3's policy goals by FSF during GPLv3's drafting. As I show above, it's clear that Stallman's rhetoric about extending installation information requirements in GPLv3 had complex additional policy goals that don't exist in GPLv2. Specifically, I don't think that GPLv2 reinstallation requires that all “merely aggregated” works continue to function as designed upon reinstallation of the GPLv2 works. Stallman has agreed with that GPLv2 interpretation, but differed from me regarding forward-looking policy (in that he finds such disabling of proprietary software deplorable) and thus Stallman wrote GPLv3 to prevent that practice that GPLv2 permits.

Furthermore, and most importantly, I quote the May 2020 recent exchange with Sullivan to point out that FSF policy regarding GPLv2 and installation has not wavered since FSF established it during Bob Chassell's time, which continued on into my time as FSF's Executive Director and then into Peter Brown's and John Sullivan's time, too. As I've shown, this interpretation of GPLv2 installation requirements is at least a 17-year unbroken chain from at May 2003 all the way through to May 2020. If Bob Chassell were still alive today, I'm sure he could account for that position remaining consistent in the 1990s, too.

There is also a central and inherent flaw in McCoy's underlying argument: the idea that FSF's view, or Linus' view, or any single individual's or organization's view, is what matters. The license says what it says. If the license steward has a view, it would not mean their view is dispositive, and I say that knowing that their view happens to agree with mine! Indeed, Linus Torvalds has stated he doesn't agree with FSF's views about GPLv2, and has his own views, which McCoy himself quotes. (I'm not sure why McCoy thinks that forwards his argument, because Linus' view differing from FSF undercuts McCoy's argument that what FSF said during GPLv3 drafting is relevant.) Other contributors to Linux disagree with both FSF's and Linus' view; many prominent Linux developers have told me that they agree with Conservancy and/or FSF about this. Others have told me they have an even broader interpretation of the installation requirements under GPLv2 than I do!

Thus, McCoy makes a classic “appeal to authority” fallacy as the center of his argument. Regardless of McCoy's mostly unsupported opinion, I suspect even he would agree that only three things will really definitively matter regarding this issue: (a) what the wronged party who didn't get their complete, corresponding source code believes, (b) what the entity refusing to give them that source code believes, and (c) what the Courts says when the former sues the latter. All else is simply bluster — full of sound and fury, but signifying nothing.

---

Finally, as a reminder, please keep in mind that (as I already said in the text above), I no longer have any affiliation with FSF (since October 2019) and do not speak for them — which is precisely why I quote the words they told me.

---

⁰ Please note that I have not personally looked into TiVo's GPL compliance since late 2003. As such, it's entirely possible that TiVo models released from 2004 onward may have violated GPLv2§3¶2 and failed to include required “scripts used to control compilation and installation of the executable”. However, any later non-compliance is not capitulation by me, FSF, Conservancy or anyone else that McCoy's and others' interpretation of that clause is correct.

¹Please be abundantly clear that even as I give an interpretation of what I happen to believe is correct at this given moment, I'm a flawed human being capable of error. (Also, IANAL and TINLA.) I can misspeak, misstate, and otherwise just be plain wrong about something one way or the other. This is also true of FSF, its representatives, and all the other pundits like McCoy Smith who opine on this question. One of the horrible “race to the bottom” traps that GPL violators constantly lay for us is unrelenting pressure that we choose between (a) reducing what we believe a given license requires, or (b) suing them to ask the Court to uphold our view. No one escapes that pressure cooker unscathed; nearly every pro-copyleft activist (including me) has fallen into this trap, and succumbed to the pressure of (a) at least once. I know, even as I write this footnote, that someday I'm going to have a GPL violator's lawyer quoting this blog post back to me in a deposition about some esoteric, “race to the bottom” issue of GPL compliance. They're going to look for a way to twist my words to argue that somehow I've given their client carte blanche to trample users' rights that GPL protects. Everyone who stands up for copyleft faces this constant challenge now that intentional GPL violations are the norm rather than the exception. Conservancy simply will not capitulate when standing up for users' rights to copy, share, modify, repair, reinstall and reinstall modified versions of their software on the devices they own.

[permalink]

Tags: conservancy, GPL, law, licensing