It Matters Who Owns Your Copylefted Copyrights

by Bradley M. Kuhn on June 30, 2021

Throughout the history of Free and Open Source software (FOSS), copyright assignment has simultaneously been controversial and accepted as the norm in our FOSS communities. This paradox, I believe, stems entirely from some key misunderstandings that perpetuate. This issue requires urgent discussion, as two of the most important FOSS projects in history (GCC and glibc) are right now considering substantial and swift changes to long-standing copyright policies that date back to the 1980s. This event, and other recent events over the last few years in the area of GPL compliance and corporate FOSS adoption, point to long-term problems for projects. This essay works through these nuances, and will hopefully assist FOSS contributors as they make difficult decisions about copyright ownership for their projects. At the end, I provide a summary list of issues to consider when creating copyright ownership policies for FOSS.

The Default Is: You Give It Away To Your Boss

I was at one time bemused, but now am mostly aghast, at the true paradox of common wisdom about copyright assignment for FOSS projects. I don't believe anyone has done a statistically valid study, but anecdotally it's rare to find a FOSS contributor who enjoys assigning copyright to another entity. FOSS contributors who do assign copyright to a non-profit charity that collects copyrights (such as the FSF or Conservancy) often complain about the complexity and annoyance of the paperwork to get started as a contributor. Even more commonly, contributors express disgust or annoyance at the pressure from the project to give away something that should be rightfully theirs.

I am sympathetic on both points, and have worked over my career to design, implement, and improve copyright assignment processes for projects — in hopes to address that first complaint. However, the second concern — the preference of FOSS contributors to keep their own copyrights, is an ironic complaint. Here's why:

Almost no contributors to larger FOSS projects hold their own copyrights. If they have not gone through a process to assign them to a charity, the most likely scenario is that their employers own those copyrights. My colleagues at Conservancy have been working on the Contract Patch project — which seeks to educate FOSS contributors about their inherent right to employment agreement negotiation, and seek more favorable terms in those employment contracts. However, over the years of our Contract Patch work, we still find that only dozens (among the thousands of FOSS contributors) have insisted that their company allow them to keep their own copyrights. If you work for a company, check your employment agreement. I'll bet that your employer owns your copyrights for everything you do at work — including your contributions to FOSS — unless there's a separate agreement that gives those copyrights to a charity like Conservancy or FSF.

As a result, in debates about copyright ownership, discussions of what policy contributors want regarding the fruits of their labor is sadly moot. Without a clear, organized mitigation strategy to assure that FOSS contributors keep their own copyrights, a project (such as GCC or glibc) that switches from a standing “(nearly) all copyrights assigned to a charity” model to a plain Developer Certificate of Origin (DCO) or naked inbound=outbound contributor arrangement will, after a period of years, mostly likely have copyrights that are primarily held by the employers of the most prolific contributors, rather than by the contributors themselves.

The Faustian bargain that causes this default is the “work-for-hire” doctrine in the USA (and similar arrangements that exist around the world). When you take a job, in most places in the world, by default, your employer owns and/or effectively controls all your copyrights. They argue that they're paying you handsomely for this and as such they have every right to own it all. Perhaps that argument has merit with regard to software that will ultimately be proprietarized, but for copylefted software, the value proposition is different and history shows that the arrangement leads to surprising results.

Copyleft Is Weakened When Most Copyright Holders Oppose Enforcement

Copyleft licenses are not magic pixie dust. Copyleft is not a legislatively-mandated regulation (e.g., pollution regulations) — which are enforced by government staff. Ultimately, an entity — most commonly the copyright holders themselves — must proactively enforce GPL. This entity can be an organization, an individual, a group of individuals, a group of organizations, or a mix of all of those. Someone must enforce the rules; so-called “spontaneous compliance” is a myth promulgated by those who oppose copyleft.

Yet that myth's apparent unexamined truthiness has taken hold; many FOSS contributors reasonably think that it does not matter who owns the copyright of their copylefted works. If it's GPL'd, they surmise, surely someone out there will enforce the GPL when it's violated. Or, perhaps the contributors think that GPL violations on their particular codebase are rare. Either way, most contributors avoid the effort required to figure out who owns their copyrights and ponder whether that entity will uphold copyleft in a reasonable way. Nevertheless, I really urge FOSS contributors to think through this issue with care and healthy skepticism, as they may be surprised at the outcome. What lurks in the backchannels may well surprise you:

Once upon a time, copyleft enforcement was not considered controversial by many otherwise-pro-FOSS companies. In recent years, companies that prefer non-copylefted FOSS have succeeded in making even the most mundane GPL enforcement appear as controversial and industry-destabilizing. Many developers who contribute to GCC and glibc — even ones that work for historically FOSS-friendly companies — will be surprised to learn that their employers (or at least their legal departments) are opposed to any GPL enforcement. Conservancy, as the main organization actively doing GPL enforcement, hears this kind of pressure regularly. Our colleagues at FSF historically told us that they hear the same. It's rarely done publicly — but, when public, criticisms are delivered by proxies in a subtle, “you don't really need copyleft to be enforced anyway, do you?” manner. The public arguments are usually couched in a careful “dog whistle” style. While the message comes through loud and clear to executives, lawyers, companies and their trade associations, it's easily missed by contributors — who understandably have a much more important task to do: writing great FOSS code!

We expect that you may be surprised by this, but we can tell you that: in private, companies that contribute to key copylefted projects are not so subtle. They have communicated to those of us in the GPL enforcement community on several occasions — a message delivered by many executives over a period of many years — that they would prefer both Conservancy and FSF to curtail, or outright end, GPL enforcement. Their view, as communicated to us, is that GPL enforcement causes customers to think copyleft is problematic. As one executive once said to me: “We consider it a failure if any customer ever even asks us if they have to worry about GPL compliance”. These companies usually say: “well, we will always comply with the license, but we'd prefer if anyone who is our customer (or potential customer) simply is just left alone if they violate”. Once, an executive actually claimed to me that his company, a huge multinational software company, would: “cease to build any products on Linux and other GPL'd software at all if Conservancy and FSF don't cease their enforcement”. That statement was fortunately bluster and bluff; the company in question is still heavily invested in copylefted software, including Linux, GCC, and glibc, but the sentiment is a common one that we hear privately often. And, that company has since funded work to discredit GPL enforcement. Conservancy faces constant pressure and threats regarding its GPL enforcement efforts, and we're aware that FSF has faced to similar pressure.

In parallel, these companies have also steadily worked to hold more of the copyrights in key copylefted works — primarily by hiring the key developers that contribute to key copylefted projects. While I oppose this outcome, it's undeniably a rational approach: if companies hold the copyrights, they can decide when, how, where and most important if copyleft licenses are ever enforced. This process is well underway for copylefted works that don't have any policies about copyright ownership. For example, the “Who Contributes to Linux?” reports by LWN show starkly over recent years: fewer contributions coming copyrighted by individuals, and more contributions copyrighted by companies. While corporate involvement is always welcome in FOSS projects, we (as a FOSS community) have not responded with the necessary care to question why the companies, rather than the individual contributors, should own our FOSS. Only very few developers have even questioned this issue; we thank them for their efforts, but such questions are simply not raised enough.

As such, the most important consideration in ending copyright assignment to a charity is to consider what the employers of most of the developers will do with those copyrights, and whether they will enforce the copyleft in the best interest of the community. Even worse, might they eventually sell those copyrights to someone who will use enforcement in a manner that a charity never would — for their own avarice rather than the good of the community?

While the remainder of this essay addresses at length other secondary considerations and nuances regarding copyright ownership in copyleft projects, this point is the absolutely most important one:

Most for-profit copyright holders prefer copyleft to function much like non-copylefted FOSS. Namely, “it's certainly nice when folks voluntarily release their changes, improvements and ‘scripts used to control compilation and installation’, but if they don't, their failure to do so should be begrudgingly tolerated, and compliance should never be compelled for those who refuse”.

Violations Are More Common Than You Think

During this recent upheaval in the GCC community, I spoke at length with a GCC developer who has contributed to the codebase regularly for decades. After I'd explained some of issues above, the developer stated: “Well, is any of this really an issue for GCC? When was the last time there was a GPL violation on GCC?”. I glibly answered: “Well, I haven't heard about one for about a week, but I'll surely hear about another one soon.” The developer was flummoxed to learn that part-and-parcel to nearly every embedded Linux GPL violation (which have been, for years, innumerable) is a companion violation on GCC. Specifically, most system-on-chip (SoC) vendors not only have a stock Linux build given to the OEMs, but also include a toolchain. More often than not, a GPL violator who has what we call an “incomplete Complete, Corresponding Source (CCS)” violation on Linux will also have a “no-source-or-offer” or “incomplete CCS” violation on GCC. The usual reason is that part of the SDK given to OEMs must include an appropriate binary toolchain (sometimes with vendor-specific patches, and almost always with a complex configuration that's difficult to reverse engineer) so that the SoC integrators can compile other software for the system. This scenario is so common that we in the GPL enforcement community coined the shorthand term “toolchain violation” to refer to the scenario where the GCC violation “tags along” with a Linux violation. While glibc violations of this nature are admittedly less common than GCC, glibc violations do occur relatively often in the same manner.

Upstream developers are mostly unaware of how bad the compliance problem is regarding their code for one simple reason: the folks impacted most by GPL violations are downstream users, not upstream developers. Furthermore, correction of compliance problems usually produces code releases that “work” for the given device on which the original violation occurred, but rarely is that CCS released resulting from a GPL enforcement action trivially upstreamable. After all, this is code written, modified, and/or integrated by developers whose plan was to “get away” with a GPL violation, so why would they have invested the time to provide the improvements in a manner that it was immediately digestible for upstream? My view is that users matter, and FOSS contributors should care about their experience with the downstream consequences of their code. I urge FOSS contributors to implement copyright ownership schemes that have the most likely chance of enabling enforcement actions principled parties.

The Power of Collective Action

Regarding my views on FOSS copyright assignment, I often quote the famous gaffe of (former USA presidential candidate and senator) John Kerry, “I voted for it before I was against it” when I'm talking about copyright assignment. But I don't quote it purely for self-deprecation; I never felt the press was all that fair to Kerry, because I think policy makers should be willing to change their positions over time as new information comes to light, or when policies that we thought were beneficial in theory prove problematic in practice. I once thought universal copyright assignment for a copylefted work to a single charity was an absolutely necessity. Then, Conservancy's successful and continuing work with various BusyBox copyright holders, and our collaboration with Christoph Hellwig, showed me that there was huge value in individuals having copyrights and making their own choices about enforcing copyleft. Still later, I realized that individuals like Erik Andresen and Christoph Hellwig are quite rare, as most FOSS contributors — even if they've kept their own copyrights — ultimately have to take on such political and career risk to enforce copyleft that they must often chose not to because they could easily get blacklisted from major employers for doing so.

The central thread here is collective action by principled people who will use copyleft primarily as a tool for rights of users and for the improvement of copylefted projects. Ultimately, copyleft functions best when leaders of a project have the agency, wherewithal, commitment, and collective consensus to either ensure copyleft functions to protect their users' rights, or enable another entity to do that job for them in a principled way that serves the public good (usually in contrast to the interests of for-profit industry). (Note that even if that interest is “vendor-neutral”, as that means the interests served are the common business interests of the vendors, but not their customers.)

These issues are complex. Every policy change, or lack of policy change, will have many unintended consequences. An apparent “simple move” away from mandated assignment to a centralized organization could well be a decision to ultimately move copyright holding to for-profit corporations and their trade associations — all of whom are unlikely to stand up for the GPL and user rights. Beyond all else, I urge caution and slow deliberation before any policy changes about copyright control. I ask FOSS contributors to do the substantial and necessary homework of not only reading and considering the points of this essay, but those points raised by all parties. As you do, keep in mind that every party, including me, has a policy goal in mind for copyleft. I and Conservancy are very transparent that our policy goal is to see copyleft licenses enforced regularly on behalf of end users who buy products on the open market that contain copylefted code. We believe, as a policy matter, that copylefted copyrights are best held by entities that have a bona-fide track record of serving the public good, act in a principled and ethical manner in doing so — the most important principles being to never prioritize financial gain over users' rights — and who won't back down and give up when faced with the inevitable anti-copyleft backlash. Others, probably including your employer and the trade associations to which they pay membership dues, probably disagree with this position, but you should ask questions and listen carefully to see if you're getting a straight answer. After you've heard everyone's position, decide for yourself who deserves to have your copyrights: your employer, a charity, or yourself. Once you've decided, you'll have hard work ahead to change the default (which will likely be your employer once projects drop their copyright assignment mandate).

A Word on FSF's GPL Enforcement

The elephant in the room that I've not yet mentioned is the current status of the FSF as an organization. There is no question, given the recent mass resignation of their management, and other rapid leadership change surprises, that the FSF faces serious challenges in the next few years. I personally was previously affiliated with the FSF. That affiliation ended in 2019, so I have no real information about the internal status of the FSF since then. What I do know is that FSF currently lacks sufficient capacity to follow up on any GPL violations on GCC and glibc that we've reported for years. That said, if I have to chose between the strict dichotomy of: (a) copyrights held by the FSF (which has the possibility of recovery in the future and restoration to an organization that actively enforces the GPL) vs. (b) copyrights held by companies — many of whom are known to oppose enforcement of the GPL, I would still pick the FSF. Remember that copyright does not expire for a very, very long time. GCC and glibc are both codebases that prove the half-life of well-written software is very long, and that software stays relevant and useful for much longer than any of us usually admit. We have to think long term about the copyright ownership of copylefted works. While there are serious short-term and medium-term problems at the FSF, we have to consider carefully who is the best long-term steward of copyrights: companies or charities. Most importantly, changing 30 years of careful planning about the copyright inventory of important codebases is certainly not a decision to be finalized in a matter of just a few weeks or even months. Thus, most of all, I ask FOSS contributors to take care and ample time in their deliberations on such matters.

A Summary of Recommendations and Considerations

As promised at the start of this essay, here is a laundry list of recommendations and considerations that any copylefted project should consider regarding how to structure its copyright ownership rules. This list is provided as a quick reference only, and readers should keep in mind the complexity of the topic before jumping to a conclusion about the right policies. Not every issue below was addressed in detail in the essay above, but if there is interest from the community, I will publish further essays on other topics.

• Without your active work to avoid it (such as by modifying your contract or demanding assignment to another entity), for-profit employers will control your copyrights. You typically have no say into how or whether the license of your project is enforced if your employer holds your copyrights.
• Modern copyright assignments to charities such as the FSF or Conservancy usually take two forms: either your employer has a blanket copyright assignment, or you must individually assign copyright. In the latter case, there are typically two components: a disclaimer from copyright from your employer, and an assignment from you. In either case, you should speak at length with your employer's legal department to figure out what form, if any, is in place, and what will happen to those systems if your project changes its copyright aggregation policies.
• FOSS contributors have safety in numbers. A strong consensus that your project wants to see copyleft enforced for your users can create leverage that mitigates risk of “blacklisting” of those who chose to enforce copyleft licenses. When policies like copyright assignment to a charity or copyright ownership only by individuals are set project-wide, companies historically have simply accepted it. (The Samba project is an excellent example of a project where the developers have control.) By contrast, each contributor faces a steep climb in negotiating their ownership of the copyrights in the absence of such policies.
• While assignment to a charity can be annoying and feel problematic, this is often the most expedient way to assure that the copyleft license of your project is upheld. Conservancy, for example, will accept one-off assignment from FOSS contributors to strategically important FOSS projects. Even if you (collectively) chose to not mandate assignment for your project, it's valuable to assist and encourage your contributors to either develop together a collective individual copyright ownership plan, or assign to different charities, or recommend a mixture of the two.
• As an upstream developer, you're likely going to be unaware of most copyleft violations on your code. If possible, work with an entity that has the time and resources to investigate violations for you, and empower that entity to act on your behalf if possible.
• Pay attention to the details of Contributor Licensing Agreements (CLAs). Often, these require that you give up almost as many rights as a copyright assignment would require you to give up anyway. Avoid asking your contributors to agree to a CLA.
• Developer Certificate of Origins (DCOs) and other inbound=outbound contribution regimes are very good, useful and recommended. However ultimately such systems are entirely orthogonal to who holds the copyright. DCOs and contribution terms are general statements that attest to your right and permission to make contributions under the project's license, but are, by design, silent on the details. A DCO is absolutely compatible with a project that separately requires copyright assignment, or with a project that has other recommendations about how developers should handle copyright ownership.
• Seek and consider advice from all sources. Everyone with an opinion on these topics has a policy agenda. Ask what their policy agenda is when they advise you. Ask them their view on copyleft enforcement. Ask them if they've ever investigated copyleft violations on your software, and if so what they found and what their opinion is. If you're considering assigning your copyrights to someone, most notably your employer (who, again, is likely to by default receive your copyrights) be sure you've fully understood their policy and views on these matters. Insist that they put their policy and views in writing for you for future reference. Ask for strong commitments, and be skeptical if you cannot receive them.

[permalink]

Tags: conservancy, GPL, ContractPatch, law, licensing, resources

Understanding Installation Requirements in GPLv2

by Denver Gingerich on March 25, 2021

According to our Principles, we always begin discussions with GPL violators privately. Many of these discussions are ongoing at any time. Recently, we received many questions about GPLv2's requirements regarding installation of modified versions of GPLv2'd software on the device on which the software was distributed. GPLv2 was drafted in anticipation of future uses of the software, and includes specific license text regarding installation:

The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.

Unfortunately, we find that GPL violators often ignore (sometimes inadvertently) this part of that license text, which has always been of great importance: “the scripts used to control … installation of the executable”.

When a system is 100% FOSS “by design”, meeting this requirement is easy. We applaud the many community-oriented commercial projects that build their own hardware and give their users complete software freedom, such as the LulzBot Mini 3D Printer. We wish that all companies would follow that example and grant customers universal software freedom. Unfortunately, that is currently not realistic, even in the medium term.

Copyleft advocates have always contemplated that some companies will choose to ship proprietary software on the same device as the GPL'd works. Indeed, GPLv2 foresaw this possibility and permits that “mere aggregation” — as long as compliance is achieved for the GPLv2-covered works included on the device.

Indeed, GPLv2 was drafted as a forward looking license. Great care and attention was given to what the future might bring in software, and assure that in the future, GPLv2 defended software freedom adequately. In 1991, the year of GPLv2's drafting, one did not need to look that far ahead to see that general-purpose computers would find their way into devices other than servers, desktops and laptops. It was common, for example, in 1991 to have printers with full computers inside to handle various functionality of those printers. Famously, even back then, software freedom activists were quite frustrated that printer companies and their licensees would not liberate the proprietary software on these printers. Such activists, aware of this problem, sought to fix bugs in this printer software. They demanded source code for their printers, not because they sought to build their own printer from scratch and use that software, but because they wished to modify that source, fix the bugs, and reinstall the liberated printer firmware. This problem was well understood at the time of GPLv2's drafting, and GPLv2 was clearly drafted with this issue and use-case in mind.

To that end, GPLv2 included a clear obligation to provide “the scripts used to control … installation” that function for the GPLv2'd works. GPLv2 assures, to the purchaser of an embedded product, their absolute right to receive the information necessary to install a modified version of the GPLv2'd works. Meanwhile, rules for the legitimately proprietary works remain the prerogative of the licensors of that software. Since we have often been asked, we want to communicate this point with complete clarity and transparency: we would never require that any of the proprietary software on the device continue to function (or even be present) on the device after installation of a modified version of the GPLv2'd works on any device. However, installation of the GPL'd works must succeed and operate in a useful and functional fashion on the device.

Installation is where the proverbial rubber meets the road with software freedom. Of course, we honor the esoteric value of the freedom to study, and that right is important. But much more important, and a key reason that the GPLv2 was created, is the software freedom to reinstall a modified version. That means the right to fix bugs, the right to try out your improvements, and the right to remove privacy-disrespecting anti-features. It's the right that our community needs the most. The GPLv2 was designed to assure bug-fixing. Furthermore, the drafters knew that, on embedded systems and devices, you need to know how to install those fixes. Scripts can be technical artifacts like shell scripts, but can also be merely a recipe and/or guidance — written instructions that explain how to succeed at install.

We know that other software freedom organizations share this view. Conservancy is spearheading the ongoing effort to make this clarity widely known. Below is a simple statement of this position, phrased in other words:

The GPLv2 does not have any specific requirement for preservation of the ability to reinstall proprietary-software-centric vendor-provided firmwares (even if such firmwares contain some GPLv2'd works) on embedded systems, provided that the downstream user (i.e., the consumer with the device) can build, install, run, and (repeatedly and successfully) reinstall a firmware containing at least the copylefted components (such as Linux+Bash).

Not only is this consistent with what the license text says and requires, but it is also consistent with GPL's general policy goal. In our GPL compliance discussions, violators sometimes argue that, in order to install a modified version of the software received on a device, the user should build a new device themselves from scratch (instead of installing those GPLv2'd works on the device they have already). We don't believe that the original intent of the GPLv2 requirements for “the scripts used to control … installation of the executable” included that expectation, nor is that position supported by the license text. GPLv2 was written in a time after embedded devices already existed, and the intent is clear.

Our position is by no means controversial, but we do expect some will seek to argue it is controversial. We encourage you to consider their motives, funding sources, and licensing models. For our part, we published this policy statement to clarify repeated questions that companies distributing devices with GPLv2 software have recently raised in our GPL enforcement actions for Linux, BusyBox, and other software. We look forward to continuing the (sadly) long road toward compliance with these companies, in accordance with The Principles of Community-Oriented GPL Enforcement. We greatly appreciate the work that both individual contributors and companies put into their software and communities. It is our obligation, as copyleft activists, to ensure that GPLv2's rules apply fairly to everyone.

Finally, we encourage others to link to this statement when discussing GPLv2's “the scripts used to control … installation of the executable”.

[permalink]

Tags: conservancy, GPL, law, licensing

On Elastic, its fork, MongoDB, and the SS Public License

by Bradley M. Kuhn on January 29, 2021

Now that Elastic adopted SS Public License, folks have been asking us if Conservancy's view on the SS Public License has changed. It hasn't, and our previous two blog posts on MongoDB's license change and Copyleft Equality are still relevant. The only statement we'd like to add is:

To our knowledge, there is no individual nor organization who has yet agreed that they will run a project under the SS Public License and be themselves bound by the SS Public License. That license remains a disingenuous proposal until it's put to use in an “inbound=outbound” licensing configuration.

(Both Elastic and MongoDB require inbound contributors to give them special licensing rights.)

Meanwhile, on the orthogonal issue of whether a forked project should choose a non-copyleft or a copyleft license, we refer everyone to this excellent old keynote from Martin Fink about how copyleft makes project governance better and easier.

[permalink]

Tags: conservancy, GPL, law, licensing

17 USC § 1201, DMCA Exemptions and Software Freedom

by Bradley M. Kuhn on 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 — can we circumvent a technological measure that effectively controls access to a work. That's the basics of the exemption process.

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

While the material unfortunately includes significant pro-DRM propaganda, it does explain 17 USC §1201 quite well. The TL;DR summary is as follows:

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.

[permalink]

Tags: conservancy, law, licensing