Blog | Community | opensource

We killed our own CLA. Here’s why that’s a good thing.

We're retiring the ownCloud CLA and adopting the Developer Certificate of Origin. Here's the reasoning and why contributors should take notice.
We killed our own CLA. Here’s why that’s a good thing.

The old ownCloud Contributor License Agreement was aggressive.
Read the text:
“You hereby transfer to ownCloud your entire right, title, and interest (including all your rights under copyright) in the changes and enhancements to the Contribution.”
Full copyright assignment. You write the code, ownCloud GmbH owns it.

The CLA existed for a business reason: dual-licensing. AGPL for community, proprietary for enterprise. That model had its time, but is no longer necessary for where the project is going. The power asymmetry the CLA created made contributors uncomfortable, and they were right to be.

As of May 5th, 2026, the CLA will be retired. We’re replacing it with the Developer Certificate of Origin (DCO):

  • Per-commit attestation of origin.
  • You add a Signed-off-by line.
  • You keep your copyright.

The DCO was invented by the Linux kernel project in 2004. It’s the standard for Apache 2.0 projects, which ownCloud Infinite Scale (oCIS), our Go-based successor to the PHP server (ownCloud Classic), is.
To read more about it: https://github.com/apps/dco

Previously signed CLAs?
Still valid. No action needed. New contributions just need DCO sign-off.
Corporate contributor?
The DCO’s per-commit nature makes legal approval easier than a blanket CLA.
Were you holding back because the CLA felt extractive?
That barrier is gone.

One important and interesting nuance: the old CLA is what makes our planned legally possible. Because ownCloud GmbH owns the copyright on CLA-covered contributions, we can change licenses where we hold 100% copyright.
It is interesting that the thing that we are retiring is the what gave us the ability to do so in the first place.
With the DCO, future contributors retain their . We’re making a one-way door decision.
Deliberately.

DCO enforcement rolls out repo by repo, starting with oCIS. The new Open Source Program Office (OSPO) decides the timing.
The power asymmetry is gone, and if you’ve been searching for a project to use and contribute to, this is the invitation/time and this is the project.

Tomorrow: PHP 8.3 for Classic

This is part 3 of this blog post series.
See the earlier posts:

  1. A (re)-introduction to the ownCloud community.
  2. What happens when you fork twice, get acquired, and keep shipping anyway

About the Author

David Walter is Vice President, Open Source Program Office & Special Projects at Kiteworks, where he stewards the open source projects and drives digital sovereignty strategy globally. He’s been part of the ownCloud ecosystem since 2014, holding roles from community contributor to Chief eXperience Officer before taking on large-scale government deployments and open source governance. At heart, he’s still a script kid who happens to translate between business, community, and engineering. He holds an B.A and an LL.M., is based in Berlin, and volunteers with Germany’s Federal Agency for Technical Relief (THW).

David Walter

April 23, 2026

Read now:

Kiteworks Launches the ownCloud Open Source Program Office — Formalizing Governance, Retiring the CLA, and Committing to Sovereign, Open, Federated File Sharing for the Enterprise

Kiteworks Launches the ownCloud Open Source Program Office — Formalizing Governance, Retiring the CLA, and Committing to Sovereign, Open, Federated File Sharing for the Enterprise

The relaunch of the original open-source, self-hosted File Sync and Share platform brings a published governance charter, relicensing to Apache 2.0, a DCO-based contribution model, and an AI-assisted contribution policy—together with new releases of ownCloud Infinite Scale, ownCloud Classic on PHP 8.3, and a new MCP Server.

read more