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

Helping each other: the right to repair win and software freedom

by Denver Gingerich on November 6, 2020

We were very excited to hear that Massachusetts voters approved a new right to repair law earlier this week. Laws like these are important tools in allowing us to control the devices that we use. In particular, we believe it is important that people be able to fix their own devices, and to be provided with all the information they might need to make the best repair decisions. This principle has applied to cars for over a century and, now that cars are increasingly made up of computers, the implications for both repairing vehicles and software freedom are hard to ignore.

The proposed law is an excellent start for providing telematics information to vehicle owners. As the full text of the law (pages 5 and 6) describes, there are still implementation aspects to be decided by the Massachusetts Attorney General. These include a notice that describes "the mechanical data collected, stored and transmitted by a telematics system" and "the prospective owner's ability to access the vehicle's mechanical data through a mobile device", which dealers will be required to provide to prospective vehicle buyers and lessees.

The law also states the vehicle manufacturers must implement "an inter-operable, standardized and open access platform across all of the manufacturer's makes and models [that] shall be capable of securely communicating all mechanical data emanating directly from the motor vehicle via direct data connection to the platform". While the law mentions that this data needs to at least "be directly accessible by the owner of the vehicle through a mobile-based application", we would like to see the Massachusetts Attorney General clarify in their notice that the data should be accessible through an API available to the owner as part of this, one that is "inter-operable" and "standardized" per above.

We find often that people can read "a mobile-based application" to mean apps that are available via the Google Play Store or Apple App Store, but nowhere else. Both of these stores are proprietary software and lock users into single-company controlled infrastructure, so it is important to have other options for those who don't want to use such apps, including using an app available in some other store, for some other operating system, or that they wrote themselves if they like (using the API described earlier).

Initiatives like this Massachusetts Right to Repair measure are important for our freedom - our freedom to repair our devices (which includes vehicles) ourselves or by the repair shop of our choice, and our freedom to use whichever tools we wish in order to complete the repair. The right to repair movement is crucial in this world of increasingly locked-down devices, and we hope to build even more bridges to support the shared principles with software freedom going forward. We applaud and stand with the voters who made this initiative happen and look forward to many more such initiatives in the future.

---

Here is the email we sent to the Massachusetts Attorney General earlier today:

Dear Ms. Healey:

We at Software Freedom Conservancy, a 501(c)(3) charity dedicated in part to helping people take control of their computing experience through the freedom to choose which software they use, are very supportive of the "Right to Repair Law" Vehicle Data Access Requirement Initiative that Massachusetts voters approved this past week (organizationally and also as it relates to employees of ours based in Massachusetts). We see that as Attorney General you have been tasked with writing the telematics notice that manufacturers will provide to vehicle buyers and lessees, and we'd like to provide some suggestions given our experience with the different apps and software that users may wish to use to receive this telematics data.

In particular, we see that the notice will describe "the mechanical data collected, stored and transmitted by a telematics system" and "the prospective owner's ability to access the vehicle's mechanical data through a mobile device", which dealers will be required to provide to prospective vehicle buyers and lessees. The law also states the vehicle manufacturers must implement "an inter-operable, standardized and open access platform across all of the manufacturer's makes and models [that] shall be capable of securely communicating all mechanical data emanating directly from the motor vehicle via direct data connection to the platform".

While the law mentions that this data needs to at least "be directly accessible by the owner of the vehicle through a mobile-based application", we would like to see the Attorney General clarify in their notice that the data should be accessible through an API available to the owner as part of this, one that is "inter-operable" and "standardized" per above.

We find often that people can read "a mobile-based application" to mean apps that are available via the Google Play Store or Apple App Store, but nowhere else. Both of these stores are proprietary software and lock users into single-company controlled infrastructure, so it is important to have other options for those who don't want to use such apps, including using an app available in some other store, for some other operating system, or that they wrote themselves if they like (using the API described earlier).

Please let us know if you have any questions about our suggestions above. For reference, Conservancy's Execute Director, Karen Sandler, has been CCed. We are available to help draft specific text or join whatever process you establish for comments related to the implementation of this measure.

Thanks for your consideration!

[permalink]

Tags: law, software freedom for everyone

Asking Microsoft to resign from the RIAA over youtube-dl takedown demand

by Denver Gingerich on October 26, 2020

We learned on Friday that GitHub removed youtube-dl's primary collaboration forum and code repository from their site, which had been hosted at https://github.com/ytdl-org/youtube-dl. The action was in response to a DMCA Section 512 notice that the RIAA sent demanding removal of youtube-dl, which was released and distributed via GitHub under a liberal FOSS license. In the notice, the RIAA cites DMCA Section 1201 (the removing digital restrictions section) as justification for youtube-dl's removal.

We believe that youtube-dl has substantial non-infringing uses. There are many, but to name a few, youtube-dl has the following important features:

• enable users to watch YouTube videos without installing any non-free software
• watch YouTube at different speeds (including speeds YouTube does not offer) — an important feature for accessibility!
• view YouTube videos at their highest quality on low-bandwidth connections
• ability to download (and then, with other software, modify and reuse) freely licensed videos, such as those licensed under CC-BY
• various aids for journalists, including fact-checking, video analysis, and bandwidth saving

We realize Microsoft, a paying member of the RIAA, has left themselves stuck between their industry association's abuses of the law and the needs of FOSS projects for which they provide infrastructure. While under current law (which we object to), complying with the takedown notice is admittedly the fastest way to limit Microsoft's liability, we view Microsoft's membership in the RIAA as a much bigger liability to our community, now that Microsoft controls GitHub. We call on Microsoft to resign from the RIAA and remove their conflict of interest in this matter. This is an important opportunity for Microsoft to stand up for the values of software freedom.

If you work at Microsoft (including for its GitHub subsidiary), we call on you to petition your employer to resign immediately from the RIAA. We suggest that you raise these concerns directly with your manager or other management, or (even better) by starting an internal email petition with other employees.

To build a strong community of FOSS developers, we need confidence that our software hosting platforms will fight for our rights. While we'd prefer that Microsoft would simply refuse to kowtow to institutions like the RIAA and reject their DMCA requests, we believe in the alternative Microsoft can take the easy first step of resigning from RIAA in protest. We similarly call on all RIAA members who value FOSS to also resign.

[permalink]

Tags: FOSS Sustainability, software freedom for everyone

In free software, you're still not alone: the evolution of our weekly chats

by Deb Nicholson on July 29, 2020

We began our weekly chats in mid-March to give people a dedicated place and time each week to talk with fellow free software enthusiasts during the pandemic. During that first month, mostly we talked about what events were being cancelled and how frustrating it was that so many entities immediately embraced non-free tools for connecting remotely. We were also starting to contend with the financial effects of a global pandemic and some in our community wondered about job security and shared some information on who was doing layoffs and who might be hiring -- for remote work, of course.

Once the Copyleft Conf videos were posted in April, we hoped to sort of fill in the gap left by in-person events and so we hosted some chats based on some of those talk recordings. The talks we covered sparked some lively discussions about copyleft adoption and the effects of license choices for users. We discussed these presentations:

• Tony Sebro's keynote about community and copyleft
• "Copyleft of Things" with Peter Hoddie
• "Ethics and FOSS" with Coraline Ada Ehmke and her collaborator Don Goodman-Wilson
• "Copyleft in a Business Context" with Josh Simmons, Markus Glaser and Bjorn Scheissle

Then at the end of May, Black Lives Matter protests began happening every single day in the US as well as in many other places around the world. We thought long and hard about how we might support this long overdue moment of reckoning with systemic racism and violence. We felt we had a responsibility to look at how we might combat racism within our own community. We started with a fairly general discussion and worked towards more action-oriented topics as we went along. In the end, we hosted four discussions around racism and free software, including:

• "How to Dismantle Systemic Racism in Free Software" -- This was an open discussion where people shared resources and talked about strategies for dismantling racism in free software projects and communities that have worked and some that haven't.
• "How Racism is a Free Software Issue" -- Led by Molly de Blanc, in which "So you want to talk about race" by Ijeoma Oluo was heartily recommended.
• "Allyship in FOSS and Beyond" -- Led by Ben Cotton in which participants shared a number of reading suggestions, many of which had already been compiled by the Chicago Public Library.
• Finally, we watched Byron Woodfork's excellent talk from Strange Loop in 2017, "The Truth About Mentoring Minorities" and shared suggestions for participating in existing mentorship programs or starting programs within your workplace.

After the first Thursday in July, we hosted a "no topic" chat and noticed that the folks who showed up to that chat really appreciated the opportunity for no-topic chats. Most of the US is still limiting the size of public indoor gatherings, so we still don't know when we'll be able to do in-person FOSS events again. The virtual hallway track where we talk about installing free software on different devices, how to best advocate for software freedom, who might be hiring free software contributors and what's a good free software tool for some particular task, serves a very real function in the global, remote free software community. So, we've decided that we're going to be doing a topic on the first Thursday of the month and invite folks to share whatever's on their minds on the other Thursdays.

Tomorrow's chat (July 30th) will be "no topic" and then on August 6th we'll have a topic again. Next week we're inviting people to talk about online resources for learners of all ages that either use or teach free software or otherwise support you -- or your child's -- development as free software user or contributor. The next chat with a topic will take place on September 3rd. Feel free to write to us with a topic suggestion and we encourage you to follow us on social media where we'll be announcing the topics and reminding folks about each week's chat, either on Mastodon or Twitter.

All our public chats take place in #conservancy on freenode.net on Thursday afternoons at 2pm Eastern/6pm UTC. The #conservancy channel is accessible via your IRC client. If you don't already use an IRC client, you can come in through your browser. Just visit this page https://webchat.freenode.net/#conservancy and choose a nick (or nickname) and you'll be "in channel." In free software, you're still not alone.

[permalink]

Tags: diversity, software freedom for everyone