Software Freedom Conservancy Explained: Projects, GPL Enforcement

Software Freedom Conservancy (SFC) is a New York nonprofit, incorporated on 7 April 2006 and recognised as a US 501(c)(3) charity, that acts as a fiscal sponsor for free and open source projects such as Git, QEMU, Samba, BusyBox, Wine, OpenWrt and U-Boot, and that enforces the GNU General Public License (GPL) on behalf of developers.

It does two jobs that most people meet separately. For developers, it is the legal home that holds a project's money, trademarks and contracts so the maintainers do not have to run a company. For anyone who ships a device or firmware image, it is the organisation most likely to write to you when your GPL source release is incomplete, and since October 2021 it has been in a California court with a smart TV maker over exactly that question. This guide goes one level deeper than our posts on open source foundation governance models, what copyleft requires and when and Linux Foundation versus Apache governance. Every date and rule below comes from the primary sources listed at the end, mostly Conservancy's own pages, the court orders it publishes and the licence texts on gnu.org. Where a source left a question open, we say so.

Key takeaways

• Conservancy was announced on 3 April 2006 with help from the Software Freedom Law Center, and New York granted its certificate of incorporation on 7 April 2006. It is a US 501(c)(3) charity and publishes its Form 990 filings.
• Fiscal sponsorship means a member project becomes organisationally part of Conservancy. Conservancy can take tax deductible earmarked donations for it, hold its trademarks, domains and (optionally) copyrights, sign contracts for it and provide basic legal help. New members pay 10% of the revenue Conservancy processes for them.
• The current projects page lists 44 entries, from ArgoUML to Xorg, including Git, Inkscape, Mercurial, OpenWrt, QEMU, Reproducible Builds, Samba, Selenium, U-Boot and Wine, plus programmes such as Outreachy.
• A self perpetuating Board of Directors appoints the Executive Director and staff. An Evaluation Committee chartered by the board reviews new projects, and each project is run day to day by its own leadership committee under a fiscal sponsorship agreement.
• Conservancy enforces the GPL under the Principles of Community-Oriented GPL Enforcement: compliance is the goal, legal action is a last resort, private negotiation comes first, money is never the priority and no payment buys silence about a violation.
• In SFC v. Vizio (Orange County Superior Court, filed 19 October 2021), Conservancy argues that a buyer of a GPL licensed device can enforce the licence as a third party beneficiary. The court has refused to dismiss the contract claim, but several issues were narrowed in late 2025, the January 2026 trial was taken off the calendar and Conservancy's case page lists the trial for "late 2026".
• For anyone shipping GPL code in a product, the practical lesson is the same whatever the court decides: ship the complete corresponding source, including the scripts used to control compilation and installation, or a valid written offer for it, and test that the source actually rebuilds what you shipped.

What is Software Freedom Conservancy?

Conservancy's About page describes it as a nonprofit focused on ethical technology, with a mission "to ensure the right to repair, improve and reinstall software". It pursues that mission three ways, by its own account: fostering free and open source projects, running initiatives that make technology more inclusive, and advancing policy work that defends free software, with copyleft named as the leading example.

When was it founded?

On 3 April 2006 the Software Freedom Law Center announced that it had helped establish the Software Freedom Conservancy to give a collection of free software projects "free financial and administrative services" through one entity. Conservancy's transparency page dates its New York certificate of incorporation and by-laws to 7 April 2006 and its Form 1023 application for federal tax exemption to September 2006. The launch announcement already describes the model Conservancy still runs: one corporate entity filing one tax return that covers all of its member projects.

What is its legal form?

Conservancy is a New York nonprofit corporation that is tax exempt under section 501(c)(3) of the US Internal Revenue Code. Every page of its site states its 501(c)(3) status, and its member services page notes that, as a charity incorporated in New York, its US donors can often deduct their gifts. It files the federal Form 990 and New York's CHAR500 each year and publishes both, with auditor's reports, on its transparency page. Its fiscal year starts on 1 March.

That legal form is the first big difference from some other open source homes. A 501(c)(3) is a public charity, while the Linux Foundation is a 501(c)(6), the form US trade associations use, funded by corporate members. Neither is better in the abstract; they are built for different jobs, and the comparison table later in this guide sets them side by side.

Who runs it day to day?

Conservancy's staff page lists Karen M. Sandler, formerly executive director of the GNOME Foundation, as Executive Director. Bradley M. Kühn, who led the Free Software Foundation's GPL enforcement as its executive director from 2001 to 2005, is Policy Fellow and Hacker-in-Residence. Denver Gingerich, Director for Digital Autonomy, manages compliance work, including "verifying complete corresponding source". A small finance team keeps the books for every member project.

What does fiscal sponsorship mean for a member project?

In US nonprofit practice, a fiscal sponsor is an existing charity that lets a project operate under its legal and tax umbrella. Conservancy's services page notes that the term is not well known among open source developers, though it fits what Conservancy does. The key point is structural: a project that joins formally becomes part of Conservancy, which the page likens to "a division of a company or a department in a large agency".

Conservancy lists these services for member projects:

Typical uses of earmarked funds, per the services page, include developer travel, hosting and equipment, paying developers under contract, trademark work and licence compliance.

What does it cost a project to join?

Conservancy's application page is direct about money. New members pay 10% of the revenue Conservancy processes for them into its general fund, which mainly pays staff. The same page says that even this 10% "does not fully fund" its fiscal sponsorship work, and that Conservancy raises other money to subsidise it. For very small projects it points to Software in the Public Interest, which it says offers fewer services but asks for 5% of gross revenue, and it states that, to its knowledge, most open source fiscal sponsors charge at least 10% or bill for services at cost.

Which projects are members?

Conservancy's current projects page, fetched on 24 October 2026, lists 44 entries:

ArgoUML, Backdrop CMS, Bongo, Buildbot, BusyBox, Common Workflow Language, coreboot, Darcs, the Debian Copyright Aggregation Project, Etherpad, FreeDV, Gevent, Git, the GPL Compliance Project for Linux Developers, Harvey OS, Houdini, Inkscape, the Institute for Computing in Research, K-3D, Kallithea, Liblouis, LibreHealth, libssh, Linux XIA, Mercurial, Metalink, MicroBlocks, OpenTripPlanner, OpenWrt, Outreachy, phpMyAdmin, QEMU, Reproducible Builds, Samba, Selenium, Sourceware, Squeak, SurveyOS, SWIG, Teaching Open Source, U-Boot, Wine, Xapian and Xorg.

Not every entry is a codebase. Outreachy is an internship programme, the Institute for Computing in Research runs student research cohorts, and the GPL Compliance Project for Linux Developers and the Debian Copyright Aggregation Project are enforcement arrangements in which developers authorise Conservancy to act for them. The list also changes: Liblouis joined in March 2025 and Conservancy announced on 29 December 2025 that U-Boot, the bootloader used across embedded Linux products, was joining. Treat any list, including this one, as a snapshot and check the live page before you cite it.

For supply chain teams the list deserves a second look. Git, BusyBox, U-Boot, coreboot, OpenWrt, QEMU, Samba and libssh sit inside countless build systems, routers, hypervisors and laptops. Membership does not change their code review or releases, which each project still owns, but it tells you who holds the trademark, who signs contracts and who may act on the project's GPL rights.

How does a project join?

The application page describes the path. Projects apply, and an Evaluation Committee chartered by the Board of Directors reviews applications on a rolling basis. A project offered membership receives a draft fiscal sponsorship agreement (FSA) for its leaders to review and sign. The U-Boot announcement shows the result: it quotes a member of U-Boot's new Project Leadership Committee, who explains that companies wanting to help had needed "an organization that represents U-Boot" to work with.

How is Conservancy governed?

The Board of Directors. The board page describes a "self-perpetuating Board of Directors" that appoints the Executive Director and staff. Self perpetuating means sitting directors choose new directors; the page describes no membership vote and no seats tied to sponsorship. On 24 October 2026 the page lists five directors: Dr. Laura Fortunato, Dr. Mark Galassi, Bdale Garbee, Dr. Allison Randal (Chair of the Board) and Tony Sebro. Their biographies show long histories in Debian, GNU, the Open Source Initiative, the Python and Perl foundations and nonprofit legal work, in line with the page's stated aim of mixing nonprofit managers and experienced project leaders.

Staff and committees. The Executive Director and staff run operations. The Evaluation Committee, chartered by the board, decides which projects to admit. Conservancy's site also lists an Outside Counsel page for the lawyers who work with it.

Member project leadership. Each project keeps its own technical governance. A Project Leadership Committee (PLC), or similar body defined in the fiscal sponsorship agreement, instructs Conservancy on how the project's earmarked funds are spent and speaks for the project. The services page stresses that projects keep operating as they did before joining, without electing a board or keeping corporate records. Git's maintainers still decide what goes into Git; Conservancy holds the legal shell around it.

How transparent is it?

Its transparency page publishes Form 990 returns, CHAR500 filings and auditor's reports by fiscal year, plus its incorporation documents, by-laws and Form 1023. For due diligence on a dependency that is unusually complete: you can see who governs the legal entity behind Git or QEMU, and how it is funded, without asking anyone.

What are the Principles of Community-Oriented GPL Enforcement?

The principles were first published in 2015 by Conservancy and the Free Software Foundation together, and the current page carries copyright for both, with a 2021 update by Conservancy. The page says the principles were originally formulated by other community leaders in 2001. It opens by explaining why copyleft needs enforcing at all: copyleft uses copyright to protect the freedom to modify and redistribute, so it is enforced through the same legal mechanisms as any other copyright licence, but the goal is different.

The guiding principles, in summary:

1. The primary goal is compliance. Enforcement aims to stop incorrect distribution, encourage corrected distribution and address the damage done, which often includes telling people who already received the software how to get its source code. No other goal should outrank full compliance.
2. Legal action is a last resort. Compliance work is mainly education and assistance, and the page says most violations happen by mistake, without ill will. Even when a violation is deliberate, agreed terms that fix it beat a court fight.
3. Confidentiality can help. Starting and continuing discussions privately shows good faith and gives the company room to fix honest mistakes. Enforcers should offer confidentiality as a settlement term, but if a company uses it to hide inaction, the problem may be made public after ample warning.
4. Never prioritise financial gain. Financial penalties are legitimate when used judiciously, because if the only penalty for violating is eventually complying, bad actors would wait to be caught. Asking a violator to cover the cost of the compliance work is reasonable; seeking the maximum damages copyright law allows usually is not.
5. No payment to overlook problems. Enforcers must not take money in exchange for ignoring a violation or accepting an incomplete fix. Ideally, no payment is accepted until the past violation is fixed and the company commits in writing to future compliance.
6. Verify first, then analyse comprehensively. Reports are checked before anyone is accused, and once a case is open, all of the relevant software is examined so the dialogue ends without other violations left to find.
7. Offer GPLv3 style cure, even for GPLv2. GPLv2 terminates the licence permanently at the moment of violation. GPLv3 lets a first time violator get its rights back automatically if it fixes the problem promptly. The principles recommend extending that more forgiving approach to honest mistakes under GPLv2 works too.

The page closes by saying these are not a strict rulebook and deliberately avoids fixed escalation ladders, because real violations vary too much.

How do they differ from a litigation first approach?

A litigation first enforcer treats a violation as an infringement claim: send a demand, then sue for an injunction and damages if the company does not settle. Money becomes central, because damages and settlements fund the next case. The community oriented principles invert several of those incentives.

Conservancy's copyleft compliance page adds context that cuts both ways. It says its Strategic GPL Enforcement Initiative, launched in October 2020, follows nearly 15 years of compliance work spanning ten fiscally sponsored projects, past lawsuits against more than a dozen defendants and hundreds of compliance actions without litigation, and that for years it gave companies the benefit of the doubt. The Vizio case is the clearest sign that Conservancy will go to court when it judges the private route has failed.

What GPL enforcement programmes does Conservancy run?

Conservancy's compliance page describes four strands.

Compliance for member projects. Conservancy is best known historically for compliance work on behalf of BusyBox, and today does semi regular compliance work for BusyBox, Git, Inkscape, Mercurial, Samba, QEMU and Wine. Copyright holders in those projects are asked to contact the project's leadership committee to take part.

The GPL Compliance Project for Linux Developers. Launched in May 2012, it acts on behalf of more than a dozen Linux copyright holders who have asked Conservancy to enforce their copyrights in the Linux kernel. Some developers have also assigned their Linux copyrights to Conservancy outright, so Conservancy enforces through its own copyrights too. Conservancy published the template agreements for this project in 2016.

The Debian Copyright Aggregation Project. Announced in August 2015, it lets Debian contributors assign copyrights to Conservancy or sign agreements authorising it to enforce on their behalf.

The Strategic GPL Enforcement Initiative. Launched in October 2020 with a companion Firmware Liberation Project, it focuses on what Conservancy sees as copyleft's core promise: complete corresponding source plus "the scripts used to control compilation and installation of the executable". The compliance page criticises what it calls the "compliance industrial complex" for selling tools and services that check notices and licence lists while ignoring that promise. That criticism is useful to anyone building a compliance process, because it names the gap most automated checks leave open: a source tarball can carry every right licence file and still fail to rebuild the binary you shipped.

What is the smart TV lawsuit about?

On 19 October 2021 Conservancy sued Vizio, Inc. in the Superior Court of California for the County of Orange (case number 30-2021-01226723-CU-BC-CJC), in a case the court classifies as breach of contract. Conservancy had bought Vizio smart TVs, which run Linux and other GPL and LGPL software, intending to build a modified operating system for them. Its case page says that when it asked for the complete corresponding source code, Vizio refused, and that after years of back and forth it concluded the only route left was to sue.

Why does it argue third party beneficiary rights?

Most GPL cases are brought by copyright holders, who sue for infringement when a distributor breaks the licence's conditions. Conservancy chose a different theory. It sued as a purchaser, arguing that the GPL is a contract between Vizio and the developers of the software, and that buyers of the product are the intended beneficiaries of that contract's source code promises. Under California law, as the court's orders explain, a third party beneficiary may enforce a contract made for its benefit, but it must show that it would in fact benefit, that benefiting it was a motivating purpose of the contracting parties, and that letting it enforce fits the contract's objectives.

If buyers can enforce, anyone who buys a Linux based device could demand its source, not only the few copyright holders willing to sue. Conservancy's case page frames it as establishing whether consumers have "the right to modify and improve the technology" they buy.

What has happened so far?

What did the December 2025 rulings actually decide?

Less than headlines might suggest. A tentative ruling is a non binding signal of how a judge is leaning before oral argument, not a decision. The 23 December order granted a motion on whether the licences require information that lets modified software be reinstalled while the whole TV keeps working properly. Conservancy's response is that nobody, itself included, reads any GPL version that way: it says a user replacing the firmware may lose the proprietary TV application, just as installing a different operating system on a laptop does not guarantee the old vendor's applications still run. What it still claims is the installation scripts used for the GPLv2 and LGPLv2.1 software.

We could not find, on Conservancy's site, a final written ruling on SFC's second motion for summary adjudication or a fixed trial date as of 24 October 2026. Treat the third party beneficiary question as unresolved, and check the case page before relying on any status.

What does the case allege Vizio did not provide?

Conservancy's January 2026 post summarises the alleged gaps: complete corresponding source code, the compilation and installation scripts the GPL names, and the object code needed to relink LGPLv2.1 libraries. Those three items are the same ones that trip up device makers in ordinary compliance work, which is why the case matters even to companies that will never be sued.

What other programmes does Conservancy run?

Outreachy. Outreachy moved from the GNOME Foundation to Conservancy in February 2015 and was renamed at that point; the announcement said the programme had by then placed 214 interns with 35 organisations. Today Outreachy describes itself as "a diversity initiative of Software Freedom Conservancy" and offers remote, three month internships in open source with a $7,000 USD stipend, running May to August and December to March, for people who face under representation, systemic bias or discrimination in tech where they live.

Use The Source. Conservancy runs a tool for evaluating the source code releases that companies provide for GPL software, which ties directly to its compliance work.

OpenWrt One. Conservancy says it designed and built a wireless router intended from the start for software freedom and right to repair, named after its OpenWrt member project.

FOSSY. An annual community conference; Conservancy has announced FOSSY 2027 for 5 to 8 August at the University of British Columbia.

Copyleft guides and policy work. The free guide at copyleft.org, Copyleft and the GNU General Public License: A Comprehensive Tutorial and Guide, walks through the GPL text and compliance practice in depth and is a useful companion to Conservancy's work. Conservancy itself publishes a glossary of the legal terms that come up in its cases. It also files policy comments, for example on US DMCA anti circumvention exemptions for alternative router firmware and compliance investigation, and in 2026 to the European Commission on digital ecosystems.

Reproducible Builds. The Reproducible Builds project is a Conservancy member, a neat fit with compliance: if anyone can rebuild a binary bit for bit from published source, it is far easier to show a source release corresponds to what shipped.

What does this mean for a company shipping GPL code in devices or firmware?

Whatever happens in the Vizio case, the licence texts on gnu.org have not changed. Here is what they require.

GPLv2: three ways to provide source

GPLv2 section 3 lets you distribute object code (a firmware image, a device) only if you do one of three things: accompany it with the complete machine readable source; or accompany it with "a written offer, valid for at least three years, to give any third party" the source for no more than your cost of distribution; or, for non commercial distribution only, pass along the offer you received. In practice, commercial device makers must either ship the source with the product or include a written offer and honour it for at least three years.

The definition of what you must provide is the part companies get wrong:

"complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable."

A tarball of the Linux kernel your product started from is not that. It must be the source that corresponds to the binary you shipped, with your patches, your kernel configuration, and the build and installation scripts that turn source into the image on the device.

GPLv3: Installation Information for User Products

GPLv3 goes further for consumer devices. Section 6 defines a "User Product" (broadly, consumer goods) and requires that when you convey object code in one, you also provide "Installation Information", defined as "any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source". The information must be enough that the modified program is not stopped from working merely because it was modified. That is the anti lockdown rule: if your bootloader only accepts signed images, GPLv3 software in the product means users must be able to install their own builds.

Note the scope. That sentence protects the modified GPLv3 program, not your proprietary application, which matches Conservancy's position in the December 2025 statement.

LGPLv2.1: relinking

If a product links proprietary code against an LGPLv2.1 library, section 6 of that licence requires that users be able to relink the application with a modified version of the library. For static linking that means providing object files for the proprietary part; for dynamic linking it is usually enough to use the shared library mechanism and allow the library to be replaced. Conservancy's Vizio filings list missing relinking materials as one of the alleged gaps.

Termination and cure

GPLv2 section 4 terminates your rights automatically when you violate the licence. GPLv3 section 8 adds a cure: stop violating and your licence is reinstated provisionally, and permanently if the copyright holder does not notify you within 60 days; on a first notice from that holder, fixing the problem within 30 days restores it permanently. The Linux kernel's own documentation carries a Kernel Enforcement Statement in which the signing kernel developers agree, notwithstanding GPL-2.0's termination clause, to adopt GPLv3's 30 and 60 day reinstatement provisions for their contributions. That is helpful, but you should not plan around anyone's goodwill; plan to be compliant on the day you ship.

A comparison of what each licence asks of a device maker

Step by step: check a product for GPL obligations and assemble a complete corresponding source release

This walkthrough assumes you build an embedded Linux image, the most common case for GPL device obligations. It uses only open source tools and the build systems' own documented features. None of these commands writes to a device; they read build output or an image file on your workstation.

Step 1: inventory what is in the image, from the build system

If you build with Buildroot, its manual documents a legal-info target that collects licences and sources for every package in your configuration:

make legal-info
ls output/legal-info/
# a manifest for target packages and one for host packages: name, version, licence
# licenses/ and host-licenses/   licence texts per package
# sources/ and host-sources/     source archives and patches as used by the build
# README                         warnings about anything that could not be saved

Buildroot's manual adds an important caveat: the output "is based on declarative statements in each of the packages recipes", so you or your legal team must check it before using it as your compliance delivery. Treat it as a strong first draft, not the answer.

If you build with the Yocto Project, its licence compliance guide documents the archiver class. In the local.conf file of your build directory:

INHERIT += "archiver"
ARCHIVER_MODE[src] = "original"

During the image build, the source of every recipe that deploys packages to the image is placed under tmp/deploy/sources/, sorted by each recipe's LICENSE, and licence texts land under tmp/deploy/licenses/. The same guide describes the SPDX output, which records component versions and patch information. It also notes that the SPDX output does not, for now, cover sharing the build system and layer sources, which you still need for a complete release. Check the variable names against the Yocto manual for your release, since classes and defaults change between releases.

Step 2: cross check against the shipped image, not just the build plan

Build manifests describe what you meant to ship. Check what you actually shipped by unpacking a copy of the released image on your workstation. Work on a copy of the image file, never on a mounted production device.

mkdir -p /tmp/fw-review && cd /tmp/fw-review
cp /path/to/release/rootfs.squashfs .
unsquashfs -d rootfs rootfs.squashfs
# kernel version and the configuration it was built with, if embedded
strings /path/to/release/zImage | grep -m1 "Linux version"
# BusyBox and other common GPL components
strings rootfs/bin/busybox | grep -m1 "BusyBox v"
# kernel modules and the licence each declares
find rootfs/lib/modules -name '*.ko' -exec modinfo -F license {} \; | sort | uniq -c

Any component that appears here but not in the manifest from step 1 is a gap: something was copied into the image outside the package system, which is exactly where prebuilt vendor binaries and forgotten patches hide.

Step 3: record licences in a machine readable form

Write the inventory down as an SBOM so the next release can be compared with this one. SPDX and CycloneDX both carry licence identifiers. With the open source CycloneDX generator you can, for example, produce an SBOM for a source tree:

npx @cyclonedx/cdxgen -o sbom.cdx.json .

Use SPDX licence identifiers such as GPL-2.0-only, GPL-2.0-or-later, LGPL-2.1-only and GPL-3.0-or-later rather than free text, so tools and humans can tell "only" from "or later".

Step 4: find or write the source offer

Look where a buyer would look: the printed manual, the device's settings screen ("open source licences" or "legal notices"), the vendor's support site, and inside the image itself (/usr/share/doc, /etc/licenses or similar). For each GPL and LGPL component, confirm that you either ship the source with the product or carry a written offer that names how to request it, is valid for at least three years and charges no more than the cost of distribution.

Step 5: assemble the release

A complete corresponding source release for an embedded image usually contains:

• the exact source archives for every GPL and LGPL package at the shipped versions;
• every patch you applied, in the order you applied it;
• the kernel .config and any device tree sources;
• the build system configuration (Buildroot .config and defconfig, or Yocto layers, local.conf and bblayers.conf) and toolchain details;
• the scripts used to control compilation and installation: the image packing scripts, partition layout files and the flashing or update tool your product uses;
• for GPLv3 components in a consumer product, the Installation Information needed to install a modified build, including any keys or procedures required by a locked bootloader;
• for LGPLv2.1 libraries linked into proprietary programs, what users need to relink;
• the licence texts and a README that explains how to build.

Step 6: prove it rebuilds

The test that matters is whether someone outside your team can rebuild the GPL parts from the release. Do it yourself in a clean container with no access to your internal network:

docker run --rm -it --network none -v "$PWD/ccs:/ccs:ro" -v "$PWD/out:/out" debian:12 bash
# inside the container: unpack /ccs, follow your README, write results to /out

Compare the rebuilt kernel and BusyBox binaries with the ones in the shipped image. Exact matches are ideal (and are what the Reproducible Builds project works toward); where builds embed timestamps or paths, document the differences and why they do not change behaviour.

Step 7: test installation on a spare device

If your product uses GPLv3 software, or if you want to meet the GPLv2 "installation scripts" language in the way Conservancy reads it, install your rebuilt image on a spare development unit using only what is in the release. This step overwrites the device's firmware.

Warning: flashing replaces the firmware on the target device. Use a spare unit, confirm the device path or serial port before every write, and keep a known good image to restore.

# confirm the target before writing; for a USB serial flasher, list devices first
ls -l /dev/serial/by-id/
# then use your product's documented update tool, pointed explicitly at that device

Step 8: publish and keep it published

Publish the release where your written offer says it will be, keep it available for at least three years after the last shipment of that version, and repeat steps 1 to 7 for every firmware update. A GPL obligation attaches to each version you distribute, not just the first.

How do Conservancy, the Linux Foundation, the Apache Software Foundation and the Eclipse Foundation compare?

The four organisations are often mentioned together, but they are built for different purposes. This table compares structure, not quality; our explainers on the Eclipse Foundation and the Open Source Initiative cover two of the neighbours in more depth.

The comparison shows why an embedded product team deals with Conservancy and the Linux Foundation for different reasons. The Linux Foundation is where many companies fund and govern shared infrastructure. Conservancy is where several kernel copyright holders have pooled their enforcement rights, and where Git, BusyBox and U-Boot keep their legal home. The Apache and Eclipse foundations host projects under permissive or weak copyleft licences that do not carry GPL style source obligations for devices, though they still require notices and attribution.

Where Safeguard fits

The fit here is indirect, and we will keep it narrow. Conservancy is a legal and governance organisation, and GPL compliance is a legal obligation that no security platform resolves for you. What Safeguard does cover is the inventory underneath both. It scans repositories, container images and SBOM files (safeguard scan --dir ., --image <name>, --sbom <file>), records the components and versions it finds, shows which projects contain a given component and version, and analyses licences for those components: it parses SPDX licence expressions, classifies licences as permissive, weak copyleft, strong copyleft or network copyleft, and can generate NOTICE and attribution files. Policies and gates evaluated in the platform can flag a licence your organisation wants reviewed before release. That gives a legal or compliance team a starting list. It does not produce complete corresponding source, decide whether a component is a derivative work, interpret a licence, unpack firmware images or test installation on a device. Those stay with your engineers and your counsel, and with the build system steps above.

Common mistakes

• Publishing the upstream tarball instead of your source. The GPL asks for the source of the binary you shipped, with your patches and configuration. An unmodified upstream release is almost never that.
• Forgetting the scripts. GPLv2 names "the scripts used to control compilation and installation of the executable". Image packing scripts, partition layouts and update tools are part of the obligation, and they are what Conservancy's enforcement and the Vizio case focus on.
• Letting the written offer expire or break. An offer must stay valid for at least three years, and the email address or web page it points to must still work. Offers that point at a dead support mailbox are a common failure.
• Treating "GPL-2.0" as one licence. "Only" and "or later" are different grants. Record SPDX identifiers precisely; it changes whether GPLv3 terms can ever apply.
• Checking the build plan, not the image. Prebuilt binaries copied in by a board support package, a chip vendor's kernel tree or a last minute hotfix may never appear in the package manifest.
• Ignoring LGPL relinking. Static linking of an LGPL library into a proprietary program without providing relinkable objects is a classic, avoidable violation.
• Reading the December 2025 ruling as "no installation obligations". The order addressed a narrow question about keeping the TV fully working after modification. GPLv2's text on installation scripts and GPLv3's Installation Information rule are unchanged.
• Assuming a fiscal sponsor reviews code. Conservancy membership tells you who holds a project's assets and who may enforce its licence. It is not a security review or a release guarantee; each project's own maintainers own that.
• Waiting for a demand letter. Under GPLv2 your rights terminate at the moment of violation. Fixing it before anyone writes to you is cheaper than fixing it after.

FAQ

Is Software Freedom Conservancy a charity?

Yes. It is a New York nonprofit corporation and a US 501(c)(3) charity, and it publishes its Form 990 filings and auditor's reports on its transparency page.

When was Software Freedom Conservancy founded?

Its launch was announced on 3 April 2006 and New York granted its certificate of incorporation on 7 April 2006.

What projects are part of Software Freedom Conservancy?

The current projects page lists 44 entries on 24 October 2026, including Git, BusyBox, coreboot, OpenWrt, QEMU, Samba, U-Boot and Wine. Check the live page, since projects join and leave.

What does a fiscal sponsor do for an open source project?

It lets a project operate under an existing charity's legal and tax status: taking donations, holding trademarks and signing contracts, while the project's leaders keep technical control. Conservancy charges new members 10% of the revenue it processes for them.

Does Software Freedom Conservancy sue companies for GPL violations?

Rarely. Its principles make lawsuits a last resort, and its compliance page counts past suits against more than a dozen defendants against hundreds of non litigation actions. It is currently suing Vizio.

What is the Vizio lawsuit about?

Conservancy bought Vizio TVs running GPL and LGPL software, was refused the source and sued in October 2021 as a third party beneficiary of the licences. As of its 27 February 2026 update the case is ongoing, with trial listed for late 2026.

Can a consumer enforce the GPL?

That is the open question in the Vizio case. The court let the contract claim proceed, but a December 2025 tentative ruling leaned against the third party beneficiary grounds, mostly on procedure according to Conservancy. There is no final answer yet.

What is "complete corresponding source"?

The source needed to produce the binary you actually distributed, including your changes and "the scripts used to control compilation and installation of the executable". GPLv3 adds Installation Information for consumer devices.

How long must a GPL written offer stay valid?

At least three years under GPLv2. Under GPLv3 it is at least three years and as long as you offer spare parts or customer support for that product model.

What is Outreachy and how is it related to Conservancy?

A paid, remote open source internship programme for people facing under representation or discrimination in tech. It moved from the GNOME Foundation to Conservancy in February 2015 and is now a Conservancy initiative.

A GPL source release only works if you know exactly which components and versions went into each build, and that same inventory is what you need when a vulnerability lands in BusyBox, U-Boot, libssh or the kernel inside your product. Firmware is assembled from open source packages like any application, so the gap between an upstream fix and that fix reaching your shipped images is still yours to close.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. You ask it to fix a lodash CVE in a repository; it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval and pushes nothing. The same approval driven flow applies when the component you are upgrading is a library inside your firmware build, and when you finish it ends with /scan . to inventory the tree again.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with a device code and scans from the terminal. That is how you would inventory a board support package or an image build tree that you do not want to send anywhere before you have looked at it.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which Safeguard tools Claude may use. A compliance lead could use the same connection to ask which projects contain a given GPL component and version, while the licence interpretation itself stays with counsel.

Click through it at your own pace, or open it full screen.

To try it on your own code, download Safeguard and follow the CLI documentation.

Quick check

Sources

• Software Freedom Conservancy: home page
• Software Freedom Conservancy: About
• Software Freedom Conservancy: Board of Directors
• Software Freedom Conservancy: Staff
• Software Freedom Conservancy: Transparency (Form 990, CHAR500, incorporation documents)
• Software Freedom Conservancy: Current member projects
• Software Freedom Conservancy: Member project services
• Software Freedom Conservancy: Applying to join
• Software Freedom Conservancy: Copyleft compliance projects
• Software Freedom Conservancy: The Principles of Community-Oriented GPL Enforcement
• Software Freedom Conservancy: SFC v. Vizio case page
• Software Freedom Conservancy: lawsuit announcement (19 October 2021)
• Orange County Superior Court minute order denying Vizio's motion for summary judgment (29 December 2023)
• Orange County Superior Court minute order on SFC's first motion for summary adjudication (26 March 2024)
• Tentative rulings of 4 December 2025, with SFC's cover note
• Software Freedom Conservancy: Judge Issues Tentative Ruling in Favor of SFC (4 December 2025)
• Orange County Superior Court minute order of 23 December 2025, with SFC's statement of 24 December 2025
• Software Freedom Conservancy blog: Some Unfortunate Delays in our Struggle for Copyleft Justice (26 January 2026)
• Software Freedom Conservancy: SFLC Helps Launch Conservancy (3 April 2006)
• Software Freedom Conservancy: Outreach Program to Join Conservancy from GNOME; Program Renames to Outreachy (4 February 2015)
• Software Freedom Conservancy: U-Boot has joined Software Freedom Conservancy (29 December 2025)
• Software Freedom Conservancy: News index
• Software Freedom Conservancy: News 2025 (Liblouis, U-Boot and Vizio announcements)
• Outreachy
• GNU General Public License version 2
• GNU General Public License version 3
• GNU Lesser General Public License version 2.1
• Copyleft and the GNU General Public License: A Comprehensive Tutorial and Guide
• Linux kernel documentation: Linux Kernel Enforcement Statement
• Buildroot user manual (legal-info)
• Yocto Project Development Tasks Manual: Working With Licenses
• npm registry metadata for @cyclonedx/cdxgen
• Linux Foundation: About
• Apache Software Foundation: About the ASF
• Apache Software Foundation: How the ASF works
• Eclipse Foundation: About
• Eclipse Foundation: Governance documents
• Eclipse Foundation Project Handbook

Last reviewed: 24 October 2026. SFC v. Vizio is ongoing and Conservancy's member list changes; check the case page and the current projects page before relying on a specific detail.