The Software Freedom Conservancy

Everyone is asking the wrong questions about TikTok

Sat, 18 Jan 2025 21:54:01 -0500

A blog post from Software Freedom Conservancy.

Blog post by Bradley M. Kuhn and Karen M. Sandler. Please email any comments on this entry to [email protected]"><[email protected]>.

As we write this, everyone is wondering what will happen with TikTok in the next 48 hours. Social media as a phenomenon was designed to manufacture drama to sell advertising, and in this moment, the meta-drama is bigger than the in-App drama.

The danger of pervasive software is clear: powerful entities — be they governments or for-profit corporations — should not control the online narrative and remain unregulated in their use of personal data generated by these systems. However, the approach taken by Congress and upheld by SCOTUS remains fundamentally flawed. When there is power imbalance between a software systems' users and its owners, the answer is never “pick a different owner”.

Whoever owns ByteDance, the fundamental problem remains the same: users never really know what data is collected about them, and they don't know how the software manipulates that data when deciding what they are shown next. The problem can only be solved if users can learn, verify, and understand how that software works.

TikTok is a software system — implemented in two parts: somewhere, there is a server (or, likely, a group of servers), running the software that gathers and aggregates posts, and then there is the client software — the App — installed on users' devices. In both cases, ByteDance likely owns and controls both pieces of technology and is the only entity with access to the “source code” — the human readable software that can be studied and understood by human beings. When users download the TikTok App, they don't get that source code for the App, and certainly get no information about the software running on the servers.

If the USA operations of TikTok are sold to another entity, quite likely the software itself will remain in control of ByteDance. While the wording in the Act is expansive about the required divestment, it's likely the new USA owners wouldn't themselves receive the right to review or modify the source code — they could just receive a binary (non-source form) of that software. In that case, no one in the USA will have permission to review and verify that software behaves in a way that is in the interest of its USA users. The Act is vague on these details. Will complete, corresponding source code ultimately be considered part of “a qualified divestiture”? The Act simply leaves "an interagency process", with no guidance (to our knowledge) on the issue of server or App source code. (We have seen similar failures where government agencies with a duty to examine software found in medical devices do not actually even have access to the source code.)

The root problem is that the act doesn't require an action that would truly resolve the biggest threat to TikTok users in the USA. Users (and our government) should instead insist that, to operate in the USA, that ByteDance respect the software rights and freedoms of their users by releasing both the server and App components of the software under a “free and open source” (FOSS) license. FOSS respects the software rights of all by allowing everyone to review, modify, improve, and reinstall their own versions of the software. By technical necessity, this means that everyone could understand the communication protocol between the App and the servers. Users (or third-party App makers) could, for example, modify the App to no longer send users down the rabbit hole of toxic recommended posts, or refuse to transmit user usage data back to the servers in China. FOSS is the best method we have to democratize technology and its algorithms.

Industry will, of course, ask how could a new company, build around a purely FOSS platform, ever generate the revenue necessary to run the network of servers and implement needed improvements to the App? The answer to that is, in fact, part of the beauty to this solution. The primary reasons that sites like TikTok are so toxic is inherent in their business model: privacy-unfriendly data gathering to sell targeted advertising. Indeed, these issues are raised as serious concerns by individuals from all over the political spectrum and they are the primary reason the initial bill passed the House so easily. If we demanded a FOSS and transparent business model, TikTok would have little choice but to move to subscription-based revenue instead of advertising.

As we continue on the dystopian path where most of our technological solutions are funded primarily by advertising and massive, privacy-invading data collection, we must decide if the price that we pay for this technology is just too high. From our perspective, $14.99/month (plus full transparency and software rights) looks a lot better than $0 (plus no privacy and a daily dose of advertisements and occasional CCP propaganda). As the saying goes, if you don't pay for the product, you are the product.

Furthermore, a mandated FOSS release more directly exposes the true problem that the mandated sale tried to solve. We are not politically naïve; we know ByteDance would resist releasing TikTok (server and App) as FOSS just as much as they resisted the mandated sale. But the real problem we have is that we simply don't know if the Chinese government has undue influence over TikTok or not. We have that problem primarily because we cannot examine their opaque technology. Transparent technology leads the only way to the truth in our software-controlled world.

2024 End-of-Year Fundraiser Succeeds: over $480k to support software freedom

Thu, 16 Jan 2025 19:31:40 -0500

A blog post from Software Freedom Conservancy.

Blog post by Daniel Takamori. Please email any comments on this entry to [email protected]"><[email protected]>.

We thank both donors who offered this historic $204,877 match & those who gave to help to exceed the challenge

In late November, SFC, with the help of a group of generous individuals who pledged match gifts large and small, posted a huge challenge to our donors. We were so thankful for the donors who came together to offer others a match challenge of $204,877 — which was substantially larger than any of our match challenges in history.

Donors heard our ask, and we were even more thankful of all the donors who responded. Toward the end, we were so overwhelmed by last minute response that we were tabulating updates by hand. We saw so many donors who had already given coming in for another $10, $50 or $100 to get us there. We made the match primarily because of the hundreds of small donors who came in with Sustainer amounts, and we thank those small donors so much for often doing a bit extra: so many of you hit the $512 and even the $1024 button instead of the minimum of $128. It means so much to us when we see a donor who gave $128 in 2023 double their donation for 2024 — you all made this match challenge succeed. We also so appreciate the donors who, despite experiencing financial challenges, gave smaller amounts when it was a stretch for them to give at all.

Most surprising of all, an anonymous donor who in the past has made a very large donation around the time of FOSDEM came in early this year. That donation bursts us right through our status bar and puts us well over. We've raised over $475,000 this season, which is now reflected on our fundraiser status bar. (We're still tabulating and entering the paper checks and ACH/wire transactions that came during the final days of the fundraiser, so the number may soon increase even more!)

We are truly humbled. Every year, our staff is working tirelessly through the holiday season to make sure we balance our work and fundraising. Every dollar you all give us is noticed and appreciated, and gets us there, step by step.

SFC does receive some grants and corporate sponsorship for which we are also grateful, but the bulk of our funding comes from individual donors, like you. Fundraising is (sometimes annoyingly) mandatory work that as a small staff we must do in addition to our normal work. Nevertheless, it's a simple fact that the more you donate, the more program activity we can do. In essence, you make our important work for software freedom and rights.

Karen Sandler interviews Cory Doctorow

Wed, 15 Jan 2025 17:51:06 -0500

A blog post from Software Freedom Conservancy.

Blog post by Daniel Takamori. Please email any comments on this entry to [email protected]"><[email protected]>.

Our Executive Director Karen Sandler recently sat down with Cory Doctorow to talk about software right to repair, the utility and history of DMCA exemptions, and some of the differences between the way laws take effect in different places around the world. Doctorow is widely known for his speculative fiction touching on issues of technology, activism, and post-scarcity economics. We were so excited for this conversation, many on SFC staff are fans and had a great time preparing for the conversation.

Covering a range of topics, it was great to hear from Cory about how proprietary platforms can actually lead to conversations with loved ones about interoperability. Of particular note was a discussion about the similarities to the accessibility rights movement. Interoperability and accessibility are fundamental rights that technology should empower us to have, but often times we need to advocate and fight for those rights.

If you run out of things you can do with code, there's nothing wrong with mounting a big normative campaign. If the norms aren't doing it for you...

With a good appreciation of history combined with a forward looking eye Doctorow's unique perspective sheds light on how the free software movement can be more open to availing itself to the wider public. We look forward to a future where more people are brought into the conversations and issues that today's technology forces us to reckon with.

Karen talked about the potential of software freedom and in particular the opportunities inherent in all copyleft licenses to completely change the way ordinary people experience technology that impacts them. She talked about the concrete and incremental work Software Freedom Conservancy does to move the needle towards ethical technology.

Thanks to Cory for sitting down with Karen and having a great conversation that we hope inspires you as much as us to look to the future with eagerness and energy for change!

PS: Today is the last day of our fundraiser, so if you like content like this, please donate now to support us in making things like this happen!

SFC Files Amicus Brief in Support of Users' Rights under AGPLv3§7

Mon, 13 Jan 2025 19:31:47 -0500

A news item from Software Freedom Conservancy.

SFC Defends Copyleft Licensing in Important Federal Circuit Appeal

SFC filed an amicus brief in the ongoing case of Neo4j, Inc. v. PureThink, LLC, which is now appealed to the United States Court of Appeals for the Ninth Circuit. The appeal focuses on a downstream licensee's right under the Affero General Public License, version 3 (and similar rights under GPLv3 and LGPLv3) to remove “Further Restrictions” — even when such restrictions are put in place by original licensors. SFC was proud to stand up for this important right under copyleft, and appears to be the only organization that filed an amicus brief in this case.

While the case in the lower court covered many issues, SFC's amicus brief focuses on one key important issue: the right for licensees — be it for commercial or non-commercial reasons — to remove further restrictions placed by Neo4j — pursuant to this unqualified right enshrined in AGPLv3§7¶4:

If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term.

Neo4j had appended the non-free Commons Clause at the end of the the full, unmodified text of the AGPLv3 (including its original preamble) to create what Neo4j dubbed the “Neo4j Sweden Software License”. There was no dispute that the so-called “Commons Clause” was a “further restriction” that could be removed under AGPLv3 §7¶4. But Neo4j had argued (and the lower court agreed) that this right was in conflict with AGPLv3 §10¶3 (which, in part, prohibits licensees from adding “further restrictions”). Neo4j further argued (and the lower court agreed) that since §10¶3 did not mention licensors explicitly, then not only must licensors have the right to add “further restrictions” but this implicit right trumped the licensees' explicit right to remove such restrictions under §7¶4.

SFC's amicus brief in this case argues that the lower court erred when it agreed with Neo4j's interpretation of AGPLv3§§7/10. Neo4j included the entire text of the AGPLv3, including AGPLv3 §7 and the AGPLv3 preamble, and licensees legitimately were within their rights to follow what the terms said (as informed by the preamble) and remove the appended proprietarizing modifier. Our brief provided detailed legal analysis that we hope will convince the Court to uphold the principles of software freedom and users' rights under copyleft in this situation.

Amicus briefs take a great deal of effort, and unfortunately the appellate court is not obligated to give them any weight. Nevertheless, we do hope the Court and other organizations will hear our voice on this important matter. The language of AGPLv3§7¶4 and §10¶3 is found in other GPLs. The lower court's interpretation, if upheld on appeal, could radically alter the community's understanding of whether and how “further restrictions” (and not just the so-called “Commons Clause”) may be added and removed.

SFC thanks outside counsel Aaron Williamson who helped with this brief. You can review SFC's amicus brief in full here.

SFC-funded lawsuit gets software repair and reinstall for users of AVM routers

Thu, 09 Jan 2025 08:36:00 -0500

A news item from Software Freedom Conservancy.

AVM chooses not to appeal purchaser's suit that established users' rights on wireless router

Software Freedom Conservancy (SFC) today announces the conclusion of a lawsuit that we funded and supported in Germany. (As is typical with German cases, SFC was unable to give public updates during the case.) The defendant, Berlin-based AVM, ultimately delivered the necessary information to reinstall modified software on their device. Delivery of this information resolved the lawsuit. The plaintiff was Sebastian Steck, who received a grant from SFC to pursue this work. Steck purchased an AVM router in May 2021 and quickly found that the source code candidate which AVM sent him could not be compiled and reinstalled onto his router. AVM, the largest home router manufacturer in Germany, refused to correct its source code candidate. Steck sued AVM in a Berlin court in July 2023.

Months after the lawsuit was filed, AVM finally provided Steck with all remaining source code that Steck requested, including “the scripts used to control … installation of the library”. Steck brought his claim under copyleft terms of the Lesser General Public License, version 2.1 (LGPLv2.1). As part of the case's resolution, AVM paid Steck's attorney's fees. The appeal deadline elapsed two weeks ago. AVM chose not to appeal the court's ruling on the fees.

The favorable result of this lawsuit exemplifies the power of copyleft — granting users the freedom to modify, repair, and secure the software on their own devices. Companies like AVM receive these immense benefits themselves. This lawsuit reminded AVM that downstream users must receive those very same rights under copyleft.

Historically, lawsuits have focused on the copyrights licensed under GPL (or the GPL and LGPL together). Steck's lawsuit uniquely focused exclusively on users' rights under the LGPL. Steck's work showed that despite being a "Lesser" license than GPL, LGPLv2.1 still guarantees users the right to repair, modify and reinstall modified versions of the software on their device. There is now no doubt that both GPL and LGPL mandate the device owner's ability to make changes to the software in the flash memory so those changes persist across reboots. AVM initially tried to claim that changes in volatile memory (RAM) would suffice, but Steck successfully argued that users must be able to install such changes to the permanent storage. AVM eventually provided the required installation information for just that.

Both SFC and Steck remain frustrated that companies like AVM usually ignore user requests under copyleft until a lawsuit is filed. Nevertheless, we are happy to see that the legal process confirmed Steck's rights, and required AVM to pay Steck's legal costs. “I am pleased that this litigation compelled AVM to provide the compilation and reinstallation information in the filings,” Steck said. “I look forward to them amending their publicly available source code archives with the complete scripts used to control compilation and installation soon.” In the meantime, we at SFC published these updated source code archives ourselves, along with the key court documents in the case.

Embroidery and resilient software freedom in 2025

Mon, 06 Jan 2025 18:55:31 -0500

A blog post from Software Freedom Conservancy.

Blog post by Sage A. Sharp. Please email any comments on this entry to [email protected]"><[email protected]>.

CC-BY-NA 4.0 Sage Sharp

I spent most of 2024 recovering from a spine injury after a car accident. I’d love to share my new insight into free software accessibility, and how both free software and embroidery helped me build resiliency. I’ve been working on a special embroidery that I’ll send to a donor who gives to Software Freedom Conservancy on January 8. We hope if you are able to give you’ll consider donating!

Outreachy Team AMA

Please join me on January 8 for a Q&A session with the SFC staff and contractors who run the Outreachy internship program. After the Outreachy organizer Q&A, join me for a crafting session while I work on the SFC logo embroidery.

There will be two Q&A sessions with the Outreachy team to accommodate time zones. You can join us on BigBlueButton at the times below (information is also in the attached .ics files):

First chat on Wednesday:

Wednesday 8 January 2025 at 9AM (09:00) US/Eastern (-0500)
Wednesday 8 January 2025 at 6AM (06:00) US/Pacific (-0800)
Wednesday 8 January 2025 at 3PM (06:00) Europe/Central (+0100)
date -d "2025-01-08 14:00 UTC"

Second chat on Wednesday:

Wednesday 8 January 2025 at 9PM (09:00) US/Eastern (-0500)
Wednesday 8 January 2025 at 6PM (06:00) US/Pacific (-0800)
Thursday 8 January 2025 at 1PM (13:00) Australia/East (+1100)
date -d "2025-01-09 02:00 UTC"

My healing journey

In February 2024, my car was rear-ended. The impact damaged the nerves from my shoulder to my hand.

I had pain and tingling in my fingers for 6 months. Everything I touched felt like picking up a cactcus.

It was painful to type on a keyboard. Touching my phone, either to swipe or type, hurt.

This chronic pain made it hard to do my normal work tasks as Software Freedom Conservancy’s Senior Director of Diversity and Inclusion, and an organizer for Outreachy internships. Most free software communication happens via email or text chat. Which meant a whole lot of very painful typing for me.

Luckily, free and open source software helped me find a more accessible way to work. I dreaded looking for accessibility software because I knew it’s usually both expensive and proprietary. I was so excited to find speech to text free software like vosk for the Linux desktop. For my phone, I found sayboard, a speech to text Android keyboard that uses vosk.

Free software allowed me to switch away from using my hands to write, and towards using my voice to write. I wrote this email using those tools. I am so grateful to the free software developers who helped me avoid hand and shoulder pain.

Accessibility in FOSS

My injury also gave me a new perspective on the gaps in software accessibility best practices. Very few free software projects offer options to accommodate people who have pain whenever they touch a screen, use a keyboard, or click a mouse button.

Free software developers rarely think about how many actions it takes to do a particular task. How many mouse clicks does it take to find information on a website? How many phone screen touches does it take to use that new feature?

When I have to go through five software actions to do a task, my brain translates each mouse click, phone screen touch, and keyboard press into feeling like a needle is poking my finger. Extra actions to complete a task are literal pain points for me.

I encourage other free software developers to explore how many touches, clicks, or key presses it takes to do a common task. My fellow Outreachy organizer, Anna e só, mentioned there is a whole field of Human-Computer Interaction research around minimizing software task overhead.

I encourage other free software developers to study their project’s gulfs of evaluation and execution. Identifying the extra actions it takes to execute a task may help you understand how software contributes to chronic hand pain. Anna recommends reading the book “The Design of Everyday Things” by Donald A. Norman to get started learning about this field research.

Community support and accommodations

Even with somewhat improved free software accessibility, I still needed time to rest and recover. SFC staff and the Outreachy team helped me reassign tasks that required a lot of typing or mouse movement. They encouraged me to find verbal and audio-based work. I also shared knowledge and processes so that any team member could do critical tasks.

I am so grateful to SFC and the Outreachy team for their flexibility and accommodation of my short term disability.

While my body was healing, I thought a lot about the right to repair, both for software and for physical objects. Why do we decide an object is beyond repair, and must be replaced by something expensive and new? Why do companies put out products that easily break physically, or will become obsolete or insecure due to a lack of software updates?

In a world of shiny fragile tech toys and easy to consume fast fashion, I felt out of place. I felt like my healing body would be viewed as imperfect, broken, and disposable. I worried that opening up about my invisible disabilities would cause people to view me as needing to be replaced.

My identity as a free software contributor was so dependent on using my hands. My outdoor hobbies involved climbing over rocks or gripping a walking stick for a long time, both of which caused hand and back pain. Who was I, if I could not use my hands in ways I was used to?

Resiliency and Embroidery

While I was healing, I needed to be more gentle with my physical self. I also wanted a hobby that would help me rebuild my hand dexterity and nerve sensation. So I took up embroidery.

When it came time for the SFC fundraiser, I knew I couldn’t be on social media as much because it would cause additional hand and back pain to be so online. Instead I decided to create an embroidered art piece that would encourage people to donate to Software Freedom Conservancy.

Other SFC staff were excited about my embroidery project, and crafting became a theme for SFC’s fundraiser. SFC’s yearly post card features SFC’s tree logo re-imagined as a cross-stitch. We also created a special t-shirt design (available if you become a sustainer ) this year that features a work-in-progress cross-stitch of SFC’s logo. In both free software and crafting projects, there is always something to more improve or work on.

I’m so excited to send my embroidered art to an SFC donor. My embroidery is an artistic take on Software Freedom Conservancy’s tree logo. It features the words ‘Grow Software Freedom’, and ‘2024 Sustainer’.

A tree cannot thrive without good water and sunlight. SFC cannot thrive without your support. I encourage you to donate today at https://sfconservancy.org/sustainer/.

Donate for Embroidery

Your donation to Software Freedom Conservancy will help us grow software freedom together.

My embroidered art will go to the top donor SFC’s fundraiser, from the time you receive this email until end of day (AOE) on January 8th. If the top donor doesn’t want it, the art will go to a random donor, including anyone who donated from the start of Conservancy’s fundraiser through January 8th.

This means even if you can only give a smaller amount to support Conservancy, there is still a chance you may receive this SFC art. Every donation to SFC helps us sustain software freedom!

I hope you will take heart in my recovery journey. If it inspires you, please use that energy to support software freedom, especially the right to repair and accessibility.

I encourage you to donate to Software Freedom Conservancy to build the resilient future free software needs.

Sage Sharp
Senior Director of Diversity and Inclusion at Software Freedom Conservancy
Cultural Change Agent at Outreachy

Kuleana and software freedom for the future

Mon, 23 Dec 2024 16:00:25 -0500

A blog post from Software Freedom Conservancy.

Blog post by Daniel Takamori. Please email any comments on this entry to [email protected]"><[email protected]>.

Pono and Meredith in Hawai'i - CC-BY-NA 4.0 Pono Takamori

During the holiday season I really want to share with you some thoughts on why software freedom is so important to me. Please donate during our fundraiser (and have you donation doubled from our matchers!). Also please see the note at the bottom about 2 Q&A sessions we’ll be having on December 27th and 30th!

My name is Pono, a name my native Hawaiian grandmother gave me. In Hawaiian we have a word: kuleana. A duty to take care of the land and the people around you given your own gifts and abilities. It’s been an important concept to me to guide me and share my passions and desires for a better world with the community around me. I came to Software Freedom Conservancy first as a Sustainer and activist, and then years later an employee. Software Freedom is an interesting area to think about place, because the digital world sometimes feels like an astral plane, so distant from our everyday lives. But the reality is that we can inhabit the physical world and digital world at the same time. Whether it’s liberating farming equipment so that we can repair the software on tools vital for food production or making sure that the internet connected devices in our homes are not spying on us, our stewardship for the Earth and for the digital spaces we occupy are not distinct but intertwined.

My wife and I are expecting our first child soon. We’re so excited for the future and how the three of us will grow and experience the world together. And while software freedom certainly wasn’t the first thing on our minds in this situation, we’ve already encountered baby gear that is internet connected and has moved to subscription model for existing features (this article from The Register talks about it as well as the letter we signed to the FTC advocating against such technology). It’s frustrating the many ways that our technology is dictated to us, when it is from our own labor that all this technology is created in the first place [footnote]. What does software freedom look like to someone growing up in a world filled with proprietary cloud based software, an increasing surveillance state, and corporations seeking to lock you in the their walled gardens?

Working for Software Freedom Conservancy has been amazing to work with community to build our collective future. We focus on protecting technological rights that corporations continually belittle and seek to undermine. Working with such an incredibly passionate and small team is something that makes advocating for software freedom feel good. Our activism, while sometimes driven to fight back against unchecked power, has it’s roots in the joy and liberation of programming and cooperation of our digital activities. It’s a long road ahead, but we must remember that there is joy to be had along the way.

I’m sure by wishing my daughter has an interest in computers, she will wind up finding her joy somewhere else. But isn’t that what we want? Regardless of technical proficiency or interest, we want to guarantee rights for all people. My kuleana is knowing that I’ve been given abilities and an interest in computing; I have a responsibility to others to make sure they are afforded the same rights and privileges I’ve attained.

I’m so thankful for the opportunity to share my story and why I think software freedom is a necessary (if not sufficient) condition for human liberation. It's my humble ask to support our organization you spread the word and tell a friend or family member about what we do. But if you are able to give this season, your contribution will be doubled during our fundraiser :)

While the annual sustainership level is $128/year, you can make monthly donations and get all the benefits of sustaining SFC for lightly less (at just $10/month)!

We’d also like to invite you to a Q&A with our Executive Director Karen Sandler and Policy Fellow Bradley M. Kuhn on the evening of December 27th and morning of December 30th. Use the commands below to find your local time.

$ date -d "2024-12-27 14:00 UTC"

$ date -d "2024-12-31 02:00 UTC"

Join us in #conservancy on libera.chat or our [email protected]?join">XMPP channel at those times for the BigBlueButton link. Can’t wait to see you!

Maholo nui loa,

— Daniel Sean Pono Takamori

footnote: The Luddites get a bad rap, but they were the skilled laborers who fought against technology replacing them in a way that's very reminiscent to our own movement. I highly recommend Brian Merchant's book "Blood in the Machine: The Origins of the Rebellion Against Big Tech"

Matcher interview with Emily Dunham - 2024 Fundraiser

Thu, 19 Dec 2024 23:43:54 -0500

A blog post from Software Freedom Conservancy.

Blog post by Daniel Takamori. Please email any comments on this entry to [email protected]"><[email protected]>.

CC-BY-NA 4.0 Emily Dunham

Next up in our matcher interview series is Emily Dunham (edunham). Having been involved in free software for almost 20 years, her work has spanned all kinds of places from working at Mozilla with the Rust community to being a developer advocate and now being at Okta. Thanks to Emily for the incredible interview!

SFC: Tell us a bit about yourself! Where are you from, what are some of your hobbies?

edunham: I'm from the middle of nowhere, grew up off-grid in a tiny community where I still live and volunteer to this day. I've been working remotely in tech since around 2014, in various ops and automation roles for a series of Californian tech companies. I'm barely aware of how fundamentally this forestry-community upbringing shaped my worldview, except for how it causes the culture shock of bay-area thinkers being okay with planning only a year or a quarter ahead.

I have a rotating portfolio of hobbies where if I share about too many at once, it starts to sound like I'm exaggerating for comedic effect. Right now, in November of 2024, my free time is going to a combination of revisiting Skyrim Special Edition and addressing my backlog of "that seems like a neat idea, but..." topics with the fallible but well-read tutelage and co-thinking of claude.ai and, soon, local more-open models. (Claude is very helpful for bootstrapping into a toolchain to deliver similar benefits while being less at the mercy of some distant corporation choosing to keep offering it as a product, not unlike learning to brake and steer in an automatic vehicle before learning to drive a manual). There are a lot of surprises about AI that each individual who meets it has to have for themself at this moment in history, so I'm working on getting those out of the way without sounding too silly about it, because that seems like a prerequisite for making any useful contribution to our collective thought about and understanding of it. I'm quiet on the socials these days, but that might change as I continue building out the cognitive prosthetics to let me do more of the things I want to. I'm also halfway through a couple baby quilts for friends who are expecting next spring (if you're wondering, AI is unhelpful past the point of uselessness so far with quilting).

SFC: Why do you care about software freedom? How long have you been involved?

edunham: I care because it's good for me -- like I care about my garden because fresh veggies are delicious, or I care about keeping on top of routine maintenance around the house because it's super inconvenient to have to fix things if one lets them get to a point where they break.

I think everyone has their version of Stallman's printer story, and mine is the high school robotics team. We had these huge corporations throwing money and resources, especially "free" licenses for expensive software, at us left and right. This confused me, and I asked "why" enough times to eventually get the picture: They wanted us to build marketable job skills with specific proprietary technology so that we would go to employers and demand that they buy us a license for expensive proprietary software. They wanted us to invest our time in skills that they could then hold for ransom. We have plenty of mythology about the importance of thinking very carefully before entering that kind of contract with a more-powerful-than-human entity, so I thought through it carefully, and declined the offer.

My rule of thumb for investing time in learning a software tool is that I must be able to take that tool with me, online or offline. Software is cognitive prosthetics, and I'm lucky enough to have a choice among many options, unlike physical prosthetics like Karen's augmented heart. The tools I can keep with me through my life, without depending on money or an employer to maintain my access to the skills I've invested my own time in refining, tend to be free software.

SFC: How do you use free software in your life?

edunham: Free software is the invisible infrastructure that facilitates basically every benefit our species derives from computers. We hide it well, because free software often chooses raw power over generic usability -- it's like the logistics areas of an airport rather than the public spaces. But let's say I drive to the store to get some groceries. Maybe the traffic is bad, so I pull up google maps to get its opinion of the fastest route. First, I'm using an Android phone, so there's decades of Linux work underpinning its existence. But even on an iPhone, GPS "just works" and knows where the device is at by receiving signals from satellites and cell towers. How do those signals turn into a location? It's basically because all the devices agree on exactly what time it is, and they do that using the NTP stack and referencing public timeservers. (if you know with enough precision when a signal was sent and when it was received, and you know the speed at which it propagated, you know the distance it traveled. so from there it's just triangulation with multiple satellites or cell towers) Maybe I check my bank balance on my phone as I walk into the store, to make sure I know how much is in the account for the debit card I'll pay with later. My ability to do that safely instead of having my banking details easily stolen relies on encryption that's usually implemented using free software tools. And then the food at the store, from all over the world -- that got into the store through supply chains that use servers, databases, sometimes mainframes, and I'd challenge you to name any one of those systems with no load-bearing free software utility in its creation and maintenance. XKCD 2347 holds true. That's barely scratching the surface, as there's a whole lot more free software and right-to-repair concerns in growing the food before it even touches those systems!

SFC: On the spectrum on developer to end user, where do you lie? And how do you think we could do better bridging that divide?

edunham: The closest tech stereotype to how I relate to development is that of "ops guy". I love automation -- there's something so satisfying and grounded about working in a feedback loop where I am among my own customers. It often sidesteps that philosophical quagmire about what a more distant user's problem "really is" and when it's "really solved".

edunham: I think you could do better at reaching out to people so un-technical that they don't even realize they're the end users. You do targeted outreach to non-technical people in political positions of power, and I'll bet you're learning insights about what works and what doesn't that would scale excellently to the populations who vote for those people as representatives of their way of being. In other words, I suspect that your model of communicating with lawmakers has a lot of room for trying to scale to their constituencies.

SFC: What's got you most excited from the past year of our work?

edunham: Selfishly, you held FOSSY, which was like everything I missed out on by being a rural middle schooler during the early OSCON days. In the bigger picture, your DMCA work is ground-breaking, and the continued focus on right to repair should be of great interest to anyone who likes eating food that comes from farms where farmers wear these amazing mechanical exoskeletons of agricultural equipment to produce produce at a literally superhuman scale.

SFC: Do you think we are doing a good job reaching a wider audience and do you see us at places you expect?

edunham: I'm blissfully unaware of how wide an audience you reach. It's one of those problems where if nobody was successfully dealing with it, I'd feel like I "had to" help out more directly... but that kind of work is definitely not above the fold in my list of ways i'd rather be spending my time, so I'm grateful that you have it handled.

SFC: Have you been involved with any of our member projects in the past?

edunham: I'm doing this interview on an Etherpad as we speak, connecting using hardware running OpeWrt. I use Git on a daily basis to get my work done... Wine gives me games, Selenium gives me automation even when things don't offer a featureful api. I worked at the OSU OSL back in the day and did more direct ops support for some of the projects, but the intersection of my time availability, interests, and skillset doesn't have me contributing directly to any Conservancy projects at the moment.

SFC: How do you see our role amongst the various FLOSS organizations?

edunham: I get the luxury of not caring deeply about who does what role in the FLOSS organization landscape. I categorize you loosely as an organization that focuses on interfacing with the US government and helping it notice and course correct when it accidentally passes legislation that violates the principles on which it was founded. Translating modern tech concepts into "normal" human terms is really hard, especially when the people you're talking to might hold the belief that they already know the things which are worth knowing, so having as many unique approaches as possible to this challenge seems to bring far more value than trying to somehow consolidate them all. It's like by having a lot of organizations which each specialize in a high-impact area of opportunity, we demonstrate the engineering principle of building many simple utilities that excel at their tasks.

SFC: Do you think we do a good job standing up to the organizations with more corporate funding?

edunham: I think you do a good job of standing up to the organizations which are accidentally anti-freedom, and working within their worlds to explain how freedom is good actually. I hope you're not standing up to other software freedom organizations except when absolutely necessary, because the potential impact and good of working together is on a whole other scale from the potential good of infighting about less-important details.

SFC: What other organizations are you supporting this year?

edunham: I'm actually not that into the whole "donate money to charity" thing as a first line of social impact, because I'm uncomfortable with the harmonics of systems where giving money incentivizes asking for more money. I support my community by volunteering as an EMT and firefighter; I support local businesses by spending at them even when it's more expensive or less convenient than buying the same thing online. And I support roads and schools and stuff, along with the other side effects, by paying my taxes. But I happen to work at a larger corporation that offers a holiday giving match, and I strongly believe that corporations should do more to support the FOSS that they rely on, so what better way to combine these beliefs than leveraging their matching funds program to double a donation to Conservancy?

Linux banned Russian contributors. Does my FOSS project need to worry about U.S. Sanctions?

Thu, 12 Dec 2024 14:22:09 -0500

A blog post from Software Freedom Conservancy.

Blog post by Rick Sanders. Please email any comments on this entry to [email protected]"><[email protected]>.

Since the Linux project removed a number of entries from the MAINTAINERS ﬁle, all of whom were putatively Russian, in October, we've been receiving questions about U.S. sanctions against Russia and what, if anything, we should do about them. As I explain below, our position is that such drastic action, though defensible, is unnecessary.

What would compel the Linux project to take action against speciﬁcally Russian contributors—and is it a good enough reason such that other FOSS project should follow suit? The Linux project has access to the lawyers of the Linux Foundation, after all. Unfortunately, the Linux project's initial announcement said only that the removals were due to various compliance requirements. The announcement added that the Russian contributors can come back in the future if sufficient documentation is provided. But it didn't say what sort of documentation would be required. Linus Torvalds added a little clarity when he said that "sanctions" were the cause.

Speculation quickly centered on Executive Order (“EO”) 14071, one of the U.S. sanctions against Russian. It had recently been expanded to include software development and IT services, just a month before the Linux project's announcement. (EO 14071 dates to April 2022, but its scope is expanded from time to time to include new industries.)

The problem with this theory is that EO 14071 doesn't apply to contributions from a Russian national to a software project (even though it now applies to software development). It is true that, when a Russian national makes a copyrightable contribution to a software project governed by the GPL, the Russian national enters into a contractual relationship with (at least) all downstream distributors. But EO 14071 doesn't sanction any and all contractual relations with Russian nationals. It only prevents the provision of certain software- and IT-related services (including software development and consulting) to Russian nationals from a “U.S. person”. In other words, EO 14071 works in reverse to the Linux project's situation.

So, if it's not EO 14071, could it be some other U.S. sanction? There are, after all, quite a number of them. On October 24, James Bottomley provided something of an answer. Citing Linux Foundation lawyers, Bottomley wrote that the Linux project means to exclude companies on the U.S. OFAC SDN lists, subject to an OFAC sanctions program, or owned/controlled by a company the list. (OFAC is the Office of Foreign Assets Control, a division of the Treasury Department, in charge of maintaining these sorts of sanctions. SDN means “Specially Designated Nationals,” i.e., persons and businesses, as opposed to entire regimes.) Under this analysis, the documentation referenced in the initial announcement would be paperwork tending to prove that the contributor did not work for such a sanctioned company.

Alas, this doesn't tell us very much. Not only are there several U.S. sanctions against Russians, which cover different activites and serve different purposes, but each of them affects its own set of (overlapping) Russian parties. Wading one's way though these sanctions is a slog that almost no FOSS projects can possibly wade through. You have to parse the actual statutory and regulatory language, review later regulations and executive orders that might alter the sanction's scope, check whether a given Russian individual or entity is subject to that particular sanction (because two given sanctions don't necessarily apply to the same Russians), then check whether your activity or relationship with that Russian individual or entity is covered by the sanction. (On the upside, the U.S. government provides a handy website that allows you to check which sanctions, if any, affect a particular Russian person or entity. But, even if you can be sure you've checked the right person/entity, you still need to determine whether the sanction actually applies to your own activity.)

This is a lot of work. And I think that explains the Linux project's cautious approach: namely, suspending all Russian contributions to the project temporarily; then checking each contributor, case-by-case; and (presumably) reinstate them if they don't show up on any sanctions list. Even this strategy might not be feasible for many if not most projects. They might be more reliant on Russian contributions, be less able to withstand the blowback from sudden suspensions, or simply lack the legal resources.

In my view, none of the Russian sanctions prevents Russians from contributing to American-based software projects governed by the GPL. While the approach taken by the Linux project is reasonable and understandable, I do not believe SFC's projects to take similar actions at this time.

Besides, the spirit of FOSS, I think, requires a bias toward acceptance of otherwise valid and competent contributions. The goal is great software that, in many cases, affirmatively improves people's lives. Rejecting good contributions undermines that goal. Further, rejecting otherwise good contributions does nothing to further the sanctions' goals. The sanctions are primarily intended to punish Russia for, and to degrade its ability to conduct, its interference in U.S. elections, its flouting of international rules, and its aggression in Ukraine. It is difficult to see how rejecting Russian contributions furthers any of these goals.

There remains one final mystery. Some of these Russian sanctions are several years old, so why is this an issue now? My best guess is that EO 14071 brought the issue of Russian sanctions to Linux Foundations's attention because it was explicitly directed at software development. Even if EO 14071 was found to be inapplicable, Linux Foundation couldn't ignore the whole raft of other Russian sanctions, which would take time to sort through.

Ideally, we could keep geopolitics (and lawyers!) out of FOSS. But that's not always possible. U.S. sanctions are one reason. There's no harm in being cautious, so long as the spirit of FOSS is respected. Different projects and organizations will reasonably come to different conclusions on this matter.

Links to the documents referenced above:

OFAC FAQ 1128, which sets forth various expansions of EO 14071:
OFAC FAQ 1187, which explains what's covered by "IT consultancy and design services."
OFAC's webpage re: Russia-related sanctions
OFAC's Sanctions List Search

2024 Fundraising matcher interview with Patrick Masson

Thu, 05 Dec 2024 16:29:39 -0500

A blog post from Software Freedom Conservancy.

Blog post by Daniel Takamori. Please email any comments on this entry to [email protected]"><[email protected]>.

CC-BY-NA 4.0 Patrick Masson

We're so happy to feature our incredible matchers this year! Thanks to all of them for contributing to our largest match goal yet. Today we're talking with Patrick Masson, Executive Director of the Apereo Foundation.

SFC: Tell us a bit about yourself! Where are you from, what are some of your hobbies? Social media?

Patrick: I am currently the Executive Director of the Apereo Foundation. Apereo was established in 2012 as a non-profit organization and works to support and develop open source software for higher education. The foundation's mission is to assist academia in developing, adopting, and maintaining open source software for teaching, learning, and research. Before Apereo, I was the General Manager of the Open Source Initiative. I have also worked in higher education as a CIO of The State University of New York, Delhi, and CTO at the University of Massachusetts, Office of the President. I started my career as a Scientific Illustrator, moving from pen and ink to computer-generated imaging, thus leading to my later roles in academic computing and free and open-source software.

I live in Albany, New York, moving here from southern California (San Diego and Santa Monica) about 20 years ago. I am on Mastodon at @[email protected]. I have a Twitter account, but it is dormant and redirects to Mastodon. I'm on LinkedIn but rarely participate. In addition to working at Apereo, I am an adjunct professor at The University at Albany, teaching "Open Source Princinples and Practices" in the College of Computing & Information. I also served on my local school board for four years, 2014-2018. I enjoy playing hockey and biking (slow touring, nothing serious) with my wife, Jamie. We have two sons--and despite all my tutelage and advocacy, one works for Microsoft as a software engineer developing very proprietary video games--Thanksgiving is tough ;-).

SFC: Why do you care about software freedom? How long have you been involved?

Patrick: I first discovered Free Software in the early 90s while working at UCLA. My work focused on medical and scientific visualization. Many of the tools we used from academic and research initiatives were readily shared. The idea of "software freedom" was not well established (or perhaps known to me) then. Rather, universities worked under traditional, collaborative models where peers created cohorts of practice around shared research interests and efforts. The software was just another output of research to be peer-reviewed, edited, built upon, and used by researchers as needed (That sounds like "software freedom"). While we did use software that today carries an OSI Approved License (remember this is before the OSI was founded), including Linux, NCSA HTTPd, some FTP servers, etc., most of the software was community-built, where collaboration, cooperation, and co-creation, were the drivers. No one thought about this beyond the software-specific use cases driving development at an institution or across research efforts. While not labeled as such, the ideals or ethos, practices, and benefits of software freedom took root with me then.

SFC: How do you use free software in your life?

Patrick: I use free and open source software daily and emphasize its use, from my home computing (mobile phone, laptop, and desktops) to professionally at the Apereo Foundation. Working for an organization advocating and supporting free and open source software, I feel it is essential that "we eat our own dogfood." As such, my work computer runs Linux and only FOSS tools/applications, and we strive to deploy FOSS for our business and administrative computing, e.g., Drupal for our website, CiviCRM for our constituent management, BigBlueButton for web conferencing, XWiki for our document management, etc. Truth be told, a few legacy systems are in place, but as opportunities arise to migrate, I expect to do so. How can we convince the institutions we reach out to that FOSS is a viable option if we've not also selected that option?

SFC: On the spectrum on developer to end user, where do you lie? And how do you think we could do better bridging that divide?

Patrick: Like many in our industry, "career advancement" often requires moving away from developer to administrative roles. So, while I am--and always will be--an end user personally and an advocate for free and open source software within the organizations I work with, I do not do any significant development (coding) of software these days. I suppose it could be said that my "development" efforts today are focused on developing organizations that create and maintain free and open-source software and the communities of practice that make it all possible. My efforts (building awareness, fostering adoption, and promoting contributions) include developing an authentic ecosystem beyond software communities were free and open source software--and even the ideals/ethos--can thrive throughout industries and institutoins.

SFC: Tell us about how Apereo is forwarding software freedom and about your role in the org.

Patrick: I joined Apereo just over two years ago. At the time, Apereo primarily served as a fiscal sponsor for open source software developed by academic and research institutions. As free and open source software has become operational on campuses and fundamental to research activities, Apereo is extending its role in supporting educational, administrative, and research computing through software freedom. Many campuses have opportunities through grant funders and consortia initiatives to adopt and even develop their own free and open source software. Campuses, too, rely on open source software created internally or even developed and deployed by trusted third-party service providers. In response, Apereo offers "OSPO as a Service" and "Foundation as a Service." support models where campuses can access Apereo expertise and services to manage their own internal open source software projects locally or outsource their initiatives to the Apereo Foundation. Despite the long history of the practice, especially in higher education where many free and open source projects began, software freedom is still poorly understood by many outside technology fields (i.e., faculty, researchers, administrators). Apereo is working to foster authentic engagement to realize the maximum benefits of software freedom.

Institutions of higher education have an inherent understanding and an appreciation for software freedom as it aligns with and supports academic freedom. Guiding principles include the open exchange of ideas and the pursuit of knowledge. Both prioritize transparency, collaboration, and the freedom to explore, modify, and share work without undue restrictions. In higher education, academic freedom empowers scholars to research and teach freely, fostering innovation and critical thinking. Similarly, software freedom enables developers to study, adapt, and improve code, driving technological progress and accessibility. Together, these principles create an ecosystem that values intellectual curiosity, shared learning, and the democratization of knowledge. Apereo's vision is for an academy where both flourish and mutual support creates a thriving environment for education and technology to grow together.

SFC: What's got you most excited from the past year of our work?

Patrick: FOSSY, FOSSY, FOSSY!!! While there are several activities SFC undertook this year (and has undertaken for many years, hosting several important projects, Outreachy, license protection, general advocacy etc. etc., etc.), organizing and delivering a software freedom-focused conference was for Apereo (and me personally) a highlight. It is not simply because it provides a forum for peer communities of practice to meet after such a dearth of opportunities (due to COVID, OSCON shutting down, etc.), but because the event so well aligns with Apereo's direction and strategy.

For Apereo, the event is a perfect opportunity to work with the free and open source community--projects, foundations, industry, experts, advocates--to introduce the higher education community--institutions, faculty, researchers, administrators--through shared interests and activities. Rarely do these two groups interact, and Apereo--because of FOSSY and SFC--has another touch point to facilitate greater engagement and productivity; we were thrilled to run the FOSS for Education track and are excited to submit a proposal again for the track in 2025. SFC's work to grow and mature the event is phenomenal and inspiring. I am sure FOSSY will continue to grow in size and impact, and Apereo is dedicated to supporting it as best we can through community and contributions.

SFC: What issues happened this past year that you were happy we spoke about?

Patrick: While the history and activities undertaken by SFC related to AI and LLMs extend back to 2020, the recent announcement, "Aspirational Statement on LLM-backed generative AI for Programming," was uniquely prominent for Apereo and higher education. While there are many issues related to AI, two fundamental concerns among institutions of higher education are bias and reproducibility. AI is taking higher ed by storm--if you attended the recent EDUCAUSE Annual Conference, you know what I am talking about. However, real concerns should be evident considering how and where AI "solutions" are being marketed.

A core tenet of research is reproducibility. Research reproducibility suffers significantly when AI models, particularly LLMs, and the datasets used to train them are closed-source or proprietary; transparency, black box algorithms, independent verification/validation, accessibility/equity, etc., are all issues that may impact research and hinder discovery. The same applies to administrative systems where bias, ethical concerns, and a general lack of accountability can impact student and faculty affairs.

I was also delighted to see SFC's response was "aspirational" and delivered in a tone to help and contribute.

SFC: Do you think we are doing a good job reaching a wider audience and do you see us at places you expect?

Patrick: I think SFC--like other organizations working with shared values and a common vision, like Apereo--is in a tough spot. Despite the 30 years of history, many organizations are either unaware or unengaged with free and open source software. Gone are the early days (2004-2012?) where open source was the hot topic, marketing magic, and investors' and industry's funding choice. While the adoption and dependency on FOSS are greater than ever (especially in higher education), actual support and participation by those who most rely on sustainable communities and the projects they produce are declining (disappearing?).

Reaching a wider audience is a real challenge, considering reaching the current audience- which should already be engaging- is so difficult (and frustrating). I honestly believe organizations will come to appreciate the importance of supporting the FOSS core to their business and operations, especially with growing external pressures (e.g., the Cyber Resiliency Act, Software Bill of Materials) combined with new opportunities (e.g., increased funding from granting organizations). While several new organizations are popping up--which, in my opinion, are simply chasing the latest money and buzz--those like SFC, with years of services, credibility with the community, and authenticity in practice, will emerge as fundamental resources and valuable services for organizations that choose to best leverage FOSS for their benefit and the benefit of others.

SFC: Have you been involved with any of our member projects in the past?

Patrick: While most of my involvement has been as an end-user (e.g., I have several scientific illustrations created in Inkscape and published in medical and dental textbooks and journals), I have been most active with the Teaching Open Source project run by Heidi Ellis and Greg Hislop. Considering the project's focus on using open source software and technologies to teach computer science and other disiplines, it's probably obvious why I am involved.

SFC: How do you see our role amongst the various FLOSS organizations?

Patrick: "Supporting the supporters." I rely on SFC as a resource for Apereo's foundational work, which extends Apereo's capacity and capabilities in service to our constituents in higher education. Examples include policy analysis and advocacy, copyleft compliance, the aforementioned "Statement on LLM-backed generative AI," etc. In this sense, SFC serves a similar role to the OSI, where organizations like Apereo, whose focus is "FOSS outward facing," i.e., connecting with end-users, benefit from SFC's "FOSS inward facing," i.e., connecting with FOSS organizations on broader issues impacting their constituent communities.

SFC: Do you think we do a good job standing up to the organizations with more corporate funding?

Patrick: Times are tough for FOSS foundations, and funding from all sources should be pursued. I think SFC does a good job with corporate sponsorship- everyone knows what SFC is all about, and SFC has stayed true to its mission and is authentic in its practices. I do not feel SFC has compromised its credibility or shied away from issues based on corporate support.

SFC: What other organizations are you supporting this year?

Patrick: I am committed to supporting the FOSS projects and foundations I use (rely on) personally or professionally. I consider this no different than those who pay annually for proprietary software. Both models need funding to develop software, but FOSS is a better deal for the consumer: lower TCO, funds that support development--not profits, the ability to help shape the project (features and functions), etc. It is simply a better/smarter business decision for organizations (and individuals) to pay for FOSS than proprietary software.

OpenWrt One: manufacturing software freedom

Tue, 03 Dec 2024 00:54:05 -0500

A blog post from Software Freedom Conservancy.

Blog post by Denver Gingerich. Please email any comments on this entry to [email protected]"><[email protected]>.

Software cannot run without hardware. To have software freedom, we need hardware to run our software. Sadly, the vast majority of hardware is not built with software freedom in mind. Too often, we are beholden to the big hardware companies that sell us our laptops, phones, routers, TVs and other devices. Few manufacturers today build devices with user modifiability and longevity in mind. And it's getting worse. Hardware is becoming more and more locked down, making the need for devices that will work in our interests more and more acute.

Software Freedom Conservancy announced on Friday, in conjuction with our OpenWrt member project, that the first router designed from the ground up by the OpenWrt community is now shipping. OpenWrt developers and SFC staff have been coordinating over the past year to design and produce a hardware device that showcases the best of what OpenWrt has to offer. From the upstream-first approach, to the up-front source code availability, no stone was left unturned in ensuring the device would give people flexibility and control over the software (and hardware) that runs their network.

SFC works toward GPL compliance across the industry, so the devices running Linux out there (which now include toasters, dishwashers, fridges, and dryers, as well as laptops, phones, routers, and TVs) all comply with the copyleft terms that give you the right to modify and reinstall changes onto your device. GPL enforcement is one way we tackle this problem, but we constantly seek other approaches. In the case of OpenWrt, we have yet another example that shows the device manufacturers that haven't yet complied with the GPL (and given users the rights they are owed) how to do it right — to give people what they want and what the GPL requires.

We are very excited to watch the interesting applications you find for your OpenWrt One. We're amazed and impressed to learn some people are already running Doom and other software that just won't run on a router that you buy from one of the big name router brands. :) We think it's important for people to have the freedom to make their software work for them, to explore, and enjoy their software experience. The GPL and other copyleft licenses exist to make this possible.

The OpenWrt One is admittedly not perfect. It's sadly a prime example of hardware from recent eras that relies on a few binary component firmwares (in this case, for small parts of the wifi, 2.5 GbE port, and RAM calibration). It is difficult to construct modern hardware without a few of these binary blobs. While this reality is a travesty, we are excited that nearly all the source code for the software on the OpenWrt One is freely licensed. This ensures the maximum possible ability to repair and improve the device. We hope the device will last, and someday, since the binary parts are electronically upgradable, future users can replace the binary component firmwares as FOSS replacements become available. The design and distribution of the OpenWrt One shows that it is not only possible to distribute a device containing both copylefted and non-FOSS code, but that it is also cost-effective and straight-forward to comply with the relevant licenses, and allow users to modify and reinstall the device from source.

SFC wants to build this future of freedom for all your electronics (especially those running Linux and other GPL'd software). I work every day through private channels (and the courts, when needed) to get companies to respect your rights under the GPL. I'm ecstatic that we're now creating new hardware to show the world what is possible when we put software rights first! We're excited for everyone to join us on this journey, and encourage you to read our OpenWrt One launch announcement for more details on this first step.

We just started our annual fundraiser and we'd be thrilled if you could support us by becoming a sustainer. For a limited time, until January 15 (or $204,887 of donations), all donations will be matched, so renew or become a Sustainer today! Thanks for helping us bring software freedom (and hardware respecting it) to everyone!

First Router Designed Specifically For OpenWrt Released

Fri, 29 Nov 2024 13:05:07 -0500

A news item from Software Freedom Conservancy.

The New OpenWrt One on sale now for $89 — Ultimate Gift for Right-To-Repair Enthusiasts

Today, we at SFC, along with our OpenWrt member project, announce the production release of the OpenWrt One. This is the first wireless Internet router designed and built with your software freedom and right to repair in mind. The OpenWrt One will never be locked down and is forever unbrickable. This device services your needs as its owner and user. Everyone deserves control of their computing. The OpenWrt One takes a great first step toward bringing software rights to your home: you can control your own network with the software of your choice, and ensure your right to change, modify, and repair it as you like.

The OpenWrt One demonstrates what's possible when hardware designers and manufacturers prioritize your software right to repair; OpenWrt One exuberantly follows these requirements of the copyleft licenses of Linux and other GPL'd programs. This device provides the fully copyleft-compliant source code release from the start. Device owners have all the rights as intended on Day 1; device owners are encouraged to take full advantage of these rights to improve and repair the software on their OpenWrt One.

Priced at US$89 for a complete OpenWrt One with case, it's ready for a wide variety of use cases. Manufactured in collaboration with Banana Pi, the OpenWrt One uses the MediaTek MT7981B SoC, with MT7976C wifi, 1 GiB DDR4 RAM, 128 MiB SPI NAND + 4 MiB SPI NOR flash, two Ethernet ports (2.5 GbE and 1 GbE), a USB host port, M.2 2042 for NVMe SSD or similar devices, and mikroBUS expansion header. The OpenWrt offers both PoE (Power over Ethernet) via the 2.5 GbE port , or direct power via the USB-C power port with 12V USB-PD. A convenient USB serial interface is built into the other USB-C port: expert users won't miss any boot messages! This hacker-friendly device is unbrickable, providing a switch to separately flash the NOR and NAND portions of the flash memory.

This new product has completed full FCC compliance tests; it's confirmed that OpenWrt met all of the FCC compliance requirements. Industry “conventional wisdom” often argues that FCC requirements somehow conflict with the software right to repair. SFC has long argued that's pure FUD. We at SFC and OpenWrt have now proved copyleft compliance, the software right to repair, and FCC requirements are all attainable in one product!

You can order an OpenWrt One now! Since today is the traditional day in the USA when folks buy gifts for love ones, we urge you to invest in a wireless router that can last! We do expect that for orders placed today, sellers will deliver by December 22 in most countries.

Everyone can purchase a complete OpenWrt One with case via that link and other sale outlets, too. Regardless of where you buy from, for every purchase of a new OpenWrt One, a US$10 donation will go to the OpenWrt earmarked fund at Software Freedom Conservancy. Your purchase not only improves your software right to repair, but also helps OpenWrt and SFC continue to improve the important software and software freedom on which we all rely!

An interview with Anna e só

Thu, 28 Nov 2024 14:16:29 -0500

A blog post from Software Freedom Conservancy.

Blog post by Karen Sandler. Please email any comments on this entry to [email protected]"><[email protected]>.

Today is Thanksgiving in the United States, and I am so grateful for all of the amazing people worldwide who are working together towards software freedom.

I am excited to share with you this video where I recently sat down with Anna e só, one of our intrepid Outreachy organizers. Anna is one of the voices I'm most excited to hear from, especially about the most important issues concerning our digital freedoms.

In the interview, we got so excited talking about Anna's experiences and thoughts that we didn't even get to topics related to diversity and inclusion. We'll have to do it again! I'm sure you'll understand from watching this discussion why I'm so thankful to work with Anna!

2024 Fundraiser launches with historic match challenge!

Tue, 26 Nov 2024 14:41:22 -0500

A news item from Software Freedom Conservancy.

$204,887 for software freedom pledged

The 2024 Software Freedom Conservancy match fundraiser launches today with an historic $204,887 match total! That means for every dollar you donate before January 15th 2025, our generous individual matchers will donate the same, making your donation go twice as far until we reach our goal! SFC prides itself on being funded by individuals like you, who believe that software freedom is a right for everyone.

Our matchers include people giving large donations but also people who are giving small amounts as their budget allows because they care about software freedom. This year, we're so grateful to highlight Sustainers Kyle Wiens (CEO of iFixit), Holger Kienle, Emily Dunham, and Patrick Masson. Look forward to some interviews about what makes software freedom important to them and why they continue to support our mission driven work.

We have been extremely busy this year! Our pursuit of copyleft compliance ramps up with completely new efforts like Use the Source and coalition building with Right to Repair groups. Our commitment to diversity and inclusion within free software remains a priority, and programs like Outreachy continue to serve and grow our community.

Software Freedom Conservancy has always spoken to current issues and trends in technology; we think it's incredibly important to stand up for all users and our fundamental digital freedoms. In that vein we've spoken out at various regulatory processes, technology conferences and created an aspirational statement on generative AI. We see the technology as secondary, serving people should always be first.

Our member projects dedicated to providing freedom respecting technology have achieved major successes this year, like the hardware project, the OpenWrt One (which will be generally available by the end of the year), improved supply chain security and high quality tooling for open standards. You can read a detailed account of what we've been up to in our Year in Review.

Please renew or become a Sustainer now and help us kick off this fundraising season.

Success in the DMCA triennial

Thu, 31 Oct 2024 16:11:07 -0400

A news item from Software Freedom Conservancy.

Director of Compliance, Denver Gingerich, speaking before the Library of Congress

Software Freedom Conservancy is proud to announce its successful work in the latest triennial DMCA exemption process to stand up for the rights of FOSS developers. This week, the Copyright Office granted all of the exemptions we requested, according to the final rule Exemption to Prohibition on Circumvention of Copyright Protection Systems for Access Control Technologies. Due to these rulings, the LoC renewed the DMCA exemptions SFC established for the jailbreaking of routers and smart TVs, and for investigating copyleft compliance. Our executive director, Karen Sandler, also successfully participated in a coalition of medical device researchers in a request to renew the exemption for medical devices. SFC's Director of Compliance, Denver Gingerich, also participated and gave testimony during the hearings (for Computer Programs—Repair, led by iFixit and discussed below) when the LoC was looking for expert opinion.

In their rule making, the Librarian of Congress fully summarized our submission regarding license investigations, concluding that we "demonstrated personal knowledge and experience regarding the exemption."

Jailbreaking of routers + smart TVs

This is technically two separate exemptions, one for routing equipment and one for smart TVs, but the Copyright office referred to them together in their ruling, showing that we are making progress in advocating for the critical need for consumers to retain control of their own equipment across different types of devices. The exemptions allow the so called jailbreaking of these devices for alternative firmware that extends the lifetime of the devices as well as expands software capabilities. We are especially happy to receive this exemption for our member project OpenWrt, a critically important piece of software. Another exemption was for "smart televisions" which "includes both internet-enabled televisions, as well as devices that are physically separate from a television and whose primary purpose is to run software applications". This is great news for streaming devices which have alternative firmwares and also the whole swath of free software that can run on such devices. Protecting consumers from "planned obsolescence" by extending the lifetime of their devices, as well as protecting our freedoms by allowing us to run our own software on the devices.

License investigation

We're also proud of the exemption for circumvention of technological measures for purposes of investigating and confirming violations of FOSS license. To see the Library of Congress recognize the importance of protecting software licensing shows just how far we've come in terms of FOSS advocacy. This explicitly allows license investigation to continue, and we at Software Freedom Conservancy hope that others will take up the cause of holding device manufacturers accountable to their use of copyleft and other FOSS licensed software so that people can exercise their software freedom rights. This ruling, regrettably, continues to disallow such investigation into video game consoles, but we believe that, with persistence, the LoC will come to see that these general purpose computers that happen to play video games, also require the same kind of exemptions. This renewed exemption is vitally important to the future of free software, as without understanding what software is running on our devices, we are unable to guarantee that licensing terms are met, that newcomers are informed that they have rights with respect to their software and our freedoms for using free software are preserved.

Medical devices

Our Executive Director Karen Sandler, along with Hugo Campos and Jay Radcliffe, filed for DMCA exemptions to medical devices which was submitted and defended by the USC Gould School of Law. The request was signed by Karen, and cited the difficulty she had accessing the information on her defibrillator during 2023. This exemption dovetails with requests made by small companies seeking to gain the right to repair medical equipment during this triennial process, which were also successful.

Onwards

Seeing the Librarian of Congress continue to grant our exemptions shows that the work we are doing is being received well by governmental entities. Without such advocacy, the power corporations have over our technology would be reducing innovation, harming our freedom, and stifling our voices. The work that SFC does in protecting and defending digital rights is expansive and this policy work is just one way that we are dedicated to defending our rights.

We would also like to point out that iFixit filed an exemption for "Computer Programs—Repair of Motorized Land Vehicles, Marine Vessels, or Mechanized Agricultural, Vehicles or Vessels" which helps protect the software right to repair for vehicles including farm equipment like tractors. In an increasingly software driven world, the importance of protecting all our technology incredibly vital. Our relationship with iFixit and various right to repair organizations has shown how important this kind of intersectional approach to activism and advocacy is.

Many thanks for our General Counsel, Rick Sanders, who drafted and shepherded these filings.

Open Source AI Definition Erodes the Meaning of “Open Source”

Thu, 31 Oct 2024 12:51:09 -0400

A blog post from Software Freedom Conservancy.

Blog post by Bradley M. Kuhn. Please email any comments on this entry to [email protected]"><[email protected]>.

This week, the Open Source Initiative (OSI) made their new Open Source Artificial Intelligence Definition (OSAID) official with its 1.0 release. With this announcement, we have reached the moment that software freedom advocates have feared for decades: the definition of “open source” — with which OSI was entrusted — now differs in significant ways from the views of most software freedom advocates.

There has been substantial acrimony during the drafting process of OSAID, and this blog post does not summarize all the community complaints about the OSAID and its drafting process. Other bloggers and the press have covered those. The TLDR here, IMO is simply stated: the OSAID fails to require reproducibility by the public of the scientific process of building these systems, because the OSAID fails to place sufficient requirements on the licensing and public disclosure of training sets for so-called “Open Source” systems. The OSI refused to add this requirement because of a fundamental flaw in their process; they decided that “there was no point in publishing a definition that no existing AI system could currently meet”. This fundamental compromise undermined the community process, and amplified the role of stakeholders who would financially benefit from OSI's retroactive declaration that their systems are “open source”. The OSI should have refrained from publishing a definition yet, and instead labeled this document as ”recommendations” for now.

As the publication date of the OSAID approached, I could not help but remember a fascinating statement that Donald E. Knuth, one of the founders of the field of computer science, once said: [M]y role is to be on the bottom of things. … I try to digest … knowledge into a form that is accessible to people who don't have time for such study. If we wish to engage in the highly philosophical (and easily politically corruptible) task of defining what terms like “software freedom” and “open source” mean, we must learn to be on the “bottom of things”. OSI made an unforced error in this regard. While they could have humbly announced this as “recommendations” or “guidelines”, they instead formalized it as a “definition” — with equivalent authority to their OSD.

Yet, OSI itself only turned its attention to AI only recently, when they announced their “deep dive” — for which Microsoft's GitHub was OSI's “Thought Leader”. OSI has responded too rapidly to this industry ballyhoo. Their celerity of response made OSI an easy target for regulatory capture.

By comparison, the original OSD was first published in February 1999. That was at least twelve years after the widespread industry adoption of various FOSS programs (such as the GNU C Compiler and BSD). The concept was explored and discussed publicly (under the moniker “Free Software”) for decades before it was officially “defined”. The OSI announced itself as the “marketing department for Free Software” and based the OSD in large part on the independently developed Debian Free Software Guidelines (DFSG). The OSD was thus the culmination of decades of thought and consideration, and primarily developed by a third-party (Debian) — which provided a balance on OSI's authority. (Interestingly, some folks from Debian are attempting to check OSI's authority again due to the premature publication of the OSAID.)

OSI claims that they must move quickly so that they can counter the software companies from coopting the term “open source” for their own aims. But OSI failed to pursue trademark protection for “open source” in the early days, so the OSI can't stop Mark Zuckerberg and his cronies in any event from using the “open source” moniker for his Facebook and Instagram products — let alone his new Llama product. Furthermore, OSI's insistence that the definition was urgently needed and that the definition be engineered as a retrofit to apply to an existing, available system has yielded troublesome results. Simply put, OSI has a tiny sample set to examine, in 2024, of what LLM-backed generative AI systems look like. To make a final decision about the software freedom and rights implications of such a nascent field led to an automatic bias to accept the actions of first movers as legitimate. By making this definition official too soon, OSI has endorsed demonstrably bad LLM-backed generative AI systems as “open source” by definition!

OSI also disenfranchised the users and content creators in this process. FOSS activists should be engaging with the larger discussions with impacted communities of content creators about what “open source” means to them, and how they feel about incorporation of their data in the training sets into these third-party systems. The line between data and code is so easily crossed with these systems that we cannot rely on old, rote conclusions that the “data is separate and can be proprietary (or even unavailable), and yet the system remains ‘open source’”. That adage fails us when analyzing this technology, and we must take careful steps — free from the for-profit corporate interest of AI fervor — as we decide how our well-established philosophies apply to these changes.

FOSS activists err when we unilaterally dictate and define what is ethical, moral, open and Free in areas outside of software. Software rights theorists can (and should) make meaningful contributions in these other areas, but not without substantial collaboration with those creative individuals who produce the source material. Where were the painters, the novelists, the actors, the playwrights, the musicians, and the poets in the OSAID drafting process? The OSD was (of course) easier because our community is mostly programmers and developers (or folks adjacent to those fields); software creators knew best how to consider philosophical implications of pure software products. The OSI, and the folks in its leadership, definitely know software well, but I wouldn't name any of them (or myself) as great thinkers in these many areas outside software that are noticeably impacted by the promulgation of LLMs that are trained on those creative works. The Open Source community remains consistently in danger of excessive insularity, and the OSAID is an unfortunate example of how insular we can be.

Meanwhile, I have spent literally months of time over the last 30 years trying to make sure the coalition of software freedom & rights activists remained in basic congruence (at least publicly) with those (like OSI) who are oriented towards a more for-profit and corporate open source approach. Until today, I was always able to say: “I believe that anything the OSI calls ‘open source’ gives you all the rights and freedoms that you deserve”. I now cannot say that again unless/until the OSI revokes the OSAID. Unfortunately, that Rubicon may have now been permanently crossed! OSI has purposely made it politically unviable for them to revoke the OSAID. Instead, they plan only incremental updates to the OSAID. Once entities begin to rely on this definition as written, OSI will find it nearly impossible to later declare systems that were “open source” under 1.0 as no longer so (under later versions). So, we are likely stuck with OSAID's key problems forever. OSI undermines its position as a philosophical leader in Open Source as long as OSAID 1.0 stands as a formal defintion.

I truly don't know for sure (yet) if the only way to respect user rights in an LLM-backed generative AI system is to only use training sets that are publicly available and licensed under Free Software licenses. I do believe that's the ideal and preferred form for modification of those systems. Nevertheless, a generally useful technical system that is built by collapsing data (in essence, via highly lossy compression) into a table of floating point numbers is philosophically much more complicated than binary software and its Corresponding Source. So, having studied the issue myself, I believe the Socratic Epiphany currently applies. Perhaps there is an acceptable spot for compromise regarding the issues of training set licensing, availability and similar reproducibility issues. My instincts, after 25 years as a software rights philosopher, lead me to believe that it will take at least a decade for our best minds to find a reasonable answer on where the bright line is of acceptable behavior with regard to these AI systems. While OSI claims their OSAID is humble, I beg to differ. The humble act now is to admit that it was just too soon to publish a “definition” and rebrand these the OSAID 1.0 as “current recommendations”. That might not grab as many headlines or raise as much money as the OSAID did, but it's the moral and ethical way out of this bad situation.

Finally, rather than merely be a pundit on this matter, I am instead today putting myself forward to try to be part of the solution. I plan to run for the OSI Board of Directors at the next elections on a single-issue platform: I will work arduously for my entire term to see the OSAID repealed, and republished not as a definition, but merely recommendations, and to also issue a statement that OSI published the definition sooner than was appropriate. I'll write further about the matter as the next OSI Board election approaches. I also call on other software rights activists to run with me on a similar platform; the OSI has myriad seats that are elected by different constituents, so there is opportunity to run as a ticket on this issue. (Please contact me privately if you'd like to be involved with this ticket at the next OSI Board election. Note, though, that election results are not actually binding, as OSI's by-laws allow the current Board to reject results of the elections.)

SFC Announces Aspirational Statement on LLM-backed generative AI for Programming

Fri, 25 Oct 2024 15:20:40 -0400

A news item from Software Freedom Conservancy.

In 2022, Software Freedom Conservancy (SFC) convened a committee in the wake of Microsoft's GitHub Copilot announcement, to meet and begin considering the complex questions that arise from the use of large language models (LLMs) in generative AI systems that seek to assist software developers.

Today, we announce a joint statement by this committee, entitled Machine-Learning-Assisted Programming that Respects User Freedom.

Everyone on our committee has watched as interest in this issue has grown in the FOSS community. While the Committee was initially convened to consider how copyleft related to these systems, our focus changed as we considered the complex issues. With the unending influx of models, products, and projects in this area, we began to see a potential dystopia: no systems available today are reproducible by the public, and all of them seem to disrespect user rights and freedoms in some manner. Rather than despair, we turned our minds to what FOSS does best: imagining the ideal if corporate interests were not the primary force defining society's relationship with software.

In the past, the FOSS community has responded to new challenges with a race-to-the-bottom document that defines the bare minimum of user rights and freedoms that the community of activists will accept. For-profit companies hope to legitimately claim whatever they produce is “FOSS enough”. As such, we have avoided any process that effectively auto-endorses the problematic practices of companies whose proprietary products are already widely deployed . No system, particularly a proprietary one, should ever be "too big to fail".

While our proposal may seem unrealistic, nearly every proposal in the history of FOSS has seemed unrealistic — until it happened. We call on the FOSS community to not lament what is, but to dream and strive for what can be. The statement follows:

Machine-Learning-Assisted Programming that Respects User Freedom

There has been intense industry ballyhoo about a specific branch of Artificial Intelligence (AI): generative AI backed by large language models (LLMs). We have reached an era in computing history where input data sets for many different types of works are quite large (after decades of Internet content archiving), and hardware is powerful enough to rebuild LLMs repetitively. As FOSS (Free and Open Source Software) activists, we must turn at least a modicum of attention to the matter, lest its future be dominated by the same proprietary software companies that have curtailed user rights for so long.

LLM-backed generative AI impacts the rights of everyone — including developers, creators, and users. Software freedom, both in theory and practice, yields substantial public good. Yet, traditional, narrow FOSS analysis has boundaries and confines; it's inadequate when applied to these technologies.

We propose an aspirational vision of a FOSS, LLM-backed generative AI system for computer-assisted programming that software rights supporters would be proud to use and improve.

This narrow approach is by design. We are keenly cognizant that LLMs have been built for myriad works — from visual art, to the spoken human voice, to music, to literature, to actors' performances. However, this document focuses on systems that employ LLM-backed generative AI to assist programmers because such systems have a critical role in the future of FOSS. While the impact of AI-based programming assistants' in the daily life of programmers remains unclear (in the long term), it seems likely that AI assistants have the potential to advance FOSS goals around the democratization of software development. For example, such systems help newcomers get started with unfamiliar codebases. We must look hopefully to these technologies and seek ways to deploy them that help everyone.

Aspirational Target for a Software-Rights-Respecting AI Assisted Programming System

The ideal system for generative-AI-assisted programming should have the following properties:

The system is built using only FOSS, and is used only for the creation of FOSS, and never for proprietary software. In this manner, the system would propagate and improve interest in software freedom and rights.
The system must respect the principle of “FOSS in, FOSS out, and FOSS throughout”. In detail, this means:
1. All software and generally useful technical information (including but not limited to: user interface code and applications for generating new material from the model, data cleaning code, model architecture, hyper parameters, model weights, and the model itself) needed to create the system are freely available to the public under a FOSS license¹.
2. All training data should be fully identified, and available freely and publicly on the Internet, under a FOSS license.
The system will aid the user in adding necessary licensing notices and determining any licensing requirements² of the output.

As an aspirational document, this is not intended to be prescriptive nor definitional. We describe the absolute ideal LLM-backed generative AI system for FOSS that we can imagine. Articulating the ideal paves the road to understanding why common consensus remains insufficient. We must be the change we want in the world, and strive for what is right — until the politically unviable becomes viable.

It is well established that FOSS activists consider it a moral imperative to share any generally useful technical information under a FOSS license. As such, we should not tolerate any portion of the software and generally useful technical information released under a license that is non-FOSS. ↩
Since recitation (i.e., verbatim repeating of parts of the training set) is known to occur in these systems, we know they will occasionally output Works Based on the training set, so our ideal system would be capable of notifying the user that recitation occurred and properly mark the licensing for it. ↩

Save the date for FOSSY 2025!

Thu, 17 Oct 2024 16:30:41 -0400

A news item from Software Freedom Conservancy.

Submit track proposals now

A view towards the Smith Memorial Student Union, copyright Karen Sandler, CC-BY 3.0

Mark you calendars - FOSSY will return July 31 to August 3, 2025! The next iteration of FOSSY will once again take place at the Portland State University Smith Memorial Student Union.

Once again, FOSSY will feature community led tracks on a variety of topics relevant to Free and Open Source Software.

You can submit your track proposals now! We will consider repeat tracks that were particularly successful and new tracks that have significant community interest on a rolling basis so they can be announced as early as possible. We are also excited about tracks that may be smaller or that represent new ideas, but we will wait until all track proposals are received by February 15 to announce the final tracks on February 16. We expect to open the CfP on March 3rd.

Feel free to reach out to us if you would like to discuss an idea for a track. Either [email protected] or on our [email protected]?join">XMPP / IRC channel #conservancy on libera.chat.

Also be sure to check out the videos from last year's FOSSY.

Please also considering recommending sponsorship to your company. The prospectus for FOSSY 2025 is here and contains a variety of sponsorship levels. We can't wait to see you in Portland at the end of July!

Excitement for GPL enforcement at Linux Plumbers

Thu, 03 Oct 2024 11:56:47 -0400

A blog post from Software Freedom Conservancy.

Blog post by Denver Gingerich. Please email any comments on this entry to [email protected]"><[email protected]>.

We were excited and very happy to participate in Linux Plumbers Conference this year, which happened last month (Sep 18-20) in Vienna. As one of the premiere programs using a software right to repair license (GPLv2), Linux is crucial for the future of software freedom in our devices, from those we use to develop and write new code, to the phones many of us carry with us, to the many appliances and even cars that bring conveniences to our lives. And so we were delighted to discuss Linux and its role in our connected future with Linux kernel developers and other enthusiasts who attended this technical conference.

We hosted a BoF, Let's talk about GPL and LGPL enforcement!, which brought dozens of developers together to discuss the hard questions of how we can ensure that Linux's license is enforced so people can get the code they're entitled to, and the current state of GPL and LGPL enforcement across the board. After some discussion of how often companies use software under the GPL and LGPL without honoring the license terms (it's unfortunately very very common), we fielded some questions about source candidates that people had received. The first example that a participant provided as a positive example of a company meeting its obligations turned out to actually be from a company that SFC had sued in the past, showing that SFC's prior enforcement efforts were helping to change behavior, causing companies to provide GPL/LGPL source code when they hadn't before.

The discussion moved on to how we can bring the next generation of developers into the Linux community, so they can keep improving the Linux kernel in the coming decades. It was noted that a lot of new computer users aren't getting the same computing environment that most Linux developers grew up with. In particular, most Linux developers today started computing with desktop or laptop computers that gave them a wide range of software options, and easy ways to switch operating systems and other key software. However, today most new computer users are getting less capable devices, not because they are less powerful, but because the devices don't have the same malleability and accessibility as they did two decades ago, which is due in part to GPL violations where the user is prevented from reinstalling modified Linux or other software onto their device.

This really struck me, as I had many conversations in the "hallway track" where I asked people how they got into FOSS, and the responses were invariably a version of "to do more interesting things with my computer". It was clear that the computing devices of the 90s and early 2000s really promoted this developer mindset, and that we would have to keep the momentum going to ensure that new developers would have the same opportunities. This leaves us with a mission to make sure that as computing platforms change, we retain the freedoms that enabled the current generation of technology to flourish.

While GPL enforcement isn't the only factor in ensuring people can access developer tools and make meaningful changes to their devices, it is certainly an important piece of the puzzle, given everything we heard at Plumbers this year. With large percentages of Linux devices still distributed without giving users the freedoms that Linux's license is designed to give them, GPL enforcement is immensely important, as our discussions at Plumbers and elsewhere remind us.

The feedback from the BoF was overwhelmingly positive, and we were so happy to be able to take questions, share information, connect with longtime contributors and meet newcomers with such a keen interest in copyleft and enforcement. As always, we invite feedback about this work. You can email us anytime at [email protected]">[email protected], and we'll be scheduling some synchronous sessions later in the year.

In the meantime, we are proud to continue the work to ensure that everyone can repair and modify the software on their Linux devices, and everything else using software right-to-repair licenses, for current and future generations of software users and developers.

FOSSY 2024 CFP announcement

Thu, 23 May 2024 13:50:46 -0400

A news item from Software Freedom Conservancy.

Submit before June 14th

FOSSY 2024 CFP and ticket sales are now open! Join us in Portland, OR on August 1-4th at Portland State University. This year our track selection runs the gamut from Artificial Intelligence and Machine Learning, Supporting User Groups, FOSS in Education, Reproducibility and much much more. Whether you are a veteran of the FOSS conference circuit, or just starting your speaking career, we want to hear from you! FOSSY is a community focused conference focused on being accessible and highlighting the incredible work happening in free software.

To submit a talk, please visit our Call for Proposals page to make an account and enter your talk under a specific track. If you aren't sure which track you fit into, or feel you are a bit outside the scope for any of the listed tracks, use the Wild card track. We are also soliciting panel suggestions for our keynotes, (which last year included a celebration for Outreachy's 1000th intern celebration and a timely community discussion about RHEL's licensing). Our CFP will be open until ~~June 14th~~ June 18th (with notice of acceptance the week of the 24th) so be sure to find us on IRC #conservancy on Libera.chat, XMPP or email. We will start having office hours at 19:00 UTC on Tuesdays and Thursdays in our chat room for anyone to come and ask questions.

Along with the opening of the CFP, we have opened ticket sales. If you'd like to provide extra support for the conference you can buy the $1,000 ticket. We also have professional tickets at $500, community tickets at $200, and discounted tickets at $35. If your company is interested in sponsoring the event, you can find our Sponsorship Prospectus here. You can email [email protected] if you have any questions, we can't wait to see you in August!

FOSSY is back in Portland - August 1-4th at Portland State University

Thu, 28 Mar 2024 16:13:14 -0400

A news item from Software Freedom Conservancy.

CC-BY 3.0

Join us at FOSSY this year, Thursday August 1st - Sunday August 4th at the Portland State University Smith Memorial Student Union. We're looking forward to convening another conference that shows the multiple facets of what it means to work with, advocate for, and build free software in community. Last year we had over 300 attendees from over 10 countries! There was an incredible diversity of community led tracks, covering FOSS for Education, Right to Repair, Worker-Owner Co-ops that write and use FOSS, and Diversity, Equity and Inclusion and FOSS, to name a few. This year we hope to see a return of some of the great tracks and ideas that inspired us and an introduction of new tracks. If you would like to host a track, please consider applying to our community track proposals. We will be hosting office hours at 19:00 UTC on Tuesdays and Thursdays on our XMPP/ IRC channel if you would like to chat with someone about your proposal.

Please help us make the event a success by sponsoring at one of our tree themed tiers (Giant Sequoia, Redwood, Douglas Fir) or by providing coffee, transit, or A/V. If you or your organization would like more information here is our sponsorship prospectus or you can contact us at [email protected] for more information.

Come join us for what we hope will be a beautiful summer weekend in Portland, OR, packed with community led discussions about what the future of free software looks like. We can't wait to see you there, so mark your calendars!

Use the Source! A Revolution in Grassroots Software Right to Repair

Sat, 03 Feb 2024 02:02:00 -0500

A news item from Software Freedom Conservancy.

SFC launches key tool in the fight for user rights at FOSDEM

This past weekend at FOSDEM, Software Freedom Conservancy (SFC) announced an innovative new community tool in the software right to repair: Use The Source. Use The Source is an elegant collaborative platform for users to catalog, find and test source code candidates for real products to verify their reproducibility and reinstallability. Users can discuss whether their device's software is repairable, so they know if the device can be fixed or updated, especially to fix security vulnerabilities or otherwise adapt it to their needs.

Most consumer electronics ship with software that is provided under various copyleft licenses that (ostensibly) guarantee the consumers' right to software repair. Owners of these devices have a right to receive the complete source code for that software. Sadly, too often, the source isn't provided at all. Even when some source is provided, the provided source is usually incomplete.

Use The Source seeks to be a hub for collaboration in solving this problem. Based on the ideals and methodologies behind successful FOSS projects, Use The Source provides device owners an outlet to share and discuss how they reviewed source code candidates that companies provide to them, so they can determine, with the community's help, whether they can truly repair and modify the device's software. SFC encourages device owners to first test the offers for source code for all their products, and then share the source candidates they have received.

This Use The Source initiative harkens back to the beloved but now defunct mailing lists of gpl-violations.org. In their heyday, these mailing lists were a central place for those who cared about their rights under copyleft licenses to learn from each other. On those lists, the early FOSS community learned how to make effective use of compliant source, and how to demand that source if none is provided or it is incomplete.

SFC is acutely aware that, for the last decade since those resources disappeared, the skills and knowledge in the FOSS community has atrophied. SFC feels an obligation to use our expertise to launch a community to rebuild these skills in the volunteer core of FOSS, and to otherwise teach and educate about what we know and how we do.

As always, SFC plans to follow its Principles of Community-Oriented GPL Enforcement in this process. SFC has developed a timeline for companies who wish to actively participate in resolving any concerns, based on the importance of promptly fixing source candidates that are not in compliance with copyleft terms. Our process balances the urgent need to publish and discuss source candidates with the common desire of for-profit companies to remain anonymous while they correct inadvertent GPL violations.

SFC encourages anyone interested to review the source code candidates on our Use The Source platform, and to submit any source code candidates they find, so the community can build its knowledge and experience in reviewing and assessing source candidates for their compliance with the copyleft licenses that companies choose to use. You can also join our ccs-review mailing list, where the public can engage with SFC and other official Use The Source commenters in discussing the published source candidates as well. Source candidates and comments from Use The Source will auto-post to the ccs-review list so you can see and react to what we're doing in real time. We hope that our discussions will eventually lead to a much higher percentage of source candidates being in compliance with the software right to repair licenses they use. With compliant source code candidates, device owners can keep themselves secure, adapt to their future needs, and ensure others can do the same, by themselves or by working with the community or third-party repair services to give them the freedoms that software right to repair licenses have always intended to convey.

Prioritizing software right to repair: engaging corporate response teams

Sat, 03 Feb 2024 01:54:01 -0500

A blog post from Software Freedom Conservancy.

Blog post by Denver Gingerich. Please email any comments on this entry to [email protected]"><[email protected]>.

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.

2023 Fundraiser met and exceeded!

Thu, 18 Jan 2024 23:32:19 -0500

A news item from Software Freedom Conservancy.

$325,400 raised for software freedom!

This year's fundraiser went right up to the last hour; thanks to all of you for supporting the work we do, and showing us we're on the right track. We're so thankful for meeting our biggest match yet, $161,729 and $1,942 additional raised for a total of $325,400! Our Sustainers and donors showed particular interest in promotion and defense of copyleft, including our case against Vizio, as well as in our work On Outreachy. Funding our organization leads directly to more compliance action and more initiatives to further software freedom for all of us.

Overall, there was great turn out to our Q&A sessions with SFC leadership during the fundraising period. During the last call we received word that the judge had rejected Vizio's call for summary judgment! What a way to end the year 🥳 You told us that these kind of presentations were informative and very welcome, so we're looking at how best to organize them in the future with a more regular (quarterly?) cadence. Connecting with our community and keeping you all up to date with our activities and myriad types of work we do is definitely a goal for this next year. Come find us at conferences, social media (thank you so much for all your engagement on the Fediverse during our #SFCdrive!), and the revival of weekly "office hours" on IRC/XMPP.

We'll see some of you at FOSDEM in a couple weeks, so please come by to get a sticker and say hello! Meanwhile, we are back hard at work defending your digital rights and making sure our technology is in our hands, under our own control. Thank you all again for showing us with your hard earned money that you respect and value the work we do.

Supporter Interview with Elijah (and Oliver!) Voigt

Mon, 15 Jan 2024 11:02:16 -0500

A blog post from Software Freedom Conservancy.

Blog post by Daniel Takamori. Please email any comments on this entry to [email protected]"><[email protected]>.

CC-BY-NA 4.0 Lucy Voigt

Thanks so much to one of our matching supporters, The Voigt Family! We're so happy to highlight a young family involved in free software and hear from about what they think about our work and the future. Read on to hear from Eli from a quick interview we did!

SFC:Tell us a bit about yourself! Where are you from, what are some of your hobbies? Social media?

Eli: I moved from Chicago to Portland as a tween. I have since adopted many Pacific Northwest hobbies like hiking, camping, and enjoying microbrews.

SFC: Why do you care about software freedom? How long have you been involved?

Eli: In college (almost 10 years ago? Oh no.) I helped run the Oregon State University Linux Users Group (OSU LUG) where we ran InstallFests and gave talks on different Open Source tools. Prior to that I used open source software like Linux and Blender to produce 3D art.

Software Freedom is important to me because world class software tools should be accessible to everybody. Growing up middle class I had the privilege of a computer and free time, but I couldn't afford expensive 3D software like Adobe. Thankfully I got into Blender because it was free but also because it was good!

I definitely think of Software Freedom as a spectrum. For example: using Blender on Windows is a win compared with using Adobe products.

SFC: How do you use free software in your life?

Eli: I use Linux and free software whenever I can. I also run a physical server in my basement which hosts instances of open source services like Gitea for friends and family. Being a nights-and-weekends Sysadmin isn't for everybody but I love it!

SFC: On the spectrum on developer to end user, where do you lie? And how do you think we could do better bridging that divide?

Eli: I am definitely more of a Developer, and I struggle with bringing co-workers, friends, and family into the fold of Free Software. When a tool is Free, Convenient, and Good people are more than happy to use it. Beyond that though I have no idea!

SFC: What's got you most excited from the past year of our work?

Eli: I was a huge fan of FOSSY! I could only make the first day because we had a BABY during the conference. The one day I went I got to speak to Andrew Kelley (of Ziglang) and I learned about running AI models on my laptop which was enlightening and fun! I also volunteered and got to see so many community folks for the first time since COVID.

SFC: What issues happened this past year that you were happy we spoke about?

Eli: I think the work you're doing with Right to Repair is really meaningful. It's the kind of thing every consumer agrees with and wants but we still need to fight for!

SFC: Do you think we are doing a good job reaching a wider audience and do you see us at places you expect?

Eli: I am sure running a conference like FOSSY, especially in a post-COVID-lockdown world, is challenging but really helped me feel connected to the SF Conservancy and the community around your work. I can't wait to see it grow over the coming years.

SFC: Have you been involved with any of our member projects in the past?

Eli: I am a huge fan of Busybox! When I put on my system administrator hat (at work and for fun) I use it every day.

SFC: What other organizations are you supporting this year? charities, local, non-tech, etc

Eli: A few of my recurring donations I want to plug:

My local public broadcasting channel: Oregon Public Broadcasting
The Wayback Machine
My go-to for Climate Change stories: Grist

SFC: Did you have the first FOSSY Baby?

Eli: Yes! His name is Oliver and he just turned 6 months old (as of January 15)!

Outreachy 2023: Year in Review

Thu, 11 Jan 2024 23:51:18 -0500

A news item from Software Freedom Conservancy.

Photo CC-BY Outreachy

Celebrating 14 Years of Impact

In 2023, Outreachy marked a significant milestone in its 14-year journey by welcoming over 1,000 interns into the open source community. This remarkable achievement was commemorated through a series of 6 local celebrations across various countries and 3 virtual events, showcasing the global reach of Outreachy's impact. The celebrations served as a testament to the diversity and inclusivity that Outreachy champions.

Outreachy in 2023: By the Numbers

Outreachy's impact in 2023 by the numbers tells a compelling story. Collaborating with 40 open source communities and engaging 191 mentors, Outreachy inspired 488 new open source contributors to embark on their open source journey. The open source communities saw an impressive 3,439 contributions merged from 764 applicants, showcasing the incredible impact of this program.

The heart of Outreachy lies in the interns it supports. In 2023, 121 interns worked full-time on open source projects for three months each. This commitment was met with a distribution of $847,000 in internship stipends to people facing discrimination and systemic bias.

Despite these achievements, the need for financial support remains urgent. It requires significant resources to continue this level of success. And with 1,936 applicants in 2023, there is a compelling case for increased funding to expand Outreachy and provide more opportunities for those eager to contribute to open source. If Outreachy had additional funding, we could support and recruit more mentors, directly fund more internships, and accept more interns from the 764 applicants who made open source contributions.

Outreachy Team Milestones

1. 1000th Intern Celebration

The Outreachy organizing team played a big role in orchestrating the celebratory events. In addition to hitting the milestone of accepting the 1,000th Outreachy intern, the team organized 6 local celebrations and 3 virtual events. The local celebrations were held in 6 countries: Cameroon, Canada, India, Kenya, Nigeria, and the USA. Each celebration served as a testament to the global reach of Outreachy's impact and the diversity it fosters within the open source community.

We also appreciate our alums who served as the leads for the local celebrations. These dedicated leads played a crucial role in organizing the events, ensuring that everyone at the event felt celebrated and included. Outreachy merch were also sent around the world, symbolizing the interconnectedness of the global Outreachy community.

Photo albums capturing the vibrant moments of each celebration are available:

These celebratory events not only recognized the interns but also acknowledged the vital role of mentors, coordinators, and the wider open source community. It was a moment to reflect on the collaborative efforts that have driven Outreachy to its current standing and set the stage for future endeavors.

2. Intern and Community Support

The heart of Outreachy lies in its interns, and the team ensured their support throughout 2023. With 121 interns participating in the May and December cohorts, the Outreachy team encouraged personal connections through 1:1 meetings and a social hour. These initiatives aimed not only to facilitate professional growth but also to foster a sense of community among interns across diverse open source communities.

3. Applicant Empowerment

Empowering applicants is a core focus of Outreachy, and in 2023, 1,936 applicants were approved to participate in the May and December contribution periods. To enhance the application process, the team increased initial application reviewers to 17, providing a more comprehensive and supportive review process. Live Q&A sessions were conducted to help applicants navigate open source community practises and understand the Outreachy application process better.

4. Mentor and Coordinator Engagement

The involvement of mentors and community coordinators is crucial to Outreachy's success. In 2023, 191 mentors supported interns in the May and December cohorts, showcasing the growing mentorship network. The team addressed challenges faced by mentors through discussion sessions at three different conferences. Outreachy's commitment to mentorship extended to encouraging interns to become mentors, resulting in 30 mentors who were past Outreachy interns – a significant increase from previous years.

To further support mentors, a full-time Outreachy mentor advocate - Tilda Udufo was hired, reflecting the dedication to enhancing the mentorship experience. The team also conducted office hours, providing a platform for mentors and coordinators to seek guidance during critical phases such as the community sign-up period, contribution period, and internship period.

5. Embracing Open Source

Outreachy's commitment to open source and software freedom extended beyond its internship program. The team embraced platforms like Mastodon, PeerTube, NextCloud, Big Blue Button, Espanso, and Etherpad, showcasing a dedication to using and promoting open source software. This move not only aligns with Outreachy's values but also sets an example for the wider community.

6. Community Engagement

Outreachy didn't limit its impact to its own community. The team actively spoke about Outreachy at 14 different events and meet-ups, amplifying the message of diversity and inclusion in open source. These engagements provided opportunities to share insights, inspire new contributors, and foster collaborations with like-minded organizations.

Outreachy organizers gave a keynote at FOSSY to celebrate 1,000 interns and talk about Outreachy's history:

Outreachy keynote at FOSSY

Outreachy organizers also attended the following conferences:

Diversity and Inclusion in Scientific Computing (DISC) Unconference by NumFocus, PyData Amsterdam, and PyCon Uganda: Report
OSCA fest: Report and Video
Euro Python: Report and Video
Django Africa: Report
Open Life Science program (Open Seed Cohort 8): Report
Dublin Developer Relations Meetup (August 2023 edition): Report and Video
Women TechMakers Karu branch, Abuja FCT, Nigeria: Report
FOSS Backstage (Dinner with Outreachy mentors): Report
CZI LatAm meeting: Report
FOSSY: Report
DevFest Cerrado: Report
Angola Open Source Community's The Open Source Café: Video

Looking Ahead to 2024

As Outreachy gears up for the May 2024 cohort, the team is committed to continuous improvement. Beyond the usual operations, the Outreachy team has identified key areas for development:

Better mentor support: The Outreachy team will continue to offer more chances for mentors to connect through office hours, group chats, public Q&A sessions, and private advice sessions.

Spotlighting Outreachy mentors: The Outreachy team will be running a series of online chats and blog posts to acknowledge and spotlight the awesome work Outreachy mentors do to support interns and applicants.

Improved website experience: The Outreachy team will work on user experience improvements for mentors and coordinators.

Partnering with organizations: The Outreachy team will explore partnerships with other organizations to increase the reach of our call for mentors.

Updated longitudinal study: Building on the success of the 2019 longitudinal study, Outreachy is set to conduct another study in 2024. This updated version will provide valuable insights into the program's impact and areas for further enhancement.

Outreachy remains steadfast in its mission to foster diversity and inclusion in open source, and with the ongoing support of the community, the future looks promising for creating lasting positive change. The collaborative efforts of interns, mentors, coordinators, and supporters are shaping a more inclusive and vibrant software freedom landscape.

Support Outreachy: Your Contribution Matters!

Please donate by January 15

If you appreciate Outreachy's work, we encourage you to donate to Software Freedom Conservancy's yearly fundraiser by January 15, 2023.

Outreachy is a core part of Software Freedom Conservancy. Outreachy would not exist without the support of Software Freedom Conservancy.

Link to original post.

Judge dismisses Vizio's call for summary judgment

Wed, 03 Jan 2024 13:55:14 -0500

A news item from Software Freedom Conservancy.

SFC files own “Motion for Summary Adjudication”

A very welcome victory in our case against Vizio was presented last week. Judge Sandy Leal denied Vizio's Motion for Summary Judgment, allowing the case to proceed in state court. The Order echoes SFC arguments in court that the claim is not preempted by copyright law and that consumers like SFC have standing to enforce the GPL as third-party beneficiaries to the GPL — without any action by copyright holders of copylefted code.

SFC counsel and Policy Fellow posing outside the courthouse - CC BY-SA 4.0

The decision speaks clearly:

Allowing third parties such as SFC to enforce their rights to receive source code is not only consistent with the GPLs’ objectives; it is both essential and necessary to achieve these objectives. Recipients of GPL-licensed software will be assured of their right to receive source code only if they have standing to enforce that right.

and

… the Court finds that Plaintiff’s claim for breach of contract is not preempted by the Copyright Act, and Vizio’s motion for summary adjudication on this issue is DENIED

The (full decision is available in its entirety here, and you can read the transcript from the oral arguments from the hearing.

With that decided, we now turn our focus to our own filing, a “Motion for Summary Adjudication”. An MSA is very similar to a motion for summary judgment, except that it does not fully resolve the entire case. Our MSA asks to resolve substantial parts of the case that are a matter of law.

Our motion seeks to establish that distributors of GPL'd software, such as Vizio, have a duty to the recipients of the software, such as purchasers of Vizio TV sets, to provide the source code for the software upon request. Unfortunately many companies completely ignore source code requests from consumers, or do not provide complete corresponding source, when the license sets out their obligations clearly. We have asked to confirm that Vizio has a duty to us, as purchasers of their televisions, to make good on those obligations. In her order, Judge Leal acknowledged that this kind of power imbalance between corporations and recipients of copyleft software creates an inequity when it comes to receiving source code:

Defendant Vizio, as the licensee, is responsible for ensuring that it complies with the terms of the license. As such, it would be more equitable to allow third parties to assert claims against a licensee who fails to adhere to the terms and conditions of the license.

We focus on protecting the rights of all end users as third party beneficiaries and making sure that corporations who choose to use copyleft licenses are held accountable if they fail to follow the rules. As this case continues to unfold, we will continue to protect the freedoms given to us by copyleft licenses. This work is essential for the Software Right to Repair, and we will work to create legal mechanisms to ensure our devices are as free, open and repairable as possible.

You can help fund our continuing work in this case by becoming a Sustainer to our organization. We rely upon individuals to make the important work we do possible and if you make a contribution before January 15th during our annual fundraiser, our funding matchers will double your donation!

Is Tesla open source? Roadster certainly isn't...

Thu, 21 Dec 2023 16:28:19 -0500

A blog post from Software Freedom Conservancy.

Blog post by Denver Gingerich. Please email any comments on this entry to [email protected]"><[email protected]>.

There appears to be some debate over whether a certain billionaire said on November 22 that "Tesla Roadster is now fully open source", or maybe that "All design & engineering of the original @Tesla Roadster is now fully open source". In any case, as the people who work every day on whether or not what companies say is FOSS really is FOSS, we reviewed the materials Tesla provided on the Tesla Roadster Service Information page. We found no source code — and last time we reviewed the Open Source Definition, providing source code was mandatory to meet it. But this situation is worse than that. Tesla did include several copies of the Linux kernel in only binary form, with no offer for source whatsoever. That's a GPL violation. We immediately emailed Tesla to ask them where the source code was but (now 3 weeks later) we have still heard nothing back.

Tesla's violation is not surprising, given their past behavior. We've written before about Tesla's prior inabilities to provide complete source code. But now Tesla has completely backslid from incomplete source code all the way to "no source or offer". Instead of learning from its past mistakes, Tesla has increased its erratic behavior to make even more mistakes of the same type.

Now you may wonder why we care about a company that is decidedly not open source, and about code that is relatively old at this point. Well, we believe that people should have the right and ability to repair their software, no matter how old, and that this applies to everything that contains software, including TVs, wireless routers, and (in this case) cars.

The need for being able to repair here is not hypothetical. The dangers of Tesla drivers' inability to fix the software in their cars is palpable. After discussing safety concerns in the software on its cars with the NHTSA, Tesla recently did a voluntary recall on all cars it has produced in the past 10 years. This recall is *due to faulty software*, which was only discovered to be faulty after many drivers died. Neither NHTSA nor the public has the right to review Tesla's actual software for safety. If Tesla at least complied with the GPL, regulatory bodies and the public could review those portions for safety. (Of course, we think Tesla should be required to make the source for even those parts of the software not governed by GPL available to the public for security audits and review.)

Tesla has taken a strong and disturbing position: they'd rather keep their source code secret than increase safety for software in cars. Furthermore, rather than letting car owners fix their cars, they were forced to wait for Tesla to both agree that there was a problem, and then work on Tesla's own schedule to release a fix for the problem. If owners had the source code, the owners (and the press, who uncovered the systematic problems in this case) could more quickly identify that there was a problem to begin with, and then implement a fix right away, instead of waiting for Tesla to decide they wanted to do something about it.

By refusing to comply with the GPL agreements, Tesla is not only violating licenses - it is making its cars more dangerous, and removing the ability of owners to fix problems when they arise. This cannot continue, and we again call on Tesla today to give all its customers the complete source code for all copylefted software Tesla has distributed to them. This is common sense, and is merely what the agreements require.

Of course, we're just as concerned as anyone that owners might make software modifications to their car that decrease safety. We support certification requirements for any software that is installed to drive on the road. Just as it is completely legal for a consumer to build their own car from parts, and be subject to safety inspection before driving it on public roads, so too should that apply to software. Tesla, sadly, continues to maintain the fiction that they know better than everyone what's safe for software in cars to do — even after it's been shown that Tesla's software is killing people. As a for-profit automaker, in this regard Tesla is actually held to a lower burden than a hobbyist who built their own car.

We hope you will stand with us in calling on all companies to follow the terms of the copyleft agreements they are bound by. Violating the GPL and using proprietary software is not, as Tesla claims, the only way to keep drivers safe, instead it's downright dangerous.

A Note from Our Executive Director: 2023 and my personal quest for software freedom

Tue, 19 Dec 2023 15:53:13 -0500

A blog post from Software Freedom Conservancy.

Blog post by Karen Sandler. Please email any comments on this entry to [email protected]"><[email protected]>.

Just 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.

Download Karen's talk or watch on YouTube

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.

SFC Responds to Big Tech's Disengenous Arguments in Copyright Office's “Artificial Intelligence Study”

Mon, 11 Dec 2023 17:12:08 -0500

A news item from Software Freedom Conservancy.

After filing our initial comments in the Copyright Office's request for comments, SFC staff have remained engaged in the process — we've given particular attention to comments related to software freedom and rights as assured through copyleft licenses like the GPL. We advocate for your software rights and freedoms in many ways — including participation on public policy discussion of relevant issues, such as this Copyright Office study.

In this case, we're particularly glad to stay engaged. We discovered that we were the only charity to bring up issues of copyleft and the GPL with the Copyright Office. We appreciate so much the support of our donors so that we can show up to defend your rights regarding copyleft licenses. Meanwhile, Big Tech was all over this comment process undermining software rights. We were able to address, in particular, serious attacks on software rights from Microsoft — who dismissed as irrelevant copyright holders' rights with respect to copyleft licenses and the GPL. As we stated in our reply comment, directed primarily at Microsoft's attacks:

To concede Microsoft’s “fair use” claims would be the first step in eviscerating the copyleft licenses that protect the primary commons of software source code, which, in turn, comprise much of the software in Training Sets already in use for these Generative AI systems.

Microsoft seeks maximalist copyright protections, but only when convenient to their proprietary software business model and none in the providing the basis for creating ever more proprietary software. We stand for the users — to protect against corporations who unduly extract labor and profit from copyleft-licensed works. As our Policy Fellow Bradley M. Kuhn has previously written, community-led efforts must lean even stronger into the judo move of copyleft in the age of Generative AI; copyleft works because it reverses the power of copyright maximalism that Microsoft and other large corporations created to liberate users:

While we and other FOSS activists might support a full reconsideration of copyright rules for software from the ground-up, we do not think a piecemeal reworking of some rules in some contexts, particularly to merely serve the interests of large corporations, is in the interest of authors who do not have Big Tech’s resources. Such changes would be particularly toxic to those of us who have chosen to license our copyrights under copyleft licenses, which were specifically designed to assure full transparency and the complete sharing of source code.

Finally, our comments reiterated our timely concern: “compulsory licensing” for use in generative AI systems for copyrighted work such as copylefted software. Compulsory licensing typically finanically compensates authors for a use of their works, but we believe no amount of money should be sufficient to buy Big Tech “out of” their copyleft obligations to users and consumers.

You can read our full comments on our website — we'll update with the published link on the Copyright Office's site when available.

Please consider becoming a Sustainer of our organization to support work like this. If you donate before January 15th, your donation with be double while our matched fundraiser is going on, so your contribution will go twice as far!

SFC joins amicus curiae in Green v. Department of Justice

Wed, 06 Dec 2023 19:02:02 -0500

A news item from Software Freedom Conservancy.

Large coalition against DMCA among right to repair, digital rights and advocacy groups speaks out

In the case of Green v. Department of Justice, filed in 2016 concerning section 1201 of the DMCA, Software Freedom Conservancy — along with Public Knowledge, The Digital Right to Repair Coalition, iFixit, The Open Source Hardware Association, and Jonathan Askin, Aaron Perzanowski, and Anthony Rosborough — all joined an amicus curiae brief led by Charles Duan in support of the defendant. The DMCA includes many incredibly harmful policies. In particular, for almost 20 years, the DMCA has allowed overbroad corporate control of our technology in the name of copyright. Particularly harmful are the Draconian §1201-backed TPMs (“technological protection measures”) — which have curtailed and nearly eliminated these core rights of ownership:

The right to repair: TPMs block third-party parts or fixes — allowing monopolies in the repair market, or forcing consumers to harm our environment by discarding otherwise repairable devices.
The right to exclude: TPMs spy on consumers and open insecure backdoors on their computers — allowing malicious software to enter from anywhere.
The right to use: TPMs prevent consumers from using their devices as they wish. For example, some coffee machines' TPMs prohibit the brewing of other companies’ coffee pods.
The right to possess: Device manufacturers have leveraged TPMs to dispossess consumers of their purchases (without legal justification).

The amicus brief expresses its support for Green's position that, as a matter of free speech under the Constitution, Green should have permission to share information on circumventing TPMs with other consumers. Quoting from the brief:

When consumers seek to circumvent TPMs to protect their property interests, fight back against anticompetitive monopolization, or preserve their privacy, their efforts have everything to do with protecting individual consumer rights and virtually nothing to do with copyright.

§1201 gives corporations power over us. The amici believe that §1201 “… advanc[es] not copyright policy but rather corporate interests in denying consumers their rights to use and enjoy what they own.“ Seeking to empower people through policy change and promotion of free and open source software, SFC pushes for ethical technology standards and through coalition building like has been done for this brief. We stand with other organizations doing adjacent work and in doing so, show that there is near universal support for consumer and user focused rights advocacy.

Also, SFC's Executive Director, Karen Sandler, shared her compelling story of real-world negative healthcare impacts of TPMs in the brief:

A software malfunction on the device misinterpreted her pulse, causing it to shock her heart unnecessarily while she was pregnant. Yet the defibrillator’s TPM kept [her] from even finding the bug in the software, let alone repairing it, leaving her at the mercy of the device’s manufacturer to stop the erroneous shocks.

Free and open source software is a necessary (but not sufficient) condition to ensure our rights are protected and is key in making policy changes that empower all users of technology while restricting corporate control over our hardware and software. Software Freedom Conservancy provides a critical viewpoint to contribute with the other organizations joining us in support of this brief. By working with other advocacy groups, we broaden our own viewpoints and spread the ideas of software freedom to other organizations. This has a twofold benefit of enabling us to bring more people into the software freedom movement who are left out by our rhetoric and simultaneously bring the software freedom movement to other organizations and people by sharing our perspective. It's work like this that makes us hopeful for the future of all our digital rights.

You can read the whole brief with the official court document subject to change. Also please consider supporting our organization by becoming a Sustainer or making a donation. Now is an especially good time because your donation goes towards our matching fund, so all donations until January 15th are doubled up to our match amount!

Sourceware thanks Conservancy for their support and urges the community to support Conservancy

Mon, 27 Nov 2023 16:45:34 -0500

A blog post from Software Freedom Conservancy.

Blog post by Sourceware PLC. Please email any comments on this entry to [email protected]"><Sourceware [email protected]>.

Sourceware 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 [email protected]/">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.

2023 Fundraiser Kicks Off With Historic $161,729 Match Fund!

Tue, 21 Nov 2023 17:24:19 -0500

A news item from Software Freedom Conservancy.

Double your contribution to software freedom before January 15th

We at Software Freedom Conservancy are proud to be supported by individuals who find the mission of providing ethical technology for all worth investing in. Your support is what lets us develop free and open source alternatives to proprietary technologies like being the home to Inkscape, OpenWrt, Git and many others, support copyleft compliance, and run Outreachy, which just hosted its 1000th intern this year! It's the continued support of individuals which enables our work to protect us all from incursion of our digital rights and freedoms.

Our annual match drive of an historic $161,729 is provided this year by a group of passionate individual donors, giving all different levels of support to make sure we can continue to achieve our mission. For every dollar you give during the match challenge period and up to that overall amount, they will match to make your contributions to software freedom double! Over the next few weeks we'll be talking with some of our matchers like: Alison Chaiken, Ben Kero, Vipul Siddharth, Lucy and Eli Voigt, and Justin Vreeland, to see what they are most excited about our work and the future of software freedom.

This has been an exciting year for our organization, from hiring new staff, to running the first FOSSY conference, to seeing our projects continue to grow and develop. You can read all about this years exciting developments on our Year In Review page.

We urge you to become a Sustainer, renew your existing membership or donate before January 15th to maximize your contribution to furthering the goals of software freedom!

SFC Submits comments to US Copyright Office on Generative AI and Copyleft

Wed, 01 Nov 2023 07:44:28 -0400

A news item from Software Freedom Conservancy.

SFC warns that “compulsory licensing” undercuts goal of copyleft

This week, Software Freedom Conservancy responded to the United States Copyright Office's request for comments to better understand how so-called generative AI systems present new challenges and concerns to copyright. SFC's comments, prepared primarily by our Policy Fellow, Bradley M. Kuhn and Director of Compliance, Denver Gingerich, addressed the unique issues raised in relation to copyleft-licensed materials and the implications of their use in training set materials.

SFC's submitted comments highlight how copyleft truly “promote[s] Progress in Science and the Useful Arts" (the phrase used in the United States Constitution that established copyright) and that copyleft licensing should be specifically considered in any rulemaking or legislation. Copylefted Free and Open Source Software (“FOSS”) uniquely creates a collaborative environment for creative production; SFC's comments call on policymakers to carefully consider how these conditions differ from typical corporate and business contexts for policymaking. Because copyleft licensing requires reciprocity, SFC asked the Copyright Office to understand that financial compensation for copyright holders does not properly advance the policy goals of copyleft, and by extension, the policy motivation of“promot[ing] Progress" . Furthermore, SFC's comments draw attention to the power imbalance between Big Tech and the actual producers of labor that has filled their trained models.

SFC drew specific attention to the questions regarding financial-focused “compulsory licensing”. Compulsory licensing has been used for automatic permissions on copyrighted works, such as musical compositions, using royalty payments to compensate copyright holders. SFC's comments specifically explain that when, as with copyleft, the policy goals of licensors are principled and encompass more than mere financial compensation, compulsory licensing fails as a remedy. SFC fears that, either through Congress or industry “self regulation”, compulsory licensing of software may become a tool to eviscerate copyleft. As pointed out in the comments, this is also among the reasons that SFC does not support finanically-motivated class action litigation against Big Tech.

You can view SFC's submitted comments in their entirety on our site, and they will be made public by the Copyright Office once processing of the comments is complete. If you are interested in other writings and programs about AI from the SFC staff we have convened an expert group on code generation tools, written about the harms and concerns of Generative AI for software development. SFC was also invited to speak alongside many activists in a broad area of creative fields at a recent FTC panel regarding “Creative Economy and Generative AI“.

You can support work like this by becoming a Sustainer or making a donation.

How I watched a Motion for Summary Judgment hearing

Thu, 12 Oct 2023 12:00:00 -0400

A blog post from Software Freedom Conservancy.

Blog post by Denver Gingerich. Please email any comments on this entry to [email protected]"><[email protected]>.

In 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.

Read the Transcript: Key Legal Issues Argued in Vizio's Summary Judgment Motion

Thu, 12 Oct 2023 12:00:00 -0400

A news item from Software Freedom Conservancy.

SFC lawyers posing outside the courthouse - CC BY-SA 4.0

Last Thursday, Software Freedom Conservancy took the next step in our ongoing litigation to liberate the complete, corresponding source code for Vizio televisions. Our lawyers argued on our behalf the core legal issues at the center of our case against VIzio. The motion and responses were filed in the weeks prior to the hearing and in-person oral arguments took place before Judge Sandy N. Leal of the Superior Court of California, County of Orange on Thursday, October 5, 2023.

The motion, and consequently the hearing, focuses on two of the most critical issues of the case: (a) whether recipients of GPL'd software can enforce their rights to the corresponding source code themselves (under a legal theory known as “third-party beneficiary”) and (b) whether or not this contractual right is preempted by copyright law. The preemption issue was previously decided by a federal judge in SFC's favor (a decision which “remanded” this case back to Judge Leal). However, the federal ruling is not necessarily binding on the state court; Vizio is within their legal rights to represent it to Judge Leal.

In the courtroom, SFC was represented by leading California lawyers Naomi Jane Gray and Don Thompson. As immediate Past President of the Copyright Society, Naomi has spearheaded copyright law awareness and education. Naomi brings a wealth of knowledge to support our case and its focus on benefits to third parties, which, we argued, are not preempted by copyright law — but rather these contractual rights work in concert with the copyright rights to provide users with software freedom under the GPL Agreements. Naomi's colleague, Don Thompson, brings significant litigation experience is invaluable for making our case. They both excel in breaking down complicated concepts into simple explanations, which was extremely helpful in the hearing.

Together, Naomi and Don were a powerhouse representing us on these important issues before Judge Leal. As Don stated in the courtroom:

Vizio does not dispute that the recipients of licensed software have a right to source code under the GPL's, and yet Vizio argues that as a matter of law those recipients of licensed software may not enforce the right that we indisputably enjoy, because somehow it would be inconsistent with the objectives of the contract and the reasonable expectations of the contracting parties. Nothing could be further from the truth,

Naomi gave an excellent primer on the difference between valid copyright and contract claims and the reserved rights under copyright law. Here are two excerpts from her arguments:

Vizio now argues that it can breach this contract with impunity, because any claim for breach would be preempted by copyright law, and because the parties who are harmed by the breach lack standing to enforce their rights. That is not and cannot be the law.

Vizio is taking the position that enforcement by copyright holders ought to be sufficient, but copyright is a different right. Copyright holders are different plaintiffs. We are not asserting copyright in this case. What we are asserting is our right to source code, which exists under the terms of the contract.

We were thrilled to hear in real-time our lawyers argue so passionately for the rights of consumers and users everywhere. They drove home the importance of having access to see and modify the source code we rely on, and that consumers are the ones who are truly hurt when company's don't comply with the terms of the GPL. As Naomi put it using the legal terms at issue,

In this case the party that is harmed is the party demanding the source code, denied the right to source code. And we need the source code to modify the software. That is our irreparable harm.

We encourage those of you that care about the rights granted under the GPL Agreements to read the full transcript. We also think you'll enjoy reading this blog post from our Director of Compliance, Denver Gingerich, talking about watching the hearing.

We expect a decision on this motion in the coming days, and will share news of the decision with the FOSS community quickly thereafter.

Public policy litigation like this is expensive. We urge you to support our efforts in this case by becoming an SFC Sustainer urgently. We rely upon donations like yours to fund the important work of defending the GPL Agreements, and all the other important work that our organization does to advance software freedom and rights.

Joint Statement by Free Software Foundation Europe and Software Freedom Conservancy Regarding Eben Moglen and Software Freedom Law Center

Wed, 11 Oct 2023 13:00:00 -0400

A news item from Software Freedom Conservancy.

Both Free Software Foundation Europe (FSFE) and Software Freedom Conservancy (SFC) are committed to defending and expanding software freedom and the rights of people to use, understand, share and improve their software.

As part of this work, both FSFE and SFC strive to create a software freedom community that is egalitarian, fair, kind, and welcoming to everyone. Sadly, though, we are also aware that toxic behavior, bullying, and other violations of Codes of Conduct do occur throughout our community. As such, both organizations make substantial efforts to protect our volunteers and staff from bad behavior.

Historically, both FSFE and SFC collaborated and coordinated with a third organization — Software Freedom Law Center (SFLC), and specifically with SFLC's founder/President/Executive Director, Eben Moglen. However, some time ago, both our organizations ended our collaborations and affiliations with SFLC. Furthermore, both FSFE and SFC now have internal policies to avoid any situations where our employees or volunteers might work directly with him.

We arrived at these decisions through our organizational processes. After years of reported abusive behavior by Eben Moglen toward members of the staff and volunteers of both organizations, each organization independently made a categorical rule that we would avoid Eben Moglen and not invite him to our events and fora. (Examples of reports of his behavior — towards SFC staff (page 8), FSFE staff (page 51), and others (page 28) — have been (with reluctance) documented publicly in the proceedings of the ongoing trademark cancellation petition that SFLC filed against SFC in the United States Trademark Trial and Appeal Board.)

Today, we share — with the community at large — our policy to not work with Eben Moglen or SFLC. We have chosen to speak publicly on this matter because we feel we have an obligation to warn volunteers and activists in software freedom that this pattern of reported behavior exists. Of course, everyone should read the publicly available source materials and make their own decisions regarding these matters. While we are loathe to publicly speak of these unfortunate events, the decades of ongoing reports of abusive behavior — and the risk that behavior creates for unknowing members of the Free Software community — ultimately requires that we no longer remain quiet on this issue.

Abusive behavior is a distraction from the mission of any activist organization. We urge everyone to separate themselves as best they can from such behavior (and from those who tolerate and/or employ it), and focus on the important work of increasing software freedom.

Policy Fellow to speak on FTC roundtable about “Creative Economy and Generative AI“

Wed, 04 Oct 2023 08:55:00 -0400

A news item from Software Freedom Conservancy.

Click the thumbnail for a link to the recording which includes proprietary Javascript.

Software Freedom Conservancy's Policy Fellow Bradley M. Kuhn, participated today in the FTC's roundtable discussion about the “Creative Economy and Generative AI”. Bradley represented the FOSS and indepndant software authorship communities on this panel. Bradley joined the voices of artists, union activists, and other policy makers to discuss the pressing issue of how machine learning impacts the rights and livelihoods of artists, technologists and others. We thank the FTC for putting the issues of software freedom and rights front and center in this important mainstream issue.

Given the increasing prevalence of machine learning technologies, SFC applauds the FTC's efforts to convene creatives, technologists and forward thinking policy makers concerned by the lack of regulation and oversight around deployment of machine learning platforms. There has been significant conversations and coverage representing the large corporate interests surrounding AI technologies, but we hope this panel highlights the needs and concerns of the labor force and general public surrounding these issues. This panel lifts voices affected by the overreach of corporations seeking to profit off of the labor existing works.

SFC has written and spoken previously on the concerns around AI by creating a committee to examine AI assisted software creation, Executive Director Karen Sandler keynoted a conference about AI Law and Ethics, hosted a track at the first annual FOSSY conference, and Policy Fellow Bradley M. Kuhn has written about the licensing and ethical concerns around GitHub's CoPilot.

You can watch the recording of the discussion, and find more information about the panel on the FTC's events page.

Below, we include in their entirety Bradley's open statement at the event:

First, I'd like to thank the FTC for organizing this panel. It's humbling to be here among these key individuals from such a broad range of important creative endeavors.

Folks will notice that I'm not appearing by video today, and I again thank the FTC for providing a method for me to join you today without requiring that I agree to Zoom's proprietary terms and conditions. As a matter of principle, I avoid using any proprietary software, but in this case, it is not merely esoteric principle. Zoom is among the many Big Tech companies that have sought to cajole users into allowing their own user data as training input for machine learning systems. If consumers take away anything from my comments today, I hope they remember to carefully read the terms and conditions of all software platforms they use, as they may have already agreed for their own creative works to be part of the company's machine learning data sets. It may take you a week to read all those terms, but it's sadly the only way you'll know what rights you've given away to Big Tech.

The creative works that I focus on, however, is the source code of software itself. Software is unique among creative endeavors because it is so easy to separate the work that's created by humans (which is the source code), from the form of the work that's enjoyed day-to-day by consumers (which is the compiled binary). I'm an activist in the area of software freedom and rights specifically because I believe every consumer deserves the right to examine how their software works, to modify, improve and change it — be it altruistically or commercially. Free and Open Source software (abbreviated FOSS) aims to create, through licensing and other means, an equal field for all software professionals and hobbyists alike, and to grant rights to consumers so they have true control of their own tools.

For 30 years, our community has created FOSS and made it publicly available. Big Tech, for its part, continues to refuse to share most of its own software in the same way. So, as it turns out, nearly all the publicly available source code in the world today is FOSS, and most of it is licensed under terms that are what we call copyleft: a requirement that anyone who further improves or modifies the work must give similar permissions to its downstream users.

This situation led FOSS to become a canary in the coal mine of Big Tech's push for machine learning. Hypocritically, we've seen Big Tech gladly train their machine learning models with our publicly available FOSS, but not with their own proprietary source code. Big Tech happily exploits FOSS, but they believe they've found a new way to ignore the key principles and requirements that FOSS licenses dictate. It's clear Big Tech ignore any rules that stand in the way of their profits.

Meanwhile, Big Tech has launched a campaign to manufacture consent about these systems. Big Tech claims that the rules, licensing, and legislation that has applied to creative works since the 1800s in the United States are suddenly moot simply because machine learning is, in their view, too important to be bogged down by the licensing choices of human creators of works. In the FOSS community, we see this policy coup happening on every level: from propaganda to consumers, to policy papers, to even law journal articles.

I realize that I sound rather pessimistic about the outcomes here. I'm nevertheless hopeful sitting here in this panel today, because I see that so many of my colleagues in other fields are similarly skeptical about Big Tech's self-serving rhetoric in this regard, and I hope we can work together to counter that rhetoric fully.

The FTC asked Bradley this question:

What kind of insight do you feel like you have now into how your work or likeness is being used by generative AI systems, and what kind of transparency do you feel is needed?

to which Bradley responded:

First of all, there is now no question that the body of copylefted FOSS is a huge part of the software-assisted development machine learning systems. Big Tech are also playing cat-and-mouse, by simply excluding on the back-end the most egregious examples of copyright infringement that are found.

We now know Big Tech has disturbingly found a way to take a transparent body of freely shared information on the Internet and exploit it in secret. We simply shouldn't accept that as legitimate, and there is no reason that Big Tech shouldn't be regulated to make these systems transparent — end to end.

In my view, the public should have access to the input set, have access to the source code of the software that does the training and generation, and most importantly, access to the source code that does these forms of back-end exclusion, which will hopefully expose the duplicity of Big Tech's policies here.

Finally, I expect that once we have real transparency, it will bear out what many of the other speakers today also noted: that the issues with these machine learning systems can't be solved merely with a financial compensation model to creators. FOSS shows this explicitly: since most FOSS is written altruistically and the compensation that authors seek is the requirement for future improvement of the commons, not financial compensation. We really need full transparency in these systems to assure that essential non-monetary policy license terms and the consumers' rights are upheld.

FOSSY videos are out!

Thu, 14 Sep 2023 09:38:00 -0400

A news item from Software Freedom Conservancy.

The recordings from FOSSY are now up! You can check them out on the Internet Archive. We have over 100 talks from 19 tracks, from speakers coming from over 12 countries. It was such an incredible first year conference and we're so happy to share the presentations with you. We'll be highlighting specific talks over the comings days, so be on the lookout on our social media.

"You don't carry a phone?! Improving societal acceptance of abnormal people" CC-by-SA 4.0

During the four days of the conference, there were a wide variety of talks from speakers with a range of experience and backgrounds, and amazing community focused discussions. Featuring wide ranging topics such as a panel discussion about software coops, what is life like without a smartphone (where the picture on the right is from), and thinking about FOSS from a systems theory perspective. Our track organizers brought together communities from all over, and led by example choosing speakers, topics and setting up panels for important conversations. There is definitely a talk that will interest you, whether you are interested in nonprofit board structure, an introduction to Reproducible Builds or maybe you are looking to have more nature adventures with free software.

It was a privilege and honor to make space for the community to (safely!) come together and have the critical and community building discussions in real time. Our modest expectations for the conference were blown away by the passion, expertise and graciousness of the speakers and community. And while we cannot replicate the energy of the hallway track, there's plenty of video content to get your fill on until next year! If you want to get the hallway track experience, you can join us on xmpp:[email protected]?join which is also bridged to the IRC channel #conservancy on libera.chat

Thank you to all the people that came out for our first conference and made it an incredible event. A special thanks to local Portland non-profits Open Signal PDX and Friends of Noise who provided AV for the conference. And a huge thanks to our sponsors! If you are interested in sponsoring next years conference, please get in touch with us at [email protected].

We Call on FOSS Contributors to “Exit Zoom”

Tue, 15 Aug 2023 12:00:00 -0400

A news item from Software Freedom Conservancy.

SFC Announces Program to Help FOSS Enthusiasts Adopt Zoom Alternatives

Software Freedom Conservancy stands with concerned users and consumers; we too face difficult choices with respect to software rights and freedom. As part of our ongoing advocacy work, we educate and help people to choose more Free and Open Source Software (“FOSS”), and we aid developers to create and improve FOSS options for the general public. We also strive to “meet people where they are.”

The industrialized world has changed since the advent of FOSS. Only the most privileged among us have the option to avoid proprietary software — from the grocery store coupons, to interacting with government agencies, to looking for a job, to attending mandatory meetings at our jobs. The pandemic accelerated the widespread adoption of new technologies, such as video chat. Quite quickly after the pandemic started, we noted that some of our colleagues began pressuring us to meet on Zoom. It was really hard in the early days of the pandemic to balance the need for human connection and a principled stance on video conferencing software. We want to acknowledge that we all make tradeoffs and negotiations with our ethics, and these are not cut and dry issues. The wider business and non-profit sectors beyond FOSS quickly standardized on wholly proprietary video chat software — and Zoom was, by far, the market leader.

We considered completely avoiding those meetings in protest. However, we saw the same pressure that every individual feels when presented with a Zoom link: you miss the chance to even participate in the dialogue, and in some cases, you even risk losing your job! As a compromise for our situation, SFC staff took an activist approach. We insist on joining those meetings solely by phone — allowing us to use our mostly-FOSS LineageOS mobile devices.

This strategy had benefits and downsides. Sometimes, being the only participant without video sparked interesting discussion about avoidance of proprietary and centralized platforms was an essential part of advocating for ethical technology. Participants on those calls, often acknowledged that on a high level the issues we raised were important, even if they weren't ready to make a change immediately. Other times, we were made to feel “othered” because we weren't appearing on video and had no visual clues about what was happening in the meeting. That feeling is difficult for anyone to endure, even while we stood steadfast in our principles.

Throughout the pandemic and its widespread Zoom adoption, we warned that relying on proprietary, for-profit controlled technology as essential infrastructure is dangerous. Last week, Zoom demonstrated exactly why everyone must stop using their services without any further delay. Specifically, a March 2023 change to Zoom's terms and conditions was uncovered by the press. Namely, Zoom was revealed to be repurposing private user data to train machine learning models.

After widespread pushback and negative press, Zoom amended their terms of service to say they would not use any user participation in Zoom meetings or other user data to train their models. But as is so frustratingly common in the incredibly long and legal language laden terms of service, Zoom reserves the right to change the terms at any point. Only suggesting that users “regularly check” for updates to ensure their security and rights are not taken from them. This points to the constant struggle in the power dynamic between corporations and users. Zoom has abused their household name for profit, knowing that users will not be able to understand the change of terms of service or have an option to use any other software.

Sadly, such corporate bullying by Big Tech is nothing new. Technology users are presented with complex terms and conditions constantly merely to engage in the most simple operations. A recent analysis showed that it could take up to 30 hours just to read the entirety of Zoom's terms and conditions. And, if you haven't gotten some training in reading contracts, it's unlikely you'll be sure what you're really agreeing to, and even with such knowledge and training, we estimate it would take about 50-100 person hours to really understand every implication on rights, privacy, and freedom of Zoom's terms. It's thus no surprise that it took the press months (from March to August) to realize that the clause granting Zoom a “perpetual, worldwide, non-exclusive, royalty-free, sublicensable, and transferable license and all other rights” to use all Customer Content for “machine learning, artificial intelligence, training, testing,” and a variety of other product development purposes.

At SFC, we invested, because our principles (to find or build FOSS solutions for our work) demanded it, in self-hosting alternative video chat platforms through the pandemic (as a parallel strategy to attending Zoom meetings by phone). It was complicated, difficult, and we got teased and sometimes insulted by colleagues who kept questioning why it was so important that we self-host FOSS to do the job of video conference calls. The proprietary and for-profit nature of Zoom also has made it subject to multiple cases of algorithmic bias. The once esoteric seeming issues are now a stark reality. Without control over our basic infrastructure, we will become wholly reliant on companies who prioritize profits over consumer rights. And, like Lando Calrissian, consumers must worry that Darth Vader, at any time, may “alter our deal”. We can do little more than “pray they do not alter it further” . In response to this conundrum, SFC is working to mitigate the damage that Zoom is causing to our colleagues.

Our FOSS member projects have had access to our BigBlueButton chat server for some time. Today we are making it an official part of our infrastructure that we provide to FOSS projects that are part of our organization. More importantly, we announce that we are welcoming anyone who contributes to FOSS who needs access to a video chat server they can trust to apply for access. Finally, we are welcoming anyone who becomes (or renews as) an SFC Sustainer to also have access. Details on all this are below.

Even more, in the coming months, we will run various online sessions that show how we set up and configured our own BBB server and publish tutorial information — in hopes that others can launch self-hosting collectives and Exit Zoom!

We realize this is a small step in mitigating the damage that Zoom is doing and has done. Big Tech's classic strategy — going back to the 1970s — is to lock users into a specific technological workflow and software stack, and then manipulate the terms. Users become victims of Big Tech's control of their devices and technological needs. We are extremely concerned about individuals who run confidential support groups, doctors who practice telemedicine, and workers who Zoom is now telling “if your office uses Zoom, your choices now are to become a subject in our machine learning experiments, or lose your job for not showing up to mandatory meetings”. We hope that this action by Zoom will finally convince the industry and governments that funding FOSS solutions for key infrastructure is necessary — rather simply funding more and more proprietary solutions under the full control of for-profit companies.

How Sustainers Get Access

Make your annual renewal using our online form, and (starting early next week), you'll receive instructions on how to set up your account.

How SFC Member Projects Get Access

Contact your Project Leadership Committee (PLC) and ask them to send you the instructions they received.

How FOSS Community Members Get Access

We will be providing limited access to other FOSS community members. As you know, we are a small non-profit and do not have the resources to provide unlimited access to our video conferencing software, but are working to expand that through donations. If you are interested in applying for an account, you can sign up for a new account here and once you've received the email verification link, please send us an email with the following information:

What is the name and email you used to sign up?
What FOSS communities are you a part of?
What kinds of meetings do you expect you'll be hosting?
Where do your meetings currently take place?
How will using FOSS video conferencing help your community?

Software Freedom & Trademarks: Examining Rust's New Policy through the Lens of FOSS History

Thu, 27 Jul 2023 15:18:00 -0400

A blog post from Software Freedom Conservancy.

Blog post by Denver Gingerich. Please email any comments on this entry to [email protected]"><[email protected]>.

When 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.

RHEL Panel Discussion at FOSSY 2023

Wed, 19 Jul 2023 12:14:00 -0400

A blog post from Software Freedom Conservancy.

Blog post by Bradley M. Kuhn. Please email any comments on this entry to [email protected]"><[email protected]>.

This past weekend, July 13-16th, 2023, Software Freedom Conservancy (SFC) hosted and ran a new conference, FOSSY (Free and Open Source Software Yearly) in Portland, Oregon, USA. I was glad to host the keynote panel discussion on the recent change made by Red Hat (now a subsidiary of IBM) regarding the public source code releases for Red Hat Enterprise Linux (RHEL).

Download the talk video or watch on YouTube

The panelists included (in alphabetical order) Jeremy Alison, software engineer at CIQ (focused on Rocky Linux) and Samba co-founder, myself, Bradley M. Kuhn, policy fellow at SFC, benny Vasquez, the Chair of the AlmaLinux OS Foundation, and James (Jim) Wright, who is Oracle’s Chief Architect for Open Source Policy, Strategy, Compliance, and Alliances.

Red Hat themselves did not reply to our repeated requests to join us on this panel, but we were able to gather the key organizations impacted by Red Hat's recent decision to cease public distribution of RHEL sources. SUSE was also invited but let us know they were unable to send someone on short notice to Portland for the panel.

We're very glad to make the video available to everyone who has been following this evolving story. FOSSY is a new event, and we've hopefully shown how running a community-led FOSS event here in Portland each summer creates an environment where these kinds of important discussions can be held to explore issues impacting FOSS users around the world.

I thank our panelists again for booking last-minute travel to be with us for this exciting panel and thank all the FOSSY attendees for their excellent questions during the panel.

I hope to see all of you at next years' FOSSY!

One week till FOSSY in Portland, Oregon

Thu, 06 Jul 2023 15:10:00 -0400

A news item from Software Freedom Conservancy.

Are you registered?

One week from today (July 13-16), we will be gathered at the Oregon Convention Center for the first ever Free and Open Source Software Yearly (FOSSY) conference, which will be an engaging, educational, inspiring four days of presentations and conversations. Whether you are a long time contributing member of a free software project, a recent graduate of a coding bootcamp or university, or just have an interest in the possibilies that free and open source software bring, FOSSY will have something for you.

Are you coming? It's not too late to join us. Even walk-up registrations will be possible, but if you can register online by tomorrow (July 7), you'll help us get accurate counts for the lunch we're providing and enable us to have your badge ready for you. We sell tickets because the event can't happen without funding, but please don't let that cost be a reason you can't attend -- see below about ways to volunteer, or email us at [email protected].

If you register by tomorrow, you'll have a printed badge just like this one!

If you've been leaning toward coming but haven't booked yet, now is the time. If you're not sure which way you're leaning, please allow us to give you a push with the following updates on what we have planned for you:

Keynotes announced!

We have three timely keynote sessions, and they are all collaborative, to highlight what people in this movement can achieve by working and thinking together.

Friday's will be an in-depth discussion about Red Hat's recent announcements concerning Red Hat Enterprise Linux led by Bradley M. Kuhn with of a panel of very special guests close to the situation.

On Saturday, we'll talk with activists like Kyle Wiens of iFixit about current topics in Right to Repair and how they impact free and open source software communities, from participating in the "1201 process" for Digital Millennium Copyright Act exemptions with the US Copyright Office, to strategies that might work to increase Right to Repair legislation and bringing lawsuits to compel companies to respect consumers' rights.

Sunday's session will invite all FOSSY attendees to come celebrate an important milestone thirteen years in the making: Outreachy surpassed 1,000 interns with its current round of internships! Members of the Outreachy organizers (Anna e só, Karen Sandler and Sage Sharp) will be on stage to reflect on the program's evolution, its successes and the people who have made it possible.

FOSSY is a community conference so of course there is no connection between sponsorship and our keynote sessions. We are very grateful to our sponsors for supporting the event.

Schedule updated!

Please check the schedule again to see updates we've made over the last couple weeks. We're very excited about the work our track and workshop organizers have done to assemble sessions on FreeBSD; BSD Unix; XMPP; FOSS for Education; Growing your Project; FOSS at Play; AArch64/ARM64 Servers; Sustainable Open Source Business; Community: Open Source in Practice; Copyleft and Compliance; Diversity, Equity and Inclusion; Science of Community; FOSS in Daily Life; Issues in Open Work; Right to Repair; Containers; Open Source AI + Data; Software Worker Coops; Security -- and more!

The schedule is also available in the free mobile apps Giggity and Confy.

Thursday night social event

Thursday night we will be hosting a social for all attendees at 7pm at Punch Bowl Social Portland, 340 SW Morrison St Suite 4305, Portland, OR 97204 which is a quick ~15 minute Max ride from the convention center. We are providing appetizers, and the bar will be open to purchase your choice of beverages. All attendees and volunteers are invited!

Volunteers, we appreciate you

As a very small nonprofit, we can't make this event happen without volunteers. We have a good crew in place, but we really could use more! We appreciate our volunteers by thanking you profusely, and by providing a gratis ticket for all four days. Volunteering is also a great way to meet people and make connections. We're scheduling shifts so that you can still have plenty of time to enjoy other parts of the conference too. If you are able to pitch in a few hours to help make the first FOSSY awesome, please sign up and let us know what you'd like to do.

Hotel discounts

There are still discounted rooms available at the conference hotel. To be able to offer the discount, we committed to a block of rooms, so booking here is actually another way to support the conference.

For additional travel and lodging info, see the webpage.

Health and safety

In-person events bring so much positive energy and inspiration. They also do come with some risks. We are aiming to provide a welcoming and safer environment for people who are immunocompromised, disabled, elderly, have support needs, or are caregivers for children, and those of us who share households with or caretake for people in those groups. Face coverings will be required of everyone inside the conference venue. If you are feeling sick or exhibiting symptoms of COVID-19, or test positive for COVID-19, prior to the start of the conference, or on any day of the conference, please contact us at <[email protected]> and we will issue you a refund. You can read our full policy here.

Exhibit Hall

We're proud to offer a carefully curated exhibit hall, which will feature: GNOME, FreeBSD Project and Foundation, Apereo Foundation, SeaGL, XMPP Software Foundation, Open Source Initiative, and CHAOSS.

Sponsors, it's not too late

Thank you to the sponsors who have helped make the first FOSSY possible!

It's not too late to invite your employer to sponsor. Please share our prospectus with them, and email your commitment or questions to [email protected].

If you can't make it

We really hope to see you in-person next week. But, this movement is all about sharing, and we want to share these valuable sessions as widely as we can. While we could not pull off livestreaming this year, we are working hard to make session recordings available after the event. You'll also be able to follow along during the event via our posts on Mastodon.

See you in a week!

A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model

Fri, 23 Jun 2023 12:55:00 -0400

A blog post from Software Freedom Conservancy.

Blog post by Bradley M. Kuhn. Please email any comments on this entry to [email protected]"><[email protected]>.

This article was originally published primarily as a response to IBM's Red Hat's change to no longer publish complete, corresponding source (CCS) for RHEL and the prior discontinuation of CentOS Linux (which are related events, as described below). We hope that this will serve as a comprehensive document that discusses the history of Red Hat's RHEL business model, the related source code provisioning, and the GPL compliance issues with RHEL.

For approximately twenty years, Red Hat (now a fully owned subsidiary of IBM) has experimented with building a business model for operating system deployment and distribution that looks, feels, and acts like a proprietary one, but nonetheless complies with the GPL and other standard copyleft terms. Software rights activists, including SFC, have spent decades talking to Red Hat and its attorneys about how the Red Hat Enterprise Linux (RHEL) business model courts disaster and is actively unfriendly to community-oriented Free and Open Source Software (FOSS). These pleadings, discussions, and encouragements have, as far as we can tell, been heard and seriously listened to by key members of Red Hat's legal and OSPO departments, and even by key C-level executives, but they have ultimately been rejected and ignored — sometimes even with a “fine, then sue us for GPL violations” attitude. Activists have found this discussion frustrating, but kept the nature and tenure of these discussions as an “open secret” until now because we all had hoped that Red Hat's behavior would improve. Recent events show that the behavior has simply gotten worse, and is likely to get even worse.

What Exactly Is the RHEL Business Model?

The most concise and pithy way to describe RHEL's business model is: “if you exercise your rights under the GPL, your money is no good here”. Specifically, IBM's Red Hat offers copies of RHEL to its customers, and each copy comes with a support and automatic-update subscription contract. As we understand it, this contract clearly states that the terms do not intend to contradict any rights to copy, modify, redistribute and/or reinstall the software as many times and as many places as the customer likes (see §1.4). Additionally, though, the contract indicates that if the customer engages in these activities, that Red Hat reserves the right to cancel that contract and make no further contracts with the customer for support and update services. In essence, Red Hat requires their customers to choose between (a) their software freedom and rights, and (b) remaining a Red Hat customer. In some versions of these contracts that we have reviewed, Red Hat even reserves the right to “Review” a customer (effectively a BSA-style audit) to examine how many copies of RHEL are actually installed (see §10) — presumably for the purpose of Red Hat getting the information they need to decide whether to “fire” the customer.

Red Hat's lawyers clearly take the position that this business model complies with the GPL (though we aren't so sure), on grounds that that nothing in the GPL agreements requires an entity keep a business relationship with any other entity. They have further argued that such business relationships can be terminated based on any behaviors — including exercising rights guaranteed by the GPL agreements. Whether that analysis is correct is a matter of intense debate, and likely only a court case that disputed this particular issue would yield a definitive answer on whether that disagreeable behavior is permitted (or not) under the GPL agreements. Debates continue, even today, in copyleft expert circles, whether this model itself violates GPL. There is, however, no doubt that this provision is not in the spirit of the GPL agreements. The RHEL business model is unfriendly, captious, capricious, and cringe-worthy.

Furthermore, this RHEL business model remains, to our knowledge, rather unique in the software industry. IBM's Red Hat definitely deserves credit for so carefully constructing their business model such that it has spent most of the last two decades in murky territory of “probably not violating the GPL”.

Does The RHEL Business Model Violate the GPL Agreements?

Perhaps the biggest problem with a murky business model that skirts the line of GPL compliance is that violations can and do happen — since even a minor deviation from the business model clearly violates the GPL agreements. Pre-IBM Red Hat deserves a certain amount of credit, as SFC is aware of only two documented incidents of GPL violations that have occurred since 2006 regarding the RHEL business model. We've decided to share some general details of these violations for the purpose of explaining where this business model can so easily cross the line.

In the first violation, a large Fortune 500 company (which we'll call Company A), who both used RHEL internally and also built public-facing Linux-based products, decided to create a consumer-facing product (which we'll call Product P) based primarily on CentOS Linux, but P included a few packages built from RHEL sources. Company A did not seek nor ask for support or update services for this separate Product P. Red Hat later became aware that Product P contained some part of RHEL, and Red Hat demanded royalty payments for Product P. Red Hat threatened to revoke the support and update services on Company A's internal RHEL servers if such royalties were not paid.

Since Company A was powerful and had good lawyers and savvy business development staff, they did not acquiesce. Company A ultimately continued (to our knowledge) on as a RHEL customer for their internal servers and continued selling Product P without royalty payments. Nevertheless, a demand for royalties for distribution is clearly a violation as that demand creates a “further restriction” on the permissions granted by GPL. As stated in GPLv3:

You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License.

Red Hat tried to impose a further restriction in this situation, and therefore violated the GPL. The violation was resolved since no royalty was paid and Company A faced no consequences. SFC learned of the incident later, and informed Red Hat that the past royalty demand was a violation. Red Hat did not dispute nor agree that it was a violation, and did informally agree such demands would not be made in future.

In another violation incident, we learned that Red Hat, in a specific non-USA country, was requiring that any customer who lowered the number of RHEL machines under service contract with Red Hat sign an additional agreement. This additional agreement promised that the customer had deleted every copy of RHEL in their entire organization other than the copies of RHEL that were currently contracted for service with Red Hat. Again, this is a “further restriction”. The GPL agreements give everyone the unfettered right to make and keep as many copies of the software as they like, and a distributor of GPL'd software may not require a user to attest that they've deleted these legitimate, licensed copies of third-party-licensed software under the GPL. SFC informed Red Hat's legal department of this violation, and we were assured that this additional agreement would no longer be presented to any Red Hat customers in the future.

In both these situations, we at SFC were worried they were merely a “tip of the proverbial iceberg”. For years, we have heard from Red Hat customers who are truly confused. It's common in the industry to talk about RHEL “seat licenses”, and many software acquisition specialists in the industry are not aware of the nuances of the RHEL business model and do not understand their rights. We remain very concerned that RHEL salespeople purposely confuse customers to sell more “seat licenses”. It's often led us to ask: “If a GPL violation happens in the woods, and everyone involved doesn't hear it, how does anyone know that software rights have indeed been trampled upon in those woods?”. As we do for as many GPL violation reports as we can, we zealously pursue RHEL-related GPL violations that are reported to us, and if you're aware of one, please do [email protected]">email us at <[email protected]> immediately. We fear that be it through incompetence or malice, many RHEL salespeople and business development professionals may regularly violate GPL and no one knows about it. That said, the business model as described by IBM's Red Hat may well comply with the GPL — it's just so murky that any tweak to the model in any direction seems to definitely violate, in our experience.

Furthermore, Red Hat exploits the classic “caveat emptor” approach — popular in many a shady business deal throughout history. While, technically speaking, a careful reader of the GPL and the RHEL agreements understands the bargain they're making, we suspect most small businesses just don't have the FOSS licensing acumen and knowledge to truly understand that deal.

Why Was an Independent CentOS So Important?

Until Red Hat's “aquisition” of CentOS in early 2014, CentOS provided an excellent counterbalance to the problems with the RHEL business model. Specifically, CentOS was a community-driven project, with many volunteers, supported by some involvement from small businesses, to re-create RHEL releases using the CCS releases made for RHEL. Our pre-2014 view was that CentOS was the “canary in the murky coalmine” of the RHEL business. If CentOS seemed vibrant, usable, and a viable alternative to RHEL for those who didn't want to purchase Red Hat's updates and services, the community could rest easy. Even if there were GPL violations by Red Hat on RHEL, CentOS' vibrancy assured that such violations were having only a minor negative impact on the FOSS community around RHEL's codebase.

Red Hat, however, apparently knew that this vibrant community was cutting into their profits. Starting in 2013, Red Hat engaged in a series of actions that increased their grip. First, they “acquired” CentOS. This was initially couched as a cooperation agreement, but Red Hat systematically made job offers that key CentOS volunteers couldn't refuse, acquired the small businesses who might ultimately build CentOS into a product, and otherwise integrated CentOS into Red Hat's own operations.

After IBM acquired Red Hat, the situation got worse. Having gotten rights to the CentOS brand as part of the “aquisition”, Red Hat slowly began to change what CentOS was. CentOS Linux quickly ceased to be a check-and-balance on RHEL, and just became a testing ground for RHEL. Then, in 2020, when most of us were distracted by the worst of the COVID-19 pandemic, Red Hat unilaterally terminated all CentOS Linux development. Later (during the Delta variant portion of the pandemic in late 2021) Red Hat ended CentOS Linux entirely. IBM's Red Hat then used the name “CentOS Stream” to refer to experimental source packages related to RHEL. These were (and are) not actually the RHEL source releases — rather, they appear to be primarily a testing ground for what might appear in RHEL later.

Finally, Red Hat announced two days ago that RHEL CCS will no longer be publicly available in any way. Now, to be clear, the GPL agreements did not obligate Red Hat to make its CCS publicly available to everyone. This is a common misconception about GPL's requirements. While the details of CCS provisioning vary in the different versions of the GPL agreements, the general principle is that CCS need to be provided either (a) along with the binary distributions to those who receive, or (b) to those who request pursuant to a written offer for source. In a normal situation, with no mitigating factors, the fact that a company moved from distributing CCS publicly to everyone to only giving it to customers who received the binaries already would not raise concerns.

In this situation, however, this completes what appears to be a decade-long plan by Red Hat to maximize the level of difficulty of those in the community who wish to “trust but verify” that RHEL complies with the GPL agreements. Namely, Red Hat has badly thwarted efforts by entities such as Rocky Linux and Alma Linux. These entities are de-facto the intellectual successors to CentOS Linux project that Red Hat carefully dismantled over the last decade. These organizations sought to build Linux-based distributions that mirrored RHEL releases, and it is now unclear if they can do that effectively, since Red Hat will undoubtedly capriciously refuse to sell them exactly-one RHEL service and update “seat license” at a reasonable price. It appears that, as of this week, one must have at least that to get timely access to RHEL CCS.

What Should Those Who Care About Software Rights Do About RHEL?

Due to this ongoing bad behavior by IBM's Red Hat, the situation has become increasingly complex and difficult to face. No third party can effectively monitor RHEL compliance with the GPL agreements, since customers live in fear of losing their much-needed service contracts. Red Hat's legal department has systematically refused SFC's requests in recent years to set up some form of monitoring by SFC. (For example, we asked to review the training materials and documents that RHEL salespeople are given to convince customers to buy RHEL, and Red Hat has not been willing to share these materials with us.) Nevertheless, since SFC serves as the global watchdog for GPL compliance, we [email protected]">welcome reports of RHEL-related violations.

We finally express our sadness that this long road has led the FOSS community to such a disappointing place. I personally remember standing with Erik Troan in a Red Hat booth at a USENIX conference in the late 1990s, and meeting Bob Young around the same time. Both expressed how much they wanted to build a company that respected, collaborated with, engaged with, and most of all treated as equals the wide spectrum of individuals, hobbyists, and small businesses that make the plurality of the FOSS community. We hope that the modern Red Hat can find their way back to this mission under IBM's control.

FOSSY schedule announcement

Mon, 19 Jun 2023 11:15:00 -0400

A news item from Software Freedom Conservancy.

The FOSSY schedule has been set! With four days of talks and workshops, we are looking forward to a fantastic conference. Thanks to all our incredible track organizers and speakers for working with us to create a jam packed weekend of FOSS. We look forward to building this conference with you all in Portland, OR this July 13-16th.

Join us Thursday the 13th for registration and a welcome lunch, then there are 2 workshops and 3 tracks to choose from! Grow Your Project Workshop, Free BSD Workshop, AArch64/ARM64 Servers and Open Source, FOSS For Education, XMPP.

Friday the 14th we'll begin with a keynote and coffee and continue with FOSS For Education, Sustainable Open Source Business, Community: Open Source in Practice, FOSS at Play: Games, creative development, and open technology, and 2 half day tracks for BSD Unix and Copyleft and Compliance.

Saturday the 15th has continuations for FOSS For Education and Community: Open Source in Practice also FOSS in Daily Life, Diversity Equity and Inclusion and FOSS, Security, Issues in Open Work.

Sunday the 16th rounds out the conference with day 2 of Diversity Equity and Inclusion and FOSS and Software Worker Coops, Open Source AI + Data, Container Days, Science of Community.

Registration is open and ticket sales are ramping up. Be sure to buy your ticket to give us time to accommodate food orders and dietary restrictions. And our hotel block at the Hyatt still has rooms available that we want to fill. It's a great time to visit Oregon so make the most and see some sights while you are there.

If you would like to volunteer, we are looking for people to help out with setup/ cleanup, room hosting, code of conduct enforcement and the other tasks listed on our volunteering page. Volunteers will get a complimentary ticket, good for all 4 days of the conference.

We are so thankful for all the effort and patience the community has shown us with our first time running a conference. As this first year will be a learning opportunity for us, we hope to gain experience from working cooperatively with all of you to find out how to best serve our community and provide a meaningful conference experience. Working with you all is a pleasure and thank you so much for building this conference with us!

Sourceware, one of the longest standing Free Software hosting platforms, joins SFC

Mon, 15 May 2023 10:48:00 -0400

A news item from Software Freedom Conservancy.

Important Free Software infrastructure project finds non-profit home

As a home for Free Software projects since 1998, Sourceware is a keystone in Free Software infrastructure. For almost 25 years Sourceware has been the long-time home of various core toolchain project communities. Projects like Cygwin, a UNIX API for Win32 systems, the GNU Toolchain, including GCC, the GNU Compiler Colection, two C libraries, glibc and newlib, binary tools, binutils and elfutils, debuggers and profilers, GDB, systemtap and valgrind. Sourceware also hosts standard groups like gnu-gabi and the DWARF Debugging Standard. See the full list project hosted and services provided on the Sourceware projects page.

Becoming an SFC member project will improve future operations carried out by dedicated volunteers to and furthering the mission of Free Software hosting. This will accelerate the Sourceware [email protected]/">technical roadmap to improve and modernize the infrastructure.

As the fiscal host of Sourceware, Software Freedom Conservancy will provide a home for fundraising, legal assistance and governance that will benefit all projects under Sourceware's care. We share one mission: developing, distributing and advocating for Software Freedom. And to offer a worry-free, friendly home for Free Software communities. We see a bright future working together. With Conservancy as fiscal sponsor, Sourceware will also be able to fundraise and have the community of volunteers work together with paid contractors and enter into contracts for managed infrastructure where appropriate.

SFC looks to Sourceware's years of experience in providing outstanding infrastructure as an inspiration for improving the Free Software ecosystem both for other SFC projects, and also in furthering SFC's mission around campaigns to promote Software Freedom Infrastructure. For decades, Sourceware has shown that hosting Free Software projects with Free Software infrastructure is not only possible, but helps create and fosters the growth of relationships and networks within the Free Software communities. SFC is thrilled to join the powerful history of demonstrable experience to grow hosting options that are 100% free software, in the future to bring in new ideas, communities, and projects!

Projects hosted by Sourceware are part of the core toolchain for GNU/Linux distros, embedded systems, the cloud and, through Cygwin, Windows. Back in 1984 Ken Thompson's Reflections on Trusting Trust already described how making the source code for these tools available is essential to create what today we call secure software supply chains. Sourceware provides robust infrastructure and services for projects to adopt secure collaboration and release policies. We forsee future cooperation with other Conservancy member projects, such as the Reproducible Builds project which provides an independently-verifiable path to supply chain security. Additionally, Sourceware will leverage Conservancy advisory role in how community projects are impacted by and can comply with regulations like NIST, CISA, USA Cyber Security Directives and the EU Cyber Resilience act.

Each SFC member project is led by a Project Leadership Committee (PLC). Each individual member of the PLC participates in their own capacity, but nevertheless the majority of the PLC never includes a majority of people affiliated with the same organization. Sourceware's PLC includes various volunteers, past and present, from the Sourceware community. The founding PLC is: Frank Ch. Eigler, Christopher Faylor, Ian Kelling, Ian Lance Taylor, Tom Tromey, Jon Turney, Mark J. Wielaard and Elena Zannoni.

Recent discussions have inspired the Sourceware volunteers to think carefully about the future and succession of the leadership for this important hosting project. By joining SFC, Sourceware gains access to strategic advice and governance expertise to recruit new volunteers and raise funds to support work on Sourceware infrastructure. As part of this governance improvement, Sourceware also announces today regular irc office hours for guest project admins to advise and discuss any needs and issues in hosting. The Sourceware mission page lists various other ways to contact and participate in the community.

Sourceware will continue its long standing mission of providing free software infrastructure to the projects it supports, and this will not change moving forward. The affiliation with SFC will be transparent to the projects hosted on Sourceware. Project admins will keep being in charge of how they utilize the services Sourceware provides.

To support the Software Freedom Conservancy, please become a Sustainer.

You can also donate directly to Sourceware (mention Sourceware in the comment or memo line).

See the donation page for other ways to donate.

Sourceware may be volunteer managed, but wouldn't be possible without the hardware, network resources and services provided by Red Hat and OSUOSL. Additionally build/CI testing machines are provided by various individuals and the Brno University, Marist College, IBM, the Works on Arm initiative and the Gentoo Foundation.

John Deere's ongoing GPL violations: What's next

Thu, 16 Mar 2023 09:00:00 -0400

A blog post from Software Freedom Conservancy.

Blog post by Denver Gingerich. Please email any comments on this entry to [email protected]"><[email protected]>.

I grew up on a farm. My parents worked hard to grow crops and manage the farm business. My parents also found additional jobs to make ends meet. As farmers have done for millennia, my family used tools to farm. Some of those tools were tractors. Farmers now, as they have for thousands of years, rely on their ability and right to fix their tools. Perhaps that's bending a hand rake back into shape. Maybe they need to weld a broken three-point hitch back together. Agriculture was humanity's first truly revolutionary technological advancement. Since its inception, each generation of farmers exercised their right to repair their tools. This has allowed agriculture to grow and improve immeasurably. We take for granted the benefits that this has given us, and the abundance of food it provides.

The right to repair farm tools is now in serious jeopardy, not because farmers haven't fought to maintain this right, and not even because farmers haven't chosen to use tools that guarantee their right to repair their tools. In fact, most farmers are still buying tools that have a right to repair built into them, not by their intrinsic nature, but by the software that the toolmakers have chosen to include as part of the tools they sell to the farmers.

Sadly, farm equipment manufacturers, who benefit immensely from the readily-available software that they can provide as part of the farming tools (tractors, combines, etc.) they sell to farmers, are not complying with the right to repair licenses of the software they have chosen to use in these farming tools. As a result, farmers are cut off from their livelihood if the farm equipment manufacturer does not wish to repair their farming tools when they inevitably fail, even when the farmer could easily perform the repairs on their own, or with the help of someone else they know.

In particular, John Deere, the largest manufacturer of farm equipment in North America and one of the largest worldwide, has been failing to meet the requirements of the software right to repair licenses they use for some time. While we have worked for years with John Deere to try and resolve their compliance problems, they have still not complied with these licenses for the software that they use, which would give farmers the right, and technical details, to repair their own farm tools if Deere complied. This is a serious issue that goes far beyond one person wanting to fix their printer software, or install an alternative firmware on a luxury device. It has far-reaching implications for all farmers' livelihoods, for food security throughout the world, and for how we as a society choose to reward those who make our lives better, or stand in the way of empowering everyone to improve the world.

As we have been doing privately for multiple years, we now publicly call on John Deere to immediately resolve all of its outstanding GPL violations, across all lines of its farm equipment, by providing complete source code, including "the scripts used to control compilation and installation of the executable" that the GPL and other copyleft licenses require, to the farmers and others who are entitled to it, by the licenses that Deere chose to use. What Deere has provided to SFC as of today falls far short of the requirements of the GPL, with respect to both this quoted text, and many other parts of the license. And that speaks only of the products for which Deere has started to engage with us about - for many of almost a dozen requests we've made (each for a different product) Deere has yet to provide anything to us at all. In addition to failing to respond at all to others who have requested source code, Deere's inability to provide complete corresponding source to us for all requested products more than 2 years after our first request is beyond unacceptable, which is why we are making this public statement today - to more strongly encourage Deere to do the right thing and comply with the licenses they use, and to let others know about these serious problems so they have a more complete picture of Deere's attempts to stifle farmers' right to repair their farm equipment.

We stand with all the other organizations that are taking John Deere to task for its various violations of other agreements and laws, including antitrust, and we hope these organizations succeed in bringing fairness to farmers. We each help in our own ways, which is the true strength of the right to repair movement.

If you are a farmer concerned by Deere's practices, or personally affected by them, please reach out to us at [email protected]">[email protected]. By working together, we can give farmers back their rights, allowing them to repair their own farm tools again, by themselves or using their friend or shop of choice, improving their lives and the lives of everyone on earth who depends on them every day.

Call for Community-Led Tracks at FOSSY

Tue, 31 Jan 2023 14:49:00 -0500

A blog post from Software Freedom Conservancy.

Blog post by Daniel Takamori. Please email any comments on this entry to [email protected]"><[email protected]>.

Today Software Freedom Conservancy is officially opening our call for track proposals for our first annual FOSSY conference! We will be holding the conference in Portland, Oregon July 13-16, 2023 at the Oregon Convention Center. We are looking for community driven tracks that can balance important and in depth technical and non-technical issues, while uplifting contributors of all experiences. Tracks will be modeled after the DevRooms at FOSDEM and the miniconfs at linux.conf.au. They may be between 1 and 4 days, and the organizers of the tracks will be in charge of outreach, calls for submissions, communicating with potential speakers in the track, determining the schedule and hosting the track in person at FOSSY.

We're looking for organizers who can give us a really good idea of what we can expect from their track. The description should give a detailed explanation of the topic, ideally along with some of the issues you expect to cover. Example talks you expect, what kind of audience are you aiming for, and how this topic fits into the larger FOSS ecosystem are good things to mention.

You'll note that we ask for two people to be listed as organizers for the track. It's easy to underestimate the work involved so having more than two organizers could also really help to take care of all of the work. We'll be there to help and support you, but this will be your show!

We'd like you to tell us why the organizers are the right ones for the job. Do they have experience running conferences, unique perspectives due to involvement with the topic? Conference organizing is a demanding job that requires a balance of logistics, people centered concerns and technical skills. We trust you to assemble a group of people that can cater to those needs and want to put on a great event.

Given that this is the first FOSSY, we will be creating this space together! How is the topic you are proposing beneficial for the FOSS community and how does it fit into this new space? The hope is to have a balance of technical and non-technical topics, and we want to hear from you about what's important on those issues. Given that we want to shape the conference into something that uplifts contributors of all levels and experience, how will you approach a varied audience?

How long will your track be? Are you planning a quick and deep dive into a single topic or do you dream of having a 4 day long track dealing with tough issues that you want attendees to sit with and reflect on over the weekend? We don't need you to lock yourself into this choice, but we do need a rough figure how much participation and space you'll need if you are hoping to do something specific.

Anything that gives us a sense of the organization and spirit of your tracks will be helpful.

Please use our submission page or email us at [email protected]">[email protected] if you have any questions.

The deadline for application is Sunday March 19th, so be sure to reach out soon!

We're very excited to hear from you about how we can shape this conference into something for us all. Thanks so much for your interest and we hope to see you in July!

(Software) Repair info on EnergyGuide labels: Conservancy replies to FTC's request

Wed, 21 Dec 2022 13:45:00 -0500

A blog post from Software Freedom Conservancy.

Blog post by Denver Gingerich. Please email any comments on this entry to [email protected]"><[email protected]>.

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.

Supporter Interview with Jondale Stratton

Mon, 12 Dec 2022 14:30:00 -0500

A blog post from Software Freedom Conservancy.

Blog post by Daniel Takamori. Please email any comments on this entry to [email protected]"><[email protected]>.

Photo CC-BY-NC-SA Jondale Stratton

Next in our interview series, we have Jondale Stratton, a long time supporter of Software Freedom Conservancy. Jondale is the IT Manager for the National Institute for Mathematical and Biological Synthesis and the Technical Director for his local hackerspace, Knox Makers. In his spare time he enjoys laser cutting, tractors, playing with his bunnies, and replacing people with shell scripts.

Software Freedom Conservancy: Why do you care about software freedom? How long have you been involved?
Jondale Stratton.: From a consumer standpoint, I like how free licences enforce a more honest relationship with vendors. There becomes a balance between the value of the software and how terrible the producer can be before the project will be forked or brought in-house. Personally, I like that the answer to whether I can make something work might be hard but it's never no.

SFC: How do you use free software in your life?
JS: Linux runs every server I administer and every device I use personally. I actively seek to use only FLOSS licenses and consider it a concession when I cannot.

SFC: How do you see our role amongst the various FLOSS organizations?
JS: Most FLOSS organizations seem to be focused on legislation. SFC seems to be the only one actively defending the GPL. Both are important. I really like the SFC's support of member projects. I learned of SFC through my desire to support Inkscape. I believe most people do not know the fiscal responsibilities and navigations required to run a larger project and I appreciate your role in helping with that.

SFC: What's got you most excited from the past year of our work?
JS: I'm happy that you are willing to litigate in defence of GPL. It's a big task and probably deserves more attention. Without defence the GPL loses value and meaning. The stance on Github is logical but tough. They have positioned themselves as ubiquitous with open source projects through early good faith and now seem to be taking advantage of that. It's the danger of being a consumer of closed/proprietary solutions.

SFC: Do you think we are doing a good job reaching a wider audience and do you see us at places you expect? (COVID has made this difficult)
JS: I believe there is room for improvement here. I would expect to start seeing involvement in more conferences and events in the future.

SFC: Have you been involved with any of our member projects in the past?
JS: Only as an end user for a few of the projects. I am mostly involved in the online community for Inkscape.

SFC: What other organizations are you supporting this year?
JS: I support SFC and the EFF.