Donating your project to a foundation: what it actually means for risk and compliance

We don't write about the CRA because we have it figured out. We write because we're in the middle of it, and writing is how we think. What we know is evolving, and a lot of that evolution happens through genuine conversation with people who are closer to the detail than any one of us could be alone: in Giant Swarm and Friends, in NEXT, in the conversations those tend to start.

The first piece on the CRA and open source touched something. The question that kept coming back in the conversations afterward wasn't about compliance timelines or stewardship categories. It was more specific: if we donate one of our internal tools to a foundation rather than running it ourselves, what does that actually do to our risk and compliance position?

It's a question worth sitting with. Because the honest answer is that it restructures your risk. It doesn't eliminate it. Some things genuinely get better. Some things stay exactly the same. A few things quietly get harder. And which of those dominates depends almost entirely on what you do after the donation.

What the CRA actually says first

Before getting into the trade-offs, one piece of framing that matters.

The CRA distinguishes between manufacturers (companies putting a product with digital elements on the EU market) and open source stewards, a category introduced in the final text to cover foundations and community projects. Stewards have real obligations, but lighter ones: facilitate vulnerability reporting, take security seriously, cooperate with authorities. The heavy lifting (SBOM documentation, conformity assessments, active vulnerability response) sits with manufacturers.

Donate your tool to the CNCF, and that project is no longer your product in the same sense. That's a real change in your legal position and worth acknowledging.

But if you then ship that foundation project as part of something commercial, even just as a dependency, you're a manufacturer again. Not of that open source component specifically, but of the product it lives inside. Your obligation to track what's in that product, monitor CVEs against it, and respond when something goes wrong doesn't change based on where the upstream code lives.

That's the baseline. Now the three-part map.

What gets better

The legal surface area around direct ownership shrinks. You're no longer the entity responsible for the project's conformity as a standalone product. For a tool with wide distribution beyond your own use case, that matters.

Governance overhead moves to the foundation. IP disputes, trademark management, contributor license agreements: these shift to an organization with legal infrastructure built specifically for this. For a company whose core business isn't software, that's not a small thing.

The project becomes more defensible as a dependency. A well-governed foundation project with an active community, a clear CVE response process, and a documented security policy is easier to account for in an audit conversation than an internal tool you're hoping nobody examines too closely. Foundation provenance doesn't remove the question (auditors will still ask about it) but the answers are usually cleaner.

What stays the same

Your obligation to know what you're shipping. The CRA expects manufacturers to understand their supply chain. Foundation provenance helps tell that story, but it doesn't tell it for you. You still need a software bill of materials. You still need to know what version of what project is in what product.

Your obligation to respond to vulnerabilities. A well-maintained foundation project may issue patches faster than you would have internally, which is a real operational advantage. But you still need to be watching for CVEs, and you still need to apply the fixes. The foundation handles the upstream. The downstream is still yours.

The underlying question of whether you know what you're running. Not in the abstract. Not 'we use open source, so someone handles this.' But specifically. What projects, what versions, who maintains them, what the response process looks like when something goes wrong. The CRA is forcing that question into the open. Donating a project to a foundation is not an answer to it.

What gets harder

Control over security response timelines. When you owned the code, you could issue a fix on your schedule. In a foundation project with a proper disclosure process, there's a coordinated timeline — responsible disclosure windows, notification periods, coordinated release. You participate in that process, but you don't set it. Most of the time this is fine. In a crisis, when you need a patch in 48 hours and the foundation's process runs on a two-week cycle, the gap becomes operational. This is a real trade-off.

Roadmap alignment. The project's direction is now a collective decision. Your ability to push through changes that serve your specific product (security hardening that only matters to your deployment context, a configuration option that only you need) depends on your standing in the community and your ability to make the case. Sometimes that works well. Sometimes you're outvoted or deprioritized by a contributor base whose needs are different from yours.

The gap between donating and contributing. This one is specific enough to name directly. Donating is a legal and governance act: you transfer copyright or licensing rights, the project lives under foundation governance, you become one contributor among many. Contributing is ongoing work: engineers on the steering committee, active maintenance, foundation membership that reflects genuine investment rather than a logo placement.

These are not the same thing, and the gap between them is where a lot of companies are going to get into trouble. A foundation project with one company's fingerprints still all over it, and that company no longer actively maintaining it, is not a thriving open source project. It's a liability with better branding. If a CVE drops two years after you donated the code and you're still shipping it in your product, you still need to respond — and whether the foundation has the capacity to patch it quickly depends on whether you stayed involved enough to help build that capacity.

Governance complexity as culture shock. Foundation projects have processes for a reason. Those processes add overhead. If your team isn't oriented toward open community collaboration (and a lot of internal tooling teams aren't, because they've never had to be) the overhead can feel like friction. It usually is friction. Productive friction, over time. But the transition period is real, and it can slow down exactly the kind of security response work that the CRA is asking you to take seriously.

The version that doesn't work

There's a specific approach worth naming directly, because it's tempting and it's fragile.

Donating code to a foundation as a compliance maneuver, contributing nothing afterward, assuming the liability question is resolved: it probably doesn't hold up. Regulators aren't unsophisticated about corporate structure. If your product ships code that originated in your organization, lives in a foundation project your engineers still effectively control, and has your team as the primary maintainers in practice, the argument that you're merely a downstream user will face scrutiny.

The CRA's stewardship model is designed for genuine open source governance. We're still early in implementation and enforcement, so how aggressively this will be tested is an open question. But building your compliance posture on a structure that depends on regulators not looking closely is not a posture. It's a bet.

What good looks like

The companies doing this well aren't approaching it as a compliance decision first. They're approaching it as a product and community decision, with the compliance picture improving as a result.

The pattern that tends to work: real governance transfer, including copyright. Engineers who stay involved after the donation, not as owners but as active community participants. Foundation membership at a level that reflects genuine investment. A documented internal process for how the company handles vulnerabilities in the project even after it's no longer theirs to control unilaterally. And honest internal agreement about what you've actually signed up for: how you influence the roadmap through contribution rather than control, what your engineers can and can't decide on their own.

The Kubernetes graduation from Google to the CNCF is the clearest large-scale example of what genuine transfer looks like: Google didn't walk away, but it also genuinely gave up control. The project became something the whole industry could build on precisely because it stopped being Google's project in practice, not just in name. Most donations won't be at that scale, but the principle holds.

For some teams and some projects, this is clearly the right move. The code is more valuable as a shared resource than as a proprietary dependency. For others, the math doesn't add up. Running the tool yourself, with proper security processes and documentation, is less overhead than navigating foundation governance for something only you really use.

Both can be right answers. What's rarely the right answer is treating donation as a shortcut.

We'll keep thinking through this as the landscape evolves — in these posts, in Giant Swarm and Friends, and in NEXT. If you're working through the specifics of your own situation and want to think out loud, reach out. We're figuring it out alongside you.