Copyleft Won't Solve All Problems, Just Some of Them

by Bradley M. Kuhn on March 17, 2022

Toward a Broad Ethical Software Licensing Coalition

We are passionate about and dedicated to the cause of software freedom and rights because proprietary software harmfully takes control of and agency in software away from users. In 2014, we started talking about FOSS as fundamental to “ethical software” (and, more broadly “ethical technology”) — which contrasts FOSS with the unethical behavior that Big Tech carries out with proprietary software. Some FOSS critics (circa 2018) coined the phrase “ethical source” — which outlined a new approach to these issues — based on the assumption that software freedom activists were inherently complicit in the bad behavior of Big Tech and other bad actors since the inception of FOSS. These folks argue that copyleft — the only form of software licensing that makes any effort to place ethical and moral requirements on FOSS redistributors/reusers — has fundamentally ignored the larger problems of society such as human rights abuses and unbridled capitalism. They propose new copyleft-like licenses, which, rather than focusing on the requirement of disclosure of source code, they instead use the mechanisms of copyleft to mandate behaviors in areas of ethics generally unrelated to software. For example, the Hippocratic License molds a copyleft clause into a generalized mechanism for imposing a more comprehensive moral code on software redistributors/re-users. In essence, they argue that copylefted software (such as software under the GPL) is unethical software. This criticism of copyleft reached crescendo in the last three weeks as pundits began to criticize FOSS licenses for failing to prohibit Putin from potentially using FOSS in his Ukrainian invasion or other bad acts.

We have in the past avoided a comprehensive written response to the so-called “ethical source” arguments — lest our response create acrimony with an adjacent community of activists who mean well and with whom we share some goals, but with whose strategies (and conclusions about our behavior and motivations) we disagree. Nevertheless, the recent events have shown that a single, comprehensive response would help clarify our position on a matter of active, heated public debate and fully answer these ongoing criticism of FOSS and our software freedom principles.

The primary criticism is that FOSS licensing over-prioritizes the rights of software freedom above substantially more important rights and causes — such as sanctions against war criminals. This rhetoric implies that software freedom activists have “tunnel vision” about the relatively minor issue of the rights to copy, modify, redistribute and reinstall software while we ignore bigger societal problems. This essay gives a comprehensive explanation of the specific reasons why copyleft avoids the “scope creep” of handling moral and ethical issues that relate only tangentially to software — even though those moral issues are indeed more urgent and dire than the moral issue of software freedom.

Software Freedom Isn't The Most Important Human Right

I personally, and many of my colleagues, have been admittedly imperfect advocates for software freedom. For the last thirty years, Big Tech and their allies have unfortunately successfully convinced the public that rights for users to control their own software are unimportant, and even trivial. (Apple has even successfully convinced their biggest fans that Apple's ironclad device lock-down is in your interest as a consumer.) In that climate, software freedom activists often overcompensated for the tech community's trivialization of software rights — specifically, overstating the relative importance of software freedom when compared to other human rights. Our error left a political vulnerability, allowing the opposition to successfully even further trivialize users' rights. Critics capitalized on this miscommunication, and often claim that FOSS activists believe that software freedom is the most important human right. Of course, none of us believe that.

I suspect most software freedom activists agree with me on the following: while I do believe software freedom should be a human right, I don't believe that our society should urgently pursue universal software freedom at the expense of upholding the many other essential rights (such as those listed in the Universal Declaration of Human Rights). Clearly many other rights are more fundamental. In a society that fails to guarantee those fundamental human rights, software freedom (by itself) is virtually useless. Those who would violate the most basic human rights will simply ignore the issue of software freedom, too. Or, even worse, such bad actors will gladly use any software, flagrantly in violation of any license, to bolster their efforts to violate other human rights.

Software freedom as a general cause becomes essential and relevant when a society has already reached a minimal level of justice. Indeed, I've spent much of my career as a software rights activist considering whether I should instead work on a more urgent cause — such as ending human trafficking, animal rights, or remedying climate change. Personally, the only valid moral justification for my personal focus on software freedom instead of those other rights is four-fold: (a) there is an increasingly limited number of qualified people who are willing to work on software freedom as a charitable cause at all, (b) there is an increasing number of talented people who are actively working to create more proprietary software and seeking to thwart software freedom and copyleft, (c) my personal talents are in the area of software production and authorship, not in areas directly applicable to other causes, and (d) an increasingly digitized society mean software rights slowly increase in importance as an “enabler right” to defend and protect other rights (just as Free Speech enables activists to expose (and hopefully prevent) atrocities and their cover-ups). In other words, I am unlikely to make any useful impact on any other cause in my whole career, whereas due to the unique match of my skills to the cause of software freedom, I have made measurable positive impact on software rights. I generally encourage activists to focus on tasks that directly coincide with their existing talents, and have tried to do the same myself.

So my argument starts in fervent agreement with the first point made by proponents of adding non-software ethical issues into copyleft licensing: yes, I absolutely agree there are social justice causes that are more urgent than the right to copy, modify, redistribute and reinstall software. That begs their question: then, why not immediately begin using all the tools, mechanisms and strategies used for FOSS advocacy to advocate for these other causes? The TL;DR answer is simple: because these tools, mechanisms and strategies are highly unlikely to have any measurable impact on those other causes, while using them for these other causes would ultimately minimize software freedom and rights unjustly.

Indeed, we need to make progress on the issue of software freedom, precisely because even while others are working to address and redress these other social justice issues, proprietary software (such as through proprietary AI-based advertising software that manipulates public opinion) is currently used to undermine these other causes. Universal software freedom would thwart Big Tech's efforts to undermine other causes. Proprietarization of software isn't the most heinous human rights violation possible; nevertheless, proprietarization of software does assist companies to do harm regarding other social justice causes. I conclude from that realization that our society should seek to make progress on both upholding the existing human rights already listed in the Universal Declaration on Human Rights, and also seek to make simultaneous progress on key rights not listed there, such as software freedom. We also err as activists if one group of activists seeks to thwart another by falsely claiming the other group is “complicit in human rights abuses” merely due to a strategic disagreement.

Ultimately, copyleft (and other FOSS licensing) is a strategy, not a moral principle unto itself. The moral principle is that proprietary software is harmful to people because it forbids their right to control their own software, learn how it works, and remove spyware from it (among many other ills). That moral principle remains valuable and deserves some of our collective attention, even if there are other more urgent moral principles that deserve even more attention.

Copyleft Is The Worst Strategy, Except for all the Others

So, if the production of proprietary software harms society, then why not focus all efforts on lobbying legislators to make proprietary software illegal? This should be the first question any new software freedom activist asks themselves. After all, for those of us who live in societies with relatively minimal corruption and that are governed by the rule of law, we should seek to make criminal those acts that harm others.

Criminalizing proprietary software has always been, and remains, politically unviable. We should constantly reevaluate that political viability (which software freedom activists have done throughout the last three decades). But as of the time of writing, this strategy remains unviable, primarily due to the worldwide domination of incumbent unbridled capitalism and a near universal poor understanding of the harm that proprietary software causes and enables.

Another possible approach to ending proprietary software is a universal boycott on authorship of proprietary software (perhaps through mass unionization of software developers). This is one of my favorite “thought experiments”, as it shows how much power individual software developers have regarding proprietary software. However, this universal boycott is also politically unviable, at least as long as proprietary software companies continue to pay such exorbitant salaries relative to other fields of endeavor.

So, if we can't make proprietary software illegal, and we can't dissuade developers from taking piles of money to write proprietary software, what's the next best strategy? The answer is to organize people to write alternative software that is not proprietary. This was the strategy that the software freedom movement pursued in earnest beginning in the early 1980s, and currently remains our best politically viable strategy. However, this approach always contained a fundamental problem: such software can easily be used as a basis for proprietary software. Thus non-copylefted FOSS competes against itself, rather hopelessly, since the proprietary version will likely always be a feature or two ahead, and the FOSS version a bug or two behind. Copyleft is the innovative strategy designed specifically to address that specific problem. Without copyleft, the only possible approach to answering the harm of proprietary software is the aforementioned general strike of all software development, since non-copyleft FOSS can be and is regularly used as a basis for advancing proprietary software and Big Tech's interests.

Copyleft generally works reasonably well as a strategy, but it admittedly requires constant vigilance. Copyleft needs someone to enforce it, and resources to do that. Copyleft must withstand the pressure of proprietary software companies who seek to erode and question its validity. The primary conceit of those who seek to use a copyleft-style strategy to address other software-tangential social injustices is their apparent belief that merely writing policy into a software license has any chance of changing behavior on its own. It simply doesn't.

Other Mechanisms Are More Effective If Politically Viable

The Hippocratic License and similar efforts have a laudable goal: they seek to assure that companies who deal in software always respect human rights. However, advocacy for universally recognized human rights, as a social justice cause, does have access to better advocacy mechanisms that software freedom activism does not.

Most notably, almost everything listed in the Universal Declaration of Human Rights is illegal in the USA and in most other industrialized nations where the bulk of software development occurs. Also, it is certainly politically viable to improve those laws — for those rare cases where a violation of a particular universally recognized human right is legal. In short, because these other rights are much more widely accepted as fundamental by the public, we can employ other, better means (including those listed above that don't work for FOSS) to compel compliance by companies with these other principles.

Furthermore, copyleft is ill-suited as a mechanism to enforce any rights in places where human rights violations are common. For example, no one has ever bothered to enforce copyleft licenses in jurisdictions where corruption is rampant and the judiciary is easily bribed. Over the last twenty years, we've received many reports of GPL violations in the Russian Federation, but we don't pursue them — not because they shouldn't be addressed, but because, under Putin's regime, it's highly unlikely we can get a fair hearing to uphold software freedom and rights for Russian citizens. Copyleft relies on a well-formed rule-of-law for contracts and copyright to protect people's rights (of any kind). In jurisdictions that already hold human life and the rights of its people in low regard (or simply have an exceedingly corrupt government), it's a pointless symbolic act to also take away the permissions of software redistribution and modification for bad behavior (of any kind). Companies and oligarchs operating in a corrupt, unjust society will successfully ignore those injunctions, too.

Meanwhile, in jurisdictions with relatively less corruption, other systems besides distribution licenses function well to curtail bad behavior. For example, I've owned exactly two cars in my life here in the USA. While I concede there are many problems with corruption here, we have a relatively just society that usually respects the rule of law for contracts and copyrights. The cars that I purchased here did not have a license that said: if you drive dangerously with the vehicle, you cannot purchase and utilize cars in the future from that manufacturer. We don't look to the car manufacturers to enforce the ethical use of vehicles; we instead make traffic laws, with various escalating penalties, including a driver licensing structure that can be revoked temporarily or permanently for egregious acts. We don't require manufacturers to contract with drivers to pollute less; we instead create and enforce environmental regulation and incentives both before and after the time of purchase. Because such systems exist and because there is widespread societal consensus about what is or is not ethical driving behavior, there is no point in enforcing these rules using copyright and contracts that bind the vehicle's purchaser. A more resilient system (of traffic and environmental laws, and their enforcement) works to deal with the problem, and improving those laws is politically viable. Additional licensing terms from the car manufacturers (imposed at the point of sale of vehicles) would create a useless redundancy, since the penalties and remedies available under that license are substantially less severe than those available under the laws that regulate drivers.

There are strategies other than licensing changes that would likely work well to both build a stronger coalition for software freedom and rights and curtail the atrocities committed by Big Tech and their customers. These strategies might become political viable, and are worth pursuing in parallel and in coalition. For example, widespread unionization of tech workers (not over wages, which are generally high, but over other issues, such as bad behavior and policy by their employers) could both improve companies' respect of software freedom and handle many problems raised by those who seek tangential expansion of copyleft into non-software issues. For our part, Software Freedom Conservancy has done some work in this area by encouraging developers to begin insisting on better terms in their employment contracts. I do worry that a functioning coalition on these matters is exceedingly difficult to build (and the very fact this essay ultimately became necessary hints at the difficulty in building that coalition). We'd be glad to work in coalition with such activists to further those causes if they include software freedom as an issue that belongs on the coalition's agenda.

But that's a long-term, speculative action. Meanwhile, for software freedom, copyleft is the best-available compromise strategy — since software rights are not and cannot be defended in a more robust way (such as through direct legislation, as opposed to indirectly relying on the copyright and contract legal systems to assure the rights). Copyleft is a round-about strategy. Using copyleft as a strategy to impact broader ills that have more effective mechanisms to address those ills is (at the very least) wasted time and (possibly) downright counter-productive.

Copyleft Focuses On Coalition

In our increasingly politically divided society, omnibus social justice reform has always been exceedingly difficult. Copyleft works precisely because it holds together a very thin coalition — by confining the issues to only those that happen with software.

Consider this example: I became a vegetarian in 1992. It does bother me that software that I've written could potentially assist a slaughterhouse to run more efficiently. I obviously have considered licensing my software under terms that would forbid use in a slaughterhouse (and a dozen other activities that I personal morally oppose, including for the waging of war). However, hand-picking my most important social justice causes and stringing a copyleft clause on them would dissolve a rather thinly-held coalition of copyleft proponents. Successful advocacy for a given cause relies on building broad coalitions among people with widely disparate views on other topics. Imagine how difficult activism on climate change would be if activists working to end human trafficking claimed that activists working to address climate change were complicit in human trafficking because The Paris Climate Agreement does not include penalties if participating nation-states fail to meet benchmarks on reducing human trafficking. Coalition building is complex. Context matters.

In a diverse political ecosystem, elegant solutions that work “ok” often fare better than comprehensive-but-complex solutions. Copyleft's innovation is that the only action you can take that revokes your right to copy, modify, redistribute and reinstall the software is failure to give that same right to someone else. This elegance makes the copyleft strategy powerful and effective. “Porting” the copyleft strategy to other causes may seem that it would yield “more of a good thing”. But, in practice, that approach turns copyleft licenses into complex omnibus legislation around which coalitions will evaporate.

Relatedly, the most difficult hurdle of copyleft has always been the creation of software that was so enticingly useful that political opponents (i.e., proprietary software companies) would gladly give users the rights to copy, modify, and reinstall the software — in direct exchange for having the benefit of building their new software on top of the existing copylefted components (rather than rewriting it themselves). I do not see a viable path to create the necessary coalition that would, after agreeing on an omnibus list of social justice issues, also find the funding and volunteer labor necessary to build software (under that license) that would entice those who currently work against that list of social justice causes to stop working against those causes merely because they'd gain so much more from the software than they gain from violating the principles. Copylefted software in a vacuum, adopted only by other copyleft activists does not change behavior of bad actors. For example, imagine if we wrote into our licenses that all who copy, modify and distribute the software must cease use of fossil fuels. That's an important cause, but it's hard to imagine our software would be so useful that companies would accelerate their reduction of fossil fuel use merely to gain immediate the permission to copy, modify and redistribute that software.

Copyleft Requires Constant Vigilance

Copyleft isn't magic pixie dust that liberates software. In fact, likely one of the biggest flaws in copyleft design has been a gross underestimation of resources required for enforcement in the scenario we now have. Broad adoption of key copylefted components remains an important step to curtail proprietary software developers' mistreatment of users. The situation slowly improves as such developers incorporate copylefted software like Linux into their essential computing systems — provided that is done so in compliance with the license. However, violations on essential GPL'd components such as Linux and GCC are rampant and limited funding is available to resolve these violations and restore users' rights in the software. Big Tech has also been relentless and highly creative in thwarting our enforcement efforts.

Thus, even if not for my earlier strategic reasons that I oppose adding ethical-but-software-unrelated restrictions to FOSS licenses, I'd still oppose it on tactical grounds. Namely, there is no clear funding path whereby additional terms seeking to protect and advance software-tangential social justice causes could be adequately enforced to make a measurable difference in advancement of those causes.

FOSS Must Still Have a Conscience on Non-Software Issues

This essay merely argues that FOSS licenses are not an effective tool to advance social justice causes other than software freedom. It does not argue that FOSS communities have no duties to other causes and issues; in fact, they do have such a moral obligation. For example, FOSS developers should refuse to work specifically on bug reports from companies who don't pay their workers a living wage. I also recommend that FOSS communities create (alongside their Codes of Conduct for behavior inside the project), written rules of the types of entities that the projects will officially assist with volunteer labor, or (in the case of a commercial FOSS community or organization), what types of entities the community will engage in business deals.

At Software Freedom Conservancy, we regularly discuss at both the staff and Board of Directors level what other social justice issues that we have a moral obligation to incorporate. Most notably, we've been the home for Outreachy, a program our own Executive Director, Karen Sandler, helped create, and for which we are glad to have Sage Sharp on staff to work on full-time. We know that FOSS lags behind proprietary software development in welcoming and providing opportunities for underrepresented groups. We dedicate significant organizational resources on these issues through Outreachy and other newer programs (such as the Institute for Computing Research). We made a public statement that Trump's travel ban directly thwarted FOSS. We go beyond the mere legal requirements to create ethical and equitable hiring practices that are without bias. In defending the rights of users under copyleft, we do not leave other issues behind. I believe that the critics have simply not paid attention to, or are willfully ignoring, the holistic and intersectional approach that we have brought to FOSS.

Regarding Putin's FOSS Permissions Upon Invasion of Ukraine

Initially, only a few FOSS critics insisted on this radical change to copyleft licensing structure. The issue had fallen into the far background of our community — until the last few weeks. Specifically, many recently began asking whether we should redraft FOSS licenses to impose sanctions on Putin in retaliation for his violent and unprovoked invasion of Ukraine. Admittedly, FOSS licenses do not prevent Putin from incorporating existing FOSS already in his possession into his war machine. I personally have been a conscientious objector to all military action since 1990, so I am sympathetic. I have always felt the OSI's framing the discussion of military use of FOSS as a “field of use restriction” misses the point; it inappropriately analogizes software to physical materiel, and analogizes those who write FOSS to de-facto military contractors. Software, fundamentally, is the written word; while it “feels” like more than that to us, factually speaking, software is merely a written record of knowledge, methods, and instructions for how to solve digital problems. It is disturbing that the plans for heinous acts can sometimes be modeled as digital problems, and that some of those problems may be solvable with existing FOSS. But we must curtail and punish actual actions, not knowledge nor writing, nor the unfettered sharing of generally useful technical information. Particularly in cyber-warfare circles, some folks tend to talk about software as we did during the days when sharing encryption software was banned: as if certain software is more like bombs than books. I don't think we should concede that rhetoric; all software remains much more like books than it is like bombs.

Even if we choose to not take away the right to read from the Russian people, that does not mean that FOSS activists concede that nothing can be done. Our nations can, should, and many currently do, forbid commerce with Russia during this period. This can and should include embargoes of selling new books, new copies of software, providing services for improvements to software, and any other commercial activities that could inadvertently aid Putin's war effort. Every FOSS license in existence permits capricious distribution; software freedom guarantees the right to refuse to distribute new versions of the software. (i.e., Copyleft does not require that you publish all your software on the Internet for everyone, or that you give equal access to everyone — rather, it merely requires that those whom you chose to give legitimate access to the software also receive CCS). FOSS projects should thus avoid providing Putin easy access to updates to their FOSS. Indeed, FOSS licenses planned well for how to manage bad actors who want your software: all FOSS licensing authorities have upheld the right to capricious distribution — precisely so that the license would not compel any developer to provide software to a bad actor.

I suspect activists will continue to disagree about whether we have a moral imperative to change FOSS licenses themselves to contractually forbid Putin to copy, modify, redistribute and reinstall the FOSS he already has (or surreptitiously downloaded by circumventing sanctions). However, these horrendous events in Ukraine offer real world examples to consider the viability of expanding copyleft term expansion beyond software, and consider how it might work. My analysis is that such changes would only give us the false sense of having “done something”. Ultimately enforcement of such licensing changes would either be impossible or pointless. The very entities (such as the varied international courts and treaty organizations) that could enforce such terms will also have plenty of other war crimes and sanctions violations to bring against Putin and his cronies anyway. The penalties for the actions of war that Putin took will be much stronger than Putin's contractual breach or copyright infringement claim that could be brought under a modified copyleft license and/or the Hippocratic License.

Conclusion

Copyleft licensing is a powerful strategy. As a strategy, copyleft has both its upsides and downsides in its ability to advance the software freedom and rights of users. However, the proverbial hammer of copyleft will not help you when your problem is more like a screw than a nail. Having already dedicated my entire career to advance the copyleft strategy, I do feel honored that folks who care deeply (as I do) about other important social justice causes are seeking to apply that strategy to new types of problems. However, despite my lifelong love and excitement for copyleft, and perhaps because of it, it's my duty to point out that copyleft is not a panacea for all that ills our troubled world.

Copyleft works because it's the best strategy we have for software freedom, and because copyleft elegantly confines itself to the software rights of users. Attempts to apply the copyleft strategy to software-unrelated causes will (at the very least) fail to achieve the intended results, and at their worst, will primarily serve to trivialize the important issue of software freedom that copyleft was invented to accentuate.

[permalink]

Tags: conservancy, GPL, security, law

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

"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