![[RSS]](/static/img/feed-icon-14x14.2168a573d0d4.png){kind=icon}
Conservancy BlogDisplaying posts
by Bradley M. Kühn
by on January 9, 2026
We at Software Freedom Conservancy are disappointed at some surprising news. Yesterday (THU 2026-01-08), we had a pretrial motions hearing scheduled in our historic impact litigation against Vizio. Just about an hour before the hearing's start-time, Judge Sandy Leal issued a minute order that rescheduled the hearing and (effectively) removed the trial (which was set to start this Monday 12 January 2025) from her calendar.
We have been in this litigation against Vizio since October 2021. Vizio violated both the General Public License (GPL) and Lesser GPL Agreements. Vizio's “Smart” TV products include more than a dozen packages under these copyleft licenses, yet Vizio has continually failed to comply with these agreements in various ways — most notably (and including but not limited to) by (a) not providing complete, corresponding source code, (b) not providing “the scripts used to control compilation and installation of the executable[s]”, and (c) not providing object code necessary for relinking the LGPLv2.1'd works. We were looking forward to our days in Court next week to show the world all the details of Vizio's non-compliance, and to ask the Court to acknowledge (among other things) our right as a third-party beneficiary under the GPL Agreements to receive all the materials that those Agreements require Vizio to give to all consumers who purchase their devices. These devices, BTW, are called “Smart” TVs because what's inside is actually a small (but powerful) computer attached to the giant video display — driven and controlled largely by copylefted FOSS.
Notwithstanding our frustration, our trial was delayed for good reason. Another case — even older than ours — needed more time for their jury trial (and thus had priority over ours). While some criticize the USA for being “too litigious”, we at SFC believe firmly that the civil Courts are the best place where ordinary citizens and small, scrappy non-profit charities like SFC can seek justice when our rights are violated. We also know that there is more injustice in our country these days than anyone would like, and this delay occurred because there are other folks out there seeking justice on other important issues and rights, too.
We understand that we've been waiting for a long time in a very long queue in the California Courts, and while we (like everyone) get frustrated when the line is taking much longer than expected, we also appreciate that Judge Leal is carefully managing her docket to grant all parties an impartial opportunity for justice.
Right now, our only item scheduled with the Court is the rescheduled pretrial hearing at 09:00 (US/Pacific) on the morning of Monday 26 January 2026. We'll spend the next two weeks posting the various recent motions and filings in the case, and publishing some retrospective summaries of the last four and a half years of the case for you all to read.
Be sure subscribe to our feed in your RSS readers/aggregators and follow us on the Fediverse (via Mastodon or your preferred ActivityPub software). to receive updates!
by on December 23, 2025
I wrote last month about my diabetes diagnosis this year and my difficult choice to wear a proprietary device (called a CGM) on my arm 24/7 to continuously monitor my glucose levels. Like my friend and colleague, Karen M. Sandler — who previously made a much higher-stakes choice to receive a proprietary implanted defibrillator to keep her safe given her genetic heart condition — I reluctantly chose to attach proprietary hardware and software to my body.
The device itself is quite proprietary, but fortunately the FOSS community has reverse engineered its activation and data collection protocols — creating an Android application that does a better job than the manufacturers' proprietary ones0.
Here in the USA, we strangely use capitalism as the center of our health care system. Two major for-profit competing brands of CGM are available here. My diabetes specialist prefers the (ironically named) Freestyle Libre Plus from Abbott. I (also rather strangely) bring a prescription for electronics to a pharmacy every month. On 2025-12-03, that pharmacy sent me an alarming text message (shown here).
After reading that text, I found the USA FDA announcement. My spouse cross-referenced the lot numbers while I read them off from all my Freestyle boxes1. I had indeed recently worn an impacted device!
Only because my diabetes is so early of a stage was I relatively safe. The FDA reports that Freestyle injured over 700 people and killed seven people with this bug. Specifically, the bug caused the device to falsely report an extremely low glucose level. Advanced stage diabetics use low reading information to inform them that they may have too much insulin currently. The usual remedy is to eat something sugary to raise glucose in the blood. Such should be done only with great care, as a false low reading can harm and even kill the patient (who eats a high-sugar-content item while glucose in the blood is, in fact, not low).
Proprietary software in medical devices harming patients is not new. In 1985, the Therac-25 killed three people. In 2020, hundreds of patients who relied on a financially troubled tech startup found their occular implants suddenly unsupported. Some patients went blind as the devices powered down without updates. There are more examples that I could include here, but rereading these horrific stories is frankly more than I can take right now when I think of fellow diabetes sufferers who were “killed by code” recently..
It's hubris for activists to guarantee that harm would be prevented if Freestyle had publicly released the hardware specifications and the complete, corresponding source code (CCS). FOSS isn't immune to bugs — even dangerous ones. However, in the centuries since the Enlightenment, we know that the scientific method depends on public disclosure about data and wide-reaching peer review of past work. FOSS (plus a publicly disclosed hardware design) wouid allow the millions of hardware and software engineers to peer-review the integrity, security, and safety of the devices to which patients entrust their lives. We achieve the promise of humanity when we each entrust our safety and health to our entire community — not merely a single for-profit entity.
We also will probably never know whether this issue was in hardware or software. The bug disclosure is incredibly vague, and it remains unclear how much investigation was done (if any) by government regulators into this problem. As a public policy and public health matter, the public deserves to know the technical details (software and hardware) of both the functioning device and the failed devices. NGOs should be permitted to perform their own investigations and confirmations of public safety.
Given that the hardware, software, and medical for-profit industries refuse to put the rights, safety and security of patients first, wrongful death lawsuits are typically the only way to hold these companies accountable. Yet, there are very few people who have not agreed Abbott's toxic terms of their proprietary companion application — I guestimate that fewer than 1% of Freestyle-using patients have used Juggluco from their very start (and thus never agreed to Abbott's terms). This is significant because Abbott includes a comprehensive one-way indemnity for themselves in the terms. I hope that a class action suit begins soon on this matter, but I wonder and worry that so much of the class may have signed this indemnity (which may make the road to justice bumpier).
Finally, I want to offer that if there is anyone out there who does tear-downs of extremely tiny electronic devices, I would be thrilled to find a volunteer who would like to see if we can either extract any software components from the device, or reverse-engineer the hardware. I have saved and sanitized all of my prior CGMs. I'd gladly send one along to anyone who wants to give a try at taking them apart. (Contact SFC or contact me on the Fediverse (via Mastodon) if you're available to do this work.)
For my part, I look forward (after the Vizio trial) to sending some patches to Juggluco and also getting Juggluco available in F-Droid. Our best option in the face of these powerful medical device companies curtailing our rights is to invest our volunteer time into the edges where FOSS has resiliently worked around the constant roadblocks erected by bad actors.
0My prior post about CGMs discussed the GPLv3'd Juggluco in more detail.
1 In a fascinating turn of events, at least one of my past monitors (of which I fortitously saved all the boxes with the lot/serial number on them) is listed in the FDA's spreadsheet as recalled lot, yet the serial number is listed as “ safe to use” on Abbott's webform 🤔 … I'm left wondering how I can trust Abbott to write reliable software stuck into my arm if they can't even write a web form that cross-references serial numbers to lots correctly 😬.
by on November 6, 2025
Our member project representatives and others who collaborate with SFC on projects know that I've been on part-time medical leave this year. As I recently announced publicly on the Fediverse, I was diagnosed in March 2025 with early-stage Type 2 Diabetes. I had no idea that that the diagnosis would become a software freedom and users' rights endeavor.
After the diagnosis, my doctor suggested immediately that I see the diabetes nurse-practitioner specialist in their practice. It took some time get an appointment with him, so I saw him first in mid-April 2025.
I walked into the office, sat down, and within minutes the specialist asked me to “take out your phone and install the Freestyle Libre app from Abbott”. This is the first (but, will probably not be the only) time a medical practitioner asked me to install proprietary software as the first step of treatment.
The specialist told me that in his experience, even early-stage diabetics like me should use a Continuous Glucose Monitor (CGM). CGM's are an amazing (relatively) recent invention that allows diabetics to sample their blood sugar level constantly. As we software developers and engineers know: great things happen when your diagnostic readout is as low latency as possible. CGMs lower the latency of readouts from 3–4 times a day to every five minutes. For example, diabetics can see what foods are most likely to cause blood sugar spikes for them personally. CGMs put patients on a path to manage this chronic condition well.
But, the devices themselves, and the (default) apps that control them are hopelessly proprietary. Fortunately, this was (obviously) not my first time explaining FOSS from first principles. So, I read through the license and terms and conditions of the ironically named “Freestyle Libre” app, and pointed out to the specialist how patient-unfriendly the terms were. For example, Abbott (the manufacturer of my CGM) reserves the right to collect your data (anonymously of course, to “improve the product”). They also require patients to agree that if they take any action to reverse engineer, modify, or otherwise do the normal things our community does with software, the patient must agree that such actions “constitute immediate, irreparable harm to Abbott, its affiliates, and/or its licensors”. I briefly explained to the specialist that I could not possibly agree. I began in real-time (still sitting with the specialist) a search for a FOSS solution.
As I was searching, the specialist said: “Oh, I don't use any of it myself, but I think I've heard of this ‘open source’ thing — there is a program called xDrip+ that is for insulin-dependent diabetics that I've heard of and some patients report it is quite good”.
While I'm (luckily) very far from insulin-dependency, I eventually found the FOSS Android app called Juggluco (a portmanteau for “Juggle glucose”). I asked the specialist to give me the prescription and I'd try Juggluco to see if it would work.
CGM (3.75cm Ø)
CGM's are very small and their firmware is (by obvious necessity) quite simple. As such, their interfaces are standard. CGM's are activated with Near Field Communication (NFC) — available on even quite old Android devices. The Android device sends a simple integer identifier via NFC that activates the CGM. Once activated — and through the 15-day life of the device — the device responds via Bluetooth with the patient's current glucose reading to any device presenting that integer.
Fortunately, I quickly discovered that the FOSS community was already “on this”. The NFC activation worked just fine, even on the recently updated “Freestyle Libre 3+”. After the sixty minute calibration period, I had a continuous readout in Juggluco.
Juggluco — 21-hour period
CGM's lower latency feedback enables diabetics to have more control of their illness management. one example among many: the patient can see (in real time) what foods most often cause blood sugar spikes for them personally. Diabetes hits everyone differently; data allows everyone to manage their own chronic condition better.
Juggluco — long period
My personal story with Juggluco will continue — as I hope (although not until after FOSDEM 2026 😆) to become an upstream contributor to Juggluco. Most importantly, I hope to help the app appear in F-Droid. (I must currently side-load or use Aurora Store to make it work on LineageOS.)
Fitting with the history that many projects that interact with proprietary technology must so often live through, Juggluco has faced surreptitious removal from Google's Play Store. Abbott even accused Juggluco of using their proprietary libraries and encryption methods, but the so-called “encryption method” is literally sending an single integer as part of NFC activation.
Juggluco's summary stastics
While Abbott backed off, this is another example of why the movement of patients taking control of the technology remains essential. FOSS fits perfectly with this goal. Software freedom gives control of technology to those who actually rely on it — rather than for-profit medical equipment manufacturers.
Juggluco's average graph
When I returned to my specialist for a follow-up, we reviewed the data and graphs that I produced with Juggluco. I, of course, have never installed, used, or even agreed to Abbott's licenses and terms, so I have never seen what the Abbott app does. I was thus surprised when I showed my specialist Juggluco's summary graphs. He excitedly told me “this is much better reporting than the Abbott app gives you!”. We all know that sometimes proprietary software has better and more features than the FOSS equivalent, so it's a particularly great success when our community efforts outdoes a wealthy 200 billion-dollar megacorp on software features!
Please do watch SFC's site in 2026 for more posts about my ongoing work with Juggluco, and please give generously as an SFC Sustainer to help this and our other work continue in 2026!
by on October 31, 2024
This week, the Open Source Initiative (OSI) made their new Open Source Artificial Intelligence Definition (OSAID) official with its 1.0 release. With this announcement, we have reached the moment that software freedom advocates have feared for decades: the definition of “open source” — with which OSI was entrusted — now differs in significant ways from the views of most software freedom advocates.
There has been substantial acrimony during the drafting process of OSAID, and this blog post does not summarize all the community complaints about the OSAID and its drafting process. Other bloggers and the press have covered those. The TLDR here, IMO is simply stated: the OSAID fails to require reproducibility by the public of the scientific process of building these systems, because the OSAID fails to place sufficient requirements on the licensing and public disclosure of training sets for so-called “Open Source” systems. The OSI refused to add this requirement because of a fundamental flaw in their process; they decided that “there was no point in publishing a definition that no existing AI system could currently meet”. This fundamental compromise undermined the community process, and amplified the role of stakeholders who would financially benefit from OSI's retroactive declaration that their systems are “open source”. The OSI should have refrained from publishing a definition yet, and instead labeled this document as ”recommendations” for now.
As the publication date of the OSAID approached, I could not help but
remember a fascinating statement that Donald E. Knuth, one of the founders
of the field of computer
science, once
said: [M]y role is to be on the bottom of things. … I try to
digest … knowledge into a form that is accessible to people who don't
have time for such study
. If we wish to engage in the
highly philosophical (and easily politically corruptible) task
of defining what terms like “software freedom” and
“open source” mean, we must learn to be on the “bottom of
things”. OSI made an unforced error in this regard. While they could
have humbly announced this as “recommendations” or “guidelines”,
they instead formalized it as a “definition” — with equivalent authority to their
OSD.
Yet, OSI itself only turned its attention to AI only recently, when they announced their “deep dive” — for which Microsoft's GitHub was OSI's “Thought Leader”. OSI has responded too rapidly to this industry ballyhoo. Their celerity of response made OSI an easy target for regulatory capture.
By comparison, the original OSD was first published in February 1999. That was at least twelve years after the widespread industry adoption of various FOSS programs (such as the GNU C Compiler and BSD). The concept was explored and discussed publicly (under the moniker “Free Software”) for decades before it was officially “defined”. The OSI announced itself as the “marketing department for Free Software” and based the OSD in large part on the independently developed Debian Free Software Guidelines (DFSG). The OSD was thus the culmination of decades of thought and consideration, and primarily developed by a third-party (Debian) — which provided a balance on OSI's authority. (Interestingly, some folks from Debian are attempting to check OSI's authority again due to the premature publication of the OSAID.)
OSI claims that they must move quickly so that they can counter the software companies from coopting the term “open source” for their own aims. But OSI failed to pursue trademark protection for “open source” in the early days, so the OSI can't stop Mark Zuckerberg and his cronies in any event from using the “open source” moniker for his Facebook and Instagram products — let alone his new Llama product. Furthermore, OSI's insistence that the definition was urgently needed and that the definition be engineered as a retrofit to apply to an existing, available system has yielded troublesome results. Simply put, OSI has a tiny sample set to examine, in 2024, of what LLM-backed generative AI systems look like. To make a final decision about the software freedom and rights implications of such a nascent field led to an automatic bias to accept the actions of first movers as legitimate. By making this definition official too soon, OSI has endorsed demonstrably bad LLM-backed generative AI systems as “open source” by definition!
OSI also disenfranchised the users and content creators in this process. FOSS activists should be engaging with the larger discussions with impacted communities of content creators about what “open source” means to them, and how they feel about incorporation of their data in the training sets into these third-party systems. The line between data and code is so easily crossed with these systems that we cannot rely on old, rote conclusions that the “data is separate and can be proprietary (or even unavailable), and yet the system remains ‘open source’”. That adage fails us when analyzing this technology, and we must take careful steps — free from the for-profit corporate interest of AI fervor — as we decide how our well-established philosophies apply to these changes.
FOSS activists err when we unilaterally dictate and define what is ethical, moral, open and Free in areas outside of software. Software rights theorists can (and should) make meaningful contributions in these other areas, but not without substantial collaboration with those creative individuals who produce the source material. Where were the painters, the novelists, the actors, the playwrights, the musicians, and the poets in the OSAID drafting process? The OSD was (of course) easier because our community is mostly programmers and developers (or folks adjacent to those fields); software creators knew best how to consider philosophical implications of pure software products. The OSI, and the folks in its leadership, definitely know software well, but I wouldn't name any of them (or myself) as great thinkers in these many areas outside software that are noticeably impacted by the promulgation of LLMs that are trained on those creative works. The Open Source community remains consistently in danger of excessive insularity, and the OSAID is an unfortunate example of how insular we can be.
Meanwhile, I have spent literally months of time over the last 30 years trying to make sure the coalition of software freedom & rights activists remained in basic congruence (at least publicly) with those (like OSI) who are oriented towards a more for-profit and corporate open source approach. Until today, I was always able to say: “I believe that anything the OSI calls ‘open source’ gives you all the rights and freedoms that you deserve”. I now cannot say that again unless/until the OSI revokes the OSAID. Unfortunately, that Rubicon may have now been permanently crossed! OSI has purposely made it politically unviable for them to revoke the OSAID. Instead, they plan only incremental updates to the OSAID. Once entities begin to rely on this definition as written, OSI will find it nearly impossible to later declare systems that were “open source” under 1.0 as no longer so (under later versions). So, we are likely stuck with OSAID's key problems forever. OSI undermines its position as a philosophical leader in Open Source as long as OSAID 1.0 stands as a formal defintion.
I truly don't know for sure (yet) if the only way to respect user rights in an LLM-backed generative AI system is to only use training sets that are publicly available and licensed under Free Software licenses. I do believe that's the ideal and preferred form for modification of those systems. Nevertheless, a generally useful technical system that is built by collapsing data (in essence, via highly lossy compression) into a table of floating point numbers is philosophically much more complicated than binary software and its Corresponding Source. So, having studied the issue myself, I believe the Socratic Epiphany currently applies. Perhaps there is an acceptable spot for compromise regarding the issues of training set licensing, availability and similar reproducibility issues. My instincts, after 25 years as a software rights philosopher, lead me to believe that it will take at least a decade for our best minds to find a reasonable answer on where the bright line is of acceptable behavior with regard to these AI systems. While OSI claims their OSAID is humble, I beg to differ. The humble act now is to admit that it was just too soon to publish a “definition” and rebrand these the OSAID 1.0 as “current recommendations”. That might not grab as many headlines or raise as much money as the OSAID did, but it's the moral and ethical way out of this bad situation.
Finally, rather than merely be a pundit on this matter, I am instead today putting myself forward to try to be part of the solution. I plan to run for the OSI Board of Directors at the next elections on a single-issue platform: I will work arduously for my entire term to see the OSAID repealed, and republished not as a definition, but merely recommendations, and to also issue a statement that OSI published the definition sooner than was appropriate. I'll write further about the matter as the next OSI Board election approaches. I also call on other software rights activists to run with me on a similar platform; the OSI has myriad seats that are elected by different constituents, so there is opportunity to run as a ticket on this issue. (Please contact me privately if you'd like to be involved with this ticket at the next OSI Board election. Note, though, that election results are not actually binding, as OSI's by-laws allow the current Board to reject results of the elections.)