Conservancy Blog
A Note from Our Executive Director: 2023 and my personal quest for software freedom
by
on December 19, 2023Just when I think that I've really grokked the implications of the technology I have woven into my life, I find that life throws completely new challenges my way that make me realize the extent of the work that we have ahead of us for software freedom.
Front of hospital in Brussels CC-BY-SA 4.0 Karen Sandler
Early this year, in February, as I readied myself for the excitement of receiving an honorary doctorate at KU Leuven, I felt my heart beating strangely. An already scheduled visit to the cardiologist revealed that my inherited heart condition had caused an irregular rhythm. I struggled to walk up even shallow inclines.
I have a heart condition I was born with, called Hypertrophic Cardiomyopathy (HCM). It's a condition that generally causes me no discernible symptoms, but I am at much higher risk of what they call "sudden death" than people without this condition (sudden death is what they call it when your heart ceases its function, for HCM patients, it's often because your heart is beating so fast that it's just fluttering instead of efficiently pumping). This is why I've had, for many years, an implanted pacemaker/defibrillator.
Irregular heart rhythms are common for HCM patients over time but need to be either reverted or treated with medication to live a normal life. The longer one is in an irregular rhythm, the more likely that irregular rhythm will stay and be non-revertable. Facing these new symptoms in early in the year, I needed to determine what I needed to do and whether my travel was still safe. To figure out how best to proceed, my electrophysiologist wanted to know about the history of my irregular rhythms. Luckily, I have my implanted pacemaker/defibrillator — designed to record that important information. Ostensibly, this is one of the purposes of having an implanted medical device: to collect such data to inform my treatment.
Years before, I'd decided to have this device implanted with the greatest of trepidation. Many of the key and important features of this device are implemented in software, not hardware. This is my second device (the previous one eventually had battery failure), So, twice, I've had to decide to make an unfair moral choice: do I maximize my chance of surviving with my heart condition, or do I allow installation of proprietary software in my body?
After I decided to have the device installed, I made serious efforts to actually verify the safety and efficacy of the software in the device myself. I filed Freedom of Information Act (FOIA) requests to review the FDA's approval process of this device. What I discovered horrified me: no one — not the FDA, not the patients, not the doctors, not the public — has ever reviewed the source code of the device, or even done direct testing of the software itself. Only the manufacturer does this, and the FDA reviews their reports.
This is a problem that will take a lifetime of many activists working for patient's rights to solve. In the meantime, I had to make the difficult moral choice whether to allow the device in my body, and ultimately I did - it was simply too dangerous to go without (doctors estimated a 25% chance of suddenly dying before I reached the age of 40). I tried to reduced the harm by choosing a device manufacturer that allowed the radio telemetry to be disabled for security reasons. This was a huge benefit, but ultimately it meant I picked a device made by a company that has a large presence in Europe, but a very small one in the United States. Little did I know that this choice would lead me to another difficult decision, which would again only be difficult because the software in the device is proprietary.
In February 2023, while I scrambled to have data in my device extracted before my trip, I discovered that due to the proprietary nature of the device, no one but a company representative could help me. The only one who worked In my city (a major city!) had gone on vacation to visit family overseas. The company had no other representatives available to help me. After much calling to different numbers of the company, I was able to get a list of hospitals and offices across the city that might have had a machine (oddly, they call them “programmers”) that could interface with (or “interrogate”) my device. Upon calling those locations, only a few actually had the programmers and none of those were able to give me an appointment before I left for Europe.
The helplessness that I felt was a powerful echo of how I felt years ago when I realized that my defibrillator was shocking me unnecessarily when I was pregnant. The only way to stop it was to take (otherwise unnecessary) medication to slow my heart rate down. Proprietary software, installed in my body, led me to no choice but to accept medical treatment that I didn't even need.
This time, even though I live in a major city, just one employee's vacation schedule meant my doctors could not diagnosis my urgent health problem. These heart devices are all locked down. Equipment between companies and also among newer models are *not* interoperable. I and my doctors could not access the critical information in my own body when I needed it most.
Ultimately, I made the difficult and potentially dangerous decision to go to KU Leuven anyway to receive the honorary doctorate. It was an incredible honor and I would have missed a once-in-a-lifetime opportunity. Outraged and frustrated again that I was forced to make a life-or-death decision that would have been much easier to evaluate were it not for proprietary software being the only option for heart devices, I nevertheless went.
Thanks to a fellow software freedom activist who helped me navigate the Belgian medical system, I was able to get my device interrogated there. I confirmed there was not immediate danger, and I used that information to come up with a plan for the rest of my trip and for my healthcare in the coming months. While the trip was a wonderful experience, I'm haunted by that helplessness that comes from having no control over technology I rely on so deeply.
When I returned my cardiologist insisted that I get a wearable device to monitor my heart rate. Knowing my feelings about proprietary software (from all of the times I advocated for software freedom in the doctors office!), he told me “you're not going to like the recommendation I have”: the doctor suggested I get an Apple Watch. As soon as I got home I researched all of the alternatives. I found an FDA approved device that has reliable heart rate monitoring but does not require constant contact with a proprietary mobile device or continuous connection to a centralized, proprietary service. The device is unfortunately proprietary itself, but fortunately has no GPS or other similar tracking, and doesn't mandate additional use of third-party proprietary software. This was still a painful compromise for me. I wish every day that I had access to its source code and the ability to modify its software to better suit my unique heart-monitoring needs. But this is my life and my health, and I'm grateful that I found a solution that I can use while I wait for (and advocate for and support) free solutions to catch up so I can use them instead.
Karen finally getting her device "interrogated" in Brussels. Note the various "programmers" in the background for each different manufacturer's devices. CC-BY-SA 4.0 Bert Van de Poel
Happily, since that happened, surgery has returned my heart to a normal heart rhythm, but my cardiologists have said that my need for the tracking device remains. I hate that I've had to incorporate more proprietary software into my life, but I'm so grateful for the treatment I receive and the years of life I am hopefully gaining.
The ways we rely on our software are not theoretical. They pervade every aspect of our lives, and we must make our decisions carefully — knowing that there will be immediate and long term consequences of those choices.
We should stand strongly for our principles but we must also live. At Software Freedom Conservancy we have the philosophy that it's not enough to just talk about our values, it's all about actually doing work that will move the needle towards achieving software freedom for everyone.
There is at least one, and perhaps a few, rather famous FOSS activists who are fond of declaring that they live their life without using any proprietary software. I am in awe of the luck that their privilege affords them. I had to make a really tough choice: put myself at risk of an untimely death, or put proprietary software in my body. I chose to live — and continue my work advocating against proprietary software.
This year, at SFC, we focused on our partnerships with right to repair organizations to ensure that the software right to repair (which could have helped me to get the information off of my proprietary device) is an important part of the previously hardware-focused conversations. We raised the alarm about John Deere's GPL violations after years of work on the matter. We stayed in regular contact with other organizations to support them and we worked on concrete action items, like the amicus brief we recently co-signed.
Waffles for sale in a Belgian hospital CC-BY-SA 4.0 Karen Sandler
We stood up for the consumer and user rights that are baked into the GPLs and continued to push forward our lawsuit against Vizio — to make sure that everyone must be taken seriously when they ask for source code they are entitled to by the GPLs.
We know that users face real difficulty and often feel like they have few choices. We don't blame anyone who uses proprietary software; instead, we empathize with you because we live in the real world too and face difficult choices. We have campaigns such as Exit Zoom and Give Up GitHub to help you find alternatives to the proprietary software that you're using every day that you'd rather liberate yourselves from.
I do hope that (after you donate to SFC, of course!) each of you will do something to help improve the state of software freedom for yourself or someone you know, even if the solutions aren't 100% perfect, because they make a real difference in people's lives and demonstrate that we can do things differently. Help someone flash their phone with a free build, even though it has some proprietary components to remain functional (keeping it out of the landfill). Introduce someone to a free software app. Put Debian (or another free distro) on some old equipment to give it new life, even though it may remain a secondary device. Start collaborating with someone using a pad instead of centralized cloud services. I for one am looking forward to rooting a robot vacuum this holiday season to be able to control it with a free app that removes the need for centralized connectivity in order to operate at all. Maybe you'll do the same with a garage door opener? Sky's the limit when we work on it together. Let's keep it going bit by bit until all of our software is free.
Happy holidays.
Sourceware thanks Conservancy for their support and urges the community to support Conservancy
by
on November 27, 2023Sourceware is maintained by volunteers, but hardware, bandwidth and servers are provided by sponsors. It is our goal to offer a worry-free, friendly home for Free Software projects. Because Free Software needs Free Infrastructure.
We have only been a Conservancy member project for 6 months, but we started the search for a fiscal sponsor about two years ago. Although we probably didn't really know or understand why we needed one at first or the services they provide.
Sourceware has been a Free Software hosting platform since 1998. As a developer platform for developers getting consensus on technical roadmaps has always been easy. But the discussion on governance took some time. In particular how much influence corporations should get was at times contentious. Sourceware may be volunteer managed, but wouldn't be possible without the hardware, network resources and services provided by some corporate sponsors. The Sourceware community values their independence and the strong community which it manages.
After nine months of discussion we finally settled on joining the Software Freedom Conservancy with a Project Leadership Committee of eight members (Frank Ch. Eigler, Christopher Faylor, Ian Kelling, Ian Lance Taylor, Tom Tromey, Jon Turney, Mark J. Wielaard and Elena Zannoni). Our Fiscal Sponsorship Agreement with the Conservancy states that there cannot be a majority of people affiliated with the same organization (max two members can be employed by the same entity at once). The agreement also states that for projects Sourceware hosts everything will be distributed solely as Free Software and that we will publish all services as Free Software. There is also a conflict of interest policy for the PLC.
Joining the Software Freedom Conservancy as a member project made Sourceware more structured. We have monthly Open Office hours now to learn from the community about any infrastructure issues and then the Sourceware Project Leadership Committee meets to discuss these, set priorities and decide how to spend any funds and/or negotiate with hardware and service partners together with the Software Freedom Conservancy staff.
Projects hosted by Sourceware are part of the core toolchain for GNU/Linux distros, embedded systems, the cloud and, through Cygwin, Windows. Years ago Ken Thompson laid out the roadmap for attacking an operating system via the compiler and other code generation tools. These days these are known as supply chain attacks. The Free Software community should reasonably insist that they be defended against these kinds of attacks with mechanisms for prevention, detection and restoration. We have been encouraging hosted project to write up a security policy which we support with technical infrastructure. Sourceware now offers different ways to attest a patch or email is valid. Using the Sourceware public-inbox instance you can use b4 for patch attestation using dkim, gpg-signed emails or patatt. Projects concerned with source code integrity now have various options to use signed git commits, signed git pushes, or use gitsigur for protecting git repo integrity. And new services, like our snapshots server https://snapshots.sourceware.org/ are run in containers, on separate VMs or servers (thanks to our hardware partners). Sourceware also leverages Conservancy's advisory role in how community projects are impacted by and can comply with recent regulations like the USA Cyber Security Directives and the EU Cyber Resilience Act.
Conservancy staff has been attending conferences to discuss with the Sourceware community, first virtual, then in person. Without having a formal fundraising program we already collected more than $6000 in just 6 months for Sourceware. We got even more support from hardware partners, who provided us with extra servers for our buildbot and to setup new services. We wrote up a Roadmap looking backwards to the last 25 years and looking forwards to the next 25 years. All this resulted in more volunteers showing up helping out.
Having been part of Conservancy for just 6 months has given the community and volunteers running the Sourceware infrastructure confidence in the future. We hope the community will support the Software Freedom Conservancy 2023 Fundraiser and become a Conservancy Sustainer so Conservancy can support more Software Freedom communities like Sourceware.
How I watched a Motion for Summary Judgment hearing
by
on October 12, 2023In SFC's ongoing lawsuit against Vizio asking to receive the source code for the copylefted components on their TVs, last week we had a hearing with the judge to discuss the Motion for Summary Judgment that Vizio filed (requesting that the court reject our case before it even went to trial). A couple of our staff attended in-person (in an Orange County courthouse in Southern California) while others, like myself, watched remotely.
I was hoping to be able to use a standard interface to view the proceedings (such as streaming video provided to a <video/> element on a webpage), but unfortunately that was not available. The only way to view hearings in this court remotely is via Zoom, which SFC has talked about recently. This presented me with a conundrum - do I join via Zoom to see what was said? Or am I prevented from accessing this civic discourse because the court chooses not to use a standard video sharing method, preventing a large segment of society from taking part? As part of their normal practice, the court does not record (nor allow recording except through an official court reporter that can be hired by the parties to take a textual transcript) of proceedings, so I needed to decide with some urgency how to proceed, as failing to join now would mean I couldn't see the hearing at all, neither now nor in the future.
I am not sure how other countries approach this problem, and maybe it is no different elsewhere, but it did concern me deeply how this technical decision to demand the use of proprietary software could leave so many people disenfranchised, both with respect to their legal system, and other public services as well.
As part of SFC's policy to allow the use proprietary software if it is critical to our mission, I decided that it was more important for me to be able to view the proceedings (and avoid charging many hundreds of dollars to SFC for an international flight and hotel). Note that SFC would never require this of me, and would gladly pay for me to attend in-person to avoid the proprietary software, but I felt personally it was the right decision for me to make in this context.
Once this dilemma was resolved (for better or worse), I went through the technical steps required to join the Zoom call for the court hearing, where I was presented with this text:
By clicking "Join", you agree to our {0} and {1}.
Now there were no links to {0} or {1}, so I made some guesses as to what I was agreeing to. In the best case, I was agreeing to nothing, and in the worst case I was agreeing that 0 and 1 provided the foundation for all humanity which, while potentially troubling, did have a certain appeal as a technologist. In any case, I clicked Join (possibly leaving an indelible mark on the future of the universe) and was at last able to observe the hearing, after dialing in by (SIP) phone for the audio, to reduce the amount of proprietary code being run for me to view the hearing.
The hearing event itself was familiar to those who have attended such court proceedings - there were many other cases heard that day, that touched on issues such as whether you could get a DUI while riding a horse (answer: yes), to much more serious and unfortunate clear instances of DARVO tactics in domestic disputes (which we hope will not ultimately sway the judge). It appeared the judge wanted to save our hearing for last, possibly due to its complexity or novelty. The lawyers in most of the other matters appeared remotely.
Once the other cases were heard, the judge turned to us, with both our lawyers and Vizio's lawyer physically present in the courtroom. She asked Vizio to go first (since it was Vizio's motion), and their lawyer went over the points from their Motion for Summary Judgment, eventually clarifying seven specific objections Vizio had made to our case in its motion - the judge had clearly read our brief and wanted to know more on these seven topics given how we addressed them.
It was a bit jarring to hear my own name mentioned in court, as one of the objections was to an email I had sent to Vizio when we informed them they were violating the GPL. While not a problem for our case, it reminded me of the need to be extra careful, since anything we say to a company who violates the GPL can end up in court. But it also reminded me of why it is important we do this: if people feel scared to file lawsuits when companies fail to comply with the software freedom licenses they choose to use, then we at SFC must step up and use our resources and substantial experience to make sure the unfounded claims by companies of how they should be able to get away with violating are firmly rebuffed.
After Vizio's lawyer had finished, the judge turned to our lawyers for a response. Our lawyers presented an excellent litany of reasons why SFC's case is not preempted by copyright (for example, there is an extra element, provision of source code, that copyright remedies do not provide), and why we have rights as a third-party to the GPL contract between Vizio and the developers of the software that Vizio chose to use (as an example, the GPL itself clearly states, "You [Vizio] must make sure that they [third-party recipients such as SFC], too, receive or can get the source code").
Our lawyers finished with some examples of how contract law works, where if you agree to make some copies, but don't pay the money required in the contract, then that's a contract claim, not a copyright claim. In that case, a party has stiffed the beneficiary on the money. And in our case, as our lawyer so eloquently ended the hearing: "Vizio has stiffed us on the code".
We are extremely proud of our lawyers in this case, especially the two lawyers who argued in-person for us on Thursday: Naomi Jane Gray and Don Thompson, as well our General Counsel Rick Sanders. Whether companies are held accountable for following the software right to repair licenses they choose to use is immensely important - they need to give us the same rights they have, and we're incredibly happy that our legal team are so laser-focused on this.
We look forward to hearing the judge's decision on this motion when it comes out (in the meantime, you can read the hearing transcript if you like). Whatever the result, we will keep fighting for your software rights, everywhere software is used, using the legal mechanisms available (when required), to make sure everyone can control their technology.
Software Freedom & Trademarks: Examining Rust's New Policy through the Lens of FOSS History
by
on July 27, 2023When it comes to the law, people working on software freedom are often most concerned about copyright and contract law (and the licenses we use under both), since these appear to most directly affect software freedom. How people can use, study, modify, and redistribute the software is naturally of paramount importance and these laws heavily affect those rights. Generally FOSS projects don't consider their brand as much as the software and community being built, and so other fields of law, like trademark, get less consideration.
However, trademark law can have a significant impact on what people can do with a FOSS project, including whether they can enjoy these rights at all.
Practical software freedom (the right to use, study, modify, and redistribute software you've received) requires meeting several conditions. First, that program must be under a Free and Open Source (FOSS) license. Second, the entity(ies) distributing the program must abide by the terms of the license. And third, there must be no additional restrictions that would inhibit your ability to exercise your rights under the license. (Copyleft licenses include extra verbiage to assure the third condition is met.)
For non-copylefted works, which do not have additional terms in the FOSS license to avoid additional restrictions, we have to verify that no external conditions effectively revoke the rights of users surreptitiously. While that situation is rare, the repercussions can be quite severe. Historically, for some famous software, we've faced such significant challenges. This post is advice to avoid repeating these mistakes of the past. Often, these mistakes occur due to aggressive trademark policies.
Trademarks have value for FOSS; they do reduce confusion between similar products, tools, or programs. When used appropriately, they ensure people know what program they're using, who is behind it, and what they can expect from its behavior. When stretched too far, trademark policies create huge problems in software freedom communities. Sometimes, aggressive trademark policies cause programs that would otherwise give users software freedom to no longer provide the rights users rely on to copy, share, and redistribute the software.
We explore below three historical examples — each of which provide different lessons on how appropriate trademark policies can respect software freedom. We end with a recent situation that could still go either way.
Let's start with Java. As early as 1996, Sun Microsystems was aggressively going after anyone who used the 4 letters "Java" in their name, even if there was no likely confusion. Occasionally, Sun had to apologize for this behavior. Contemporaneous commentators noted: "that doesn't mean that Sun intends to rein in its trademark hawks". As a result, software freedom activists wishing to implement a Java compiler were extremely careful to never use "Java" in a way that could cause Sun to object. One example is the first FOSS implementation of the Java standard library, which developers named "Classpath" (at the suggestion of SFC's now Policy Fellow, Bradley Kuhn) to avoid any whiff of "Java". While Sun later became more friendly to software freedom, this software-freedom-hostile trademark policy persisted for over a decade, creating significant extra work for anyone wanting to create or modify Java programs, as they navigated the confusing naming landscape of not-Java names used for Java tooling.
Next, consider PHP. Starting in 2000, the PHP authors decided to remove the option to use PHP under the General Public License, beginning with PHP version 4. This left users with only the PHP License as an option, which is non-copyleft, but includes extra restrictions beyond most non-copyleft FOSS licenses. Those restrictions specifically related to use of the PHP name. This policy led to substantial debate within many communities, including Debian. Debian eventually decided to create a special policy for PHP in order to feel comfortable redistributing and modifying PHP, which is memorialized on the FTP Masters' web site. Imagine the time and effort wasted by redistributors like Debian, who had to consider special cases for a specific software program. Ultimately, such licensing makes extra work for distributions like Debian, and creates uncertainty for people wishing to modify PHP — as they navigate a license used nowhere else that awkwardly pulls in a trademark policy as part of it.
Finally, and perhaps most importantly, consider the historical situation with Mozilla. Unlike the other two examples (with very little communication between trademark holders and distributors of the software), Mozilla did try to coordinate with groups like Debian. However, Mozilla's demands (beginning in 2004) could not be accommodated without major changes to the programs that Debian and other distributions provided to users. Mozilla was unable to successfully address the legitimate concerns the Debian community raised regarding its policies for a long period of time. As a result, Debian and others spent years doing extra work to rename Firefox, Thunderbird, and other Mozilla projects before distributing them to users. This is perhaps the worst outcome of an improperly-applied trademark policy, as it causes both substantial extra work, and also a loss of brand recognition. Users of Debian and other distributions needed to do extra research to find that they were in fact using Mozilla software that is very similar to the Mozilla-branded versions. Mozilla's retrograde policies for years hurt both the Debian and Mozilla communities. Eventually, Mozilla listened to the community, negotiated fairly, and the policy was changed. The result was a clarification on how reasonable changes to Mozilla programs could retain the Mozilla names, as discussed by the Debian Project Leader involved in the discussions and others in the renaming ticket. In line with core principle 8 of the Debian Free Software Guidelines, there was nothing Debian-specific about the clarification, so all distributors of Mozilla programs could benefit.
With all these examples of trademark policies gone wrong in the first couple decades of the software freedom movement, we must create better policies going forward. Open dialog between trademark holders and software distributors can alleviate concerns over trademark policies' reach, or at least allow distributors to quickly arrive at a conclusion on appropriate next steps. So we do encourage groups with trademark policies (especially those likely to change in the near future) to proactively reach out to those affected, and ask for discussion and/or input to ensure the software freedom community remains strong and healthy.
With this in mind, we turn our attention to Rust, a programming language whose main compiler implementation is managed by the Rust Foundation, a 501(c)(6) trade assocation, comprised of companies with a common business interest. While the trademark policy that is currently in place at the time of this writing appears to be largely accepted by the community, allowing Debian to distribute the Rust Foundation compiler (rustc) to its users per standard Debian policy, there is concern that a draft trademark policy currently under consideration may change this. The draft is available at this link (HTML-only version) — in accordance with SFC's organizational decision to run non-free JavaScript when it is crucial to our work (as this link requires), we have read the document at that link to confirm its contents.
The Rust Foundation's draft trademark policy may require substantial work to avoid the problems of the past. We hope that the Rust Foundation considers the history of trademarks and software freedom that we've discussed above. While the Rust Foundation did briefly open a comment form for public feedback on the above draft, it is unfortunately closed now. We are not aware of any outreach so far by the Rust Foundation to talk with key redistributors, such as Debian, to verify the changes would fit reasonably with long-standing FOSS redistribution policies. Accordingly, we hope the Rust Foundation will open another round of comments in order to solicit further feedback on their draft trademark policy.
After reaching out to someone who is involved with the Rust community and the Foundation, we understand that this policy is still a work in progress and look forward to hearing more about it in the weeks to come. The published policy is not in effect, and we encourage the Rust Foundation, in response to this article, to reach out to relevant parties and ask for assistance and feedback. We're of course happy to help however we can.
To keep our software freedom communities vibrant, communication is key. While we are excited to see the Rust Foundation open to public comment, we hope they will work with the larger FOSS community to find a trademark policy that benefits everyone. With decades of history and experience resolving these issues, the software freedom movement has what it takes to solve these and other pressing issues of today.
Next page (older) » « Previous page (newer)
1 [2] 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64