FOSSY 2026 ran August 6-9 at the University of British Columbia in Vancouver. It's the Software Freedom Conservancy's fourth annual community conference — three days of talks across thirteen tracks, plus an unconference day. The tracks ranged from Linux kernel internals to right-to-repair to XMPP to AI ethics, but the through-line was the same one we build around: who controls the infrastructure, and what happens when that control is abused.

Three things from this year's program matter directly to the work of building sovereign community infrastructure.

SFC vs Bambu Lab: AGPLv3 Enforcement in Practice

Bradley Kühn, Denver Gingerich, and Karen Sandler from the Software Freedom Conservancy presented "Anatomy of a 3D Printer AGPLv3 violation(s)" — a detailed walkthrough of SFC's enforcement action against Bambu Lab.

Bambu Studio, the slicing software that ships with Bambu Lab's 3D printers, is built on PrusaSlicer, which is built on Slic3r. Both predecessors are AGPLv3. Every derivative carries that license. Bambu Lab has been shipping libbambu_networking — the library that handles all communication between the slicer and Bambu's cloud — as a closed-source binary alongside the AGPLv3 code. Their own README has acknowledged this for years. AGPLv3 Section 6 requires that any code distributed alongside AGPLv3 software be available under the same terms. Bambu never complied.

The second violation is worse. A developer named Paweł Jarczak forked OrcaSlicer to add Bambu printer compatibility by studying the incomplete Bambu Studio source code. He didn't touch the proprietary library. Bambu sent him a cease-and-desist, arguing their terms of service take precedence over the AGPLv3 license grant. The AGPLv3 explicitly prohibits adding restrictions on the rights it grants. Going after someone for exercising rights the license gives them is itself a violation.

SFC's response is the baltobu project — "Bringing Affero Licensed Things (On)to Bambu Users." Three repositories on SFC's Forgejo instance:

  • reverse-networking: reverse-engineering libbambu_networking to produce a free replacement. SFC's position: the binary is covered by AGPLv3, so anyone holding a copy has the right to examine and reverse-engineer it.
  • orca-slicer-for-bambu: a soft fork of OrcaSlicer compatible with Bambu printers, designed to replace Bambu Studio for users who want out of the walled garden.
  • viscose: a fork of Bambu Studio itself, preserving everything Bambu publishes in case it disappears, with a long-term goal of a version that respects user freedom.

Why This Matters for Community Infrastructure

AGPLv3 is the license we use for kryptonwolf.com. It's the license we recommend for community infrastructure that runs as a network service — Nextcloud, Matrix, Gitea. The Bambu Lab case is a concrete demonstration of two things:

The AGPLv3 works. A manufacturer tried to keep a critical component proprietary while shipping AGPLv3 code. The community caught it. The enforcement mechanism exists, and SFC is using it. The license isn't theoretical — it's a tool that produces real outcomes.

Enforcement requires institutional capacity. Individual developers can't fund a legal action against a hardware company. SFC can. This is the argument for sustaining the organizations that enforce copyleft. The license is the law; SFC is the police. Both are needed.

For communities deploying AGPLv3 software: when a vendor violates the license, you have recourse. Not through a DMCA takedown to a hosting provider — through an organization that will reverse-engineer the proprietary component and ship a free replacement. That's a different enforcement model than most people associate with open source licenses, and it's more effective.

Euro-Office: Forking as Trust Recovery

Edward Ly from Nextcloud presented "Art of the Fork: Reclaiming Community Trust," covering the Euro-Office fork of OnlyOffice.

On March 27, 2026, a coalition including Nextcloud, IONOS, and Proton announced Euro-Office — an AGPLv3-licensed fork of OnlyOffice. The stated reasons were geopolitical and technical: OnlyOffice is officially based in Latvia but its development team is described as mostly located in Russia, raising trust concerns given current tensions. The Euro-Office team also claims that contributing upstream is "impossible or heavily discouraged" and that build instructions are "unreliable, outdated or simply broken." OnlyOffice disputes both characterizations.

OnlyOffice publicly challenged the fork's legality. OnlyOffice's code includes AGPLv3 with additional Section 7 conditions. OnlyOffice argues these conditions are inseparable from the license grant. The Euro-Office team has not publicly responded to the legal claim. The dispute is unresolved.

The Licensing Question

AGPLv3 Section 7 allows additional conditions to be added by the licensor. The question is whether a fork can strip those conditions and distribute under "pure" AGPLv3. OnlyOffice says no — the conditions are part of the license grant, and removing them means you don't have a license. Euro-Office's position, by implication, is that the additional conditions are severable.

This is a real legal question without a clear answer. The practical takeaway for communities: when you fork AGPLv3 software with Section 7 additions, understand what those additions require before you assume you can strip them. Read the license. Talk to a lawyer if the stakes are high. The freedom AGPLv3 grants is broad but not unlimited, and the boundaries are being tested right now in public.

Why Forking Matters

Rich Bowen's talk "Plan to fork (So you don't have to fork)" made the complementary point. Writing a detailed fork plan has two benefits: you're prepared if the worst happens, and the exercise of planning a fork forces you to confront what makes your upstream healthy or fragile. It makes you a better upstream participant.

The Euro-Office fork is what happens when the planning phase ends and the fork begins. The talk framed it not as a failure of open source but as a feature — the AGPLv3 gives the community the right to walk away when vendor stewardship fails. The fork is the enforcement mechanism for community trust. You don't need a lawyer to fork AGPLv3 code. You need a community willing to maintain it.

Peter Farkas (formerly FerretDB, now Percona) made the same point more aggressively in "Enterprises Play Dirty" — cataloguing how vendors from Red Hat to MongoDB adopt tactics to protect market power, limit competition, and restrict user freedom while nominally remaining "open source." The pattern: open-source the code, close the cloud service, relicense to prevent competition, use trademark and contributor agreements to maintain control. The fork is the community's counter-move.

For community infrastructure: when you deploy an AGPLv3 project, you have an exit. If the vendor goes hostile, the community can fork. This is not theoretical — it happened this year, with real companies, real legal disputes, and real code on GitHub. The AGPLv3 is the insurance policy. Euro-Office is the claim being filed.

Off-Grid Inter-Neighborhood Networks

Vagrant Cascadian — Debian Developer, Guix contributor, Reproducible Builds advocate — gave a talk that reframed what federation can mean.

The premise: what if we built a federated network that was intentionally not connected to the internet? An off-line-first, off-grid network where limited range and high locality are features, not bugs. Where slow and sporadic connectivity between neighborhoods is a design intention. Where information can be delivered by bicycle.

The existing FOSS tools to build this already exist. The talk was about putting the pieces together: store-and-forward messaging protocols that don't require real-time connectivity. Mesh networking tools that work over LoRa, Bluetooth, or Wi-Fi without an upstream internet connection. Federated protocols (XMPP, Matrix) that can run over any transport, including physical media carried between locations.

This is community infrastructure at its most literal. A network that connects neighbors without connecting to a data center in Virginia. A network where the physical constraints — range, bandwidth, latency — are the design parameters, not problems to be solved by paying for a faster uplink.

For the communities we work with — rural areas with unreliable internet, communities that want communication infrastructure independent of telecom providers, organizations that need information flow without external dependencies — this is the architecture. Not a backup plan for when the internet goes down. A primary network designed for the community's actual constraints.

The tools are FOSS. The protocols are open. The transport is whatever you have. The internet is not required.

Sustaining Critical Infrastructure: The PHP Foundation

Elizabeth Barron, Executive Director of the PHP Foundation, gave a talk on sustaining critical digital infrastructure without a single owner.

PHP powers over 34 million websites. It's a community-owned language with no single corporate backer. The PHP Foundation was created to fund contributors and maintain the ecosystem without taking over governance. The model is different from traditional open source foundations — the Foundation funds the work but doesn't control the project. The community retains governance.

This matters because it's the same structural question every community infrastructure project faces. Who pays for the maintenance? Who decides the roadmap? How do you fund the boring, critical work — security patches, dependency updates, regression testing — without giving a corporation control over the project?

The PHP Foundation's answer: fund the people, not the project. Pay contributors to work on PHP. Let the community decide what they work on. The Foundation is a funding mechanism, not a governance body. This is a model community infrastructure projects can replicate: a cooperative or non-profit that pays for labor without centralizing control.

UnifiedPush: Killing the Push Notification Monopoly

Daniel Gultsch — project lead for Conversions (XMPP client), chair of the XMPP Standards Foundation council — presented on UnifiedPush.

The problem: every Android app that wants push notifications uses Firebase Cloud Messaging (FCM). Even if you run microG to remove Google's proprietary software from your phone, the push notifications still go through Google's servers. There is no FOSS alternative that most apps support.

UnifiedPush is a framework for decentralized push notifications. Pluggable transport — WebSockets, SSE, XMPP. You can self-host the push server. The talk focused on why XMPP is particularly well-suited as a push protocol: it's already designed for store-and-forward, it handles presence and delivery semantics, and it federates.

Apps already supporting UnifiedPush include Tusky (Mastodon client), DAVx5 (CalDAV/CardDAV sync), Element (Matrix client), Fedilab, and Conversations itself. The ecosystem is real.

For community infrastructure: if you're running a Matrix homeserver, a Nextcloud instance, or a Mastodon server for your community, your users' push notifications go through Google. UnifiedPush lets you run your own push server, routing notifications through infrastructure you control. It's the last mile of sovereignty for mobile — the piece that keeps Google out of the notification path without sacrificing the user experience of push.

The Pattern

FOSSY 2026 surfaced a consistent pattern across talks: the tools for community-owned infrastructure exist, the licenses that protect community ownership work, and the enforcement mechanisms for those licenses are being exercised. What's missing is deployment and operation at the community scale.

The AGPLv3 is being enforced against a hardware manufacturer. A productivity suite was forked under AGPLv3 by a European coalition for sovereignty reasons. Push notifications can be decentralized through self-hosted XMPP. Off-grid networks can be built with existing FOSS tools. Critical infrastructure (PHP) is being sustained through a foundation model that funds labor without centralizing control.

The pieces are on the table. The work is putting them together in specific communities — fire halls, town offices, rural neighborhoods, small organizations — and operating them over time. That's the work this site is about.

FOSSY 2026 confirmed that the FOSS ecosystem is producing the right tools, the right licenses, and the right enforcement. The next step is deployment. The communities that need this infrastructure don't need new tools. They need someone to install, configure, and maintain the ones that exist. That's the gap. That's the work.