Displaying posts tagged conservancy
A Modest Proposal In The New Age of DMCA Takedown Aggression
byon 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 DRM0. 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
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!
0Google 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.
Conservancy Requests Three DMCA Exemptions to Let People Control Their Devices
byon 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.
Some Work-At-Home Tips for FOSS Contributors
byon 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
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
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.
Supporting Software Freedom with Your Time through Conservancy
byon May 7, 2020
The current global pandemic has affected everyone, but the experience of essential workers couldn't be more different from the experience of remote tech workers. Even within tech, many people have found themselves with no free time at all while they work to balance child-rearing, care-giving and remote work, while some of their friends, siblings and peers have found that they suddenly have a lot of extra time.
This post is for free software enthusiasts who find themselves with extra time. Conservancy and its member projects have a variety of different ways that you could meaningfully volunteer your time -- remotely, of course.
Translation is great way to help spread free software. MicroBlocks needs help with translation to help them make their fun projects available to more new coders, all over the world. The contact email is: firstname.lastname@example.org. Etherpad, a key tool for remote collaboration, is also currently seeking translation help.
In a few weeks, we will need help with some of the bits and pieces associated with our upcoming migration to Bean Count. Moving ten years of financial records is a big undertaking. Folks who are python savvy and/or have experience with Bean Count should drop us a note at email@example.com with "Bean Count Help" in the subject.
Many of our projects could use more technical volunteers, here are two that have nice specific lists of tasks they could use help with. Reproducible Builds has a handy list of technical tasks that they could use help with on their site. Inkscape has a thorough list of both coding (and non-coding) tasks that they could use help with on their site.
Compliance is more important than ever. As more and more people come to rely on their digital devices and applications, we want to ensure that these tools empower, rather than spy on, the user. Compliance is big part of how we make sure there is source code that folks can examine -- and alter if necesary.
At a high level, this is how Conservancy's compliance process works:
- People like you tell us about products or services they use where the source code for GPLed parts isn't provided or is incomplete
- We investigate and contact the company if we can't find complete build and installation instructions
- We work with the company to get the complete source - in rare cases we file a lawsuit (only when all other avenues fail)
We're specifically interested to hear from people who are able to check their devices (TVs, smartphones, tablets, et.c) to see if they contain any GPLed software. Here's how to do that:
- If you think the device uses Linux, BusyBox, Android, etc., or the manual mentions "open source" then ask the manufacturer for source code
- If they don't reply, or refuse to provide it, please report this to us
- Or, if you can't build their source code or install the result on your device for some reason, let us know
- We will start the process to resolve it (so you can get the source!), following up in a few days
We're always interested in talking to FOSS-savvy folks who want to write for our blog. A robust free software movement includes lots of voices. Some topics we'd like to see include; stories about driving free software adoption at your work or school, ways to improve governance or work-flow at community-driven free software projects, how your company embraced copyleft or sharing strategies for growing and/or diversifying free software communities. If writing about free software sounds exciting to you, email us at firstname.lastname@example.org with "Guest Blogging" in the subject.
Some of our projects have also put out calls for help with writing. Selenium could use help answering questions, writing documentation, and updating information on their website. Inkscape has a thorough list of both non-coding (and coding) tasks that they could use help with here.
This one's a little specialized, but if you are at all familiar with the grant space or are interested in learning, we could use some help identifying grant application opportunities. If that sounds like your wheelhouse, then please email us at email@example.com with "Grant Research" in the subject.
Thanks for considering volunteering your time to support software freedom!