![[RSS]](/static/img/feed-icon-14x14.2168a573d0d4.png)
Conservancy Blog
Displaying posts tagged software freedom for everyone
Prioritizing software right to repair: engaging corporate response teams
by on February 3, 2024
Across organizations who develop and deploy software, there are a wide range of time-sensitive concerns that arise. Perhaps the most diligent team that responds to such time-sensitive concerns is the cybersecurity team. It is crucial for them to quickly understand the security concern, patch it without introducing any regressions, and deploy it. In extreme cases this is all done within a few hours — a monumental task crammed into less time than a dinner party (and often replacing such a social event at the last minute; these teams are truly dedicated).
Many other teams exist across organizations for different levels of risk and concern. In our experience, on average among many companies, the team that receives among the lowest priorities is the team that responds to concerns about a company's copyleft compliance. Now we can think of some reasons for this: the team is often not connected to the team that collated the software containing copylefted code, or that latter team was not given proper instruction for how to comply with the licenses (and/or does not read the licenses themselves). So the team responding when someone notes a copyleft compliance deficiency is ill-equipped to handle it, and is often stonewalled by developer teams when they ask them for help, so the requests for correct source code under copyleft licenses usually languish.
With this in mind, we at SFC are helping prioritize the copyleft compliance concerns an organization may face due to some of the above. To reflect the importance of teams responding to copyleft compliance concerns, we recommend that companies create a team that we are calling a "Copyleft Compliance Incident Response Team" (CCIRT). This will help convey to management the importance of properly staffing the team, but also how it must be taken seriously by other teams that the CCIRT relies on to respond to incidents. Where companies employ Compliance Officers, they will likely be obvious leaders for this team.
Now some companies may not need a CCIRT. Unlike security vulnerabilities, failing to comply with copyleft licenses is entirely preventable. If you know your company already has policies and procedures that yield compliant results (of the same form as compliant source candidates that we praise in the comments on Use The Source), then there is no need for a CCIRT. However, our experience shows that most companies do not have such policies and procedures, in which case a CCIRT is necessary until such policies and procedures can reliably produce compliant source candidates from the start.
We recently launched Use The Source (alluded to above), which helps device owners and companies see whether source code candidates (the most important part of copyleft compliance) are giving users their software right to repair, i.e. whether they comply with the copyleft licenses they use. We realize companies may be concerned about SFC publishing their source candidates before they have had a chance to double-check them for compliance, due to some of the issues with policies and procedures mentioned above. As a result, we are giving companies the opportunity to be notified before we post a source candidate of theirs, so that they can take up to 7 days to update the candidate with any fixes they feel may be necessary before we post it. And the sooner a company contacts us, the better, as we are offering up to 37 days from the launch of Use The Source before we publish candidates we receive. See our CCIRT notification timeline for details. For historical purposes, the additional grace period that we provided at launch time is detailed here.
We hope that this new terminology will help organizations prioritize copyleft compliance appropriately, and that everyone can benefit from the shared discussions of source candidates and their compliance with copyleft licenses. We look forward to working with companies and device owners to promote exceptional examples of software right to repair (through our comments on Use The Source) as we find them.
(Software) Repair info on EnergyGuide labels: Conservancy replies to FTC's request
by on December 21, 2022
Software Freedom Conservancy has today submitted its reply to the FTC's request for comments on how repair information should be displayed on EnergyGuide labels. In particular, SFC has recommended that the FTC mandate a "Software Repair Instructions" section on the EnergyGuide labels that are already required on a variety of home appliances, including televisions, refrigerators, clothes washers, and dishwashers. This would not be a new notice requirement for most manufacturers, since it (currently) only requires manufacturers to provide the notice when they already had obligations under copyleft licenses to offer source code already. This merely changes the prominence of such notices, so that users can more easily see which products contain copylefted software (and thus software repair instructions) or not. This is important because many manufacturers make efforts to deemphasize or obscure their offers (if they have them at all), which prevents consumers from learning that they have rights with respect to their software.
We are very happy to see the FTC requesting comments on how repair information for home appliances can be better provided to purchasers of these products. While the FTC's EnergyGuide labeling program started out as a way for purchasers to better assess how much energy each appliance would likely use, and approximately how much that would cost them, the FTC has been taking a more holistic view of how appliance purchases impact the world, not just in terms of how much energy they consume while operating, but also how much energy is required to manufacture them and, consequently, how we can reduce the number of appliances going into landfills, reducing the number of new appliances that need to be manufactured. Free and open source software provides many answers to these repair and longevity questions, and we hope that appliance purchasers will be made more aware of this through the FTC's updated labeling requirements.
By making a lot more people aware that software repair information is available for a device, the chance of a repair community forming for that class of devices increases dramatically. And these communities are immensely helpful to device owners, both for fixing problems that may arise in the software (which can be shared quickly and easily after one person makes them to anyone with that device, regardless of their level of technical expertise), but also for maintaining that software long after the manufacturer has stopped supporting it, meaning they can keep that device operating safely for years to come rather than having to dispose of it, which increases landfill usage and needless new device purchases. We already have several examples of such communities, including SamyGO for older Samsung TVs, LineageOS for most Android phones, and OpenWrt for wireless routers. SFC has fought extensively to protect the right to install your own firmware on your devices. By showing people that software repair information is available to them, we can build many many more communities like these, keeping more devices lasting longer (and better serving their users' needs), and fewer devices in our landfills.
We recommend those interested in this issue read our submission to the FTC, and consider whether to make their own submission in support of this or similar (especially hardware) repair information requirements. While we hope our own submission carries weight and is deemed relatively easy to implement given that it requires no new information to be provided by most manufacturers, it would help for others to provide their own experiences with lack of easily-accessible software repair information to the FTC so they are aware of the extent of the problem. The comment period is open until December 27 (likely to be extended until January 31, 2023) and you can see more details about the FTC's request for submissions and submit your own comment here.
For those that do read our submission, note that the FTC has trimmed some of its attachments from the website. You can find the attachments here instead:
You may notice that SFC has suggested the FTC require manufacturers to provide a URL to their source code distribution website, while not mentioning other ways of fulfilling an offer for source code, which we normally request that manufacturers provide (such as offering the source code on a durable physical medium, e.g. a USB stick or optical disc). Our main reason for this usual request that manufacturers provide source code on a durable physical medium is that not everyone in the world has a reliable or fast Internet connection. As a result, if a manufacturer only provides source code over the Internet, the most disadvantaged people are further disadvantaged by not being able to download the source code for their device (most source releases are hundreds of megabytes, if not more).
With our reply to the FTC, we were trying to make the best argument based on current practices and the least amount of additional work for manufacturers (to improve the chance of our suggestion being adopted, and reduce the chance that a company could make any credible argument against it), while also keeping in mind the jurisdiction this ruling applies to (USA) and its Internet connectivity standards. Though not complete yet, the National Broadband Plan in the USA does have this aim: "Every American should have affordable access to robust broadband service". Given the balance of people in the USA already connected to broadband, and the strong intent to connect the rest, we felt it was practical to make the recommendation include only web-accessible source code as the labeling requirement applies only in the USA. Note that we still request manufacturers make source code available on a durable physical medium, and would advise the FTC to make this part of their labeling requirements as well if they felt it feasible to include.
Although we have much work to do to ensure that people purchasing free and open source software (as part of appliances and other devices they may buy) know that they can repair, maintain, and modify this software, steps like this from the FTC will bring us closer. We are looking forward to the FTC's decision on our recommendation, and hope to help more people access the information they need to make their devices work for them, for as long as they choose to keep them. Together we can improve our own lives, but also the lives of others, and our planet.
Microsoft To Ban Commercial Open Source from App Store
by on July 7, 2022
Microsoft Will Even Prohibit Charitable FOSS Fundraising Through the “Microsoft Store”
A few weeks ago, Microsoft quietly updated its Microsoft [app] Store Policies, adding new policies (which go into effect next week), that include this text:
all pricing … must … [n]ot attempt to profit from open-source or other software that is otherwise generally available for free [meaning, in price, not freedom].
Yesterday, a number of Microsoft Store users discovered this and started asking questions. Quickly, those of us (including our own organization) that provide Free and Open Source Software (FOSS) via the Microsoft Store started asking our own questions too. While Microsoft has acknowledged the ensuing community outrage, they have not clarified their policy. In the meantime, this clause reverses long-standing app store policies, and is already disrupting commerce on their platform (with its tight countdown clock to implementation). In particular, Microsoft now forbids FOSS redistributors from charging any money for nearly all FOSS (i.e., “profit”). Since all (legitimate) FOSS is already available (at least in source code form) somewhere “for free” (as in “free beer”), this term (when enacted) will apply to all FOSS.
For decades, Microsoft spent great effort to scare the commercial software sector with stories of how FOSS (and Linux in particular) were not commercially viable products. Microsoft even once claimed that anyone who developed FOSS under copyleft was against the American Way. Today, there are many developers who make their living creating,supporting, and redistributing FOSS, which they fund (in part) by charging for FOSS on app stores. We in the FOSS community have long disagreed with Microsoft: we have touted that FOSS provides true neutrality regarding commercial and non-commercial activity — both are permitted equally. In short, our community proved Microsoft wrong with regard to the commercial viability and sustainability of FOSS.
Sadly, these days, companies like Microsoft have set up these app stores as gatekeepers of the software industry. The primary way that commercial software distributors reach their customers (or non-profit software distributors reach their donors) is via app stores. Microsoft has closed its iron grasp on the distribution chain of software (again) — to squeeze FOSS from the marketplace. If successful, even app store users will come to believe that the only legitimate FOSS is non-commercial FOSS.
This is first and foremost an affront to all efforts to make a living writing open source software. This is not a merely hypothetical consideration. Already many developers support their FOSS development (legitimately so, at least under the FOSS licenses themselves) through app store deployments that Microsoft recently forbid in their Store. The well-known Krita painting software and the video editing software ShotCut are both sold on Microsoft's app store (and will both soon be in violation of Microsoft's terms). Indeed, our own Inkscape project has unilaterally chosen to only request, rather than require, donations from Microsoft Store users, but this new term forces that decision upon Inkscape permanently. These represent just a few examples of developers and/or redistributors left out in the cold under Microsoft's new terms.
Microsoft counter-argues that this is about curating content for customers and/or limiting FOSS selling to the (mythical) “One True Developer”. But, even a redrafted policy (that Giorgio Sardo (General Manager of Apps at Microsoft) hinted at publicly early today) will mandate only toxic business models for FOSS (such as demo-ware, less-featureful versions available as FOSS, while the full-featured proprietary version is available for a charge). Any truly FOSS system is always “generally available for free” — since the developers do the work in public, and encourage others to remix and rebuild the software into binaries for all sorts of platforms. These are essential rights and freedoms that FOSS licenses give users and businesspeople alike. FOSS was designed specifically to allow both the original developers and downstream redistributors to profit fairly from the act of convenient redistribution (such as on app stores). No company that supports FOSS and its commercial methodologies would propose to curtail these rights and freedoms. So we're left quite suspect of Microsoft's constant claims that they've changed their tune about FOSS. They still oppose it; they've just gotten more crafty about the methods of doing so.
Selling open source software has been a cornerstone of open source's sustainability since its inception. Precisely because you can sell it, open source projects like Linux (which Microsoft claims to love) have been estimated to be worth billions of dollars. Microsoft apparently does not want any FOSS developers to be able to write open source in a sustainable way.
Finally, this is a known pattern of Microsoft's behavior. Rolling out unreasonable and unconscionable policies — only to “magnanimously” retract them weeks or months later — is a strategy that they've used before. Indeed, Microsoft employed this exact tactic when originally creating their app store (then marked under the predecessor brand name, “Windows Marketplace”). Initially, Microsoft banned all copyleft licenses from its app store, and when the obvious outrage came, Microsoft cast themselves as benevolently willing to amend the policy and allow FOSS on the Microsoft Store. Of course, we again (as we did then) immediately call on Microsoft to reverse their new anti-FOSS Microsoft Store Policies and make it explicitly clear in these Policies that selling open source is not only allowed but encouraged.
Nevertheless, we're cognizant that Microsoft probably planned all this, anyway — including the community outrage followed by their usual political theater of feigned magnanimity. It seems this is just Microsoft's latest effort to curtail the forms of FOSS activity that don't directly benefit them. Microsoft may say that they love Open Source, but only so far as they exclusively are the ones who profit from FOSS on their platforms.
Update on 2022-07-08: After we and others pointed out this problem, a Microsoft employee claimed via Twitter that they would “delay enforcement” of their new anti-FOSS regulation. We do hope Microsoft will ultimately rectify the matter, and look forward to the change they intend to enact later. Twitter is a reasonable place to promote such a change once it's made, but an indication of non-enforcement by one executive on their personal account is a suboptimal approach. This is a precarious situation for FOSS projects who currently raise funds on the Microsoft Store; they deserve a definitive answer.
Given the tight timetable (just five days!) until the problematic policy actually does go into effect, we call on Microsoft to officially publish a corrected policy now that addresses this point and move the roll-out date at least two months into the future. (We suggest September 16, 2022.) This will allow FOSS projects to digest the new policy with a reasonable amount of time, and give Microsoft time to receive feedback from the impacted projects and FOSS experts.
A Modest Proposal In The New Age of DMCA Takedown Aggression
by 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 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
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!
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.
