The Software Freedom Conservancy

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 (or US$68.42 for a caseless One's logic board), 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 or just the board via those links 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.

FOSSY CFP is open - submit your talks and buy your ticket!

Mon, 24 Apr 2023 12:20:00 -0400

A news item from Software Freedom Conservancy.

CFP open until May 14th

Today is the day we open the FOSSY CFP and ticket sales! Join us in Portland, OR on July 13-16th at the Oregon Convention Center. Our track organizers put together an incredible list of tracks including FOSS For Education, Open Source AI + Data, Science of Community, FOSS in Daily Life and much much more. We are looking for speakers of all experience levels and backgrounds; whether you are just getting into technology and want to share your experience or have been developing free software for ages, we want to hear from you!

For the first year of FOSSY we are excited at tracks out volunteer organizers have put together. You'll also find tracks curated by SFC staff including Copyleft & Compliance and SFC Member Projects. Help us put together a program dedicated to showcasing how FOSS is used around the world to help cultivate community, innovate and let us live freely with technology. It's your expertise, knowledge and experience that will help make this conference a success.

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. Our CFP will be open until May 14th (with notice of acceptance the week of the 21st) so be sure to find us on IRC #conservancy on Libera.chat, [email protected]?joinXMPP">XMPP or [email protected]">email. We will start having office hours at 19:00 UTC on Wednesdays in our chat room for anyone to come and ask questions.

You can also purchase your ticket for the conference today! We have tiered pricing to make the conference affordable to professionals, hobbyists and anyone with an interest in free software. Lunch will be provided all 4 days.

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.

SFC's Policy Fellow Files Expert Report in Neo4j v. PureThink

Thu, 09 Feb 2023 10:15:00 -0500

A news item from Software Freedom Conservancy.

Case about the “further restrictions” removal provision of the AGPLv3 continues after counterclaim filing

Update (2023-11-14): Unfortunately, the Court was not swayed by the expert report discussed below. If the SFC were the copyright holder of the text of the AGPLv3, or the trademark holder of the license's name, we would have intervened in this case to clarify these matters for the Court. Since the SFC did not create the AGPLv3 (our employees were involved in GPLv3-related drafting, but not on behalf of SFC), filing the expert report was the only action that SFC could take to assist in this matter. However, going forward, we do encourage anyone facing a “further restrictions” issue with copyleft license to contact us for support — so that those who care about the future of copyleft can coordinate a response together.

(Original announcement follows:)

In the ongoing litigation — Neo4j, Inc. v. PureThink, LLC and John Mark Suhy (5:18-cv-07182) — in U.S. federal court in the Northern District of California, Software Freedom Conservancy (SFC)'s Policy Fellow, Bradley M. Kuhn, will serve as the Defendants' third-party expert on issues related to the AGPLv3. The Defendants' request for Kuhn's expertise comes after months of public discussion about previous preliminary actions in the Neo4j litigation.

As outlined in the Joint Case Management Statement, filed earlier this month, the key issue of concern in the FOSS community remains an unsettled controversy in this case. Specifically, the list of Legal and Factual Issues That Remain In Dispute filed with the Court includes: “whether removal of the Common’s [sic] Clause on Neo4J Sweden’s open source version of Neo4J software … was justified and authorized … based on the then standard application of the terms of the AGPL allowing removal of further restrictions”. Furthermore, Defendants note in the same filing that Kuhn's expert report bears heavily on the question of PureThink and Suhy's right to exercise the AGPLv3's “further restrictions” removal clause (found in AGPLv3§7¶4).

As often happens with complex litigation, prior news on this case have led many in the FOSS community to incorrectly believe that the issue of the right to remove the so-called “Commons Clause” when it is attached to AGPLv3 is now a settled question. However, the issue is still not fully litigated. Two weeks ago, Defendants filed their updated counterclaim. In its eighth clause of action, Defendants “request a declaration [from the Court] that the Commons Clause does not prevent PureThink [et al] … from providing professional services to users of the open source versions of Neo4J where the AGPL has a Commons Clause”.

SFC, which works to uphold users' rights with copyleft, gladly provides Kuhn's time to serve as an expert on this important issue of users' rights under the AGPLv3. While it is typical for outside experts to receive compensation, Kuhn will serve pro bono publico as an expert (with only travel expenses (to appear for depositions and trial) covered by the Defendants). SFC remains deeply concerned at the incorrect claims about AGPLv3§7¶4 that Neo4j has promulgated. SFC is happy to provide Kuhn's time and expertise in this matter.

As always, SFC does its work as transparently as possible. As such, we release today the expert report that Kuhn provided in this case. This expert report not only clears up past confusing and incorrect information promulgated on this matter in the media, but also provides a thorough summary of events leading up to the creation of the “further restrictions” removal provision found in AGPLv3 and GPLv3.

SFC encourages everyone who cares about the rights and freedoms guaranteed by copyleft licenses to review the expert report available here, and to follow the Neo4j case as it proceeds.

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.

Matcher interview with Justin Flory

Wed, 30 Nov 2022 13:48: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 Justin W. Flory

This year for our fundraising season, we are highlighting some of the incredible donors contributing to our matching fund (of $104,759!!). First up in our interview series is Justin W. Flory who has generously provided matching funds. He has repped Software Freedom Conservancy at a lot of recent conferences and it's always exciting to see him handing out our stickers and speaking to people about it. We were so happy to catch up with them and see what drives his passion behind software freedom and ethical technology.

Software Freedom Conservancy: Why do you care about software freedom? How long have you been involved?
Justin W. Flory: My trajectory in life and career for the last eight years was molded by the Software Freedom movement. As a teenager, I used Linux and Open Source software to run my own multiplayer game server for Minecraft. This exposed me both to open source as a concept but also the communities responsible for the production of great things made together with others. Fundamentally, my interest and passion for Free Software come from a human-centered perspective as a method to build more responsible technology for and by society.

SFC: How do you use free software in your life?
JF: I run Fedora Linux since 2014. It began with my first personal laptop that I received as a high school student. Subsequently, since the Fedora Project only ships Free & Open Source software, libraries, and codecs by default, I have been exposed to a wide range of open tools and services. Since October 2022, I am now working full-time at Red Hat on the Fedora Project. We use a hosted Matrix server from Element for our community chat and a Discourse forum for project discussions. I am an ardent user of Firefox for many years, including my extensive self-made categorization system and library of bookmarks covering several topic areas.

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?
JF: Somewhere in the middle. Today I work as a Community Architect, but I previously worked in systems engineering and received a degree in networking & systems administration. Being a community person in a project like Fedora requires me to wear both the developer and end-user hat, both for our actual users and the people who participate in many different capacities in the project.

SFC: What is it that you see Software Freedom Conservancy does that other groups are not?
JF: The SFC are the hidden heroes of the Software Freedom movement. I love the breadth of issues that the Conservancy addresses that are of particular relevance to the survival of the Software Freedom movement. The critically-important work of enforcing reciprocal licenses guarantees the promise of Free Software licenses and ensures that licensors of copyleft software have their rights respected. Additionally, the creation and sustenance of the Outreachy program introduces numerous people of many diverse backgrounds to the movement. Outreachy opens doors for others to become a part of the young story of Free Culture and Free Software.
For a lover and supporter of Free Software, I do not see any charity or foundation that has as much of a profound impact in the ecosystem as the Conservancy.

SFC: How do you see our role amongst the various FLOSS organizations?
JF: The SFC does both the hidden labor that strengthens the foundations of FLOSS as well as key advocacy and activism to further the collective interests of the movement. The activism includes copyleft compliance work (e.g. Vizio suit) and directly supporting the many member projects supported by the Conservancy.

SFC: What's got you most excited from the past year of our work?
JF: I participated as an Outreachy mentor for the first time since 2019 and I was so excited by how the Conservancy is growing the team around Outreachy. Getting back in as a mentor helped demonstrate to me how much care and empathy the Conservancy builds into how Outreachy is handled. It might not be new work, but it is work that has a high value to me and I definitely felt grateful for it in 2022.

SFC: Do you think we are doing a good job reaching a wider audience and do you see us at places you expect?
JF: I think COVID has made this difficult, and the most recent fragmentation of Twitter compounds it. I think Copyleft Conf filled an important space in the ecosystem, and I am hopeful for its return to continue filling this space and bringing people back together again on important issues.

SFC: Have you been involved with any of our member projects in the past?
JF: I have not participated directly, but I am the user of several projects like git, Inkscape, and Etherpad.

SFC: What other organizations are you supporting this year?
JF: I am also supporting two other organizations, Green Card Voices and the Rail Passengers Association.
Green Card Voices is a U.S. non-profit organization dedicated to build inclusive and integrated communities between immigrants and their neighbors through multimedia storytelling, and Rail Passengers Association advocates on behalf of America's rail passengers for improved, expanded, and safer train service.

Justin W. Flory is one of our individual matchers this year. He is originally from the Greater Atlanta Area in the United States. Travel is one of his passions, especially traveling by rail. He knows a profuse amount about espresso and coffee, and once studied the secrets of wine from a Croatian winemaker. Music is one of his favorite artistic expressions and he curates both a physical and digital music collection. It isn't surprising when he ends up flipping through crates at a record store. The best way to find him online is through his blog at blog.jwf.io.

How we all develop and support free software

Tue, 29 Nov 2022 11:24: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 is Giving Tuesday, and I'd like to share part of my story that brought me to Software Freedom Conservancy. Having started as a donor over 5 years ago, I find myself now with even more passion for our mission as an employee.

I've been using software for close to 30 years; I wrote my first program around 25 years ago, and I've been working in non-profit free software for over a decade. Over all that time the thing that keeps bringing me back is that software is for people. Made by and for people.

Having worked in technical roles as a systems administrator, site reliability engineer and CIengineer, the last year and a half at Software Freedom Conservancy is the first non-technical role I've had. Stepping into the Community Organizer role has allowed me to reinvigorate my passion for FOSS by working directly with people. There have been the usual differences that have cropped up: feedback cycles with people are much longer than just pushing a new patch to see if the tests pass, prose is a lot harder to write than even the more esoteric programming languages (different people use different compilers!). I certainly never thought I'd have to help wih fundraising! But it turns out as a developer I often felt disconnected and distant from the people my code was supposed to support. So while stressful and juggling many things at once, it's a grounding activity that really drives home how connected our mission is to the people who help support us.

There are a few differences between non-technical and technical roles in free software development that I have noticed.

The first is bugs. There are bugs you learn to live with (screen sharing with Wayland and free software video conferencing is still a pain), and some that need the highest priority attention (it's been just over a year since the Log4J incident). Unlike debugging code, in community building spaces we don't have the luxury of thinking of problems as bottlenecks, with absolute solutions. With people, there are often no right or wrong answers. We work cooperatively over a long period of time to build a shared history that informs how we deal with issues that arise.

While in the technical context, I would often think of community building in terms of making it easier to get code upstream, or work with developers of an adjacent library. Community building itself has an intrinsic value, which is something we don't get when writing abstract code. The time scale for human interaction and relations is longer than the half life of an arbitrary patch and can thus use a bit more nuance and care when dealing with each other. Especially in the volunteer context of FOSS projects, understanding each others lives and timelines removes the ambiguity that text based communication often leaves.

Most starkly, the thing I never truly had to worry about in other jobs was fundraising. I thought I could dodge this aspect of my career by not continuing as an academic mathematician, but real work needs real resources. The technology field is an interesting one, we often have large amounts of money floating through what is often touted as a meritocracy. So in my mind if we could just talk about all the great work we do as a non-profit, by the meritocratic principles, we should have money flowing out our gills! Alas, the investors don't flock to non-profits as much as they do to startups.

So how can we work around the absence of a meritocracy to fund our work? I think it all comes back to finding the people who believe in software freedom as much as we do. And extending open arms to those people who haven't heard about it, but are equally affected by the encroaching proprietary software corporations. By sticking to our mission and actively creating a more equitable world in which software freedom is the default (and not an alternative we have to fight for) is how we'll gain momentum and win people over. Our dedication to software freedom speaks for itself through the projects we host, the diversity and inclusion efforts we sustain and by being the only organization in the world doing widespread license compliance.

The human side of open source is complex and requires deliberate, relationship-driven work. That deliberate work can be slow and doesn’t fit neatly under the profit and efficiency models that the tech industry often revolves around. The same mindset that coders apply to “bugs” doesn’t work for conflict resolution in communities, because people’s values and interests are multi-faceted. SFC works to sustain a thriving community around technology that works for people’s needs.

We at SFC do this work with your help. We are able to pursue a more just world, not just through code, but through relationship building with sustainers like you. Our community is incredible and I wouldn't trade writing unit tests for the joy and passion I feel working alongside contributors from all over the world. Please consider becoming a sustainer and helping us all year, or donating to us so we can work together to create a more just future for all.

Trademark Was Made to Prevent Attack of the “Clones” Problem in App Stores

Mon, 11 Jul 2022 12:35: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]>.

Suppose you go to your weekly MyTown market. The market runs Saturday and Sunday, and vendors set up booths to sell locally made products and locally grown and produced food. On Saturday, you buy some delicious almond milk from a local vendor — called Al's Awesome Almond Milk. You realize that Al's Awesome would make an excellent frozen dessert, so you make your new frozen dessert, which you name Betty's Best Almond Frozen Dessert. You get a booth for Sunday for yourself, and you sell some, but not as much as you'd like.

The next week, you realize you might sell more if you call it Al's Awesome Almond Frozen Dessert instead of your own name. Folks at the market know Al, but not you. So you change the name. Is this a morally and legally acceptable thing to do?

This is a question primarily regarding trademarks. We spend a lot of time in the Free and Open Source Software (FOSS) community talking about copyrights and patents, but another common area of legal issues that face FOSS projects (in addition to copyright and patent) is trademark.

In fact, FOSS projects probably don't spend enough time thinking about their trademark. Nearly ten years ago, Pam Chestek — a lawyer and expert in trademark law as it relates to FOSS and board member of OSI — gave an excellent talk at FOSDEM (2013), wherein she explored how FOSS projects can use trademarks better and to ensure rights of consumers — particularly when dealing with bad actors. Our own Executive Director, Karen Sandler, had also spoken about this issue as well. These older talks, in turn, spawned an ongoing conversation that continues to this day in FOSS policy circles.

Specifically, last week, we learned that the Microsoft Store was changing their policies, ostensibly to deal with folks (probably some of whom are unscrupulous) rebuilding binaries for well-known FOSS projects and uploading them to the Microsoft Store. Yet, this is a longstanding issue in FOSS policy. FOSS experts in this area would have been happy to share what's been learned over the last ten years of studying this issue.

The problem Microsoft faces here is the same problem that the MyTown market folks face if you show up trying to sell Al's Awesome Almond Frozen Dessert. The store/market can set rules that you will no longer be able to sell if you are found to infringe the trademark of another seller. The market could simply require the trademark holder to take trademark action themselves, or it could offer some form of assistance, arbitration, or other-extra-legal resolution mechanism⁰.

There is often temptation in FOSS to give special status to maintainers, or the original developer, or the copyright holder, or some other entity that is considered “official”. In FOSS, though, the only mechanism of officialness is the trademark — the name of the upstream project (or the fork). The entire point of FOSS is that for the code itself, everyone should have equal rights to the original developers, to the maintainers, or to any other entity.

We have faced this with our member project, Inkscape. While the Inkscape Project Leadership Committee has chosen not to charge for the version of Inkscape that they upload on Microsoft Store, we did see this very problem for many years before these app stores even existed. Namely, it was common for third-parties to sell Windows binaries on CD's for Inkscape in an effort to make a quick buck. We did trademark enforcement in these cases — not forbidding these vendors from selling — but simply requiring the vendors to clearly say that the product was a modified version of Inkscape. Or, if it was unmodified redistribution of Inkscape's own binaries, we required the vendor to note that the Inkscape project's website was the official source for these binaries.

I have often written to complain about copyright and patent law. I have my complaints about trademark law (and I've seen trademark grossly abused, even), but trademark laws tenets are really reasonable and solid: to ensure consumers know the source and quality of the products they receive.

The problem of concern here is one well handled by trademark. It doesn't need excessive app store rules; we don't need FOSS licenses to be usurped or superseded by Draconian policy. And, this solution to this particular problem has been long-known by FOSS. Pam's talk in 2013 explained it quite well!

The MyTown Market doesn't need to create a policy that forbids you from buying Al's Awesome Almond Milk on Saturday and reselling a product based on it on Sunday. They just need to let Al know his rights under trademark, and maybe offer a lightweight provisional suspension of your booth if the trademark complaint seems primia facie valid. But, most importantly, before it announces new rules with a 30 day clock, MyTown's leadership really should discuss it with the citizens first to find a policy that takes into account concerns of the people. Even if they fail to do that, there are MyTown's elected officials whose actions are accountable to the people. App store companies are accountable only to their shareholders, not the authors of the apps. Companies could benefit by learning that the FOSS community prioritizes respecting authors, protecting consumers' and users' rights, and by understanding that the line between user and contributor should blur. The FOSS marketplace functions because the community works.

Footnotes

⁰ I hesitate to even suggest that an app store should create an extra-legal process regarding trademark enforcement beyond the typical governmental mechanisms — lest they decide they have to do it. A major problem with app stores is that they create rules for software distribution that are capricious, and arbitrary. We all do want FOSS available on Microsoft, Apple, and Google-based platforms — and as such are forced to negotiate (or, rather, try to negotiate) for FOSS-friendly terms. Ultimately, though, the story of major vendor-controlled app stores is always the story of “just barely” being able to put FOSS on them, because the goal of these entities is to profit themselves, not serve the community. We prefer app stores like F-Droid that are community-organized and are not run for-profit.

Microsoft To Ban Commercial Open Source from App Store

Thu, 07 Jul 2022 12:55:00 -0400

A blog post from Software Freedom Conservancy.

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

Microsoft Will Even Prohibit Charitable FOSS Fundraising Through the “Microsoft Store”

A few weeks ago, Microsoft quietly updated its Microsoft [app] Store Policies, adding new policies (which go into effect next week), that include this text:

all pricing … must … [n]ot attempt to profit from open-source or other software that is otherwise generally available for free [meaning, in price, not freedom].

Yesterday, a number of Microsoft Store users discovered this and started asking questions. Quickly, those of us (including our own organization) that provide Free and Open Source Software (FOSS) via the Microsoft Store started asking our own questions too. While Microsoft has acknowledged the ensuing community outrage, they have not clarified their policy. In the meantime, this clause reverses long-standing app store policies, and is already disrupting commerce on their platform (with its tight countdown clock to implementation). In particular, Microsoft now forbids FOSS redistributors from charging any money for nearly all FOSS (i.e., “profit”). Since all (legitimate) FOSS is already available (at least in source code form) somewhere “for free” (as in “free beer”), this term (when enacted) will apply to all FOSS.

For decades, Microsoft spent great effort to scare the commercial software sector with stories of how FOSS (and Linux in particular) were not commercially viable products. Microsoft even once claimed that anyone who developed FOSS under copyleft was against the American Way. Today, there are many developers who make their living creating,supporting, and redistributing FOSS, which they fund (in part) by charging for FOSS on app stores. We in the FOSS community have long disagreed with Microsoft: we have touted that FOSS provides true neutrality regarding commercial and non-commercial activity — both are permitted equally. In short, our community proved Microsoft wrong with regard to the commercial viability and sustainability of FOSS.

Sadly, these days, companies like Microsoft have set up these app stores as gatekeepers of the software industry. The primary way that commercial software distributors reach their customers (or non-profit software distributors reach their donors) is via app stores. Microsoft has closed its iron grasp on the distribution chain of software (again) — to squeeze FOSS from the marketplace. If successful, even app store users will come to believe that the only legitimate FOSS is non-commercial FOSS.

This is first and foremost an affront to all efforts to make a living writing open source software. This is not a merely hypothetical consideration. Already many developers support their FOSS development (legitimately so, at least under the FOSS licenses themselves) through app store deployments that Microsoft recently forbid in their Store. The well-known Krita painting software and the video editing software ShotCut are both sold on Microsoft's app store (and will both soon be in violation of Microsoft's terms). Indeed, our own Inkscape project has unilaterally chosen to only request, rather than require, donations from Microsoft Store users, but this new term forces that decision upon Inkscape permanently. These represent just a few examples of developers and/or redistributors left out in the cold under Microsoft's new terms.

Microsoft counter-argues that this is about curating content for customers and/or limiting FOSS selling to the (mythical) “One True Developer”. But, even a redrafted policy (that Giorgio Sardo (General Manager of Apps at Microsoft) hinted at publicly early today) will mandate only toxic business models for FOSS (such as demo-ware, less-featureful versions available as FOSS, while the full-featured proprietary version is available for a charge). Any truly FOSS system is always “generally available for free” — since the developers do the work in public, and encourage others to remix and rebuild the software into binaries for all sorts of platforms. These are essential rights and freedoms that FOSS licenses give users and businesspeople alike. FOSS was designed specifically to allow both the original developers and downstream redistributors to profit fairly from the act of convenient redistribution (such as on app stores). No company that supports FOSS and its commercial methodologies would propose to curtail these rights and freedoms. So we're left quite suspect of Microsoft's constant claims that they've changed their tune about FOSS. They still oppose it; they've just gotten more crafty about the methods of doing so.

Selling open source software has been a cornerstone of open source's sustainability since its inception. Precisely because you can sell it, open source projects like Linux (which Microsoft claims to love) have been estimated to be worth billions of dollars. Microsoft apparently does not want any FOSS developers to be able to write open source in a sustainable way.

Finally, this is a known pattern of Microsoft's behavior. Rolling out unreasonable and unconscionable policies — only to “magnanimously” retract them weeks or months later — is a strategy that they've used before. Indeed, Microsoft employed this exact tactic when originally creating their app store (then marked under the predecessor brand name, “Windows Marketplace”). Initially, Microsoft banned all copyleft licenses from its app store, and when the obvious outrage came, Microsoft cast themselves as benevolently willing to amend the policy and allow FOSS on the Microsoft Store. Of course, we again (as we did then) immediately call on Microsoft to reverse their new anti-FOSS Microsoft Store Policies and make it explicitly clear in these Policies that selling open source is not only allowed but encouraged.

Nevertheless, we're cognizant that Microsoft probably planned all this, anyway — including the community outrage followed by their usual political theater of feigned magnanimity. It seems this is just Microsoft's latest effort to curtail the forms of FOSS activity that don't directly benefit them. Microsoft may say that they love Open Source, but only so far as they exclusively are the ones who profit from FOSS on their platforms.

Update on 2022-07-08: After we and others pointed out this problem, a Microsoft employee claimed via Twitter that they would “delay enforcement” of their new anti-FOSS regulation. We do hope Microsoft will ultimately rectify the matter, and look forward to the change they intend to enact later. Twitter is a reasonable place to promote such a change once it's made, but an indication of non-enforcement by one executive on their personal account is a suboptimal approach. This is a precarious situation for FOSS projects who currently raise funds on the Microsoft Store; they deserve a definitive answer.

Given the tight timetable (just five days!) until the problematic policy actually does go into effect, we call on Microsoft to officially publish a corrected policy now that addresses this point and move the roll-out date at least two months into the future. (We suggest September 16, 2022.) This will allow FOSS projects to digest the new policy with a reasonable amount of time, and give Microsoft time to receive feedback from the impacted projects and FOSS experts.

Give Up GitHub: The Time Has Come!

Thu, 30 Jun 2022 06:00:00 -0400

A blog post from Software Freedom Conservancy.

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

Those who forget history often inadvertently repeat it. Some of us recall that twenty-one years ago, the most popular code hosting site, a fully Free and Open Source (FOSS) site called SourceForge, proprietarized all their code — never to make it FOSS again. Major FOSS projects slowly left SourceForge since it was now, itself, a proprietary system, and antithetical to FOSS. FOSS communities learned that it was a mistake to allow a for-profit, proprietary software company to become the dominant FOSS collaborative development site. SourceForge slowly collapsed after the DotCom crash, and today, SourceForge still refuses to solve these problems⁰. We learned a valuable lesson that was a bit too easy to forget — especially when corporate involvement manipulates FOSS communities to its own ends. We now must learn the SourceForge lesson again with Microsoft's GitHub.

GitHub has, in the last ten years, risen to dominate FOSS development. They did this by building a user interface and adding social interaction features to the existing Git technology. (For its part, Git was designed specifically to make software development distributed without a centralized site.) In the central irony, GitHub succeeded where SourceForge failed: they have convinced us to promote and even aid in the creation of a proprietary system that exploits FOSS. GitHub profits from those proprietary products (sometimes from customers who use it for problematic activities). Specifically, GitHub profits primarily from those who wish to use GitHub tools for in-house proprietary software development. Yet, GitHub comes out again and again seeming like a good actor — because they point to their largess in providing services to so many FOSS endeavors. But we've learned from the many gratis offerings in Big Tech: if you aren't the customer, you're the product. The FOSS development methodology is GitHub's product, which they've proprietarized and repackaged with our active (if often unwitting) help.

FOSS developers have been for too long the proverbial frog in slowly boiling water. GitHub's behavior has gotten progressively worse, and we've excused, ignored, or otherwise acquiesced to cognitive dissonance. We at Software Freedom Conservancy have ourselves been part of the problem; until recently, even we'd become too comfortable, complacent, and complicit with GitHub. Giving up GitHub will require work, sacrifice and may take a long time, even for us: we at Software Freedom Conservancy historically self-hosted our primary Git repositories, but we did use GitHub as a mirror. We urged our member projects and community members to avoid GitHub (and all proprietary software development services and infrastructure), but this was not enough. Today, we take a stronger stance. We are ending all our own uses of GitHub, and announcing a long-term plan to assist FOSS projects to migrate away from GitHub. While we will not mandate our existing member projects to move at this time, we will no longer accept new member projects that do not have a long-term plan to migrate away from GitHub. We will provide resources to support any of our member projects that choose to migrate, and help them however we can.

There are so many good reasons to give up on GitHub, and we list the major ones on our Give Up On GitHub site. We were already considering this action ourselves for some time, but last week's event showed that this action is overdue.

Specifically, we at Software Freedom Conservancy have been actively communicating with Microsoft and their GitHub subsidiary about our concerns with “Copilot” since they first launched it almost exactly a year ago. Our initial video chat call (in July 2021) with Microsoft and GitHub representatives resulted in several questions which they said they could not answer at that time, but would “answer soon”. After six months of no response, Bradley published his essay, If Software is My Copilot, Who Programmed My Software? — which raised these questions publicly. Still, GitHub did not answer our questions. Three weeks later, we launched a committee of experts to consider the moral implications of AI-assisted software, along with a parallel public discussion. We invited Microsoft and GitHub representives to the public discussion, and they ignored our invitation. Last week, after we reminded GitHub of (a) the pending questions that we'd waited a year for them to answer and (b) of their refusal to join public discussion on the topic, they responded a week later, saying they would not join any public nor private discussion on this matter because “a broader conversation [about the ethics of AI-assisted software] seemed unlikely to alter your [SFC's] stance, which is why we [GitHub] have not responded to your [SFC's] detailed questions”. In other words, GitHub's final position on Copilot is: if you disagree with GitHub about policy matters related to Copilot, then you don't deserve a reply from Microsoft or GitHub. They only will bother to reply if they think they can immediately change your policy position to theirs. But, Microsoft and GitHub will leave you hanging for a year before they'll tell you that!

Nevertheless, we were previously content to leave all this low on the priority list — after all, for its first year of existence, Copilot appeared to be more research prototype than product. Facts changed last week when GitHub announced Copilot as a commercial, for-profit product. Launching a for-profit product that disrespects the FOSS community in the way Copilot does simply makes the weight of GitHub's bad behavior too much to bear.

Our three primary questions for Microsoft/GitHub (i.e., the questions they had been promising answers to us for a year, and that they now formally refused to answer) regarding Copilot were:

What case law, if any, did you rely on in Microsoft & GitHub's public claim, stated by GitHub's (then) CEO, that: “(1) training ML systems on public data is fair use, (2) the output belongs to the operator, just like with a compiler”? In the interest of transparency and respect to the FOSS community, please also provide the community with your full legal analysis on why you believe that these statements are true.
We think that we can now take Microsoft and GitHub's refusal to answer as an answer of its own: they obviously stand by their former CEO's statement (the only one they've made on the subject), and simply refuse to justify their unsupported legal theory to the community with actual legal analysis.
If it is, as you claim, permissible to train the model (and allow users to generate code based on that model) on any code whatsoever and not be bound by any licensing terms, why did you choose to only train Copilot's model on FOSS? For example, why are your Microsoft Windows and Office codebases not in your training set?
Microsoft and GitHub's refusal to answer also hints at the real answer to this question, too: While GitHub gladly exploits FOSS inappropriately, they value their own “intellectual property” much more highly than FOSS, and are content to ignore and erode the rights of FOSS users but not their own.
Can you provide a list of licenses, including names of copyright holders and/or names of Git repositories, that were in the training set used for Copilot? If not, why are you withholding this information from the community?
We can only wildly speculate as to why they refuse to answer this question. However, good science practices would mean that they could answer that question in any event. (Good scientists take careful notes about the exact inputs to their experiments.) Since GitHub refuses to answer, our best guess is that they don't have the ability to carefully reproduce their resulting model, so they don't actually know the answer to whose copyrights they infringed and when and how.

As a result of GitHub's bad actions, today we call on all FOSS developers to leave GitHub. We acknowledge that answering that call requires sacrifice and great inconvenience, and will take much time to accomplish. Yet, refusing GitHub's services is the primary power developers have to send a strong message to GitHub and Microsoft about their bad behavior. GitHub's business model has always been “proprietary vendor lock-in”. That's the very behavior FOSS was founded to curtail, and it's why quitting incumbent proprietary software in favor of a FOSS solution is often difficult. But remember: GitHub needs FOSS projects to use their proprietary infrastructure more than we need their proprietary infrastructure. Alternatives exist, albeit with less familiar interfaces and on less popular websites — but we can also help improve those alternatives. And, if you join us, you will not be alone. We've launched a website, GiveUpGitHub.org, where we'll provide tips, ideas, methods, tools and support to those that wish to leave GitHub with us. Watch that site and our blog throughout 2022 (and beyond!) for more.

Most importantly, we are committed to offering alternatives to projects that don't yet have another place to go. We will be announcing more hosting instance options, and a guide for replacing GitHub services in the coming weeks. If you're ready to take on the challenge now and give up GitHub today, we note that CodeBerg, which is based on Gitea implements many (although not all) of GitHub. Thus, we're also going to work on even more solutions, continue to vet other FOSS options, and publish and/or curate guides on (for example) how to deploy a self-hosted instance of the GitLab Community Edition.

Meanwhile, the work of our committee continues to carefully study the general question of AI-assisted software development tools. One recent preliminary finding was that AI-assisted software development tools can be constructed in a way that by-default respects FOSS licenses. We will continue to support the committee as they explore that idea further, and, with their help, we are actively monitoring this novel area of research. While Microsoft's GitHub was the first mover in this area, by way of comparison, early reports suggest that Amazon's new CodeWhisperer system (also launched last week) seeks to provide proper attribution and licensing information for code suggestions¹.

This harkens to long-standing problems with GitHub, and the central reason why we must together give up on GitHub. We've seen with Copilot, with GitHub's core hosting service, and in nearly every area of endeavor, GitHub's behavior is substantially worse than that of their peers. We don't believe Amazon, Atlassian, GitLab, or any other for-profit hoster are perfect actors. However, a relative comparison of GitHub's behavior to those of its peers shows that GitHub's behavior is much worse. GitHub also has a record of ignoring, dismissing and/or belittling community complaints on so many issues, that we must urge all FOSS developers to leave GitHub as soon as they can. Please, join us in our efforts to return to a world where FOSS is developed using FOSS.

We expect this particular blog post will generate a lot of discussion. We welcome you to interact with SFC staff on our public mailing list about this effort.

Footnotes

⁰SourceForge is now built as a (apparently proprietary) fork of a different FOSS system (called Allura). SourceForge's CEO ignored our multiple inquiries asking if SourceForge really is running upstream Allura (i.e., has no proprietary modifications), and our repeated requests for a link that explains how a project can leave SourceForge for self-hosted Allura. The responses from SourceForge management were quite similar to those received since 2001 — when they first went proprietary.

¹However, we have not analyzed CodeWhisperer in depth so we cannot say for sure if Amazon's implementation is compliant with the respective licenses. Nevertheless, Amazon's behavior here shows sharp contrast with Microsoft's GitHub: Amazon acknowledges the obvious fact that there are license obligations that deserve attention and care when building AI-assisted programming solutions.

A Federal Hearing about Rights under GPL

Wed, 11 May 2022 13:11: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]>.

Possible Opportunity for the Public To Hear Oral Arguments in Key GPL Enforcement Case

In our previous update regarding our copyleft enforcement lawsuit against Vizio, we talked about how Vizio “removed” the case to USA federal court (namely, the Central District of California), and how we filed a motion to “remand” the case back to state court. While this all seems like minor legal wrangling early in a case, this very first skirmish in our case goes to the very heart of the right for software repair for consumers. While it won't be a final decision in the case, this motion will be the first indication whether the federal courts view the GPL as purely a copyright license, or as a contract, or as both. That question has been central to legal debate about the GPL for decades, and, thanks to our case, for the first time, a federal Court will directly consider this question.

Our view (and the view of many attorneys whose opinions we trust) and which is supported by substantial case law, is that the GPL functions as both a copyright license and a contract, and that third parties who receive distribution of GPL'd (and LGPL'd) software are third-party beneficiaries. We've done both copyright-based and contract-based enforcement, and both have their advantages. Contract-based enforcement as a third-party has advantages that are central to the GPL's policy goals. Consumers are the first to discover violations in the first place. Consumers are the most likely to utilize complete, corresponding source code (CCS) to enhance their use of the products they have purchased. Third-party, contractual based enforcement gives consumers legal authority when they ask companies for access to the source code that should be available to them. In other words, this approach gives consumers the ability to ask the Court directly for the most important thing that copyleft assures: a right to receive the CCS and “the scripts used to control compilation and installation of the executable”. Indeed, in our suit we have asked only for access to the source code, not for any money.

Our case now is the first of its kind to adjudicate the third-party beneficiary contractual theory. We are excited that a federal district Court is poised to give its first answer to the central question to this endeavor, namely: “Are the GPL and LGPL merely copyright licenses, and thus preempted and only subject matter for the US federal courts, or can a third-party bring a contract claim in state court?” If this question intrigues you, we encourage you to read our motion for remand, Vizio's reply to that motion and our rebuttal reply.

Most importantly, clear your calendar for this Friday 13 May 2022 at 10:30 US/Pacific! While Judge Staton may chose to rule on this motion strictly based on those paper filings, the judge has scheduled a hearing for that date and time. What's more, anyone in the world can attend this hearing to listen! Instructions for how to attend are found on Judge Staton's website ⁰.

While, as FOSS activists, we're very sad that the Judge has chosen to use a proprietary videochat platform, we're glad that PSTN dial-in is provided, and we'll be dialing in and encourage you to do so as well. Watch our microblog for live updates!

⁰ Please take careful note of the warning on the Judge's website: Recording, copying, photographing and rebroadcasting of court proceedings is prohibited by federal law. Remember: you can take as many notes as you like, and even live blog/microblog what you hear, but take great care to follow the directives on Judge Staton's website.

Fighting for the right to repair your electronics - we need your help

Mon, 02 May 2022 10:09: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]>.

Defending your right to modify and repair the software on your electronics has been a cornerstone of Software Freedom Conservancy since its inception. We defend these rights in a variety of ways: petitioning the Copyright Office to return our repair and modification rights, investigating reports people send us where companies are using our member projects' code but aren't providing the source or repair and modification information that the project's license requires, contacting those companies to remind them of the license requirements, and (eventually, in rare cases after companies ignore our gentle reminders for many months) filing lawsuits against intransigent companies who refuse to give you the complete source and instructions you deserve (and that they are required to provide by the licenses of the software they freely choose to use).

In the rare cases where Software Freedom Conservancy has been forced to move its enforcement actions from gentle reminders to filing lawsuits, we have used a variety of approaches. Our lawsuit filed in 2007 against several manufacturers, used copyright law (specifically copyrights in the BusyBox project) to compel those manufacturers to comply with the GPL (such as Westinghouse). The lawsuit we filed last year against Vizio takes an approach more appropriate for widely marketed and available consumer devices. Namely, the claim in Vizio is a contract claim for third-party beneficiary rights under the GPL, which will allow us (and all other customers who bought Vizio TV's) to receive the repair and modification instructions to the software more directly.

Since we began enforcing the GPL fifteen years ago, the landscape of GPL violations has deteriorated: GPL'd software now appears in nearly every consumer device smarter than a toaster, and very rarely do the manufacturers even bother to offer source code to users — and almost never does the source release meet the requirements of the GPL. As a result, we at Software Freedom Conservancy continue to dedicate more time and resources to our enforcement efforts. We seek to ensure that the situation does not get even worse, and we believe that we can improve the situation even more.

The best approach, in our view, is to continue to bring a variety of different types of actions against intransigent violators. As always, we use litigation and litigation-like means as a last resort, but we've reached that point with dozens of companies. There are a variety of types of actions we could take and lawsuits that we could bring, and different ways we can go about preparing for them. But, to have the full scope of options, we need your help.

As a contributor to copyleft projects, one way that you can help us right now is to assign the copyrights of your software freedom works to Software Freedom Conservancy. As the Vizio suit shows, copyright-based claims will not be the sole focus of our enforcement. However, there are some key types of products where copyright claims are ideal. By assigning your copyrights to us, you can give us the ability to stand up for your software freedom and rights and, more importantly, the rights of your users. While we understand the FOSS community has some aversions to copyright assignment, we also know that, right now, many developers automatically assign their copyrights to their employers without demanding that their employers stand up for the copyleft rights of their users. We ask the community to reconsider this common practice, and request those who haven't already assigned copyright to their employer to assign their copyrights to us, and we urge those who have entered work-for-hire arrangements with employers ask those employers to give them back their copyrights immediately. (See our ContractPatch project for more information on how to do this.)

Today, we launch our self-service Copyright Assignment form. This new form, carefully vetted by our lawyers, allows you to quickly and easily assign your rights in your code, documentation, and other copyrightable works to Software Freedom Conservancy. We will use these copyrights to ensure companies follow the copyleft licenses that they use. You can assign copyrights for projects that are not members of Software Freedom Conservancy too. We will always enforce them in accordance with our Principles, and we will welcome you onto an internal mailing list and regular meetings to discuss our enforcement efforts.

Through the various software freedom lawsuits we have filed over the years, along with the lawsuits we've helped fund, Software Freedom Conservancy has established a track record of tangible enforcement actions.

We are very happy for all the support we've received from software freedom activists, developers, and other community members over the years in our software freedom enforcement actions. We hope you will continue to support us, and encourage others to do so, in whatever ways you can and, if it makes sense for you, by assigning your software freedom works to us so we can ensure the repairability of your electronics (and everyone else's!) going forward.

An Erroneous Preliminary Injunction Granted in Neo4j v. PureThink

Wed, 30 Mar 2022 09: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]>.

Update (2023-11-14): Unfortunately, the Court has made further bad decisions in this matter, and was not swayed by our expert report. If the SFC were the copyright holder of the text of the AGPLv3, or the trademark holder of the license's name, we would have intervened in this case to clarify these matters for the Court. Since the SFC did not create the AGPLv3 (our employees have been involved in GPLv3-related drafting, but not on behalf of SFC), filing the expert report was the only action that SFC could take to assist in this matter. However, going forward, we do encourage anyone facing a “further restrictions” issue with copyleft license to contact us for support — so that those who care about the future of copyleft can coordinate a response together. Note that the case has still not reached the appeal stage.

(Original blog post follows:)

Bad Early Court Decision for AGPLv3 Has Not Yet Been Appealed

We at Software Freedom Conservancy proudly and vigilantly watch out for your rights under copyleft licenses such as the Affero GPLv3. Toward this goal, we have studied the Neo4j, Inc. v. PureThink, LLC ongoing case in the Northern District of California , and the preliminary injunction appeal decision in the Ninth Circuit Court this month. The case is complicated, and we've seen much understandable confusion in the public discourse about the status of the case and the impact of the Ninth Circuit's decision to continue the trial court's preliminary injunction while the case continues. While it's true that part of the summary judgment decision in the lower court bodes badly for an important provision in AGPLv3§7¶4, the good news is that the case is not over, nor was the appeal (decided this month) even an actual appeal of the decision itself! This lawsuit is far from completion.

A Brief Summary of the Case So Far

The primary case in question is a dispute between Neo4j, a proprietary relicensing company, against a very small company called PureThink, run by an individual named John Mark Suhy. Studying the docket of the case, and a relevant related case, and other available public materials, we've come to understand some basic facts and events. To paraphrase LeVar Burton, we encourage all our readers to not take our word (or anyone else's) for it, but instead take the time to read the dockets and come to your own conclusions.

After canceling their formal, contractual partnership with Suhy, Neo4j alleged multiple claims in court against Suhy and his companies. Most of these claims centered around trademark rights regarding “Neo4j” and related marks. However, the claims central to our concern relate to a dispute between Suhy and Neo4j regarding Suhy's clarification in downstream licensing of the Enterprise version that Neo4j distributed.

Specifically, Neo4j attempted to license the codebase under something they (later, in their Court filings) dubbed the “Neo4j Sweden Software License” — which consists of a LICENSE.txt file containing the entire text of the Affero General Public License, version 3 (“AGPLv3”) (a license that I helped write), and the so-called “Commons Clause” — a toxic proprietary license. Neo4j admits that this license mash-up (if legitimate, which we at Software Freedom Conservancy and Suhy both dispute), is not an “open source license”.

There are many complex issues of trademark and breach of other contracts in this case; we agree that there are lots of interesting issues there. However, we focus on the matter of most interest to us and many FOSS activists: Suhy's permissions to remove the “Commons Clause”. Neo4j accuses Suhy of improperly removing the “Commons Clause” from the codebase (and subsequently redistributing the software under pure AGPLv3) in paragraph 77 of their third amended complaint. (Note that Suhy denied these allegations in court — asserting that his removal of the “Commons Clause” was legitimate and permitted.

Neo4j filed for summary judgment on all the issues, and throughout their summary judgment motion, Neo4j argued that the removal of the “Commons Clause” from the license information in the repository (and/or Suhy's suggestions to others that removal of the “Commons Clause” was legitimate) constituted behavior that the Court should enjoin or otherwise prohibit. The Court partially granted Neo4j's motion for summary judgment. Much of that ruling is not particularly related to FOSS licensing questions, but the section regarding licensing deeply concerns us. Specifically, to support the Court's order that temporarily prevents Suhy and others from saying that the Neo4j Enterprise edition that was released under the so-called “Neo4j Sweden Software License” is a “free and open source” version and/or alternative to proprietary-licensed Neo4j EE, the Court held that removal of the “Commons Clause” was not permitted. (BTW, the court confuses “commercial” and “proprietary” in that section — it seems they do not understand that FOSS can be commercial as well.)

In this instance, we're not as concerned with the names used for the software; as much as the copyleft licensing question — because it's the software's license, not its name, that either assures or prevents users to exercise their fundamental software rights. Notwithstanding our disinterest in the naming issue, we'd all likely agree that — if “AGPLv3 WITH Commons-Clause” were a legitimate form of licensing — such a license is not FOSS. The primary issue, therefore, is not about whether or not this software is FOSS, but whether or not the “Commons Clause” can be legitimately removed by downstream licensees when presented with a license of “AGPLv3 WITH Commons-Clause”. We believe the Court held incorrectly by concluding that Suhy was not permitted to remove the “Commons Clause”. Their order that enjoins Suhy from saying that such removal is permitted is problematic because the underlying holding (if later upheld on appeal) could seriously harm FOSS and copyleft.

The Confusion About the Appeal

Because this was an incomplete summary judgment and the case is ongoing, the injunction against Suhy's on making such statements is a preliminary injunction, and cannot be made permanent until the case actually completes in the trial court. The decision by the Ninth Circuit appeals court regarding this preliminary injunction has been widely reported by others as an “appeal decision” on the issue of what can be called “open source”. However, this is not an appeal of the entire summary judgment decision, and certainly not an appeal of the entire case (which cannot even been appealed until the case completes). The Ninth Circuit decision merely affirms that Suhy remains under the preliminary injunction (which prohibits him and his companies from taking certain actions and saying certain things publicly) while the case continues. In fact, the standard that an appeals Court uses when considering an appeal of a preliminary injunction differs from the standard for ordinary appeals. Generally speaking, appeals Courts are highly deferential to trial courts regarding preliminary injunctions, and appeals of actual decisions have a much more stringent standard.

The Affero GPL Right to Restriction Removal

In their partial summary judgment ruling, the lower Court erred because they rejected an important and (in our opinion) correct counter-argument made by Suhy's attorneys. Specifically, Suhy's attorneys argued that Neo4j's license expressly permitted the removal of the “Commons Clause” from the license. AGPLv3 was, in fact, drafted to permit such removal in this precise fact pattern.

Specifically, the AGPLv3 itself has the following provisions (found in AGPLv3§0 and AGPLv3§7¶4):

“This License” refers to version 3 of the GNU Affero General Public License.

“The Program” refers to any copyrightable work licensed under this License. Each licensee is addressed as “you”.

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.

That last term was added to address a real-world, known problem with GPLv2. Frequently throughout the time when GPLv2 was the current version, original copyright holders and/or licensors would attempt to license work under the GPL with additional restrictions. The problem was rampant and caused much confusion among licensees. As an attempted solution, the FSF (the publisher of the various GPL's) loosened its restrictions on reuse of the text of the GPL — in hopes that would provide a route for reuse of some GPL text, while also avoiding confusion for licensees. Sadly, many licensors continued to take the confusing route of using the entire text a GPL license with an additional restriction — attached either before or after, or both. Their goals were obvious and nefarious: they wanted to confuse the public into “thinking” the software was under the GPL, but in fact restrict certain other activities (such as commercial redistribution). They combined this practice with proprietary relicensing (i.e., a sole licensor selling separate proprietary licenses while releasing a (seemingly FOSS) public version of the code as demoware for marketing). Their goal is to build on the popularity of the GPL, but in direct opposition to the GPL's policy goals; they manipulate the GPL to open-wash bad policies rather than give actual rights to users. This tactic even permitted bad actors to sell “gotcha” proprietary licenses to those who were legitimately confused. For example, a company would look for users operating commercially with the code in compliance with GPLv2, but hadn't noticed the company's code had the statement: “Licensed GPLv2, but not for commercial use”. The user had seen GPLv2, and knew from its brand reputation that it gave certain rights, but hadn't realized that the additional restriction outside of the GPLv2's text might actually be valid. The goal was to catch users in a sneaky trap.

Neo4j tried to use the AGPLv3 to set one of those traps. Neo4j, despite the permission in the FSF's GPL FAQ to “use the GPL terms (possibly modified) in another license provided that you call your license by another name and do not include the GPL preamble”, left the entire AGPLv3 intact as the license of the software — adding only a note at the front and at the end. However, their users can escape the trap, because GPLv3 (and AGPLv3) added a clause (which doesn't exist in GPLv2) to defend users from this. Specifically, AGPLv3§7¶4 includes a key provision to help this situation.

Specifically, the clause was designed to give more rights to downstream recipients when bad actors attempt this nasty trick. Indeed, I recall from my direct participation in the A/GPLv3 drafting that this provision was specifically designed for the situation where the original, sole copyright holder/licensor⁰ added additional restrictions. And, I'm not the only one who recalls this. Richard Fontana (now a lawyer at IBM's Red Hat, but previously legal counsel to the FSF during the GPLv3 process), wrote on a mailing list¹ in response to the Neo4j preliminary injunction ruling:

For those who care about anecdotal drafting history … the whole point of the section 7 clause (“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.”) was to address the well known problem of an original GPL licensor tacking on non-GPL, non-FOSS, GPL-norm-violating restrictions, precisely like the use of the Commons Clause with the GPL. Around the time that this clause was added to the GPLv3 draft, there had been some recent examples of this phenomenon that had been picked up in the tech press.

Fontana also pointed us to the FSF's own words on the subject, written during their process of drafting this section of the license (emphasis ours):

Unlike additional permissions, additional requirements that are allowed under subsection 7b may not be removed. The revised section 7 makes clear that this condition does not apply to any other additional requirements, however, which are removable just like additional permissions. Here we are particularly concerned about the practice of program authors who purport to license their works under the GPL with an additional requirement that contradicts the terms of the GPL, such as a prohibition on commercial use. Such terms can make the program non-free, and thus contradict the basic purpose of the GNU GPL; but even when the conditions are not fundamentally unethical, adding them in this way invariably makes the rights and obligations of licensees uncertain.

While the intent of the original drafter of a license text is not dispositive over the text as it actually appears in the license, all this information was available to Neo4j as they drafted their license. Many voices in the community had told them that provision in AGPLv3§7¶4 was added specifically to prevent what Neo4j was trying to do. The FSF, the copyright holder of the actual text of the AGPLv3, also publicly gave Neo4j permission to draft a new license, using any provisions they like from AGPLv3 and putting them together in a new way. But Neo4j made a conscious choice to not do that, but instead constructed their license in the exact manner that allowed Suhy's removal of the “Commons Clause”.

In addition, that provision in AGPLv3§7¶4 has little meaning if it's not intended to bind the original licensor! Many other provisions (such as AGPLv3§10¶3) protect the users against further restrictions imposed later in the distribution chain of licensees. This clause was targeted from its inception against the exact, specific bad behavior that Neo4j did here.

We don't dispute that copyright and contract law give Neo4j authority to license their work under any terms they wish — including terms that we consider unethical or immoral. In fact, we already pointed out above that Neo4j had permission to pick and choose only some text from AGPLv3. As long as they didn't use the name “Affero”, “GNU” or “General Public” or include any of the Preamble text in the name/body of their license — we'd readily agree that Neo4j could have put together a bunch of provisions from the AGPLv3, and/or the “Commons Clause”, and/or any other license that suited their fancy. They could have made an entirely new license. Lawyers commonly do share text of licenses and contracts to jump-start writing new ones. That's a practice we generally support (since it's sharing a true commons of ideas freely — even if the resulting license might not be FOSS).

But Neo4j consciously chose not to do that. Instead, they license their software “subject to the terms of the GNU AFFERO GENERAL PUBLIC LICENSE Version 3, with the Commons Clause”. (The name “Neo4j Sweden Software License” only exists in the later Court papers, BTW, not with “The Program” in question.) Neo4j defines “This License” to mean “version 3 of the GNU Affero General Public License.”. Then, Neo4j tells all licensees that “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”. Yet, after all that, Neo4j had the audacity to claim to the Court that they didn't actually mean that last sentence, and the Court rubber-stamped that view.

Simply put, the Court erred when it said: “Neither of the two provisions in the form AGPLv3 that Defendants point to give licensees the right to remove the information at issue.”. The Court then used that error as a basis for its ruling to temporarily enjoin Suhy from stating that software with “Commons Clause” removed by downstream is “free and open source”, or tell others that he disagrees with the Court's (temporary) conclusion about removing the “Commons Clause” in this situation.

What Next?

The case isn't over. The lower Court still has various issues to consider — including a DMCA claim regarding Suhy's removal of the “Commons Clause”. We suspect that's why the Court only made a preliminary injunction against Suhy's words, and did not issue an injunction against the actual removal of the clause! The issue as to whether the clause can be removed is still pending, and the current summary judgment decision doesn't address the DMCA claim from Neo4j's complaint.

Sadly, the Court has temporarily enjoined Suhy from “representing that Neo4j Sweden AB’s addition of the Commons Clause to the license governing Neo4j Enterprise Edition violated the terms of AGPL or that removal of the Commons Clause is lawful, and similar statements”. But they haven't enjoined us, and our view on the matter is as follows:

Clearly, Neo4j gave explicit permission, pursuant to the AGPLv3, for anyone who would like to to remove the “Commons Clause” from their LICENSE.txt file in version 3.4 and other versions of their Enterprise edition where it appears. We believe that you have full permission, pursuant to AGPLv3, to distribute that software under the terms of the AGPLv3 as written. In saying that, we also point out that we're not a law firm, our lawyers are not your lawyers, and this is not legal advice. However, after our decades of work in copyleft licensing, we know well the reason and motivations of this policy in the license (described above), and given the error by the Court, it's our civic duty to inform the public that the licensing conclusions (upon which they based their temporary injunction) are incorrect.

Meanwhile, despite what you may have read last week, the key software licensing issues in this case have not been decided — even by the lower Court. For example, the DMCA issue is still before the trial court. Furthermore, if you do read the docket of this case, it will be obvious that neither party is perfect. We have not analyzed every action Suhy took, nor do we have any comment on any action by Suhy other than this: we believe that Suhy's removal of the “Commons Clause” was fully permitted by the terms of the AGPLv3, and that Neo4j gave him that permission in that license. Suhy also did a great service to the community by taking action that obviously risked litigation against him. Misappropriation and manipulation of the strongest and most freedom-protecting copyleft license ever written to bolster a proprietary relicensing business model is an affront to FOSS and its advancement. It's even worse when the Courts are on the side of the bad actor. Neo4j should not have done this.

Finally, we note that the Court was rather narrow on what it said regarding the question of “What Is Open Source?”. The Court ruled that one individual and his companies — when presented with ambiguous licensing information in one part of a document, who then finds another part of the document grants permission to repair and clarify the licensing information, and does so — is temporarily forbidden from telling others that the resulting software is, in fact, FOSS, after making such a change. The ruling does not set precedent, nor does it bind anyone other than the Defendants as to what they can or cannot say is FOSS, which is why we can say it is FOSS, because the AGPLv3 is an OSI-approved license and the AGPLv3 permits removal of the toxic “Commons Clause” in this situation.

We will continue to follow this case and write further when new events occur..

⁰ We were unable to find anywhere in the Court record that shows Neo4j used a Contributor Licensing Agreement (CLA) or Copyright Assignment Agreement (©AA) that sufficiently gave them exclusive rights as licensor of this software. We did however find evidence online that Neo4j accepted contributions from others. If Neo4j is, in fact, also a licensor of others' AGPLv3'd derivative works that have been incorporated into their upstream versions, then there are many other arguments (in addition to the one presented herein) that would permit removal of the “Commons Clause”. This issue remains an open question of fact in this case.

¹ Fontana made these statements on a mailing list governed by an odd confidentiality rule called CHR (which was originally designed for in-person meetings with a beginning and an end, not a mailing list). Nevertheless, Fontana explicitly waived CHR (in writing) to allow me to quote his words publicly.

Copyleft Won't Solve All Problems, Just Some of Them

Thu, 17 Mar 2022 10:01: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]>.

Toward a Broad Ethical Software Licensing Coalition

We are passionate about and dedicated to the cause of software freedom and rights because proprietary software harmfully takes control of and agency in software away from users. In 2014, we started talking about FOSS as fundamental to “ethical software” (and, more broadly “ethical technology”) — which contrasts FOSS with the unethical behavior that Big Tech carries out with proprietary software. Some FOSS critics (circa 2018) coined the phrase “ethical source” — which outlined a new approach to these issues — based on the assumption that software freedom activists were inherently complicit in the bad behavior of Big Tech and other bad actors since the inception of FOSS. These folks argue that copyleft — the only form of software licensing that makes any effort to place ethical and moral requirements on FOSS redistributors/reusers — has fundamentally ignored the larger problems of society such as human rights abuses and unbridled capitalism. They propose new copyleft-like licenses, which, rather than focusing on the requirement of disclosure of source code, they instead use the mechanisms of copyleft to mandate behaviors in areas of ethics generally unrelated to software. For example, the Hippocratic License molds a copyleft clause into a generalized mechanism for imposing a more comprehensive moral code on software redistributors/re-users. In essence, they argue that copylefted software (such as software under the GPL) is unethical software. This criticism of copyleft reached crescendo in the last three weeks as pundits began to criticize FOSS licenses for failing to prohibit Putin from potentially using FOSS in his Ukrainian invasion or other bad acts.

We have in the past avoided a comprehensive written response to the so-called “ethical source” arguments — lest our response create acrimony with an adjacent community of activists who mean well and with whom we share some goals, but with whose strategies (and conclusions about our behavior and motivations) we disagree. Nevertheless, the recent events have shown that a single, comprehensive response would help clarify our position on a matter of active, heated public debate and fully answer these ongoing criticism of FOSS and our software freedom principles.

The primary criticism is that FOSS licensing over-prioritizes the rights of software freedom above substantially more important rights and causes — such as sanctions against war criminals. This rhetoric implies that software freedom activists have “tunnel vision” about the relatively minor issue of the rights to copy, modify, redistribute and reinstall software while we ignore bigger societal problems. This essay gives a comprehensive explanation of the specific reasons why copyleft avoids the “scope creep” of handling moral and ethical issues that relate only tangentially to software — even though those moral issues are indeed more urgent and dire than the moral issue of software freedom.

Software Freedom Isn't The Most Important Human Right

I personally, and many of my colleagues, have been admittedly imperfect advocates for software freedom. For the last thirty years, Big Tech and their allies have unfortunately successfully convinced the public that rights for users to control their own software are unimportant, and even trivial. (Apple has even successfully convinced their biggest fans that Apple's ironclad device lock-down is in your interest as a consumer.) In that climate, software freedom activists often overcompensated for the tech community's trivialization of software rights — specifically, overstating the relative importance of software freedom when compared to other human rights. Our error left a political vulnerability, allowing the opposition to successfully even further trivialize users' rights. Critics capitalized on this miscommunication, and often claim that FOSS activists believe that software freedom is the most important human right. Of course, none of us believe that.

I suspect most software freedom activists agree with me on the following: while I do believe software freedom should be a human right, I don't believe that our society should urgently pursue universal software freedom at the expense of upholding the many other essential rights (such as those listed in the Universal Declaration of Human Rights). Clearly many other rights are more fundamental. In a society that fails to guarantee those fundamental human rights, software freedom (by itself) is virtually useless. Those who would violate the most basic human rights will simply ignore the issue of software freedom, too. Or, even worse, such bad actors will gladly use any software, flagrantly in violation of any license, to bolster their efforts to violate other human rights.

Software freedom as a general cause becomes essential and relevant when a society has already reached a minimal level of justice. Indeed, I've spent much of my career as a software rights activist considering whether I should instead work on a more urgent cause — such as ending human trafficking, animal rights, or remedying climate change. Personally, the only valid moral justification for my personal focus on software freedom instead of those other rights is four-fold: (a) there is an increasingly limited number of qualified people who are willing to work on software freedom as a charitable cause at all, (b) there is an increasing number of talented people who are actively working to create more proprietary software and seeking to thwart software freedom and copyleft, (c) my personal talents are in the area of software production and authorship, not in areas directly applicable to other causes, and (d) an increasingly digitized society mean software rights slowly increase in importance as an “enabler right” to defend and protect other rights (just as Free Speech enables activists to expose (and hopefully prevent) atrocities and their cover-ups). In other words, I am unlikely to make any useful impact on any other cause in my whole career, whereas due to the unique match of my skills to the cause of software freedom, I have made measurable positive impact on software rights. I generally encourage activists to focus on tasks that directly coincide with their existing talents, and have tried to do the same myself.

So my argument starts in fervent agreement with the first point made by proponents of adding non-software ethical issues into copyleft licensing: yes, I absolutely agree there are social justice causes that are more urgent than the right to copy, modify, redistribute and reinstall software. That begs their question: then, why not immediately begin using all the tools, mechanisms and strategies used for FOSS advocacy to advocate for these other causes? The TL;DR answer is simple: because these tools, mechanisms and strategies are highly unlikely to have any measurable impact on those other causes, while using them for these other causes would ultimately minimize software freedom and rights unjustly.

Indeed, we need to make progress on the issue of software freedom, precisely because even while others are working to address and redress these other social justice issues, proprietary software (such as through proprietary AI-based advertising software that manipulates public opinion) is currently used to undermine these other causes. Universal software freedom would thwart Big Tech's efforts to undermine other causes. Proprietarization of software isn't the most heinous human rights violation possible; nevertheless, proprietarization of software does assist companies to do harm regarding other social justice causes. I conclude from that realization that our society should seek to make progress on both upholding the existing human rights already listed in the Universal Declaration on Human Rights, and also seek to make simultaneous progress on key rights not listed there, such as software freedom. We also err as activists if one group of activists seeks to thwart another by falsely claiming the other group is “complicit in human rights abuses” merely due to a strategic disagreement.

Ultimately, copyleft (and other FOSS licensing) is a strategy, not a moral principle unto itself. The moral principle is that proprietary software is harmful to people because it forbids their right to control their own software, learn how it works, and remove spyware from it (among many other ills). That moral principle remains valuable and deserves some of our collective attention, even if there are other more urgent moral principles that deserve even more attention.

Copyleft Is The Worst Strategy, Except for all the Others

So, if the production of proprietary software harms society, then why not focus all efforts on lobbying legislators to make proprietary software illegal? This should be the first question any new software freedom activist asks themselves. After all, for those of us who live in societies with relatively minimal corruption and that are governed by the rule of law, we should seek to make criminal those acts that harm others.

Criminalizing proprietary software has always been, and remains, politically unviable. We should constantly reevaluate that political viability (which software freedom activists have done throughout the last three decades). But as of the time of writing, this strategy remains unviable, primarily due to the worldwide domination of incumbent unbridled capitalism and a near universal poor understanding of the harm that proprietary software causes and enables.

Another possible approach to ending proprietary software is a universal boycott on authorship of proprietary software (perhaps through mass unionization of software developers). This is one of my favorite “thought experiments”, as it shows how much power individual software developers have regarding proprietary software. However, this universal boycott is also politically unviable, at least as long as proprietary software companies continue to pay such exorbitant salaries relative to other fields of endeavor.

So, if we can't make proprietary software illegal, and we can't dissuade developers from taking piles of money to write proprietary software, what's the next best strategy? The answer is to organize people to write alternative software that is not proprietary. This was the strategy that the software freedom movement pursued in earnest beginning in the early 1980s, and currently remains our best politically viable strategy. However, this approach always contained a fundamental problem: such software can easily be used as a basis for proprietary software. Thus non-copylefted FOSS competes against itself, rather hopelessly, since the proprietary version will likely always be a feature or two ahead, and the FOSS version a bug or two behind. Copyleft is the innovative strategy designed specifically to address that specific problem. Without copyleft, the only possible approach to answering the harm of proprietary software is the aforementioned general strike of all software development, since non-copyleft FOSS can be and is regularly used as a basis for advancing proprietary software and Big Tech's interests.

Copyleft generally works reasonably well as a strategy, but it admittedly requires constant vigilance. Copyleft needs someone to enforce it, and resources to do that. Copyleft must withstand the pressure of proprietary software companies who seek to erode and question its validity. The primary conceit of those who seek to use a copyleft-style strategy to address other software-tangential social injustices is their apparent belief that merely writing policy into a software license has any chance of changing behavior on its own. It simply doesn't.

Other Mechanisms Are More Effective If Politically Viable

The Hippocratic License and similar efforts have a laudable goal: they seek to assure that companies who deal in software always respect human rights. However, advocacy for universally recognized human rights, as a social justice cause, does have access to better advocacy mechanisms that software freedom activism does not.

Most notably, almost everything listed in the Universal Declaration of Human Rights is illegal in the USA and in most other industrialized nations where the bulk of software development occurs. Also, it is certainly politically viable to improve those laws — for those rare cases where a violation of a particular universally recognized human right is legal. In short, because these other rights are much more widely accepted as fundamental by the public, we can employ other, better means (including those listed above that don't work for FOSS) to compel compliance by companies with these other principles.

Furthermore, copyleft is ill-suited as a mechanism to enforce any rights in places where human rights violations are common. For example, no one has ever bothered to enforce copyleft licenses in jurisdictions where corruption is rampant and the judiciary is easily bribed. Over the last twenty years, we've received many reports of GPL violations in the Russian Federation, but we don't pursue them — not because they shouldn't be addressed, but because, under Putin's regime, it's highly unlikely we can get a fair hearing to uphold software freedom and rights for Russian citizens. Copyleft relies on a well-formed rule-of-law for contracts and copyright to protect people's rights (of any kind). In jurisdictions that already hold human life and the rights of its people in low regard (or simply have an exceedingly corrupt government), it's a pointless symbolic act to also take away the permissions of software redistribution and modification for bad behavior (of any kind). Companies and oligarchs operating in a corrupt, unjust society will successfully ignore those injunctions, too.

Meanwhile, in jurisdictions with relatively less corruption, other systems besides distribution licenses function well to curtail bad behavior. For example, I've owned exactly two cars in my life here in the USA. While I concede there are many problems with corruption here, we have a relatively just society that usually respects the rule of law for contracts and copyrights. The cars that I purchased here did not have a license that said: if you drive dangerously with the vehicle, you cannot purchase and utilize cars in the future from that manufacturer. We don't look to the car manufacturers to enforce the ethical use of vehicles; we instead make traffic laws, with various escalating penalties, including a driver licensing structure that can be revoked temporarily or permanently for egregious acts. We don't require manufacturers to contract with drivers to pollute less; we instead create and enforce environmental regulation and incentives both before and after the time of purchase. Because such systems exist and because there is widespread societal consensus about what is or is not ethical driving behavior, there is no point in enforcing these rules using copyright and contracts that bind the vehicle's purchaser. A more resilient system (of traffic and environmental laws, and their enforcement) works to deal with the problem, and improving those laws is politically viable. Additional licensing terms from the car manufacturers (imposed at the point of sale of vehicles) would create a useless redundancy, since the penalties and remedies available under that license are substantially less severe than those available under the laws that regulate drivers.

There are strategies other than licensing changes that would likely work well to both build a stronger coalition for software freedom and rights and curtail the atrocities committed by Big Tech and their customers. These strategies might become political viable, and are worth pursuing in parallel and in coalition. For example, widespread unionization of tech workers (not over wages, which are generally high, but over other issues, such as bad behavior and policy by their employers) could both improve companies' respect of software freedom and handle many problems raised by those who seek tangential expansion of copyleft into non-software issues. For our part, Software Freedom Conservancy has done some work in this area by encouraging developers to begin insisting on better terms in their employment contracts. I do worry that a functioning coalition on these matters is exceedingly difficult to build (and the very fact this essay ultimately became necessary hints at the difficulty in building that coalition). We'd be glad to work in coalition with such activists to further those causes if they include software freedom as an issue that belongs on the coalition's agenda.

But that's a long-term, speculative action. Meanwhile, for software freedom, copyleft is the best-available compromise strategy — since software rights are not and cannot be defended in a more robust way (such as through direct legislation, as opposed to indirectly relying on the copyright and contract legal systems to assure the rights). Copyleft is a round-about strategy. Using copyleft as a strategy to impact broader ills that have more effective mechanisms to address those ills is (at the very least) wasted time and (possibly) downright counter-productive.

Copyleft Focuses On Coalition

In our increasingly politically divided society, omnibus social justice reform has always been exceedingly difficult. Copyleft works precisely because it holds together a very thin coalition — by confining the issues to only those that happen with software.

Consider this example: I became a vegetarian in 1992. It does bother me that software that I've written could potentially assist a slaughterhouse to run more efficiently. I obviously have considered licensing my software under terms that would forbid use in a slaughterhouse (and a dozen other activities that I personal morally oppose, including for the waging of war). However, hand-picking my most important social justice causes and stringing a copyleft clause on them would dissolve a rather thinly-held coalition of copyleft proponents. Successful advocacy for a given cause relies on building broad coalitions among people with widely disparate views on other topics. Imagine how difficult activism on climate change would be if activists working to end human trafficking claimed that activists working to address climate change were complicit in human trafficking because The Paris Climate Agreement does not include penalties if participating nation-states fail to meet benchmarks on reducing human trafficking. Coalition building is complex. Context matters.

In a diverse political ecosystem, elegant solutions that work “ok” often fare better than comprehensive-but-complex solutions. Copyleft's innovation is that the only action you can take that revokes your right to copy, modify, redistribute and reinstall the software is failure to give that same right to someone else. This elegance makes the copyleft strategy powerful and effective. “Porting” the copyleft strategy to other causes may seem that it would yield “more of a good thing”. But, in practice, that approach turns copyleft licenses into complex omnibus legislation around which coalitions will evaporate.

Relatedly, the most difficult hurdle of copyleft has always been the creation of software that was so enticingly useful that political opponents (i.e., proprietary software companies) would gladly give users the rights to copy, modify, and reinstall the software — in direct exchange for having the benefit of building their new software on top of the existing copylefted components (rather than rewriting it themselves). I do not see a viable path to create the necessary coalition that would, after agreeing on an omnibus list of social justice issues, also find the funding and volunteer labor necessary to build software (under that license) that would entice those who currently work against that list of social justice causes to stop working against those causes merely because they'd gain so much more from the software than they gain from violating the principles. Copylefted software in a vacuum, adopted only by other copyleft activists does not change behavior of bad actors. For example, imagine if we wrote into our licenses that all who copy, modify and distribute the software must cease use of fossil fuels. That's an important cause, but it's hard to imagine our software would be so useful that companies would accelerate their reduction of fossil fuel use merely to gain immediate the permission to copy, modify and redistribute that software.

Copyleft Requires Constant Vigilance

Copyleft isn't magic pixie dust that liberates software. In fact, likely one of the biggest flaws in copyleft design has been a gross underestimation of resources required for enforcement in the scenario we now have. Broad adoption of key copylefted components remains an important step to curtail proprietary software developers' mistreatment of users. The situation slowly improves as such developers incorporate copylefted software like Linux into their essential computing systems — provided that is done so in compliance with the license. However, violations on essential GPL'd components such as Linux and GCC are rampant and limited funding is available to resolve these violations and restore users' rights in the software. Big Tech has also been relentless and highly creative in thwarting our enforcement efforts.

Thus, even if not for my earlier strategic reasons that I oppose adding ethical-but-software-unrelated restrictions to FOSS licenses, I'd still oppose it on tactical grounds. Namely, there is no clear funding path whereby additional terms seeking to protect and advance software-tangential social justice causes could be adequately enforced to make a measurable difference in advancement of those causes.

FOSS Must Still Have a Conscience on Non-Software Issues

This essay merely argues that FOSS licenses are not an effective tool to advance social justice causes other than software freedom. It does not argue that FOSS communities have no duties to other causes and issues; in fact, they do have such a moral obligation. For example, FOSS developers should refuse to work specifically on bug reports from companies who don't pay their workers a living wage. I also recommend that FOSS communities create (alongside their Codes of Conduct for behavior inside the project), written rules of the types of entities that the projects will officially assist with volunteer labor, or (in the case of a commercial FOSS community or organization), what types of entities the community will engage in business deals.

At Software Freedom Conservancy, we regularly discuss at both the staff and Board of Directors level what other social justice issues that we have a moral obligation to incorporate. Most notably, we've been the home for Outreachy, a program our own Executive Director, Karen Sandler, helped create, and for which we are glad to have Sage Sharp on staff to work on full-time. We know that FOSS lags behind proprietary software development in welcoming and providing opportunities for underrepresented groups. We dedicate significant organizational resources on these issues through Outreachy and other newer programs (such as the Institute for Computing Research). We made a public statement that Trump's travel ban directly thwarted FOSS. We go beyond the mere legal requirements to create ethical and equitable hiring practices that are without bias. In defending the rights of users under copyleft, we do not leave other issues behind. I believe that the critics have simply not paid attention to, or are willfully ignoring, the holistic and intersectional approach that we have brought to FOSS.

Regarding Putin's FOSS Permissions Upon Invasion of Ukraine

Initially, only a few FOSS critics insisted on this radical change to copyleft licensing structure. The issue had fallen into the far background of our community — until the last few weeks. Specifically, many recently began asking whether we should redraft FOSS licenses to impose sanctions on Putin in retaliation for his violent and unprovoked invasion of Ukraine. Admittedly, FOSS licenses do not prevent Putin from incorporating existing FOSS already in his possession into his war machine. I personally have been a conscientious objector to all military action since 1990, so I am sympathetic. I have always felt the OSI's framing the discussion of military use of FOSS as a “field of use restriction” misses the point; it inappropriately analogizes software to physical materiel, and analogizes those who write FOSS to de-facto military contractors. Software, fundamentally, is the written word; while it “feels” like more than that to us, factually speaking, software is merely a written record of knowledge, methods, and instructions for how to solve digital problems. It is disturbing that the plans for heinous acts can sometimes be modeled as digital problems, and that some of those problems may be solvable with existing FOSS. But we must curtail and punish actual actions, not knowledge nor writing, nor the unfettered sharing of generally useful technical information. Particularly in cyber-warfare circles, some folks tend to talk about software as we did during the days when sharing encryption software was banned: as if certain software is more like bombs than books. I don't think we should concede that rhetoric; all software remains much more like books than it is like bombs.

Even if we choose to not take away the right to read from the Russian people, that does not mean that FOSS activists concede that nothing can be done. Our nations can, should, and many currently do, forbid commerce with Russia during this period. This can and should include embargoes of selling new books, new copies of software, providing services for improvements to software, and any other commercial activities that could inadvertently aid Putin's war effort. Every FOSS license in existence permits capricious distribution; software freedom guarantees the right to refuse to distribute new versions of the software. (i.e., Copyleft does not require that you publish all your software on the Internet for everyone, or that you give equal access to everyone — rather, it merely requires that those whom you chose to give legitimate access to the software also receive CCS). FOSS projects should thus avoid providing Putin easy access to updates to their FOSS. Indeed, FOSS licenses planned well for how to manage bad actors who want your software: all FOSS licensing authorities have upheld the right to capricious distribution — precisely so that the license would not compel any developer to provide software to a bad actor.

I suspect activists will continue to disagree about whether we have a moral imperative to change FOSS licenses themselves to contractually forbid Putin to copy, modify, redistribute and reinstall the FOSS he already has (or surreptitiously downloaded by circumventing sanctions). However, these horrendous events in Ukraine offer real world examples to consider the viability of expanding copyleft term expansion beyond software, and consider how it might work. My analysis is that such changes would only give us the false sense of having “done something”. Ultimately enforcement of such licensing changes would either be impossible or pointless. The very entities (such as the varied international courts and treaty organizations) that could enforce such terms will also have plenty of other war crimes and sanctions violations to bring against Putin and his cronies anyway. The penalties for the actions of war that Putin took will be much stronger than Putin's contractual breach or copyright infringement claim that could be brought under a modified copyleft license and/or the Hippocratic License.

Conclusion

Copyleft licensing is a powerful strategy. As a strategy, copyleft has both its upsides and downsides in its ability to advance the software freedom and rights of users. However, the proverbial hammer of copyleft will not help you when your problem is more like a screw than a nail. Having already dedicated my entire career to advance the copyleft strategy, I do feel honored that folks who care deeply (as I do) about other important social justice causes are seeking to apply that strategy to new types of problems. However, despite my lifelong love and excitement for copyleft, and perhaps because of it, it's my duty to point out that copyleft is not a panacea for all that ills our troubled world.

Copyleft works because it's the best strategy we have for software freedom, and because copyleft elegantly confines itself to the software rights of users. Attempts to apply the copyleft strategy to software-unrelated causes will (at the very least) fail to achieve the intended results, and at their worst, will primarily serve to trivialize the important issue of software freedom that copyleft was invented to accentuate.