![[RSS]](/static/img/feed-icon-14x14.2168a573d0d4.png)
Conservancy Blog
Displaying posts by Denver Gingerich
Fighting for the right to repair your electronics - we need your help
by on May 2, 2022
Defending your right to modify and repair the software on your electronics has been a cornerstone of Software Freedom Conservancy since its inception. We defend these rights in a variety of ways: petitioning the Copyright Office to return our repair and modification rights, investigating reports people send us where companies are using our member projects' code but aren't providing the source or repair and modification information that the project's license requires, contacting those companies to remind them of the license requirements, and (eventually, in rare cases after companies ignore our gentle reminders for many months) filing lawsuits against intransigent companies who refuse to give you the complete source and instructions you deserve (and that they are required to provide by the licenses of the software they freely choose to use).
In the rare cases where Software Freedom Conservancy has been forced to move its enforcement actions from gentle reminders to filing lawsuits, we have used a variety of approaches. Our lawsuit filed in 2007 against several manufacturers, used copyright law (specifically copyrights in the BusyBox project) to compel those manufacturers to comply with the GPL (such as Westinghouse). The lawsuit we filed last year against Vizio takes an approach more appropriate for widely marketed and available consumer devices. Namely, the claim in Vizio is a contract claim for third-party beneficiary rights under the GPL, which will allow us (and all other customers who bought Vizio TV's) to receive the repair and modification instructions to the software more directly.
Since we began enforcing the GPL fifteen years ago, the landscape of GPL violations has deteriorated: GPL'd software now appears in nearly every consumer device smarter than a toaster, and very rarely do the manufacturers even bother to offer source code to users — and almost never does the source release meet the requirements of the GPL. As a result, we at Software Freedom Conservancy continue to dedicate more time and resources to our enforcement efforts. We seek to ensure that the situation does not get even worse, and we believe that we can improve the situation even more.
The best approach, in our view, is to continue to bring a variety of different types of actions against intransigent violators. As always, we use litigation and litigation-like means as a last resort, but we've reached that point with dozens of companies. There are a variety of types of actions we could take and lawsuits that we could bring, and different ways we can go about preparing for them. But, to have the full scope of options, we need your help.
As a contributor to copyleft projects, one way that you can help us right now is to assign the copyrights of your software freedom works to Software Freedom Conservancy. As the Vizio suit shows, copyright-based claims will not be the sole focus of our enforcement. However, there are some key types of products where copyright claims are ideal. By assigning your copyrights to us, you can give us the ability to stand up for your software freedom and rights and, more importantly, the rights of your users. While we understand the FOSS community has some aversions to copyright assignment, we also know that, right now, many developers automatically assign their copyrights to their employers without demanding that their employers stand up for the copyleft rights of their users. We ask the community to reconsider this common practice, and request those who haven't already assigned copyright to their employer to assign their copyrights to us, and we urge those who have entered work-for-hire arrangements with employers ask those employers to give them back their copyrights immediately. (See our ContractPatch project for more information on how to do this.)
Today, we launch our self-service Copyright Assignment form. This new form, carefully vetted by our lawyers, allows you to quickly and easily assign your rights in your code, documentation, and other copyrightable works to Software Freedom Conservancy. We will use these copyrights to ensure companies follow the copyleft licenses that they use. You can assign copyrights for projects that are not members of Software Freedom Conservancy too. We will always enforce them in accordance with our Principles, and we will welcome you onto an internal mailing list and regular meetings to discuss our enforcement efforts.
Through the various software freedom lawsuits we have filed over the years, along with the lawsuits we've helped fund, Software Freedom Conservancy has established a track record of tangible enforcement actions.
We are very happy for all the support we've received from software freedom activists, developers, and other community members over the years in our software freedom enforcement actions. We hope you will continue to support us, and encourage others to do so, in whatever ways you can and, if it makes sense for you, by assigning your software freedom works to us so we can ensure the repairability of your electronics (and everyone else's!) going forward.
Understanding Installation Requirements in GPLv2
by 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”.
Helping each other: the right to repair win and software freedom
by 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!
Asking Microsoft to resign from the RIAA over youtube-dl takedown demand
by 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.
