Zitadel Licensing: Frequently Asked Questions

What did Zitadel announce?

Zitadel announced a license update from Apache 2.0 to GNU Affero General Public License (AGPL) 3.0.

Why did Zitadel change the license type?

We made this change to ensure Zitadel's long-term sustainability while maintaining our commitment to open source. The AGPL license requires that modifications to Zitadel used in service offerings be shared with the community. This protects our open-source nature and encourages contributions back to the project, creating a more vibrant ecosystem for everyone.

What happens to past contributions?

Past community contributions remain under their original licenses—the license change has no retroactive effect. These contributions continue to be governed by the terms agreed upon at the time they were made. Only the past code contributions by Zitadel staff will be relicensed to AGPL 3.0.

What happens to forks?

Existing forks remain under their original license terms and are not retroactively affected.  These independent projects can continue developing under their existing license.  However, any new work derived from AGPL-3.0-licensed components of Zitadel after the change must comply with AGPL 3.0 requirements.

What happens to users shipping Zitadel as part of their project?

Users shipping Zitadel as part of their project are not affected as long as they comply with the respective licenses.  Unmodified distributions are generally permissible. The AGPL 3.0 license allows for shipping Zitadel, but requires that modified versions or derivative works of the AGPL 3.0 components also be licensed under AGPL 3.0. Apache 2.0-licensed SDKs and tools remain under their more permissive license.

What should people who cannot use AGPL 3.0 do?

If AGPL 3.0 is incompatible with your project requirements, we offer a commercial license. This option allows for modifications and redistribution without the requirement to open-source your own code—ideal for those embedding or distributing modified versions of Zitadel within proprietary offerings. Contact us for more information about commercial licensing options.

Will Zitadel provide guidance to its users on how to comply with AGPL 3.0?

Yes.  While we cannot provide legal advice, we are committed to helping users understand and comply with the AGPL 3.0 license.  We will actively monitor the impact of this change, address concerns, and provide ongoing guidance regarding permissible uses of AGPL-3.0-licensed components.  Due to the wide range of potential use cases, we will continue updating our documentation with further guidance as needed.

Does this change relate to the CLA (Contributor License Agreement) introduction?

Yes.  We are adding the Apache Software Foundation's Contributor License Agreement (CLA) to prevent future license incompatibilities, coinciding with our relicensing efforts.  Contributors can decide whether to continue contributing under these new terms.

How does Zitadel prevent the APIs from being “viral” with the generated clients?

Zitadel's APIs are primarily gRPC-based, which could potentially cause generated client code to fall under AGPL 3.0.  To prevent this, our Protocol Buffer (proto) definitions are licensed under Apache 2.0.  This means developers can generate client code without being subject to AGPL 3.0's reciprocal licensing requirements.  Using generated clients in your application does not require your application to be AGPL-3.0-licensed, providing a clear separation between the generated client stub and our backend.

How will combined or derivative works be considered?

Creating combined or derivative works of the AGPL-3.0-licensed components requires all such works to be released under AGPL 3.0.  This restriction applies specifically to the AGPL-3.0-licensed portions and does not extend to the Apache-2.0-licensed SDKs and tools.

If AGPL-3.0-licensed Zitadel source code is included in the same executable file or designed to run linked together in a shared address space, they are considered combined in one program.  Communication mechanisms like pipes, sockets, HTTP-based APIs, and command-line arguments likely indicate separate applications, but if the communication involves exchanging complex internal data structures, this could be considered a combined program.

We think merely aggregating Zitadel's software into your distribution does not constitute a derivative work.  Your use and distribution of Apache-2.0-licensed SDKs and tools remain governed by the Apache 2.0 license.

I am currently using Zitadel Cloud (Free or Pro), how will this license update impact me?

It does not; you can continue to use Zitadel Cloud (Free or Pro tier) as this is not affected by our open source license change.

I have a question that has not been answered here yet. What should I do?

Please send your question to us via email, join this GitHub discussion, or post a question on Discord.

We will continue to update this page with additional information as questions arise from our community members.