Open Source in 2026: The Fork Wars Are Getting Ugly

• Project: Hermes IDE | GitHub
• Author: gabrielanhaia

---

Something is breaking in open source. Not the code. The social contracts.

The open-source world isn't collapsing from lack of funding or contributor burnout (though both are real). It's fracturing because organizations that built empires on community-written software decided the original deal doesn't work for them anymore. Forks are multiplying. Licenses are mutating. Lawyers are circling.

The volunteer maintainers who actually wrote most of this code? They're stuck in the crossfire.

The LibreOffice Purge

The Document Foundation, the nonprofit behind LibreOffice, kicked all Collabora staff out of its governance and development process. Over 30 developers, gone. Some of these people had been contributing since the project forked from OpenOffice back in 2010.

TDF said it was about conflicts of interest. Collabora, as a commercial company building products on top of LibreOffice (especially Collabora Online), had stacked up outsized influence inside the foundation. TDF's argument: Collabora's commercial priorities were steering the project away from what the community actually needed.

That's a legitimate governance concern. The execution, though, was a chainsaw where a scalpel was needed.

Thirty-plus developers don't just represent commit counts. They carry the kind of institutional knowledge and review muscle that takes years to build. LibreOffice was already hemorrhaging contributors. Gutting an entire company's worth of experienced developers doesn't fix governance. It creates a development vacuum.

Collabora keeps shipping Collabora Online. The code's under the MPL, so they can build whatever they want. But the symbiotic relationship that made both projects stronger? Dead. And LibreOffice is thinner for it.

The real casualties aren't either organization. They're the independent volunteers who now have fewer experienced reviewers for their patches and a project where political alignment matters more than code quality.

Euro-Office: When Digital Sovereignty Meets License Law

While LibreOffice was eating itself, a different fight was brewing in the office suite space.

Nextcloud and IONOS (Germany's largest cloud and hosting provider) announced Euro-Office, a fork of OnlyOffice targeting EU digital sovereignty requirements. The pitch was clean: a fully European-controlled office suite that public institutions can deploy without routing through American or Chinese infrastructure.

EU governments have been pushing hard for digital sovereignty, and public agencies across Europe want office solutions that don't depend on Microsoft 365 or Google Workspace. OnlyOffice, with its solid real-time collaboration features, was an obvious foundation.

OnlyOffice disagreed. Strongly.

The OnlyOffice team fired back claiming Euro-Office violates their AGPL licensing terms. The core dispute boils down to a question the AGPL was always going to produce: what exactly does copyleft require when someone forks a project and wraps a commercial product around it? OnlyOffice says Euro-Office isn't meeting its obligations. Euro-Office says they're fully compliant.

Here's what an AGPL license header looks like in practice, and what Euro-Office would need to maintain in every modified file:

// Euro-Office - Modified from OnlyOffice Document Server
// Copyright (C) 2024-2026 Nextcloud GmbH & IONOS SE
//
// This program is free software: you can redistribute it and/or modify
// it under the terms of the GNU Affero General Public License as published by
// the Free Software Foundation, either version 3 of the License, or
// (at your option) any later version.
//
// Based on OnlyOffice Document Server
// Copyright (C) Ascensio System SIA
// Licensed under GNU AGPL v3

That header is the easy part. The hard part is AGPL's Section 13, which requires that anyone interacting with the software over a network gets access to the corresponding source code. For a SaaS-deployed office suite, "corresponding source" becomes a legal argument, not a technical one.

Here's the problem nobody in Brussels wants to hear: digital sovereignty and open-source licensing clash more often than European policymakers admit. Forking a project to escape one dependency can create legal entanglements that are just as sticky.

The EU can't build digital sovereignty on a foundation of license litigation. That's not sovereignty. That's dependency with extra lawyers.

HashiCorp vs. OpenTofu: IBM's Legal Machine Enters the Chat

The longest-running license war in the current cycle belongs to HashiCorp's Terraform and its community fork, OpenTofu.

Quick recap for anyone who's been blissfully uninvolved: in August 2023, HashiCorp switched Terraform from the Mozilla Public License 2.0 to the Business Source License 1.1. The BSL isn't open source by any definition. It restricts commercial use by competitors. The community response was immediate. Within weeks, OpenTofu launched under the Linux Foundation, forking the last MPL-licensed version of Terraform.

That was nearly three years ago. The legal pressure hasn't eased. It's gotten worse.

HashiCorp (now owned by IBM after a $6.4 billion acquisition) has continued pursuing legal claims against OpenTofu contributors, alleging that post-fork commits incorporated proprietary HashiCorp code. OpenTofu denies this categorically, pointing to their clean-room development processes.

IBM buying HashiCorp was supposed to calm things down. It did the opposite. A startup can bluff about lawsuits. IBM doesn't bluff. IBM has a legal department the size of a mid-tier law firm and a decades-long track record of patent warfare.

The chilling effect is measurable. Some companies have quietly stopped contributing to OpenTofu, not because they think IBM is right, but because they can't afford to find out in court. That's the point. You don't need to win a lawsuit to kill a fork. You just need to make contributing feel risky.

Meanwhile, the Terraform ecosystem is splitting at the seams. Today the syntax still looks identical:

# Terraform (BSL 1.1 - HashiCorp/IBM)
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

# OpenTofu (MPL 2.0 - Linux Foundation)
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"  # Still works, for now
      version = "~> 5.0"
    }
  }
}

Same HCL, same provider source. But OpenTofu has started adding features Terraform doesn't have (client-side state encryption, for one), and Terraform has added features OpenTofu can't touch without risking legal action. Provider authors now maintain compatibility matrices. Two years in, this isn't a fork. It's a schism.

Redis: Three License Changes and Counting

Redis Labs (now just "Redis") pulled a similar move in March 2024, switching from BSD to a dual license under the Redis Source Available License and the Server Side Public License. Neither qualifies as open source under the OSI definition. The message matched HashiCorp's: cloud providers (read: AWS) were selling managed Redis without contributing back, and Redis the company was done subsidizing it.

The response followed the now-standard playbook: Valkey launched as a fork under the Linux Foundation, backed by AWS, Google Cloud, Oracle, and Ericsson.

What happened next with Redis is the interesting part. After the initial license change scared away too many users, Redis pivoted again, adding AGPLv3 as an option alongside their proprietary licenses. Elastic did the same thing with Elasticsearch after its own fork drama spawned OpenSearch.

This "return to AGPL" maneuver is telling. These companies realized that going fully proprietary torched too much goodwill. AGPL gives them the open-source label back while still making life painful for cloud providers who don't want to open-source their management layers. It's a compromise. It's also an admission that the initial license change overshot.

Valkey, meanwhile, keeps growing. AWS ships it in ElastiCache. It's not a protest fork anymore. It's production infrastructure that major companies bet their caching layers on.

Auditing Your Own Exposure

Here's the practical question every team should be asking: which of your dependencies have changed licenses, and which ones might?

Most developers don't check. They npm install or go get and move on. That's a risk now.

For Node.js projects, you can audit every license in your dependency tree with one command:

# Install license-checker globally
npm install -g license-checker

# Run against your project
license-checker --summary

# Want to flag specific risky licenses? Filter for them:
license-checker --failOn "SSPL;BSL-1.1;Elastic-2.0;RSALv2"

# For a CSV you can hand to your legal team:
license-checker --csv --out licenses.csv

For Go projects:

# Install go-licenses from Google
go install github.com/google/go-licenses@latest

# Check all dependencies
go-licenses report ./... 2>/dev/null | sort

# Look for anything that isn't MIT/BSD/Apache:
go-licenses report ./... 2>/dev/null | grep -v -E "MIT|BSD|Apache"

Python developers can use pip-licenses:

pip install pip-licenses
pip-licenses --format=table --with-urls

Run these in CI. Seriously. A dependency that was BSD last month might not be BSD today. License changes in transitive dependencies are the kind of thing that bites you six months later when legal does an audit before an acquisition.

Pro tip: Pin your dependency versions AND periodically diff the license files in your lock file. A version bump that changes a license string is a red flag worth investigating before it ships.

The Playbook Nobody Wants to Admit Exists

Here's what connects every one of these stories. The companies that built the biggest businesses on open source are systematically pulling up the ladder behind them.

The pattern:

1. Release under a permissive license (MIT, BSD, Apache, MPL)
2. Build a community. Attract contributors. Let the ecosystem grow
3. Wait until cloud providers start offering your software as a service
4. Change the license to something restrictive
5. Claim you're "protecting the community" while protecting revenue

Step 5 is the dishonest part. These license changes don't protect community contributors. They protect the company's business model. The people who wrote code under the original license didn't sign up for their work to become proprietary.

And the AGPL pivot that comes after? That's just step 5 with better PR. AGPL is a real open-source license, yes. But switching to it retroactively changes the social contract for everyone who contributed under a permissive license. Those contributors chose BSD or MIT for a reason. AGPL is a fundamentally different agreement.

What Happens to the Volunteers

The people getting the worst deal aren't companies. They're individual contributors who maintain packages, review PRs, fix bugs, and write documentation for free.

When a project forks, volunteer maintainers have to pick a side. Terraform or OpenTofu? Redis or Valkey? LibreOffice under TDF's new governance, or wherever Collabora's developers land next?

Each choice carries career weight and community relationships -- and sometimes genuine legal risk. Most volunteers didn't sign up for politics. They signed up to write good software. But writing good software in the open-source world of 2026 means dodging license changes, corporate forks, governance coups, and legal threats.

The burnout problem that open source has been hand-wringing about for a decade? License wars accelerate it. Nothing kills a maintainer's motivation faster than watching their contributions become ammunition in a corporate legal dispute they had no part in starting.

Where This Ends Up

If you're an optimist, the fork ecosystem works. When a company rug-pulls a license, the community forks, finds new governance under the Linux Foundation or Apache Foundation, and keeps building. OpenTofu exists. Valkey exists. The code survives the corporate betrayal.

But every fork also fragments the ecosystem. Two versions of Terraform means doubled documentation burden, doubled provider maintenance, doubled confusion for anyone new to infrastructure-as-code. And the legal disputes make potential contributors think twice about participating at all.

Reality sits between those poles. Open source isn't dying. But the era where a permissive license meant a permanent social contract? That's over. Gone. Buried under a pile of BSL conversions and AGPL pivots.

Companies running open source in production need to treat license risk like vendor risk. What happens if the license changes tomorrow? Where's the fork? Who's backing it? How fast can you migrate? These aren't hypothetical questions anymore. They're operational concerns with real timelines.

And for anyone starting a new open-source project in 2026, the license decision carries more weight than it ever has. Permissive licenses attract contributors but enable rug-pulls. Copyleft licenses provide protection but scare away corporate adoption. There's no safe choice. Only trade-offs with different failure modes.

The Bottom Line

Open source in 2026 isn't broken. But it's not the unified movement it spent two decades pretending to be. What's left is a collection of competing interests held together by licenses that turned out to be more ambiguous -- and more weaponizable -- than anyone who wrote them ever intended.

More forks are coming. More license changes too. And the lawsuits won't stop.

Open source will survive this. It always does. The real question is whether the people who actually write the code will stick around long enough to maintain it while corporations fight over who gets to profit from their work.

Nobody's solving that part. And based on 2026 so far, nobody's even trying.

What's your read on this? Has a license change burned your team yet? Have you switched from Terraform to OpenTofu, or from Redis to Valkey? Drop your story below.