Insights on the reproducibility and future of free software with Chris Lamb
byon December 21, 2020
The Reproducible Builds project seeks to integrate a set of development practices into software which emphasize build reproducibility, or the ability to ensure that a given build process will lead to verifiably integrous binaries which correspond to their source code. Reproducibility is especially important in software that is used for sensitive applications or even by users living in repressive regimes under mortal danger – repressive governments, for example, may choose to introduce vulnerabilities into software used by dissidents to connect to the Internet by targeting pre-compiled binaries and build processes rather than source code. The project is working towards making many widely used pieces of free software reproducible, from its aims towards making (at the very least the packages of) several widely used distributions of GNU/Linux reproducible to achieving reproducibility for individual pieces of critical software like Tor and Tails.
The Reproducible Builds project has been a Conservancy member project since 2018. Chris Lamb, one of the project's core team members, took part in a remote interview with Vladimir Bejdo, a Conservancy intern, to talk about the Reproducible Builds project, his own participation in software freedom, the importance of reproducibility in software development practices, and to have a discussion about the issues facing free software as a whole today – while also thinking about what issues the free software community needs to focus on going into the future.
CL: Chris Lamb; VB: Vladimir Bejdo
VB: To start off with, it might be useful to first ask you this – how would you relate the importance of reproducibility to a user who is non-technical?
CL: I sometimes use the analogy of the food ‘supply chain’ to quickly relate our work to non-technical audiences. The multiple stages of how our food reaches our plates today (such as seeding, harvesting, picking, transportation, packaging, etc.) can loosely translate to how software actually ends up on our computers, particularly in the way that if any of the steps in the multi-stage food supply chain has an issue then it quickly becomes a serious problem.
For example, even if we could guarantee that only the most wholesome apples were picked in our orchards, if they became tainted on the way to the supermarket it will be a real problem for us at the end of the day. We may not even be able to even tell by simply inspecting our Pink Ladies or Honeycrisps, and washing them thoroughly under the tap may not be enough either.
In an ideal world, we would be able to personally inspect the provenance of our food at all of the stages of manufacturing and transportation. But at some point, we must place our trust in the process and in brands, as well as various regulatory bodies to ensure that potential problems in our food are minimized, possibly even paying a time/effort premium by growing our own or buying direct from local markets in order to minimize the number of steps, etc.
However, when we use free software we can do better: ‘Reproducible builds’ are a set of software development practices, ideas and tools that create an independently-verifiable path all the way from the original source code to what actually runs on our machines. Reproducible builds can reveal the injection of back-doors introduced by the hacking of developers’ own computers, build servers and package repositories, and also expose where volunteers or companies have been coerced into making changes via blackmail, court order, and so on.
With reproducible builds, there is no longer any need to trust any particular source of authority. In the same way that, say, a Mr Smith might check that his calculator is giving him the right answer to “2+2=4” by asking enough of his friends to check theirs too, users and developers of a reproducible build can verify the software they are using by creating a collective consensus instead.
VB: Tell me a bit about how you got into free software to begin with – was there a particular moment or experience you could relate back to which makes free software important to you and informed this project’s libre status?
CL: I was playing with various Linux distributions throughout my teens, but it was only much later when I got my first permanent internet connection that I seriously got free software, intrigued by its collaborative development style, charmed by its international community and finally won over by the feelings of mastery and autonomy it gave me over my own computers. Like many others, this was only enabled by the privilege of excessive free time at a state-subsidized university. However, I first learned about ‘reproducible builds’ many years later via some friends who had attended FOSDEM in 2015.
In many ways, reproducible builds cannot be anything other than a free/libre project. As you cannot even view the source code of almost all proprietary software, the end-user benefits of having a transparent software ‘supply chain’ outside of a free software context are consequently limited. The Reproducible Builds project also brings together a broad mix of communities, philosophies and competing motivations, making it a true entrepôt of software development – it is difficult to imagine such a diverse cross-section of interests collaborating and sharing knowledge in a proprietary software context.
VB: Were there any specific grievances or moments which drove the Reproducible Build’s project’s creation?
CL: Yes and no. The idea of reproducible builds has been continually rediscovered across many eras of computing, so there have actually been a number of important moments depending on your individual perspective and biases. For example, it was implemented for various GNU tools in the early 1990s and was a property in countless systems that existed before this. None of these earlier instances resulted in mainstream developer consciousness, and all the arguments tended to forefront technical, rather than security, concerns.
However, the recent surge in interest in reproducible builds can probably be attributed to the Bitcoin project around 2011, as users of the cryptocurrency needed a way to trust that they were not downloading corrupted software. This coincided with the “Snowden” disclosures of global surveillance in 2013 and the Tor browser began serious work in this area as a direct or indirect result. These successes and a growing wider concern around software integrity prompted Debian Developer Lunar Bobbio to cultivate a sub-project within the Debian project that quickly gained popular and — crucially — technical momentum.
VB: The Reproducible Builds project works specifically on making free software work securely for sensitive targets like dissidents living in repressive states, but its work obviously also helps secure projects that are used by other at-risk populations as well. How do you feel that free software philosophies align with the social good your project tries to help foster?
CL: The Reproducible Builds project aligns with a great many of the philosophies of the free software movement. Take, for example, freedom 2 from the FSF’s “Free Software Definition”, which demands the right “to redistribute copies so you can help your neighbor”. This is admittedly not a literal application of the text, but it is difficult to reconcile the underlying intent of “helping your neighbor” if you are unwittingly distributing software that contains back-doors, and the practices and ideas of reproducible builds are intended to dramatically minimize the risk of this occurring.
In a wider sense, the concept of Reproducible Builds aligns with the general desire for autonomy and transparency present that is present throughout the free software community. This is particularly apparent in the way that it does not require people to place their trust in centralized authorities and are instead empowered to come to decisions either by themselves or collectively in a bottom-up and consensus driven manner.
VB: How has the free software community taken up reproducibility and worked to integrate it into their own development practices? Can you share with us a short overview of how the project has grown over time, or some notable implementations of the practices behind reproducible builds?
CL: There have been countless integrations of the practices of reproducible builds across the free software community, from high-level tools such as photo editors, server components such as databases, all the way down to low-level system components such as the Linux kernel (spearheaded by Ben Hutchings). Thanks to the F-Droid project, we have gained some of the benefits reproducible builds on mobile devices as well, and in 2020 we are seeing a number of independently developed Covid-19 tracing application that support being built reproducibility too.
Another prominent success story is Tails. Tails is a security-focused Linux distribution aimed at preserving privacy and anonymity. For example, it uses Tor by default and leaves no digital footprint on the internet or on the machine itself, so is ideally suited for high-risk users who face targeted or aggressive surveillance. As a result, all its systems (and engineers) that contribute to Tails’ development and release are high-priority targets for compromise as a successful attack would provide access to a large number of vulnerable and high-value users.
After considerable effort, Tails now offers fully reproducible and verifiable images, helping to protect the users of Tails but also the developers that volunteer their time to the project.
VB: What do you feel are the greatest areas of need for free software projects to focus on today overall?
CL: One area we are lacking in free software is for more robust and critical analysis of the free software movement itself.
Without greater self-reflection, we are likely to be ineffective in our approaches to real-life problem solving, and may not be able to fully realize our shared vision of a better world. For example, we might fall short and only solving problems for people we can directly relate to: everywhere on Earth, there are countless moral and ethical decisions being made around technology today, but our solutions can easily exclude others, such as those that lack technical expertise as well as those with different priorities, cultures and economic backgrounds.
As part of this critical analysis, free software projects should also not be afraid to ask what the limits or the negative externalities of developing free software might be. Even the ‘ethical consumerism’ of open source software will be inherently constrained by its very nature, yet we rarely discuss what these constraints could be. Any potential issues within our collective movement can find themselves sidelined too. For example, the potential exploitation of an unpaid, volunteer labor force of open source maintainers is not widely addressed. We also see this in the conversations around the perceived unethical co-option of free software too, where the general discourse seldom rises above unserious trading over definitions. My point is not to provide my own position here or that the free software movement should even hold any position either, but given these issue’s potential impact it seems strange and possibly even dangerous to not be widely discussing these topics, if only to assure ourselves that we are on the right path.
Likewise, if we could refine our culture of robust critique we would also be able to improve our responses to the acute and systemic problems in our society as well. For example, we might be able to comprehensively and confidently address the many harmful effects of social networks, the consolidation of power in centralized content platforms, a pervasive surveillance culture, the relegation of human agency by artificial intelligence, the role of information technology in our healthcare, the erosion of our democracy and individual freedoms, not to mention reversing or even ameliorating the effects of catastrophic climate change. The assertion that free software can help all possible situations is inspiring to me, but this optimistic hypothesis remains mostly unsubstantiated. Indeed, to all of the urgent concerns listed above, the free software movement is not yet collectively articulating a coherent and clear answer, and we can often still come across as having the same conversations regarding the name of our movement and other embarrassingly unimportant matters. Saying that, the discourse in this area has definitely been maturing in the past year or so, particularly with regard to diversity, and I am also looking forward to reading a number of pending publications in this wider area.
Given that we don’t find some topics particularly comfortable, it is only natural that we don’t tend to discuss them widely. But it is of cardinal importance that we overcome this habit: without robust and forthright self-critique, free software may actually start to contribute to society’s problems instead of diminishing them. Indeed, the twentieth-century has repeatedly demonstrated that techno-utopian and accelerationist visions of the future can just as easily lead to dystopian outcomes over positive ones however well-meaning they were when they started.
To be clear, there is absolutely nothing inherently wrong with having more application sandboxes, discussions on the finer points of funding models or even more printer drivers, but prioritizing these discussions over others may be preventing the free software movement from being taken seriously in a wider context, as well as dramatically reducing our effectiveness in solving the very real problems in our real world.
VB: Closing thoughts – how could someone begin to get involved with the project? Any resources you would like to direct readers to, if they are interested in learning more about the project and about the driving ideas behind it?
CL: If you are interested in contributing to the Reproducible Builds project, the first thing to do is connect with our community, either via our IRC channel (#reproducible-builds on irc.oftc.net) or on our mailing list.
You can also please visit the Contribute page, discover more technical details on the rest of our website, particularly via our many presentations and monthly news reports. You can also follow us on Twitter via @ReproBuilds.
Software Freedom Conservancy is in the middle of its annual fundraiser. Please help us continue our work by becoming a Supporter. Donate now and have your donation matched by a group of generous individuals who care deeply about software freedom.
Ethical Employment Contracts Instead of Ethical Licenses?
byon December 17, 2020
Earlier in the year at Copyleft Conf, we had a few sessions dedicated to the Ethical License movement. During the conference, Coraline Ada Ehmke gave a moving talk outlining why technologists and software freedom activists in particular must act against atrocities, especially those committed using FOSS. I have long argued that technologists (and especially software freedom activists) should dedicate more care and resources to the ethical use of technology and eliminating discrimination and oppression that technology often enables. While I don't believe software licenses are the best way to accomplish this task, I've wondered since the conference what FOSS contributors can do to protect human rights.
The proposed licenses have been essential to starting these discussions, but the license changes themselves seem unlikely to work: they'd introduce nonfree provisions, introduce license uncertainty and on top of that, we know that companies that would commit atrocities will ignore licenses and act from judgement-proof jurisdictions. So the question is how best to influence the behavior of companies who can improve their human rights record and how to insulate employees who want to take action to assure that their companies do the right thing.
Through our ContractPatch initiative, Conservancy has been working to educate developers about employment contracts. We plan to eventually draft suggested contract language to help developers negotiate their employment contracts. While ContractPatch has moved slower than I would have liked (due to our prioritization of other urgent work), the initiative has shared good information, primarily via our talks and blogposts. I've been gratified to hear from folks that they've actually been able to negotiate better terms into their employment agreements as a result! Some have told us that they've succeeded in retaining their FOSS copyrights. Others have simply negotiated a better salary, as ContractPatch information improved their negotiation skills generally.
In the context of human rights, where FOSS licenses are unlikely to achieve the desired result, perhaps contractual demands by developers can succeed. I propose here a simple “contract patch” that can more successfully leverage developers' power in the market to prevent human rights abuses due to software.
Employees of all sorts face a difficult dilemma upon discovering unethical practices at their company. If the activity is already in advanced stages and/or the profit amounts generated from the practice are high, the employee's predicament becomes even more precarious. Should they report it to their manager or their manager's manager? If those managers all know about the activity already, will a complaint even be taken seriously? Often, the employee will have signed documents upon employment committing them to confidentiality, so the employee has little choice except to decide whether to quit or not but otherwise remain silent. For matters that concern the safety and well being of human beings, the stakes are much higher. Yet, employees have even fewer choices to ameliorate the situation. While most companies have whistle blower policies, the fallout of corporate politics can leave employees powerless.
What if those employees knew exactly how to handle the situation? What if the steps to escalate this situation were spelled out in advance? What if the employee were truly assured non-retaliation for reporting the situation? What if the employee were guaranteed a soft landing if they felt they needed to quit their job when the company took no action? In other words, what if these details appeared in their employment agreement and the employee knew they could rely on it from day one of their employment?
Amending Employment Contracts
With this in mind, we can draft a clause for employment contracts. Should an employee come to know that the company is committing violations of human rights, their employment agreement can specify the ways they can raise attention to this matter. Perhaps they first report the violation to their manager. If there is no satisfactory response or repair of the situation within a certain period of time, then the employee is to report the violation their manager's manager. If again there is no satisfactory response or action, the employee is to report the violation to the head of the department. If in that instance there is again no satisfactory response or action, the employee may post the violation on an internal mailing list or posting board. If again no action is taken, the employee may choose to terminate their employment and receive a pre-agreed severance amount — similar to the “golden parachute” provisions that executives have in their contracts. The company would also promise no retaliation against the employee for reporting the violation, including a non-disparagement provision that prevents the company from speaking negatively about an employee who opts for the severance. Each company could tailor the reporting chain to match what would make the most sense with their corporate structure. Nothing in the provision would undermine the company's confidentiality provisions with the employee, but the employee would have confidence in raising an alarm and also be able to quit while having a cushion to be able to look for another job.
Like most ContractPatch proposals, these approaches works best when the clause becomes standard. Companies are more likely to agree to these terms if many developers who interview ask for it.
This is a relatively simple solution — a good set of ContractPatch terms and a collective bargaining demand around it — is an outcome that companies can actually accept when the terms are reasonable. It protects the company's confidentiality and incentivizes employees to bring to management's attention problematic practices that the companies should have an interest in knowing about. Additionally, while the company and employee may disagree about the human rights implications of a problematic behavior, the ultimate negative result of the provision's operations is that the employee leaves the company, with a small, pre-agreed and easily budgeted financial settlement. In the case the employee is simply wrong about the alleged human rights violation, a voluntary exit is an obvious benefit to both parties. However, if multiple employees exercise this contract clause, the company then has a strong incentive to cease the violations, both financially and operationally. Alone one employee may not effectuate change, but standing together employees can have a powerful voice. Adding contract provisions like this one work within the existing corporate structure but amplify the impact that employees can have.
While I've focused my example on human rights violations, the provision could also cover endangering public health and safety or substantially violating the law.
Employment contracts often have provisions where the employee represents that they will obey laws and act ethically in the position. Here's an example of this kind of language I've seen in a contract:
Employee will act in an honest and ethical manner in compliance with all applicable laws … and comply with the policies, procedures, requirements, rules, and regulations promulgated at any time and as amended or supplemented from time to time by Employer … including Employer’s policies on sexual harassment …
Employment agreements are already the correct venue for these expectations. We can build on provisions like this to introduce the one I'm proposing here. The language itself could look like this:
“Human Rights Laws”) is defined as the United Nations Universal Declaration of Human Rights and any other applicable laws protecting the rights inherent to all human beings, regardless of race, sex, nationality, ethnicity, language, religion, or any other status.
An “Unethical Action” is defined as an action by Company that violates Human Rights Laws, excluding actions Company has taken against the Employee individually.
An “Adequate Response” is defined as a written response that (a) explains why there has been no Unethical Action, or (b) provides notice that the Unethical Action has ceased.
A “Planning Response” is defined as a written response that sets forth a plan to cease the Unethical Action.
Company shall act in an honest and ethical manner in compliance with all Human Rights Laws.
In the case that Employee becomes aware of any Unethical Action, Employee will report such action to their manager in writing as soon as is reasonably practicable. If Employee's manager does not provide an Adequate Response or a Planning Response within two weeks, Employee will send the report to their [FIXME - manager's manager/department head]. If [FIXME-title] does not provide an Adequate Response or a Planning Response within two weeks, Employee may report the Unethical Action via [FIXME - whatever relevant internal company-wide dissemination makes sense, whether it be an email list, posting board] (“Company Notice&Rdquo;). Employee may also provide a Company Notice in the case that the Employee has received a Planning Response but no Adequate Response is received within the period set forth for repair in the Planning Response. If the Employee receives no Adequate Response or Planning Response to a Company Notice within two weeks, Employee may terminate their employment and receive an amount equal to the greater of (i) twelve (12) weeks severance pay or (ii) twice the amount required by any relevant applicable law or statute. Company will not retaliate, intimidate or harass any Employee who reports an Unethical Action. If Employee's employment is terminated for any reason after Employee first reported the Unethical Action, Employee shall receive an amount equal to twelve (12) weeks severance pay. Nothing in this provision contradicts, supersedes or diminishes Section [FIXME-CONFIDENTIALITY] of this agreement. However, if Employee terminates their employment pursuant to this provision, Company will not engage in any disparagement of the professional or personal life of the Employee.
This text is a first draft and edits and suggestions are welcome on the Contract Patch mailing list .
No software developer expects to encounter human rights violations or unlawful activity using software when they take a new job. But history shows that it will and does happen; Coraline's talk is an excellent list of known examples. Introducing new clauses into employment contracts is a practical way to align the interest of all parties, while providing simple mechanisms to raise attention to and end problematic behavior. Developers usually have more bargaining power than most workers. Let's use that to make sure we compel our employers to behave ethically and provide us the safety to stop providing them with our services if they don't!
 While I'm a lawyer and many of the people who have worked on ContractPatch are lawyers, Conservancy doesn't provide legal advice and so ContractPatch isn't meant as legal advice. Please use the language as a starting point or as an example for you to work on with your own lawyer to figure out what works for your situation.
Software Freedom Conservancy is in the middle of its annual fundraiser. Please help us continue our work by becoming a Supporter. Donate now and have your donation matched by a group of generous individuals who care deeply about software freedom.
17 USC § 1201, DMCA Exemptions and Software Freedom
byon December 16, 2020
We at Conservancy spent much in the last week preparing our Long Comments in our DMCA exemptions requests for this round. When we announced these exemption filings, many of our Supporters asked us to “back up and explain” what this whole process is and why Conservancy participates. These are excellent questions and so we provide below a simple explanation of the DMCA exemption process, why it exists, and why FOSS-friendly organizations like us chose to participate in what is ultimately a flawed process.
The provisions of the DMCA were designed to support DRM with the power of civil (and in some cases, criminal) law. Media companies, seeing that digital distribution of content would likely become the standard, sought an iron grip on their business models and gain absolute control of their copyrighted works — making it effectively impossible for FOSS to exist for reading books, watching movies, or listening to podcasts or music. The law is morally wrong because it it seeks to criminalize publication of some software techniques and knowledge, and, moreover, the law creates “chilling effects” for everyone in the USA who might consider writing FOSS that is on the edges of such the law's technological restrictions. We saw just in the last few months how organizations like the RIAA can use the DMCA to harm FOSS projects. Since the law has been enacted, DRM has become ubiquitous. Those who write FOSS that even comes near the job of circumventing DRM live in fear.
The dangers of such regulation are obvious to most FOSS activists and technologists. However, to people less savvy about technology, the purported “compromise” struck in the DMCA can seem perfectly reasonable. 17 USC § 1201 prohibits “circumvention [of] technological measures” put in place to stop acts that were otherwise illegal. To those not well versed in copyright policy, this would of course seem no different than other updates to laws for the digital area — such as assuring existing crimes in real life were also crimes when committed over the Internet. For those of us who understand technology and software, the compromise is not reasonable; DMCA made a digital action a crime that had never been a crime when done in analog — publishing technological know-how to improve and repair devices that we own. The DMCA ultimately gave carte blanche and the force of law to ubiquitous DRM.
The main part of the statute that accomplishes this is 17 USC § 1201(a)(1)(A). Ostensibly, §1201(a)(1)(B-C) provide limitations that rein (A) back. Take a read
of these sections and then follow along here in parallel. (A) uniformly forbids “circumvention of” a DRM measure implemented by a copyright holder. (B) tells us that we, the public,
can come forward once every three years to to identify technological measures we
should have the right to circumvent. If we can prove (per (C)), that
there are legitimate non-infringing activities that we could imagine
engaging in by circumventing the technology restrictions and we can convince the
Copyright Office that those circumventions would indeed
legitimately aid in non-infringing uses of the DRM'd copyrighted works, then — and only then —
circumvent a technological measure that effectively controls access to a work. That's the basics of the
For a more detailed understand of how the process works, there are three videos from the Copyright Office:
- A Legal Overview of § 1201 (PDF slides only).
- The Triennial Rulemaking Process for §1201 (PDF slides only).
- Streamlined Petitions for Renewed Exemptions (PDF slides only).
Basic Overview of 17 USC §1201
- First, §1201 is primarily concerned with so-called “Technological Protection Measures” (generally abbreviated “TPM” in DMCA policy circles). A TPM is defined broadly to include any access control, including scrambling, encryption, password protection and the like.
- §1201 prohibits circumvention of a TPM implemented for access controls to a copyrighted work.
- §1201 prohibits dissemination of information (both commercially and non-commercially) that explains how to circumvent a TPM put in place for either access controls, or copy prevention of work. (The statute and the Copyright Office use the pro-DRM term, “trafficking”, for such activity. We use the term “dissemination” to avoid supporting that propaganda.) If you've heard us and others talk about how the DMCA squelches Free Speech (or are familiar with the phrase “chilling effects” that we activists have argued are produced by DMCA's mere existence), this is the part of §1201 that relates to those issues.
- Exemptions to these rules exist. The law itself has some permanent exemptions, listed in §1201(d-j). These permanent exemptions are useful but certainly don't permit unbridled development of FOSS software that might be considered a circumvention technique.
- All other exemptions are temporary. The exemption process happens every three years — hence the term “Triennial Rulemaking”. There is a rulemaking process occurring right now, and here's a summary of how that works:
The Triennial Rulemaking Process
- A temporary exemption is only granted for uses of copyrighted works that are otherwise non-infringing (i.e., only §1201 restrictions cause infringement, and there must be no infringement due to any other part of the copyright act).
- The Copyright Office Exemptions are never permitted to the “dissemination prohibitions”, only for use and access. (Only Congress can change anything regarding actual dissemination of circumvention techniques. This is particularly troubling for many reasons, including that the WCT, the international treaty that DMCA intended to implement, only mandated the access control issue, and does not speak to dissemination of general circumvention information. Most DMCA-like laws in other countries are not as strict. But in the USA, there is simply no way to get an exemption for dissemination of circumvention techniques — other than lobbying for legislative change.)
- Exemption applicants must show that there is current adverse impact due to TPMs for the public regarding the non-infringing uses that the exemption would allow. (Alternatively, the applicant, may show that there will be such adverse impact within three years.)
- Hypothetical and theoretical arguments are not accepted. Applicants must show that specific people will (or soon will) suffer adverse effects when unable to engage in real-world non-infringing uses that are directly prevented by a specific TPM and that circumvention would enable those non-infringing uses to resume and/or continue.
- The Rulemaking process itself proceeds as follows:
- The Office issues an NPM, which is the standard method by which any Administrative Branch agency announces a process where new rules will be made.
- Round1: Petitioners make an initial filing to indicate that they'll apply for an exemption and its primary impetus. These are short, and were filed on 2020-09-08 for the 2021 Rulemaking.
- Petitioners and others can then make supportive public comments. Those are what were due on Monday (2020-12-14) for the 2021 Rulemaking. (We'll have follow up blog posts about our filings throughout this week and next.)
- Round 2: opponents may file objections and disagreements. We'll of course expect to see lots of software-freedom-unfriendly vendors making arguments against our filings during that period, and we'll point our blog readers to any filed in opposition of our exemption requests.
- Round 3: reply comments from the Petitioners (and neutral comments from others) are allowed.
- Finally, Round 4: public hearings occur, which are optional. Conservancy participated in the public hearings in the 2015 year Rulemaking when we successfully requested the exemption for “smart” TVs.
- Note, finally, that there is an expedited process for renewal of temporary exemptions, which Conservancy also participated in for the TV exemption originally granted in 2015 and renewed in 2018.
For many activist organizations, the question often becomes whether to participate in or boycott this process. The process places the burden on underfunded activist organizations to make a case just to permit what are ultimately extremely narrow areas of activity. (Remember that the Copyright Office's position is that exemptions are never granted for circumvention dissemination, only access, so the temporary exemptions are both narrowed in that scope and narrowed to specific types of devices or activities.) Conservancy, like EFF, used to be among those who boycotted this process. Reforms — which were sought by CDT, EFF, Public Knowledge, Public Labs, and other organizations — in recent years have improved the process, but it remains time-consuming and painful. However, given that there is no viable political will or path to seek repeal of the DMCA, we're stuck with this process. Just as copyleft is designed to utilize the general copyright system — which most FOSS activists (at least) find problematic or (in many cases) oppose outright — we must similarly work, with regard to this specific part of the Copyright Act, within the system to find our way through. Conservancy has focused our filings in the process on those areas that most directly impact software freedom, and we look forward to telling you more about them this week.
Meanwhile, the dangers we face from the parts of the DMCA that cannot receive exemptions are real. People have been put in prison for “trafficking” under this statue; a company can, as Adobe did, simply phone the FBI to get someone arrested. Companies like Sony can drag in the Feds into civil cases to apply pressure for demand of unreasonable settlements. As long as we live in a regime willing to tolerate this kind of policy, we have to make use of the process we have to improve the odds that FOSS developers and researchers don't face both civil and criminal penalties.
Public Drafting Process for the DMCA Cooperation Pledge
byon November 30, 2020
In my blog post two weeks ago, I proposed — in light of increased DMCA takedowns against FOSS projects (and relatedly, increased enforcement of 17USC§1201) — that we ask for-profit copyright holders to agree to a pledge similar to GPLv3§8¶3. Simply put, proprietary copyright holders should be equally as reasonable as GPL copyright holders are and give FOSS projects 30 days to negotiate and discuss copyright infringement allegations before triggering a de-facto injuction with the DMCA.
I admit that I thought it unlikely that any for-profit companies would even be willing to discuss the possibility of making such a pledge; my proposal was more thought experiment than actual policy. I was however pleasantly surprised to receive positive feedback from at least four companies as well as interest from another non-profit organization who is excited about the idea.
After both internal discussion and external discussion with these parties, we feel that now that the project has moved from thought experiment to real potential policy, that we should move the discussion public. It's just in our DNA at Conservancy to act transparently and welcome stakeholders into public discourse about policies. Moreover, these sorts of industry pledges and assurances have historically been drafted in secrecy by a few companies and then put forward as a fait accompli to the FOSS community. We'd like to change that tendency in this process.
Today, we created a Git repository and a mailing list for this project. We welcome anyone interested in the proposal of this pledge to join the mailing list and propose a patchset or just generally write up suggestions. Folks participating need not and do not in our view bind their company to the pledge; rather, we're looking for wide input on what the text needs to say to make it most likely that organizations will agree to the pledge.