Copyleft Won't Solve All Problems, Just Some of Them
byon 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.
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.
If Software is My Copilot, Who Programmed My Software?
byon 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.
What’s the Worse That Could Happen?
[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.
Trained Models, Fair Use, and Copyright Infringement
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.
Copilot Users Should Worry
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.
On Copyleft Maximalism and Unilateral Capitulation
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.
A Community-Led Response
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.
Open Letter to Biden: Cybersecurity for FOSS needs copyleft and consumers' right to repair
byon 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.
Bradley M. Kuhn
Policy Fellow, Software Freedom Conservancy
Matcher Interview - Tony Sebro
byon January 3, 2022
The second of our series of interviews with donors, we have another longtime Software Freedom Conservancy supporter (and former employee!) Tony Sebro. Tony recently served as Deputy and Interim General Counsel to the Wikimedia Foundation and is now General Counsel at Change.org. We "sat down" with him to talk a bit about us and what he's excited about right now.
Software Freedom Conservancy: “Why do you care about software freedom?”
Tony Sebro: “For one, I am inspired by people dedicating their time, creative energy, and technical talents to the public interest. I am also impressed by what they produce: FOSS communities have created some of the most important, innovative, and irreplaceable products that societies rely on. ”
SFC: “What do you appreciate about Software Freedom Conservancy?”
TS: “I appreciate that Conservancy supports the creation of ethical technology from multiple vantage points. Conservancy supports FOSS developer communities through services, education, and mentorship. Conservancy supports end users by defending their rights. And, Conservancy advocates for groups underrepresented in technology by providing them with gateways into FOSS communities -- which, in turn, infuses these communities with fresh talent.”
SFC: “What's got you most excited from the past year of our work?”
TS: “While I am intrigued to see what happens with the lawsuit against Vizio, I am most excited by Outreachy's continued growth, as evidenced by the record number of interns admitted into the December 2021 cohort. I admit, I'm biased. :) ”
SFC: “you think we are doing a good job reaching a wider audience and do you see us at places you expect?”
TS: “I got a good chuckle out of seeing Karen and Bradley pop up in this recent NFT project.”
SFC: “What other (non-tech) organizations are you supporting this year?”
TS: “My wife and I support other charities, as well as our local church.”
SFC: “You were Software Freedom Conservancy's second employee! What are your thoughts about how the organization has changed and grown since the beginning of your involvement in the organization?”
TS: “Conservancy has grown in virtually every direction! More projects; more commentary and scholarship. Greater investment in diversity, equity, and inclusion. Conservancy has also expanded into providing resources to educate tech employees about their employment rights.”
SFC: “Until recently, you were Deputy General Counsel at Wikimedia. Did the principles of software freedom impact your work there?”
TS: “Certainly! Free knowledge isn't just freely-licensed content, it should also be freely consumed. The Wikimedia Foundation hosts Wikipedia and its other free knowledge projects on a FOSS stack. The public can inspect the code, and can trust that Wikimedia isn't hiding anything that would bias or pervert the editorial decisions of the communities who maintain the project content Wikimedia hosts.”
SFC: “As a former employee, a member of the board of directors and as an organizer of Outreachy you've participated in many facets of Software Freedom Conservancy and have such a unique perspective. What are you most proud of? What do you think the organization should do in the future?”
TS: “I enjoyed providing advice and counsel to the various member projects -- getting to understand their specific cultures and needs. Outreachy continues to have a special place in my heart. That said: my favorite part of working at Conservancy was the deep conversations about ideology and strategy that I'd have with Karen, Bradley, and Denver. The team cares deeply about the work they do, and their passion for the mission was and is infectious.”
SFC: “Congratulations on starting your role at change.org! What can we look forward to seeing you work on there?”
TS: “Change.org's mission is to empower individuals to make a difference, and more than 450 million people use the platform to amplify their voice. I am leading the Legal & Policy department, which includes the organization's legal, trust and safety, platform policy and public policy functions.”
Next page (older) » « Previous page (newer)
1 2 3  5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62