Public Drafting Process for the DMCA Cooperation Pledge

by Bradley M. Kuhn on 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.

[permalink]

Tags: conservancy, law, licensing

A Modest Proposal In The New Age of DMCA Takedown Aggression

by Bradley M. Kuhn on November 13, 2020

Just two weeks ago, my colleague Denver posted a criticism of Microsoft's GitHub for its capitulation to the RIAA takedown notice — which alleged, with specious evidence, that youtube-dl violated 17 USC § 1201. Frankly, this is the kind of behavior we'd expect from the RIAA — an organization controlled in recent decades by two dudes who seem to have helped write § 1201. No one is surprised when the RIAA attacks FOSS projects.

Last night, though, I was shocked to learn that a company that generally has a much better track record on DMCA matters (and with FOSS projects) joined the recent onslaught of DMCA takedown notices against FOSS projects. Namely, GitHub announced yesterday that Google sent a § 1201 DMCA takedown notice for a FOSS project called widevine-l3-decryptor.

Google is the primary provider of browser-based DRM technology for nearly all of the well-known entertainment streaming services, through a product called Widevine. If you've watched a streaming video from a major provider (such as Netflix, Prime Video, and Hulu), then you've probably used Google's DRM. For the past two years, researchers have been in a DRM arms race with Google in cracking the lowest level (and lowest video quality level) of Widevine (called “L3”). The most recent crack inspired creation of a FOSS project, called widevine-l3-decryptor. If successfully integrated into browsers and other platforms, this new freely licensed code may well allow a 100% FOSS solution for viewing videos at this lowest level of DRM⁰. As always, though, DRM and software freedom remain on an irreconcilable collision course; the function of one always precludes the other.

If you just had déjà vu, it's likely because the narrative here resembles the story of DeCSS from about 20 years ago. The big differences are: (a) cracking L3 isn't as big of a threat to DRM technology (since it yields video output at very low quality), and (b) more importantly, and strangely, Google takes on the role of the MPAA in this repeat dance of DMCA history.

What Should Activists Do?

I admit that this situation kept me up half the night. My first thought was to come out blogging today that we needed to immediately institute a full boycott of all DRM, and the companies that produce it. Yes, a boycott would surely be effective, but it is effectively impossible. Seth Schoen, who has spent nearly a lifetime working to fight DRM, told me once that the talking point inside the industry circles in the early 2000s was: DRM is inevitable. Indeed, the media companies succeeded in inserting that phrase into culture, research circles, and everywhere else — so much so that it eventually became a running joke for activists.

We erred in our arrogant belief that DRM would remain clunky and rare. Media companies and their technology providers have laughed at us all the way to the proverbial bank. Then, the W3C and Mozilla Foundation capitulated with EME. Simply put, the boycott won't work now because DRM, along with the ubiquity of proprietary software in (at least as some component of) every popular platform means that DRM is seamless, easy-to-use, and rarely gets in the way of paying customers. We in fact tried, and mostly succeeded, in boycotting DRM when it was cumbersome, full of bugs, and annoyed users in the early 2000s. Today, most users of DRM don't even know it's there, or who provides it. While I'm not a user of browser-based streaming, I am still embarrassed to say that until yesterday I didn't even know Widevine was a Google product. I thought others were fighting the good fight against DRM and I mostly ignored it. But no one really is. DRM may not rule the technological world for software freedom activists who shun proprietary platforms. But it silently rules everyone else's tech world, and boycotting DRM effectively means boycotting most technology.

This led me to think of political polarization and a failure to compromise, and how it puts policy issues into gridlock. So, for a moment, let's step aside from our visceral negative reaction to 17 USC § 1201. Of course, we should never forget that § 1201 frustrates many Free Speech rights with respect to software in the USA; however, we also must admit that strategies until now have failed to repeal that abhorrent law. So, let's attempt for a few minutes to see the other side's position, as it might help us find other ideas to try while we wait indefinitely (22 years and counting ☹) for restoration of technological Free Speech rights.

Toward that mindset, consider that the copyright statute is ultimately a tool. We in the FOSS community created copyleft as a method to use that tool for good rather than ill. Meanwhile, the media and big tech companies lack any moral motivations on this issue, so they see this tool as merely a method to keep paying customers paying over and over again for the same content. It seems on the surface that there's no zone of agreement, but perhaps there is. Maybe we can agree, especially when we look back to the era of DeCSS, that §1201 is a tool so sharp that it instead became a clumsy weapon. Herein, I propose a compromise that slightly blunts §1201's sharpness. That compromise can be found by focusing on the consensus we already have regarding what parts of copyright that copyleft enforcement should avoid.

Short Term: Copyright Enforcement Parity

Two years ago, Google along with many other companies signed on to the IBM's Red Hat initiative and agreed to the RHCC. The RHCC is a pledge (similar to the KESAP, the latter of which we endorsed) whereby all copyright holders in GPL'd software agree to allow infringers 30 days to repair any copyright infringement consequence-free. During that 30 days, the infringer can continue acts of copyright infringement (e.g., violating the GPL) with impunity. On the thirtieth day, if the infringer achieves full compliance with the GPL, all is forgiven and no penalties are imposed.

While 30 days of unabated GPL violations are quite problematic and often result in thousands of customers remaining uninformed forever that their products contain copylefted software (and thus are possibly never informed that software freedom exists), GPL enforcers have always understood that it takes time for folks to coordinate a response and fix the situation. We have remained steadfast in our focus on beginning with friendly and respectful conversation with any infringer. We never demand immediate injunction; in fact, we usually don't even request one for about 120 days or more. By contrast, DMCA takedown is the exact opposite approach. Takedowns are unwarranted for FOSS projects that develop and operate transparently in the open and facilitate important work for the public good.

Thus, I hereby call on all these companies who signed onto the RHCC to agree immediately to the following pledge:

We agree that regarding any and all alleged copyright infringement committed by any software project that is licensed under (or intends to license under) an OSI-Approved License, that we will give notice to the project, and take no action of copyright enforcement (including but not limited to DMCA takedown) for at least 30 days from the date of notice of our concerns made to the project.

I will be writing to my contacts at all the companies who signed onto the RHCC to ask them to sign onto this provision as well.

Medium and Long Term Solutions

An agreement to slow the rising DMCA takedown onslaught won't actually solve the scourge of §1201. But it can raise awareness. We live every day under unreasonable restrictions from the DMCA and similar laws worldwide. We sometimes forget the urgency of this problem, but this fall's reemergence of the DRM wars should remind us that we must regularly discuss concrete ideas for response. Over the coming weeks, I'll be blogging more on the topic with more ideas to address this problem. In the meantime, I hope I've inspired some of you to propose ideas on how to respond in this struggle, and please do share this post and the request above on social media and any other fora you frequent!

⁰Google does claim, without evidence (presumably because DMCA doesn't require Google to provide evidence at this stage of the process), that some of the files in the project were copyrighted by Google and therefore not licensable as FOSS. If true, Google would also have a more mundane copyright infringement allegation unrelated to §1201. However, recall that it's typical for pro-DRM organizations to (incorrectly) claim that databases of keys or even keys themselves are independently copyrightable, and we strongly suspect that's occurring here.

[permalink]

Tags: conservancy, licensing, software freedom for everyone

Conservancy Requests Three DMCA Exemptions to Let People Control Their Devices

by Conservancy's Staff on September 16, 2020

Every three years, the US Copyright Office conducts a rulemaking process to consider exemptions to the anticircumvention provisions of the Digital Millennium Copyright Act (DMCA). These are the provisions of the law that make it a criminal offense to circumvent digital rights management technology (DRM). These provisions give technology companies far too much control over the technology people use, prohibiting all kinds of modification and tinkering in the name of “copyright protection.” We would love to see the anticircumvention provisions of the DMCA repealed in their entirety.

Until that happens, the rulemaking process gives us an opportunity to request exemptions that are strategically important for software freedom and essential for us to be able to control our own devices. This year we requested three new exemptions:

• To allow people to investigate whether software on a device violates free and open source software (FOSS) licenses, and to exercise rights that would ordinarily be granted by those licenses were it not for the technological restrictions
• To allow people to conduct good-faith testing, investigation, and correction of privacy issues—for example, think Internet of Things devices that phone home with more information than they disclose
• To allow people to install alternative firmware on routers and other network hardware they buy, to add or remove functionality as they see fit

All of these exemptions recognize the growing prevalence of small, dedicated devices in many people’s lives. We’re always horrified to learn when gadgets that should be innocuous like doorbells, thermostats, and baby monitors are spying on us, whether by design or careless programming. It should not be a crime for people to investigate these issues and take steps to defend themselves with devices they’ve bought and own—especially when the device is running FOSS that promises the user those very rights. Our requests call on the US Copyright Office to codify that common sense into law.

We also requested renewal of the exemption that allows people to install alternative software on smart TVs that we previously won in 2015.

These requests kick off the beginning of the process, where all new exemptions are requested. We can expect the Copyright Office to announce what exemptions are granted around this time next year. We’ll be sure to keep you updated on the process.

[permalink]

Tags: conservancy, Filings, GPL, law

Some Work-At-Home Tips for FOSS Contributors

by Bradley M. Kuhn on June 23, 2020

The global COVID-19 pandemic has changed everyone's lives, and taken the lives of so many of our family members and friends. For those of us that have been spared, our lives must continue, and this is particularly true for those who work in Free and Open Source Software (FOSS), since so many of us already worked from home. Doing so when our world faces so many simultaneous crises is undoubtedly difficult. I share below a few ideas that I've had that might be able to help my fellow FOSS contributors.

We have a weekly meetup of FOSS contributors where I live, which once upon a time met at a restaurant for late breakfast, but now meets weekly on a Jitsi instance installed by one of the members. During a recent session, one contributor complained about a real problem she faced, as she put it: All my non-FOSS friends keep asking me ‘Teach me how you work from home; I'm doing it for the first time and failing’. The answer she gave them was that what is happening now is not the “working from home” that she had trained herself for all this time.

Specifically, she meant that most of us who already work from home have built quite easy routines of having the home to ourselves. Roommates, children, life partners, and family who live in the house often have at least some of their day when they're away. Now, everyone is staying at home, so the personal procedures and systems that those of us who stay while the others go have simply evaporated.

My colleague's observation was quite salient. I've seen plenty of articles talking about how to work from home, but few have tips for how to handle the unique situation where everyone in the house and must all work from home together. I have a few ideas that I thought might help in this regard. Admittedly, some of these tips are likely FOSS-specific, but if you've found this article and don't work in FOSS, there might still be a hint or two that helps. Here's a list of changes that I've made that have really worked for me:

• Hour-shift if you can. If you're able to, attempt to try new times of day. For me, I've been attempting to wake up earlier than everyone else in the house and get a few hours of work before others in the home start their day. Our Executive Director, Karen Sandler, has been working late in the evening after her children are in bed. Of course, shifting to inconvenient times is difficult and annoying, but we've found it can help to fit in a few hours of focused work during these difficult times.

• Reorganize rote tasks for right time of day. When lots of people are around the house, some times of the day are inherently going to be louder and more chaotic than others. Keeping that in mind, I often try to plan out a day so that tasks that require serious concentration are scheduled for the most quiet moments and rote tasks are saved for those moments when it feels like nothing else can be done. For example, if I have to write complex correspondence with FOSS project leaders, I try to do that early in the morning, and save the Git repository reorganization project — which is mostly waiting for long rebases to finish and cherry-picking changes from other branches — for those times when my quarantined neighbor is power-washing his driveway.

• Mix housework with conference calls. My colleagues at Conservancy already know this, but for those of you who have been on the phone with me now may be in for a shock: if you've had a conference call with me recently, I was probably loading or unloading my dishwasher, cleaning the kitchen, or doing laundry while I spoke with you. The amount of housework for all of us has gone up now that we're all going nowhere else, and it's tough for all of us to fit it in. Most of our work in FOSS is at a keyboard, but for those moments when I don't need the keyboard and screen in front of me, I look for tasks that need attention that I can easily do while wearing a headset. Of course, I recommend the double-mute button solution to really ensure that your colleagues don't hear the kitchen sink spigot on the line!

• Not everything needs a video chat. Video chat is now mainstream and everyone seems to want to use it. Of course, I (and all of us at Conservancy) encourage use of FOSS solutions, such as Jitsi and Big Blue Button. However, not every meeting needs a video chat, and, fitting with the previous point, being tied to your desk for a long video chat at a time when you're in a crowded house can be difficult. Encourage your colleagues to use a simple phone call when it will do for a meeting. Use a mobile or cordless phone so you can take a walk while talking, even if it's just wandering around the house. Furthermore, being cognizant to the increased noise levels in all our homes — be it from children playing, or that power washer next door that I mentioned — consider meetings on IRC, XMPP or other forms of FOSS online chat. This also allows folks the flexibility to step away for an emergency and come back to catch up.

• Keep working on context switching skills. I admit that I envy people who can truly multitask and keep clear attention on two complicated things at once. It's a skill that I've never been able to develop, but there's another skill that can be equally valuable: the ability to switch between two tasks quickly. Those of us that program know that speeding up context switches on a computer speeds just about everything up on the computer. It's also (at least a bit) true with a person. If you can handle a surprise issue that someone in your house is asking you about, and quickly return to work without losing too much time to re-acclimate yourself, it really helps to keep work efficient during these tough times. Like any skill, it requires practice to develop. I find the best way to practice is be very mindful about what I'm working on at any moment and why, and when a distraction comes along, I evaluate it carefully by sub-vocalizing, and then note down something about where I was with the task I'm on before switching. I find that even the briefest of notes (3-5 words) makes a huge difference when I attempt to swap the task back into my mind.

Finally, keep in mind that one good fact in the sea of bad things in our world is that all of humanity is facing COVID-19 together. Those of us who are fortunate enough to do our jobs from relative safety in our home owe it to do our best to work efficiently and keep going, while the essential workers who are caring for the sick, searching for a vaccine and shelving our grocery stores take risks on our behalf to help our society survive the pandemic. I try to have empathy for all the others facing challenges that are greater than mine during the pandemic, and do the best I can in my own work to honor their sacrifices.

[permalink]

Tags: conservancy, FOSS Sustainability, resources