The Software Freedom Conservancy

info@appleenthusiast.com (Software Freedom Conservancy) — 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.

The Software Freedom Conservancy

denver@appleenthusiast.com (Denver Gingerich) — 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 <denver@appleenthusiast.com>.

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.

The Software Freedom Conservancy

info@appleenthusiast.com (Software Freedom Conservancy) — 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.

The Software Freedom Conservancy

pono@appleenthusiast.com (Daniel Takamori) — 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 <pono@appleenthusiast.com>.

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)!

The Software Freedom Conservancy

info@appleenthusiast.com (Software Freedom Conservancy) — 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.

The Software Freedom Conservancy

info@appleenthusiast.com (Software Freedom Conservancy) — Wed, 03 Jan 2024 13:55:14 -0500

A news item from Software Freedom Conservancy.

SFC files own “Motion for Summary Adjudication�?lt;/strong>

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:baccarat liveM?i quy?n ???c b?o l?u cho trang web ch��nh th?c 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!

The Software Freedom Conservancy

denver@appleenthusiast.com (Denver Gingerich) — 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 <denver@appleenthusiast.com>.

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.

The Software Freedom Conservancy

karen@appleenthusiast.com (Karen Sandler) — 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 <karen@appleenthusiast.com>.

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.

The Software Freedom Conservancy

info@appleenthusiast.com (Software Freedom Conservancy) — Mon, 11 Dec 2023 17:12:08 -0500

A news item from Software Freedom Conservancy.

After filing our initial comments in the Copyright:baccarat liveM?i quy?n ???c b?o l?u cho trang web ch��nh th?c 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:baccarat liveM?i quy?n ???c b?o l?u cho trang web ch��nh th?c 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:baccarat liveM?i quy?n ???c b?o l?u cho trang web ch��nh th?c 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:baccarat liveM?i quy?n ???c b?o l?u cho trang web ch��nh th?c 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!

The Software Freedom Conservancy

info@appleenthusiast.com (Software Freedom Conservancy) — 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!

The Software Freedom Conservancy

Sourceware PLC@appleenthusiast.com (Sourceware PLC) — 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 <Sourceware PLC@appleenthusiast.com>.

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

The Software Freedom Conservancy

info@appleenthusiast.com (Software Freedom Conservancy) — 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!

The Software Freedom Conservancy

info@appleenthusiast.com (Software Freedom Conservancy) — 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:baccarat liveM?i quy?n ???c b?o l?u cho trang web ch��nh th?c 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:baccarat liveM?i quy?n ???c b?o l?u cho trang web ch��nh th?c 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:baccarat liveM?i quy?n ???c b?o l?u cho trang web ch��nh th?c 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�?lt;/a>.

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

The Software Freedom Conservancy

denver@appleenthusiast.com (Denver Gingerich) — 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 <denver@appleenthusiast.com>.

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.

The Software Freedom Conservancy

info@appleenthusiast.com (Software Freedom Conservancy) — 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:baccarat liveM?i quy?n ???c b?o l?u cho trang web ch��nh th?c 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:baccarat liveM?i quy?n ???c b?o l?u cho trang web ch��nh th?c 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.

The Software Freedom Conservancy

info@appleenthusiast.com (Software Freedom Conservancy) — 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.

The Software Freedom Conservancy

info@appleenthusiast.com (Software Freedom Conservancy) — 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.

The Software Freedom Conservancy

info@appleenthusiast.com (Software Freedom Conservancy) — 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:general@chat.appleenthusiast.com?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 conference@appleenthusiast.com.

The Software Freedom Conservancy

info@appleenthusiast.com (Software Freedom Conservancy) — 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?

The Software Freedom Conservancy

denver@appleenthusiast.com (Denver Gingerich) — 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 <denver@appleenthusiast.com>.

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.

The Software Freedom Conservancy

bkuhn@appleenthusiast.com (Bradley M. Kuhn) — 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 <bkuhn@appleenthusiast.com>.

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!

The Software Freedom Conservancy

info@appleenthusiast.com (Software Freedom Conservancy) — 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 conference@appleenthusiast.com.

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:baccarat liveM?i quy?n ???c b?o l?u cho trang web ch��nh th?c Act exemptions with the US Copyright:baccarat liveM?i quy?n ???c b?o l?u cho trang web ch��nh th?c 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 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 conference@appleenthusiast.com.

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!

The Software Freedom Conservancy

bkuhn@appleenthusiast.com (Bradley M. Kuhn) — 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 <bkuhn@appleenthusiast.com>.

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 us at <compliance@appleenthusiast.com> 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 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.

The Software Freedom Conservancy

info@appleenthusiast.com (Software Freedom Conservancy) — 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!

The Software Freedom Conservancy

info@appleenthusiast.com (Software Freedom Conservancy) — 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 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.

The Software Freedom Conservancy

info@appleenthusiast.com (Software Freedom Conservancy) — 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, XMPP or 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.

The Software Freedom Conservancy

denver@appleenthusiast.com (Denver Gingerich) — 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 <denver@appleenthusiast.com>.

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 compliance@appleenthusiast.com. 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.

The Software Freedom Conservancy

info@appleenthusiast.com (Software Freedom Conservancy) — 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.

The Software Freedom Conservancy

info@appleenthusiast.com (Software Freedom Conservancy) — Thu, 02 Feb 2023 14:00:00 -0500

A news item from Software Freedom Conservancy.

Sandler commended by premier Belgian university for her outstanding work in software rights
Download the talk video or watch on YouTube
At their annual Patron Saint's Day celebration (“Patroonsfeest”), the Katholieke Universiteit Leuven (KU Leuven) bestowed SFC's Executive Director, Karen Sandler, with an honorary doctorate. Sandler was nominated by the student body in recognition of her outstanding work at Software Freedom Conservancy (SFC), her many years of FOSS leadership, and her advocacy and pursuit of software freedom and rights for all. Joining other scientists, artists and activists from across the world, Sandler was one of five honorary doctorate nominees for the 2023 “Patroonsfeest” at KU Leuven.
Download the talk video or watch on YouTube
As part of the week-long ceremonies, Sandler delivered a lecture at KU Leuven entitled Software Rights: Accountability and Autonomy In Our Technology. Sandler's lecture (included on the left) focused on the intersection of software rights and the need for autonomy over our devices that we increasingly rely on in our lives.

On Thursday, February 2, 2023, Sandler accepted the award at the “Patroonsfeest” event in Leuven. Her family and SFC Policy Fellow, Bradley M. Kuhn, attended to witness this prestigious event. Following the annual academic procession and ceremony, the University bestowed the honorary degrees to Sandler and the four co-nominees in a Convocation at the Pieter De Somer Auditorium.

This special event coincided with the exciting return of in-person FOSS events in Belgium throughout the week — which culminated in the return of in-person Free and Open Source Software Developers' European Meeting (FOSDEM) 2023.

The Software Freedom Conservancy

pono@appleenthusiast.com (Daniel Takamori) — 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 <pono@appleenthusiast.com>.

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 conference@appleenthusiast.com 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!

The Software Freedom Conservancy

info@appleenthusiast.com (Software Freedom Conservancy) — Mon, 16 Jan 2023 12:00:00 -0500

A news item from Software Freedom Conservancy.

$156,730.91 raised after extended match challenge

Thanks to SFC's incredible base of Sustainers and supporters, our original fundraising match goal of $104,759 was met in just over a month, and we quickly met an extended goal of an additional $12,030 — for a total of $116,989 matched and $156,730.91 contributed by you! Thanks to your sustaining contributions to our organization, we'll be able to continue the community driven work we have become known for. Our commitment to software rights and freedom remains as strong and ever. This support from individual contributors empowers and motivates us for the year to come.

This fundraising season has been incredibly uplifting for us to see that even in tough economic years, our donors continue to believe in the initiatives, advocacy and projects that we fund, develop and support.

This year has marked a lot of growth and progress for us: SFC has raised, administered and/or facilitated $1.7 million to directly support free software for the second year in a row. Through these efforts of sustainable FOSS funding, we are working with users, developers and communities to grow and expand the reach of software freedom for all. Outreachy — on track to complete their 1000th intern (we'll reach our “kilo-intern” as one Sustainer called it during our special video chat session 😂�?. The Institute for Computing in Research expanded to its third city this year with plans for expanding further! Denver Gingerich was appointed our first Director of Compliance; Denver now leads our compliance work — including his continuing work for the past year to integrate copyleft compliance (the right to software repair) within the larger Right to Repair community. In 2023, we will bring a large, international FOSS event back to Portland, Oregon, USA — as we organize our conference, FOSSY — July 13-16th 2023!

Thank you again for supporting our organization. Thank you for empowering our software freedom advocacy, development and diversity efforts. We are so excited to continue to pursue that passion and mission — thanks to your generous contributions.

The Software Freedom Conservancy

info@appleenthusiast.com (Software Freedom Conservancy) — Wed, 21 Dec 2022 13:46:00 -0500

A news item from Software Freedom Conservancy.

If accepted, appliances would include offer for source on EnergyGuide label

As one of his first official acts as Director of Compliance, Denver Gingerich submitted a comment to the FTC on behalf of SFC proposing adding software Right to Repair instructions for copyleft software on appliances. In conversations with various Right to Repair organizations, we brainstormed how to submit to the new FTC request for comment for the EnergyGuide labeling system. Based on these discussions, we found that there is no organization or governing body requiring repair instruction labeling for software. Given how many modern electronics and appliances rely on copylefted free software, SFC recommended adding software repair instructions that include labeling that there is copyleft software on the device and including specific links to the source code and repair instructions on the manufacturer's website. These are already required by the license, but are often buried deep in a manual somewhere. Adding these instructions would extend the rights afforded by copyleft software to all users of hardware that rely on it.

The FTC's EnergyGuide labeling system started out as a way to provide transparency in energy usage (and cost) to give consumers a better picture of what was entailed in the lifetime of the product. Over the years it has become a more holistic guide on the complete lifecycle of production, use and disposal of our appliances. SFC believes that the right to repair must be part of this holistic view. Free and open source software provides longevity for products that are either deemed too old for manufacturers to support, or want to force you into buying new ones so they can perpetuate their 'planned obsolescence'. SFC believes that FOSS is a critical component to achieving all the goals of the Right to Repair movement.

Joining together with the Right to Repair groups has opened up SFC to myriad new ways to provide advocacy for software freedom. SFC is grateful to the Right to Repair movement for the inclusion of software related concerns, and expects these budding relationships to grow into further fruitful cooperation to support users of all kinds of devices.

You can read our comment directly here or submit your own at the FTC website.

For more details on SFC's submission, see our blog post on our comment to the FTC.

The Software Freedom Conservancy

denver@appleenthusiast.com (Denver Gingerich) — 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 <denver@appleenthusiast.com>.

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:

samsung-wf46bg6500avus_manual.pdf

lg-lrfvc2406s_manual.pdf

sony-kdl_48w600b_manual.pdf

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.

The Software Freedom Conservancy

pono@appleenthusiast.com (Daniel Takamori) — 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 <pono@appleenthusiast.com>.

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.

The Software Freedom Conservancy

info@appleenthusiast.com (Software Freedom Conservancy) — Wed, 07 Dec 2022 10:36:00 -0500

A news item from Software Freedom Conservancy.

Software Freedom Conservancy is announcing our first ever Free and Open Source Software Yearly Conference (FOSSY)! Free and Open Source Software is back at the Oregon Convention Center in Portland, OR for a 4 day conference July 13-16, 2023. Join us to celebrate and learn about what makes the FOSS community so special and unique and to discuss the most critical issues in our field. The conference will focus on community driven initiatives in FOSS like licensing and legal approaches, community development as well as technical talks from contributors from all over the world. The health and safety of our attendees is an utmost priority for us and we will be publishing information about our covid protocols in the coming weeks.

We are seeking sponsors at various levels to help provide food, coffee and AV + WiFi services so we can ensure our conference is run completely on free software. If you or your organization would like more information here is our sponsorship prospectus or you can contact us at conference@appleenthusiast.com for more information.

Mark your calendars for a truly free software focused conference. We can't wait to have you join us in Portland next summer for a weekend full of sharing ideas for the future, realtime development and using free software to build the world we want to live in. Please visit our landing page, FOSSY 2023, for more information.

The Software Freedom Conservancy

info@appleenthusiast.com (Software Freedom Conservancy) — Mon, 05 Dec 2022 12:55:00 -0500

A news item from Software Freedom Conservancy.

Gingerich to coordinate and lead SFC's continued GPL enforcement

Today Software Freedom Conservancy announces that as part of its ongoing efforts to achieve widespread GPL compliance across the tech industry, SFC promotes Denver Gingerich to Director of Compliance.

SFC is the only organization actively defending Linux's license (the GPL version 2) among the various other projects for which SFC enforces. While enforcing the GPL (and other FOSS licenses) is never SFC's preferred approach, the number of egregious violations of the GPL (including examples such as Vizio) requires SFC to take action given its charitable mission of sustaining FOSS projects, which cannot exist without a fair reciprocal relationship in the organizations and for-profit companies that use them.

As part of its commitment, SFC is continually looking for additional resources and new ways of ensuring the key reciprocal relationship of copyleft is upheld. While SFC only uses lawsuits as a last resort, it is a sad fact that more and more companies have dug in their heels instead of complying with the clear text of the GPL and other FOSS licenses when we ask them to. As a result, SFC will focus its efforts, as necessary, on increasing its capacity to work with such companies. SFC is pleased that Gingerich is increasing his involvement to improve the community relationships in FOSS by increasing compliance through various means (primarily educational) to get us back to the reciprocity that copyleft licenses codify in their text.

“We met Denver just a few months after SFC's founding, and he was one of the first people to report a GPL violation to us. Since then, he's worked with us part-time, providing an incredible balance of expertise and engineering skill required to build from source offerings”, said Bradley M. Kuhn, SFC's Policy Fellow and member of our Board of Directors. Bradley added: “It has been an honor for me to mentor Denver all these years. His FOSS license knowledge and a passion for advocacy around software right to repair today ranks him among the highest echelon of FOSS advocates. He has led our community engagement with the Right to Repair movement in his decade-plus of work with SFC. I am so glad to welcome him into an expanded role as our first Director of Compliance.”

Gingerich brings more than 11 years of experience at SFC with him to his new role as Director of Compliance, while also participating in FOSS business endeavors outside of Conservancy, showing FOSS is not only pro-business, but leads to more sustainable business models and thoughtful businesses. Gingerich's experience in both fields makes him uniquely qualified to help businesses understand why FOSS licenses exist and how to be good stewards of the FOSS that these businesses modify and redistribute.

Denver has been very active in many of SFC's compliance initiatives in the past, including, working with specific companies about their compliance, helping to explain how copyleft licenses work and recently debuted our new copyright assignment project. He has spoken at conferences like Copyleft Conf and written extensively on misconceptions of compliance while keeping an eye on legislation and other timely issues for copyleft. Recently Gingerich has been leading efforts for SFC to collaborate with other Right to Repair organizations.

The Software Freedom Conservancy

pono@appleenthusiast.com (Daniel Takamori) — 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 <pono@appleenthusiast.com>.

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.

The Software Freedom Conservancy

pono@appleenthusiast.com (Daniel Takamori) — 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 <pono@appleenthusiast.com>.

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.

The Software Freedom Conservancy

info@appleenthusiast.com (Software Freedom Conservancy) — Mon, 28 Nov 2022 13:00:00 -0500

A news item from Software Freedom Conservancy.

SFC Named as Trusted Party To Verify Future Corresponding Source

Stockfish, a Free and Open Source Software (FOSS) chess engine, has announced the settlement of their lawsuit against ChessBase GmbH regarding violations of Stockfish's license, the General Public License, version 3 (GPLv3). Software Freedom Conservancy is excited to announce our role in this historic violation settlement. Specifically, SFC has been named in the settlement agreement as the trusted third-party to analyze and approve any complete “Corresponding Source” releases by ChessBase in the future.

SFC is honored that the parties chose us to carry out this critical duty. As a litigant ourselves in unrelated copyleft enforcement litigation, we know well that ongoing compliance, and assuring that the rights of the community of users remains respected for the years after the litigation completes, is the most important work of software freedom. We also appreciate the trust that the FOSS community places in SFC as arbiters on behalf of consumers and users, of what various copyleft licenses (such as the GPLv2 and GPLv3) require with regard to complete, corresponding source (CCS).

Too often, those who enforce the GPL focus so much on the copyright infringement they have suffered and forget the policy goal of all copyleft licenses: to guarantee that users and consumers get the methods, means, and technical details on how to make real use of the software rights and freedoms that the licenses promise. We congratulate both parties in this litigation for coming to an amicable agreement that makes a plan to put those rights of users first and foremost in an ongoing way.

The Software Freedom Conservancy

info@appleenthusiast.com (Software Freedom Conservancy) — Tue, 22 Nov 2022 12:53:00 -0500

A news item from Software Freedom Conservancy.

Help us unlock our match challenge

We're pleased to announce an ambitious match challenge for this fundraising season.

As a non-profit dedicated to upholding user freedoms and protections against corporate and other interests that may not be in the public's general interest, we rely upon the donations from our individual sustainers. Software Freedom Conservancy has been growing and is able to take on the work it does thanks to the incredible support of individuals who care about an organization who stands up for the equitable, ethical and end user focused technologies.

This year's match is comprised of donations solely by individual donors -- a few large anonymous donors as well as a handful of smaller donors who are planning to give just a little bit more this year to challenge SFC supporters to make their annual Sustainer contribution go further. These smaller donors include (in first name alphabetical order): Asumu Takikawa, Elizabeth Joseph, John Sullivan, Justin Flory and Will Norris, all of whom care deeply about software freedom. We are excited to highlight them over the next few weeks.

These generous donations raise our match fund to $104,759, so be sure to donate by January 16 to maximize their donations!

This year has been packed with growth for SFC and exciting work in free software, including our historic consumer rights lawsuit to promote copyleft, the diversity and inclusion efforts of Outreachy & The Institute for Computing in Research, and our support of all of our wonderful member projects.

Thank you so much for your support and please consider becoming a Sustainer now.

The Software Freedom Conservancy

bkuhn@appleenthusiast.com (Bradley M. Kuhn) — 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 <bkuhn@appleenthusiast.com>.

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.

The Software Freedom Conservancy

denverandbkuhn@appleenthusiast.com (Denver Gingerich and Bradley M. Kuhn) — 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 <denverandbkuhn@appleenthusiast.com>.

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.

The Software Freedom Conservancy

denverandbkuhn@appleenthusiast.com (Denver Gingerich and Bradley M. Kuhn) — 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 <denverandbkuhn@appleenthusiast.com>.

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.

The Software Freedom Conservancy

bkuhn@appleenthusiast.com (Bradley M. Kuhn) — 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 <bkuhn@appleenthusiast.com>.

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.

The Software Freedom Conservancy

denver@appleenthusiast.com (Denver Gingerich) — 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 <denver@appleenthusiast.com>.

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:baccarat liveM?i quy?n ???c b?o l?u cho trang web ch��nh th?c 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:baccarat liveM?i quy?n ???c b?o l?u cho trang web ch��nh th?c 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.

The Software Freedom Conservancy

bkuhn@appleenthusiast.com (Bradley M. Kuhn) — 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 <bkuhn@appleenthusiast.com>.

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:baccarat liveM?i quy?n ???c b?o l?u cho trang web ch��nh th?c 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.

The Software Freedom Conservancy

bkuhn@appleenthusiast.com (Bradley M. Kuhn) — 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 <bkuhn@appleenthusiast.com>.

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.

The Software Freedom Conservancy

bkuhn@appleenthusiast.com (Bradley M. Kuhn) — Thu, 03 Feb 2022 19:29:00 -0500

A blog post from Software Freedom Conservancy.

Blog post by Bradley M. Kuhn. Please email any comments on this entry to <bkuhn@appleenthusiast.com>.

Software freedom is our goal. Copyleft is a strategy to reach that goal. That tenet is oft forgotten by activists. Copyleft is even abused to advance proprietary goals. We too often see concern about the future of copyleft overshadow the necessary fundamental question: does a particular behavior or trend �?and the inevitable outcomes of those behaviors and trends �?increase or decrease users�?rights to copy, share, modify, and reinstall modified versions of their software? That question remains paramount as we face new challenges.

Introduced first by Microsoft’s GitHub in their Copilot product, computer-assisted software authorship by way of machine learning models presents a formidable challenge to software freedom’s future. Yet, we can, in fact, imagine a software freedom utopia that embodies this technology. Imagine that all software authors have access to the global archive of machine learning models �?and they are fullly reproducible. Everyone has equal rights to fork these models, train them further with their own datasets, provided that they must release new models (and the input code) freely in the global archive. All code produced by these models is also made freely available under copyleft. All code that builds the models, all historical input sets, and all trained models are all also made available to everyone under copyleft licenses.

While activists might quibble about minor details to optimize imagined utopia, this thought experiment shows computer-assisted software authorship does not inherently negate software freedom. Rather, the rules, requirements, and policies that apply will determine whether software freedom is respected. To paraphrase Hamlet: there is nothing either good or bad, but the policy makes it so.

What’s the Worse That Could Happen?

[They are] not a good [person] who, without a protest, allows wrong to be committed �?with the means which [they] help to supply.

�?John Stewart Mill, University of St. Andrews, 1 February 1867

Obviously, ignoring machine learning for computer-assisted software authorship will not usher in this software freedom utopia. Copyleft activists cannot stand idly by in this situation, but we must temper our attention by considering the likelihood of dystopian and problematic outcomes, and the options available to prevent them.

In response to Copilot’s announcement, pundits speculated, without evidence, a prevailing feeling of “Free Software had a good run, but I guess that’s over now�? Such predictions seem consistent with the well-documented overoptimism of artificial intelligence success. Rapid replacement of traditional software development methodologies seem unlikely. As such, we should not overestimate the likelihood that these new systems will both accelerate proprietary software development, while we simultaneously fail to prevent copylefted software from enabling that activity. The former may not come to pass, so we should not unduly fret about the latter, lest we misdirect resources. In short, AI is usually slow-moving, and produces incremental change far more often than it produces radical change. The problem is thus not imminent nor the damage irreversible. However, we must respond deliberately with all due celerity �?and begin that work immediately.

Currently, there are two factors that influence the timing of our response. First, if GitHub’s Copilot becomes a non-beta product available to the programming public, that would indicate necessity of an urgent response. Microsoft and GitHub are unlikely to share their product plans, so we cannot know for sure when this will occur. However, in the seven months since the first beta was made available, we’ve consistently heard anecdotally that more and more developers (particularly, FOSS developers!) have received beta invitations. Based on these (admittedly incomplete) facts, we must assume that a move from private beta to public deployment is imminent in 2022. This indicates some urgency of the problem.

Second, we already know that some of our worst fears are definitely true. Namely, that Microsoft and GitHub used copylefted software as part of Copilot’s training set.

Copilot was trained on “billions of lines of public code �?written by others�?lt;/a>. While GitHub has refused requests to release even a list of repositories included in the training set, the use of the word “public�?indicates that only software with source-available licenses (even if not FOSS licenses) were input into Copilot. Furthermore, GitHub admits that during training, the system encountered a copy of the GPL more than 700,000 times. This effectively confirms that copylefted public code appears in the training set.

When questioned, former GNOME developer and GitHub CEO ⁰, Nat Friedman, declared publicly �?1) training ML systems on public data is fair use (2) the output belongs to the operator�? Friedman himself, as well as Microsoft and GitHub’s other executives and lawyers, have ignored Software Freedom Conservancy’s requests for clarification and/or evidence supporting these statements.

Meanwhile, GitHub continues to improve this system, trained only on publicly source-available software, and seeks to market it to new users, including those who otherwise use FOSS development tools. Users continue to report gaining access to the beta and are noticing improvements. Microsoft and GitHub’s public position is meanwhile clear: they claim to have no copyleft obligations for training the model, the model itself, and deploying the service. They also believe there are no licensing obligations for the output.

While Friedman ignored the community’s requests publicly, we inquired privately with Friedman⁰ and other Microsoft and GitHub representatives in June 2021, asking for solid legal references for GitHub’s public legal positions of (1) and (2) above. They provided none, and reiterated, without evidence, that they believed the model does not contain copies of the software, and output produced by Copilot can be licensed under any license. We further asked if there are no licensing concerns on either side, why did Microsoft not also train the system on their large proprietary codebases such as Office? They had no immediate answer. Microsoft and GitHub promised to get back to us, but have not.

This secrecy and non-cooperativeness is expected from a proprietary software company and its subsidiary, but leaves us only with speculative conclusions to inform a strategy for copyleft here. We can reliably guess that the companies will claim “fair use�?as their primary justification for creating the model and offering the service, and will argue that both the output and the trained model are not “work[s] based on the Program�?(GPLv2) nor do they “copy from or adapt all or part of the work[s] in a fashion requiring copyright permission�?(GPLv3/AGPLv3). Furthermore, we can reliably conclude, given the continuing product promotion, that the companies have at least a medium-term commitment to Copilot.

In short, they have already hunkered down for a protracted disagreement. Their positions are now incumbent �?using their resources and power to successfully charge copyleft activists to “prove them wrong�? But we do not have to accept their unsubstantiated arguments at face value. In fact, these areas are so substantially novel that almost every issue has no definitive answers, but we must nevertheless begin to formulate our position and our response to Microsoft and GitHub’s assault on copyleft.

Trained Models, Fair Use, and Copyright:baccarat liveM?i quy?n ???c b?o l?u cho trang web ch��nh th?c Infringement

Consider GitHub’s claim that “training ML systems on public data is fair use�? We have not found any case of note �?at least in the USA �?that truly contemplates that question. The only legal case in the USA to look near this question is Authors Guild v. Google, Inc., 804 F.3d 202 (2d Cir. 2015). The Supreme Court denied certiorari on this case; it is not legal precedent in all jurisdictions where Microsoft and GitHub operate.

Even more, that case considered a fact pattern centered around search, not authorship of new/derived works. Google had made copies of entire copyrighted books, not for the purpose of displaying them, but so users could (1) run search queries, and (2) see a “snippet�?of the search hits (i.e., to see the search hit in context). The Second Circuit held Google’s copying of the books was “fair use�?because searching and providing context added value exceeding what a user could obtain from their own copies, and Google’s product did not substitute the market for the books.

The analogous fact pattern for code is obvious: GitHub could offer a search tool that assists users in finding key public repositories (and specific lines of code within those repositories) that seemed to solve tasks of interest. Developers could then easily utilitize those codebases in the usual, license-compliant ways. The actual Copilot fact pattern is not this one.

Meanwhile, the Authors Guild case begins and ends the list of major cases regarding machine learning systems and “fair use�? We should simply ignore GitHub’s risible claim that the “fair use question�?on machine learning is settled.

Perhaps most importantly, in the USA, “fair use�?is an affirmative defense to answer copyright infringement. In concrete terms, that means �?particularly in cases where the circumstances are novel �?a copyright holder brings an infringement lawsuit and then the alleged infringer shows in court that their actions met the relevant factors for “fair use�?sufficiently. Frankly, we refuse to do these companies�?job for them. Copyleft activists need not tell Microsoft and GitHub why this isn’t “fair use�?lt;/em>, rather, they need to tell us why training the model with copylefted code is “fair use�?and prove that the trained model itself is not a “work based on�?the GPL’d software.

GitHub has meanwhile artfully avoided the question of whether the trained model is a “work based on�?the input. We contend that it probably is. However, given that “fair use�?is an affirmative defense to copyright infringement, they are obviously anticipating a claim that the trained model is, in fact, a “work based on�?the inputs to the model. Why else would they even bring up “fair use�? rather than simply say their use is fully non-infringing? Anyway, we have no way to even explore these questions authoritatively without examining the model, fully affixed in its tangible medium. We don’t expect GitHub to produce that unless compelled by a third party.

Indeed, discussion of these questions outside of a courtroom is moot. For this novel and contentious fact pattern, only a court decision can settle the matter adequately. As a strategic matter, copyleft activists should keep their own counsel about what we anticipate in the opposition’s “fair use�?and/or non-infringement defenses, and the counter-arguments that we plan.

Copilot Users Should Worry

GitHub’s position does a great disservice to Copilot users. Their claim that “the output belongs to the operator�?creates a false sense of legal justification. Users have already shown that Copilot can generate a substantial amount of unique, GPL’d code, and then (rather ironically, given GitHub’s claim that they removed the text of the GPL from the training set) also suggest a license that is non-copyleft. Friedman’s statement surely does not qualify as an indemnity for Copilot users who might face GPL enforcement actions. Users almost surely must construct their own “fair use�?or “not copyrightable�?defenses for Copilot’s output.

The length and detail of what Copilot can generate for users seems unbounded. The glaring example above appears primia facie to be copyright infringement; we expect further such problems. Consider the sheer amount that a fully functional and successful Copilot would generate. Surely, AI researchers seek the ability for Copilot to “figure out�?that you are trying to solve some specific task when programming. The better Copilot gets at handing ready-made solutions to its users, the more likely it becomes that its output may offer the user copylefted software.

Copilot leaves copyleft compliance as an exercise for the user. Users likely face growing liability that only increases as Copilot improves. Users currently have no methods besides serendipity and educated guesses to know whether Copilot’s output is copyrighted by someone else. Proprietary software companies such as Synopsys provide so-called “scanning tools�?�?that can search your proprietary codebase and find hidden copylefted software. However, the FOSS tools for that job are in their infancy and unlikely to develop quickly, since historically those who want those tools are companies that primarily develop proprietary software and seek to avoid copylefted software.

We recommend users who wish to avoid infringing the copyrights of others simply avoid Copilot.

On Copyleft Maximalism and Unilateral Capitulation

Draconian copyright law generally horrifies software freedom activists for good reason. Nearly all copyleft activists would prefer a true, multilateral rewriting of copyright rules that prioritized the interest of the general public and software rights. Copyleft exists primarily because of the long-standing political non-viability of a copyright law reboot. Nothing has changed in this regard; if anything, changing legislation has become an even more expensive lobbying proposition than it was at copyleft’s advent. Copyleft activists should expect, indefinitely, for proprietary software companies and media oligarchs to control copyright legislation.

Fortunately, copyleft was designed specifically for this eventuality. Activists have called copyleft the “judo move�?of software freedom, since copyleft uses the powerful copyright force (invented primarily by our opposition) against itself. That realization leads to a painful, but pragmatically necessary, awkwardness.

The issues herein �?from training of machine learning models, to the copyright questions about those models, to the derivation questions about their output �?are novel copyright questions. As software freedom activists, we are uniquely qualified to invent an ideal copyright structure for these technologies. But, without a path to promulgate such replacement copyright rules into the incumbent system, that exercise is futile. Furthermore, systems outside of copyright �?including but not limited to EULAs, business agreements and patents �?have long been used to proprietarize software without the need of copyright. Reality of facts on the ground dictate that we not concede the only wedge we have to compel software freedom; that wedge is copyleft.

Meanwhile, proprietary software companies regularly exploit any unilateral concessions on weakening of copyleft that FOSS projects make, while continuing to pursue copyright maximalism for their works. Particularly in novel areas, we must assume a copyleft maximalist approach �?until courts or the legislature disarm all mechanisms to control users�?rights with regard to software. That adversarial process will frustrate us, but ultimately by choosing copyright as our primary tool, we already chose the courts as our battleground for contentious issues.

We all surely have our opinions about how copyleft should operate in these novel situations. We have even expressed some such opinions herein. But, ultimately, strong copyleft licenses do not defer the “what’s covered?�?question to one individual or organization. The “judo�?power comes from strong copyleft reaching to all of what copyright governs. When those issues are novel �?and companies flaunt that novel manipulation of copylefted works �?only a court can answer definitively.

A Community-Led Response

While these companies will likely not succeed in their efforts to disarm copyleft, they have nevertheless attacked the entire copyleft infrastructure. We must mount an effective response.

Software Freedom Conservancy has spent the last six months in deep internal discussions about this novel threat to the very efficacy of copyleft. We have a few ideas �?a mix of short-term, medium-term and long-term strategies to address the problem. However, we recognize that a community (rather than the traditional BDFL) approach is needed �?at least for this problem. Thus, putting first things first, we realized that we should gather the best minds in the software freedom community with direct experience in copyleft theory and practice. We will convene these individuals to a committee specifically chartered by Software Freedom Conservancy to �?as quickly as reasonably possible �?publish a series of recommendations to the community on how we should respond to both the immediate threat to copyleft found in Copilot, and (long-term) analyze the more general threat that AI-assisted programming techniques pose to the strategy of copyleft.

While we are not actively seeking applications for this committee, we do welcome anyone whom we have not yet solicited to participate to contact us and inquire. We will surely be unable to include everyone who is interested on the committee �?either due to Conflicts of Interest or due to simple logistics of creating too large a committee. However, we will carefully consider anyone who expresses bona fide interest to participate.

Finally, as much as can be done during the pandemic using FOSS tools available, we will attempt to convene public discussions as much as possible. We will contemporaneously publish the committee’s minutes publicly. If you’d like to get involved today in public discussions about this issue, please join the mailing we launched today for this topic.

⁰In November 2021, Nat Friedman was replaced by Thomas Dohmke as GitHub’s CEO. However, to our knowledge, Dohmke has not retracted or clarified Friedman's comments, and at the time of writing, no one from GitHub or Microsoft that we spoke to had responded to our requests for clarification.

The Software Freedom Conservancy

bkuhn@appleenthusiast.com (Bradley M. Kuhn) — Tue, 01 Feb 2022 09:35:00 -0500

A blog post from Software Freedom Conservancy.

Blog post by Bradley M. Kuhn. Please email any comments on this entry to <bkuhn@appleenthusiast.com>.

Inspired by the log4j situation, The White House recently met with Big Tech on the issue of security vulnerabilities in FOSS used in the nation's infrastructure. While we are glad these issues have received attention at the highest levels of the administration, we are concerned that representation in these discussions is skewed. Hobbyists, and communities organized around public interest and consumer rights, who both use and develop a large portion of FOSS, were not represented. Additionally, the entities represented at the meeting were biased toward copyleft-unfriendly organizations. Unsurprisingly, these entities focused on Software Bill of Materials (SBOM) as a panacea for the problem of FOSS security. While SBOMs are a useful small step toward hardening the nation's software infrastructure, we believe the proper solution is to favor copylefted FOSS.
Consumers must have access to source code, the right to modify and reinstall it (or hire anyone they'd like in the free market to do so). Without these rights, businesses, individuals, and the government — all of whom rely on software as part of their critical infrastructure — cannot identify and repair security vulnerabilities. Furthermore, the widespread incorporation of non-copyleft FOSS, which companies can and do proprietarize, creates a false sense of security — as many users may not realize that “FOSS inside” (as listed on their SBOM) does not mean the software is any better than proprietary software.

Our open letter to the White House which addresses our concerns is included in full below, and is also available as a PDF:

Dear President Biden, Deputy Advisor Neuberger, Director Inglis, et al:

Firstly, we appreciate very much that your administration has taken the issue of the log4j software vulnerability so seriously, and also appreciated President Obama’s efforts to take the OpenSSL vulnerability (so-called “HeartBleed”) seriously during his administration. While we at the Software Freedom Conservancy believe deeply that Free and Open Source Software (FOSS) is a better and more reliable method to develop software, we also readily acknowledge that no method of software development is perfect. (Flaws can and do occur.) However, sound planning — which includes meaningful investment in infrastructure — will not only limit potential vulnerabilities, but is also essential to respond to them adequately when they do inevitably occur.

As you likely agree, our nation’s infrastructure and national security — both of which increasingly depend on software — demand this type of care and attention. While we are pleased that your administration has taken some basic steps to focus on this critical issue, we send this open letter to request necessary improvements to the current methodology that your administration is using to address the issue of software security vulnerabilities in FOSS. In short, your administration has taken a great first step — one which the for-profit software industry has embraced — but we have deep concerns. We expect the powerful technology industry to resist the mandatory steps necessary to ensure the security of FOSS. This is due to the basic fact that the necessary changes mean that companies and their shareholders will have to live with more modest profits if your administration demands the necessary changes to ensure cybersecurity for FOSS.

Your meeting earlier this month included some important entities, but unfortunately was biased in one specific direction. Specifically, we observed that the meeting only included representatives from companies and organizations that prefer a specific form of FOSS — the form of FOSS that allows entities to change the software into their own proprietary technology. Roughly speaking, there are two forms of FOSS: non-copylefted FOSS, which allows vendors to take the publicly available software and make trade-secret changes; and copylefted FOSS, which — by contrast — is licensed in a manner that requires full disclosure of all source code (and the necessary means to repair vulnerabilities in that software) to customers. Non-copyleft FOSS has a fatal flaw: it can easily be incorporated into a proprietary product — including with modifications that may introduce vulnerabilities. Vendors can keep all details about those changes secret from everyone — including their customers and the government. Furthermore, a company may disclose that the software is based on a particular FOSS project, which perpetuates a false sense of security. Consumers will often assume that since it’s labeled as FOSS, that the key benefits of FOSS de-facto apply — such as easily auditing the software themselves (or hire an third-party firm) to examine the software for vulnerabilities and/or repair discovered vulnerabilities. However, if that FOSS is not under a copyleft license, there are no such guarantees. Imagine what can happen when a vendor goes out of business while the customer (who could be the federal government itself) still relies on that software for essential infrastructure.

As one of the leading organizations dedicated to FOSS, we believe it is extremely important to share our expertise at this critical moment. We reiterate our sincere appreciation for your administration’s interest and promulgation of Software Bill Of Materials requirements. On the surface, this is a small step in the right direction. We fear, however, that, without meaningful and informed improvements, it merely serves as camouflage and creates a false sense of security. A simple list of software included will give only vague clues as to how to repair vulnerabilities of a vendor’s software. No existing SBOM formats actually require full disclosure of software source code — nor means for its modification — to the customers who receive, use, and rely on it. Having an SBOM for your non-copylefted, proprietary software is like having a list of parts that you know are under the hood of your car, but discovering that the manufacturer has welded the hood shut, and forced you to sign an agreement that they could sue you for millions of dollars if you attempt to open it. The car may look safe and secure from the outside, but there is no way to know if the car is safe, reliable and, maintainable.

We are pleased to note that many software companies do chose to use copyleft licenses responsibly and provide the necessary source code; they serve as model citizens for other companies. Interestingly, the early positive revolution of FOSS in the software industry occurred precisely because copylefted FOSS was originally the more common form of FOSS; companies who seek higher profits and control of their customers have campaigned to limit the amount of copylefted FOSS developed. The history behind this is politically intriguing and not unique to FOSS. We see tech companies wielding power in problematic ways in other areas, too. Specifically, they have spent the last few decades pressuring hobbyist creators and small businesses to abandon copyleft licenses. As a result, non-copylefted FOSS is much more commonplace now than ever before (and the reason why this is such a critical issue). We at the Software Freedom Conservancy urge your administration to carefully consider the larger context of software cybersecurity—particularly as it relates to FOSS. We also offer up our guidance and expertise, and hope you will make room for additional seats at the table as you continue discussions and make decisions of this magnitude.

At the White House Meeting on Software Security on January 13, 2022, Big Tech was well-represented, and even overrepresented since it primarily included companies that are considered anti-copyleft. (Indeed, some Microsoft executives in the past have even called copyleft licensing “against the American Way” and a “cancer” on the software industry.) Yet, it is common knowledge in the technology sector that key components of our nation’s software infrastructure, such as Linux and the GNU Compiler Collection, were initially written by hobbyists and activists under copyleft licenses. Hobbyists and activists, who are the founders of FOSS, deserve a seat at the table—alongside Big Tech companies and their trade associations—as you continue to discuss these important national cybersecurity issues. The Software Freedom Conservancy is proud to serve and and give a voice to these hobbyist and activities, and we are also willing to recommend other organizations, academics, and individuals if you feel we’re not an ideal fit but nevertheless do want to diversify your committees on FOSS cybersecurity.

More generally, we ask that your administration reconsider how it solicits advice on these matters from technologists, and that you not succumb to the monoculture of opinion and manufactured consent from large technology companies and their trade associations. We appreciate that in other areas, your administration has valued inclusivity and actively seeks input from experts who disagree with the status quo. We believe you are truly interested in working on meaningful solutions to this critical issue facing our nation, and thank you for your consideration of our points raised in this letter.

Sincerely,
Bradley M. Kuhn
Policy Fellow, Software Freedom Conservancy

The Software Freedom Conservancy

pono@appleenthusiast.com (Daniel Takamori) — Mon, 03 Jan 2022 07:42:00 -0500

A blog post from Software Freedom Conservancy.

Blog post by Daniel Takamori. Please email any comments on this entry to <pono@appleenthusiast.com>.

The second of our series of interviews with donors, we have another longtime Software Freedom Conservancy supporter (and former employee!) Tony Sebro. Tony recently served as Deputy and Interim General Counsel to the Wikimedia Foundation and is now General Counsel at Change.org. We "sat down" with him to talk a bit about us and what he's excited about right now.

Software Freedom Conservancy: “Why do you care about software freedom?”

Tony Sebro: “For one, I am inspired by people dedicating their time, creative energy, and technical talents to the public interest. I am also impressed by what they produce: FOSS communities have created some of the most important, innovative, and irreplaceable products that societies rely on. ”

SFC: “What do you appreciate about Software Freedom Conservancy?”

TS: “I appreciate that Conservancy supports the creation of ethical technology from multiple vantage points. Conservancy supports FOSS developer communities through services, education, and mentorship. Conservancy supports end users by defending their rights. And, Conservancy advocates for groups underrepresented in technology by providing them with gateways into FOSS communities -- which, in turn, infuses these communities with fresh talent.”

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

TS: “While I am intrigued to see what happens with the lawsuit against Vizio, I am most excited by Outreachy's continued growth, as evidenced by the record number of interns admitted into the December 2021 cohort. I admit, I'm biased. :) ”

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

TS: “I got a good chuckle out of seeing Karen and Bradley pop up in this recent NFT project.”

SFC: “What other (non-tech) organizations are you supporting this year?”

TS: “My wife and I support other charities, as well as our local church.”

SFC: “You were Software Freedom Conservancy's second employee! What are your thoughts about how the organization has changed and grown since the beginning of your involvement in the organization?”

TS: “Conservancy has grown in virtually every direction! More projects; more commentary and scholarship. Greater investment in diversity, equity, and inclusion. Conservancy has also expanded into providing resources to educate tech employees about their employment rights.”

SFC: “Until recently, you were Deputy General Counsel at Wikimedia. Did the principles of software freedom impact your work there?”

TS: “Certainly! Free knowledge isn't just freely-licensed content, it should also be freely consumed. The Wikimedia Foundation hosts Wikipedia and its other free knowledge projects on a FOSS stack. The public can inspect the code, and can trust that Wikimedia isn't hiding anything that would bias or pervert the editorial decisions of the communities who maintain the project content Wikimedia hosts.”

SFC: “As a former employee, a member of the board of directors and as an organizer of Outreachy you've participated in many facets of Software Freedom Conservancy and have such a unique perspective. What are you most proud of? What do you think the organization should do in the future?”

TS: “I enjoyed providing advice and counsel to the various member projects -- getting to understand their specific cultures and needs. Outreachy continues to have a special place in my heart. That said: my favorite part of working at Conservancy was the deep conversations about ideology and strategy that I'd have with Karen, Bradley, and Denver. The team cares deeply about the work they do, and their passion for the mission was and is infectious.”

SFC: “Congratulations on starting your role at change.org! What can we look forward to seeing you work on there?”

TS: “Change.org's mission is to empower individuals to make a difference, and more than 450 million people use the platform to amplify their voice. I am leading the Legal & Policy department, which includes the organization's legal, trust and safety, platform policy and public policy functions.”