![[RSS]](/static/img/feed-icon-14x14.2168a573d0d4.png){kind=icon}
Conservancy BlogDisplaying posts
by Bradley M. Kühn
by on February 3, 2022
Software freedom is our goal. Copyleft is a strategy to reach that goal. That tenet is oft forgotten by activists. Copyleft is even abused to advance proprietary goals. We too often see concern about the future of copyleft overshadow the necessary fundamental question: does a particular behavior or trend — and the inevitable outcomes of those behaviors and trends — increase or decrease users’ rights to copy, share, modify, and reinstall modified versions of their software? That question remains paramount as we face new challenges.
Introduced first by Microsoft’s GitHub in their Copilot product, computer-assisted software authorship by way of machine learning models presents a formidable challenge to software freedom’s future. Yet, we can, in fact, imagine a software freedom utopia that embodies this technology. Imagine that all software authors have access to the global archive of machine learning models — and they are fullly reproducible. Everyone has equal rights to fork these models, train them further with their own datasets, provided that they must release new models (and the input code) freely in the global archive. All code produced by these models is also made freely available under copyleft. All code that builds the models, all historical input sets, and all trained models are all also made available to everyone under copyleft licenses.
While activists might quibble about minor details to optimize imagined utopia, this thought experiment shows computer-assisted software authorship does not inherently negate software freedom. Rather, the rules, requirements, and policies that apply will determine whether software freedom is respected. To paraphrase Hamlet: there is nothing either good or bad, but the policy makes it so.
[They are] not a good [person] who, without a protest, allows wrong to be committed … with the means which [they] help to supply.
— John Stewart Mill, University of St. Andrews, 1 February 1867
Obviously, ignoring machine learning for computer-assisted software authorship will not usher in this software freedom utopia. Copyleft activists cannot stand idly by in this situation, but we must temper our attention by considering the likelihood of dystopian and problematic outcomes, and the options available to prevent them.
In response to Copilot’s announcement, pundits speculated, without evidence, a prevailing feeling of “Free Software had a good run, but I guess that’s over now”. Such predictions seem consistent with the well-documented overoptimism of artificial intelligence success. Rapid replacement of traditional software development methodologies seem unlikely. As such, we should not overestimate the likelihood that these new systems will both accelerate proprietary software development, while we simultaneously fail to prevent copylefted software from enabling that activity. The former may not come to pass, so we should not unduly fret about the latter, lest we misdirect resources. In short, AI is usually slow-moving, and produces incremental change far more often than it produces radical change. The problem is thus not imminent nor the damage irreversible. However, we must respond deliberately with all due celerity — and begin that work immediately.
Currently, there are two factors that influence the timing of our response. First, if GitHub’s Copilot becomes a non-beta product available to the programming public, that would indicate necessity of an urgent response. Microsoft and GitHub are unlikely to share their product plans, so we cannot know for sure when this will occur. However, in the seven months since the first beta was made available, we’ve consistently heard anecdotally that more and more developers (particularly, FOSS developers!) have received beta invitations. Based on these (admittedly incomplete) facts, we must assume that a move from private beta to public deployment is imminent in 2022. This indicates some urgency of the problem.
Second, we already know that some of our worst fears are definitely true. Namely, that Microsoft and GitHub used copylefted software as part of Copilot’s training set.
Copilot was trained on “billions of lines of public code … written by others”. While GitHub has refused requests to release even a list of repositories included in the training set, the use of the word “public” indicates that only software with source-available licenses (even if not FOSS licenses) were input into Copilot. Furthermore, GitHub admits that during training, the system encountered a copy of the GPL more than 700,000 times. This effectively confirms that copylefted public code appears in the training set.
When questioned, former GNOME developer and GitHub CEO0, Nat Friedman, declared publicly “(1) training ML systems on public data is fair use (2) the output belongs to the operator”. Friedman himself, as well as Microsoft and GitHub’s other executives and lawyers, have ignored Software Freedom Conservancy’s requests for clarification and/or evidence supporting these statements.
Meanwhile, GitHub continues to improve this system, trained only on publicly source-available software, and seeks to market it to new users, including those who otherwise use FOSS development tools. Users continue to report gaining access to the beta and are noticing improvements. Microsoft and GitHub’s public position is meanwhile clear: they claim to have no copyleft obligations for training the model, the model itself, and deploying the service. They also believe there are no licensing obligations for the output.
While Friedman ignored the community’s requests publicly, we inquired privately with Friedman0 and other Microsoft and GitHub representatives in June 2021, asking for solid legal references for GitHub’s public legal positions of (1) and (2) above. They provided none, and reiterated, without evidence, that they believed the model does not contain copies of the software, and output produced by Copilot can be licensed under any license. We further asked if there are no licensing concerns on either side, why did Microsoft not also train the system on their large proprietary codebases such as Office? They had no immediate answer. Microsoft and GitHub promised to get back to us, but have not.
This secrecy and non-cooperativeness is expected from a proprietary software company and its subsidiary, but leaves us only with speculative conclusions to inform a strategy for copyleft here. We can reliably guess that the companies will claim “fair use” as their primary justification for creating the model and offering the service, and will argue that both the output and the trained model are not “work[s] based on the Program” (GPLv2) nor do they “copy from or adapt all or part of the work[s] in a fashion requiring copyright permission” (GPLv3/AGPLv3). Furthermore, we can reliably conclude, given the continuing product promotion, that the companies have at least a medium-term commitment to Copilot.
In short, they have already hunkered down for a protracted disagreement. Their positions are now incumbent — using their resources and power to successfully charge copyleft activists to “prove them wrong”. But we do not have to accept their unsubstantiated arguments at face value. In fact, these areas are so substantially novel that almost every issue has no definitive answers, but we must nevertheless begin to formulate our position and our response to Microsoft and GitHub’s assault on copyleft.
Consider GitHub’s claim that “training ML systems on public data is fair use”. We have not found any case of note — at least in the USA — that truly contemplates that question. The only legal case in the USA to look near this question is Authors Guild v. Google, Inc., 804 F.3d 202 (2d Cir. 2015). The Supreme Court denied certiorari on this case; it is not legal precedent in all jurisdictions where Microsoft and GitHub operate.
Even more, that case considered a fact pattern centered around search, not authorship of new/derived works. Google had made copies of entire copyrighted books, not for the purpose of displaying them, but so users could (1) run search queries, and (2) see a “snippet” of the search hits (i.e., to see the search hit in context). The Second Circuit held Google’s copying of the books was “fair use” because searching and providing context added value exceeding what a user could obtain from their own copies, and Google’s product did not substitute the market for the books.
The analogous fact pattern for code is obvious: GitHub could offer a search tool that assists users in finding key public repositories (and specific lines of code within those repositories) that seemed to solve tasks of interest. Developers could then easily utilitize those codebases in the usual, license-compliant ways. The actual Copilot fact pattern is not this one.
Meanwhile, the Authors Guild case begins and ends the list of major cases regarding machine learning systems and “fair use”. We should simply ignore GitHub’s risible claim that the “fair use question” on machine learning is settled.
Perhaps most importantly, in the USA, “fair use” is an affirmative defense to answer copyright infringement. In concrete terms, that means — particularly in cases where the circumstances are novel — a copyright holder brings an infringement lawsuit and then the alleged infringer shows in court that their actions met the relevant factors for “fair use” sufficiently. Frankly, we refuse to do these companies’ job for them. Copyleft activists need not tell Microsoft and GitHub why this isn’t “fair use”, rather, they need to tell us why training the model with copylefted code is “fair use” and prove that the trained model itself is not a “work based on” the GPL’d software.
GitHub has meanwhile artfully avoided the question of whether the trained model is a “work based on” the input. We contend that it probably is. However, given that “fair use” is an affirmative defense to copyright infringement, they are obviously anticipating a claim that the trained model is, in fact, a “work based on” the inputs to the model. Why else would they even bring up “fair use”, rather than simply say their use is fully non-infringing? Anyway, we have no way to even explore these questions authoritatively without examining the model, fully affixed in its tangible medium. We don’t expect GitHub to produce that unless compelled by a third party.
Indeed, discussion of these questions outside of a courtroom is moot. For this novel and contentious fact pattern, only a court decision can settle the matter adequately. As a strategic matter, copyleft activists should keep their own counsel about what we anticipate in the opposition’s “fair use” and/or non-infringement defenses, and the counter-arguments that we plan.
GitHub’s position does a great disservice to Copilot users. Their claim that “the output belongs to the operator” creates a false sense of legal justification. Users have already shown that Copilot can generate a substantial amount of unique, GPL’d code, and then (rather ironically, given GitHub’s claim that they removed the text of the GPL from the training set) also suggest a license that is non-copyleft. Friedman’s statement surely does not qualify as an indemnity for Copilot users who might face GPL enforcement actions. Users almost surely must construct their own “fair use” or “not copyrightable” defenses for Copilot’s output.
The length and detail of what Copilot can generate for users seems unbounded. The glaring example above appears primia facie to be copyright infringement; we expect further such problems. Consider the sheer amount that a fully functional and successful Copilot would generate. Surely, AI researchers seek the ability for Copilot to “figure out” that you are trying to solve some specific task when programming. The better Copilot gets at handing ready-made solutions to its users, the more likely it becomes that its output may offer the user copylefted software.
Copilot leaves copyleft compliance as an exercise for the user. Users likely face growing liability that only increases as Copilot improves. Users currently have no methods besides serendipity and educated guesses to know whether Copilot’s output is copyrighted by someone else. Proprietary software companies such as Synopsys provide so-called “scanning tools” — that can search your proprietary codebase and find hidden copylefted software. However, the FOSS tools for that job are in their infancy and unlikely to develop quickly, since historically those who want those tools are companies that primarily develop proprietary software and seek to avoid copylefted software.
We recommend users who wish to avoid infringing the copyrights of others simply avoid Copilot.
Draconian copyright law generally horrifies software freedom activists for good reason. Nearly all copyleft activists would prefer a true, multilateral rewriting of copyright rules that prioritized the interest of the general public and software rights. Copyleft exists primarily because of the long-standing political non-viability of a copyright law reboot. Nothing has changed in this regard; if anything, changing legislation has become an even more expensive lobbying proposition than it was at copyleft’s advent. Copyleft activists should expect, indefinitely, for proprietary software companies and media oligarchs to control copyright legislation.
Fortunately, copyleft was designed specifically for this eventuality. Activists have called copyleft the “judo move” of software freedom, since copyleft uses the powerful copyright force (invented primarily by our opposition) against itself. That realization leads to a painful, but pragmatically necessary, awkwardness.
The issues herein — from training of machine learning models, to the copyright questions about those models, to the derivation questions about their output — are novel copyright questions. As software freedom activists, we are uniquely qualified to invent an ideal copyright structure for these technologies. But, without a path to promulgate such replacement copyright rules into the incumbent system, that exercise is futile. Furthermore, systems outside of copyright — including but not limited to EULAs, business agreements and patents — have long been used to proprietarize software without the need of copyright. Reality of facts on the ground dictate that we not concede the only wedge we have to compel software freedom; that wedge is copyleft.
Meanwhile, proprietary software companies regularly exploit any unilateral concessions on weakening of copyleft that FOSS projects make, while continuing to pursue copyright maximalism for their works. Particularly in novel areas, we must assume a copyleft maximalist approach — until courts or the legislature disarm all mechanisms to control users’ rights with regard to software. That adversarial process will frustrate us, but ultimately by choosing copyright as our primary tool, we already chose the courts as our battleground for contentious issues.
We all surely have our opinions about how copyleft should operate in these novel situations. We have even expressed some such opinions herein. But, ultimately, strong copyleft licenses do not defer the “what’s covered?” question to one individual or organization. The “judo” power comes from strong copyleft reaching to all of what copyright governs. When those issues are novel — and companies flaunt that novel manipulation of copylefted works — only a court can answer definitively.
While these companies will likely not succeed in their efforts to disarm copyleft, they have nevertheless attacked the entire copyleft infrastructure. We must mount an effective response.
Software Freedom Conservancy has spent the last six months in deep internal discussions about this novel threat to the very efficacy of copyleft. We have a few ideas — a mix of short-term, medium-term and long-term strategies to address the problem. However, we recognize that a community (rather than the traditional BDFL) approach is needed — at least for this problem. Thus, putting first things first, we realized that we should gather the best minds in the software freedom community with direct experience in copyleft theory and practice. We will convene these individuals to a committee specifically chartered by Software Freedom Conservancy to — as quickly as reasonably possible – publish a series of recommendations to the community on how we should respond to both the immediate threat to copyleft found in Copilot, and (long-term) analyze the more general threat that AI-assisted programming techniques pose to the strategy of copyleft.
While we are not actively seeking applications for this committee, we do welcome anyone whom we have not yet solicited to participate to contact us and inquire. We will surely be unable to include everyone who is interested on the committee — either due to Conflicts of Interest or due to simple logistics of creating too large a committee. However, we will carefully consider anyone who expresses bona fide interest to participate.
Finally, as much as can be done during the pandemic using FOSS tools available, we will attempt to convene public discussions as much as possible. We will contemporaneously publish the committee’s minutes publicly. If you’d like to get involved today in public discussions about this issue, please join the mailing we launched today for this topic.
0In November 2021, Nat Friedman was replaced by Thomas Dohmke as GitHub’s CEO. However, to our knowledge, Dohmke has not retracted or clarified Friedman's comments, and at the time of writing, no one from GitHub or Microsoft that we spoke to had responded to our requests for clarification.
by on February 1, 2022
Inspired by the log4j situation, The White House recently met with Big Tech on the issue of security vulnerabilities in FOSS used in the nation's infrastructure. While we are glad these issues have received attention at the highest levels of the administration, we are concerned that representation in these discussions is skewed. Hobbyists, and communities organized around public interest and consumer rights, who both use and develop a large portion of FOSS, were not represented. Additionally, the entities represented at the meeting were biased toward copyleft-unfriendly organizations. Unsurprisingly, these entities focused on Software Bill of Materials (SBOM) as a panacea for the problem of FOSS security. While SBOMs are a useful small step toward hardening the nation's software infrastructure, we believe the proper solution is to favor copylefted FOSS.
Consumers must have access to source code, the right to modify and reinstall it (or hire anyone they'd like in the free market to do so). Without these rights, businesses, individuals, and the government — all of whom rely on software as part of their critical infrastructure — cannot identify and repair security vulnerabilities. Furthermore, the widespread incorporation of non-copyleft FOSS, which companies can and do proprietarize, creates a false sense of security — as many users may not realize that “FOSS inside” (as listed on their SBOM) does not mean the software is any better than proprietary software.
Our open letter to the White House which addresses our concerns is included in full below, and is also available as a PDF:
Dear President Biden, Deputy Advisor Neuberger, Director Inglis, et al:
Firstly, we appreciate very much that your administration has taken the issue of the log4j software vulnerability so seriously, and also appreciated President Obama’s efforts to take the OpenSSL vulnerability (so-called “HeartBleed”) seriously during his administration. While we at the Software Freedom Conservancy believe deeply that Free and Open Source Software (FOSS) is a better and more reliable method to develop software, we also readily acknowledge that no method of software development is perfect. (Flaws can and do occur.) However, sound planning — which includes meaningful investment in infrastructure — will not only limit potential vulnerabilities, but is also essential to respond to them adequately when they do inevitably occur.
As you likely agree, our nation’s infrastructure and national security — both of which increasingly depend on software — demand this type of care and attention. While we are pleased that your administration has taken some basic steps to focus on this critical issue, we send this open letter to request necessary improvements to the current methodology that your administration is using to address the issue of software security vulnerabilities in FOSS. In short, your administration has taken a great first step — one which the for-profit software industry has embraced — but we have deep concerns. We expect the powerful technology industry to resist the mandatory steps necessary to ensure the security of FOSS. This is due to the basic fact that the necessary changes mean that companies and their shareholders will have to live with more modest profits if your administration demands the necessary changes to ensure cybersecurity for FOSS.
Your meeting earlier this month included some important entities, but unfortunately was biased in one specific direction. Specifically, we observed that the meeting only included representatives from companies and organizations that prefer a specific form of FOSS — the form of FOSS that allows entities to change the software into their own proprietary technology. Roughly speaking, there are two forms of FOSS: non-copylefted FOSS, which allows vendors to take the publicly available software and make trade-secret changes; and copylefted FOSS, which — by contrast — is licensed in a manner that requires full disclosure of all source code (and the necessary means to repair vulnerabilities in that software) to customers. Non-copyleft FOSS has a fatal flaw: it can easily be incorporated into a proprietary product — including with modifications that may introduce vulnerabilities. Vendors can keep all details about those changes secret from everyone — including their customers and the government. Furthermore, a company may disclose that the software is based on a particular FOSS project, which perpetuates a false sense of security. Consumers will often assume that since it’s labeled as FOSS, that the key benefits of FOSS de-facto apply — such as easily auditing the software themselves (or hire an third-party firm) to examine the software for vulnerabilities and/or repair discovered vulnerabilities. However, if that FOSS is not under a copyleft license, there are no such guarantees. Imagine what can happen when a vendor goes out of business while the customer (who could be the federal government itself) still relies on that software for essential infrastructure.
As one of the leading organizations dedicated to FOSS, we believe it is extremely important to share our expertise at this critical moment. We reiterate our sincere appreciation for your administration’s interest and promulgation of Software Bill Of Materials requirements. On the surface, this is a small step in the right direction. We fear, however, that, without meaningful and informed improvements, it merely serves as camouflage and creates a false sense of security. A simple list of software included will give only vague clues as to how to repair vulnerabilities of a vendor’s software. No existing SBOM formats actually require full disclosure of software source code — nor means for its modification — to the customers who receive, use, and rely on it. Having an SBOM for your non-copylefted, proprietary software is like having a list of parts that you know are under the hood of your car, but discovering that the manufacturer has welded the hood shut, and forced you to sign an agreement that they could sue you for millions of dollars if you attempt to open it. The car may look safe and secure from the outside, but there is no way to know if the car is safe, reliable and, maintainable.
We are pleased to note that many software companies do chose to use copyleft licenses responsibly and provide the necessary source code; they serve as model citizens for other companies. Interestingly, the early positive revolution of FOSS in the software industry occurred precisely because copylefted FOSS was originally the more common form of FOSS; companies who seek higher profits and control of their customers have campaigned to limit the amount of copylefted FOSS developed. The history behind this is politically intriguing and not unique to FOSS. We see tech companies wielding power in problematic ways in other areas, too. Specifically, they have spent the last few decades pressuring hobbyist creators and small businesses to abandon copyleft licenses. As a result, non-copylefted FOSS is much more commonplace now than ever before (and the reason why this is such a critical issue). We at the Software Freedom Conservancy urge your administration to carefully consider the larger context of software cybersecurity—particularly as it relates to FOSS. We also offer up our guidance and expertise, and hope you will make room for additional seats at the table as you continue discussions and make decisions of this magnitude.
At the White House Meeting on Software Security on January 13, 2022, Big Tech was well-represented, and even overrepresented since it primarily included companies that are considered anti-copyleft. (Indeed, some Microsoft executives in the past have even called copyleft licensing “against the American Way” and a “cancer” on the software industry.) Yet, it is common knowledge in the technology sector that key components of our nation’s software infrastructure, such as Linux and the GNU Compiler Collection, were initially written by hobbyists and activists under copyleft licenses. Hobbyists and activists, who are the founders of FOSS, deserve a seat at the table—alongside Big Tech companies and their trade associations—as you continue to discuss these important national cybersecurity issues. The Software Freedom Conservancy is proud to serve and and give a voice to these hobbyist and activities, and we are also willing to recommend other organizations, academics, and individuals if you feel we’re not an ideal fit but nevertheless do want to diversify your committees on FOSS cybersecurity.
More generally, we ask that your administration reconsider how it solicits advice on these matters from technologists, and that you not succumb to the monoculture of opinion and manufactured consent from large technology companies and their trade associations. We appreciate that in other areas, your administration has valued inclusivity and actively seeks input from experts who disagree with the status quo. We believe you are truly interested in working on meaningful solutions to this critical issue facing our nation, and thank you for your consideration of our points raised in this letter.
Sincerely,
Bradley M. Kuhn
Policy Fellow, Software Freedom Conservancy
by on December 28, 2021
Yesterday afternoon, we filed a Motion for Remand in our lawsuit against Vizio for their flagrant GPL & LGPL violations, alleged with great detail in our complaint in California state court. Vizio's response to that complaint was to “remove” the case to federal court. Vizio argues that the lawsuit can only be brought by a copyright holder as a copyright infringement lawsuit in federal court. In response, we have asked the federal court to return (“remand”) the case to state court.
While Vizio's original request to “remove” the case from state court to federal court is, in the general sense, a standard litigation tactic and our response is a relatively standard response (on which we expect to prevail), the implications of these early procedural maneuvers deserve special attention for those of you that care deeply about copyleft as a strategy to achieve software freedom and rights. If you seek a deeper understanding of these essential issues in copyleft policy, we encourage you to first read our motion to remand, and then read this article as supplemental strategic context for that filing.
Many of our longstanding Sustainers will recall that we previously have enforced the GPL for BusyBox in federal court. As part of that large lawsuit against 14 defendants, we learned how the process of copyright-only GPL enforcement works in US federal court. We still believe that federal litigation brought by copyright holders is an essential component of copyleft enforcement.
But many lawyers have advised us that contract law is a useful parallel avenue. This approach has the advantage of empowering users of the software who are not necessarily copyright holders. The mantra of “the GPL is not a contract” is a mistruth that has been so often repeated that it became widely accepted and typically unchallenged. (We expect you'll hear this theory repeated even more loudly now that the our Vizio lawsuit brought the question to the forefront in a federal court case.) Yet, prominent legal experts outside of FOSS social circles have long scoffed at the assertion. Indeed, case law in the USA has held the opposite. In multiple cases, courts have been convinced, specifically, that the GPL operates as both a contract and a copyright license. The law appears clear on this, and this is among the reasons why we believe our motion to remand will succeed. In short, we'll say it plainly here and now for everyone: the GPL operates both as a copyright license and as a contract; litigation can proceed under either of those legal theories. Our motion to remand in the Vizio case explains the legal details as to why that's true.
While this seems a minor matter of legal detail, it stems from the longstanding and fundamental principles of copyleft itself. Specifically, the point of copyleft was not to further empower copyright holders. As early as 2001, I and other copyleft proponents already argued publicly that copyleft was a method for software authors to unilaterally disarm the inappropriate power held by copyright holders when they created software. Like the Constitutional Bill of Rights in the USA (which exercised government power by guaranteeing each citizen's rights), the GPL allows software authors to exercise their power in choosing a license to grant rights to all software users. Those users deserve the right to seek redress when companies impugn their rights. In short, the GPL was designed as a tool for software authors to exercise their default power of licensing control to benefit the general public (instead of only themselves).
Accordingly, this legal diversification of claims is not only a tactical matter. It's not an esoteric debate; it drives to the very heart of copyleft's policy goals. Our Vizio case is landmark GPL litigation because, in addition to seeking the source code for our immediate use to create alternative firmwares, the lawsuit trailblazes a path for consumers to assert their software right to repair. If the entire case is ultimately successful, we will have shown that individual users who purchase a device and wish to repair the copylefted software in it have a fundamental legal right to take action on their own to seek redress from the court.
Further, our claim in this lawsuit asks for what lawyers call specific performance. CCS for a specific product has unique value that cannot be replaced by awarding monetary damages instead. Once ordered to specifically perform, the vendor has no choice but to produce the CCS for all copylefted software. Our lawsuit focuses on this remedy under contract law because it is the most relevant to the policy aims of the GPL. In short, money is no substitute for CCS, and we plan to explain why to the Court as the case continues.
Nevertheless, copyright litigation under GPL also remains an important tool, and we expect that we'll work with our lawyers to bring copyright claims again in the future — when that's the best tool to do the job that needs to be done. However, we believe a consumer-led enforcement strategy (which doesn't require holding copyrights) empowers users in a fundamental way and is consistent with GPL's original policy goals. As it stands today, we receive regular reports from individuals who request source code for GPL'd devices, only to have companies ignore them — unless and until a copyright holder assists them. We provide that assistance when we can, but realistically we can't commit to provide such assistance for every copyleft violation in the world. Companies (at their peril) rely on the false notion that they need only fear a copyright holders' accusation of copyleft non-compliance. We seek to change these anti-patterns — starting with our lawsuit against Vizio.
The Vizio lawsuit may take years to complete, but we are confident that we'll win this first skirmish. We believe the remedy we seek — that Vizio acknowledge their obligations under relevant copyleft licenses and release the CCS — is reasonable and achievable. While we pursue that remedy, we know that not everyone will have the time or inclination to study every move in this lawsuit. If you don't have the time to do that, we thank you now for the trust you've shown by donating to our organization to support this work. We assure you that we take the public trust of our charitable mission very seriously and will focus this work, including our litigation, to benefit the general public. However, if you have the time and inclination, we again commit ourselves to transparency and updates like this one to explain to you the nuances and important fundamental issues of strategy that inform our every decision in our copyleft enforcement work. We believe in the power of copyleft to bring consumers a meaningful right to software repair, and we believe in upholding that right under the full scrutiny of that same public.
We thank all of you so much for your support of our work, and the many encouraging emails that so many of you have sent us about this Vizio lawsuit. While I always hate to ask for money, I'd be remiss if I didn't note that your donations helped us get to this point, and I ask that you take a moment to become a sustainer during our match donation period, which ends soon.
by on October 21, 2021
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.