Confluent Schema Registry licensing for self-hosted Kafka: what your teams may run
Start with the separation that decides most of this question: Apache Kafka and Schema Registry are licensed separately. Kafka is an Apache Software Foundation project under the Apache License 2.0, and the project itself offers no paid edition. Confluent Schema Registry is a different component with its own license, the Confluent Community License, so Apache 2.0 terms on your brokers do not carry over to it. Teams that already run Kafka under Apache 2.0 often assume the whole stack is open in the same way, and that assumption is the first thing to check before rollout.
The Confluent Community License generally permits internal use, but its key limit concerns offering the software to third parties as a competing service. In practice, the review should answer three questions: whether Schema Registry will serve only your own teams and applications, whether any business unit, customer or subsidiary will consume it as a managed offering, and whether any vendor you engage will host it for others. The Apache 2.0 serializer modules that ship alongside the registry are licensed differently, so confirm each artifact you pull into your build separately instead of treating the registry and its clients as one license.
Have counsel confirm the position against the current Confluent Community License text and the license headers of the exact versions you deploy. Start a licensing review before rollout if you plan to expose the registry outside your organization, host it for a partner, bundle it into a product, or run it as a shared service for more than one legal entity. If the review finds a constraint you cannot accept, the open-source alternatives covered in the sibling sections on Apicurio Registry and Karapace are the options to evaluate, with compatibility checked against your serializers first.
How the licensing position changes by use case
This is the most common starting point: one legal entity runs a self-hosted Kafka cluster and a Schema Registry for its own engineering teams, and no outside party consumes the service. The question to settle is whether every user of the registry is inside that organization and whether the registry is used to support the organization's own business rather than to be sold as a service. Confirm the facts in writing before you build, because the license text, not the deployment pattern, governs the answer.
- Who the users are: list the internal teams, contractors and automated systems that publish or read schemas.
- What the registry does for them: internal data flows, such as service-to-service events, usually differ from a service offered to others.
- Where it runs: confirm the cluster sits in infrastructure the organization controls.
- Version and license record: keep the exact license version you deploy and the date you reviewed it.
- Questions for counsel: does the Community License's use grant cover our internal purpose, and does any internal use fall under a restriction we have not identified?
Check the license text supplied with the version you deploy before you rely on any summary, including this one.
Groups often run one platform for several legal entities. Affiliates and subsidiaries are not automatically the same as the organization that owns the registry, so the answer depends on how the license defines the party using the software and how the entities relate. Map each entity that will publish or consume data and record the contractual and ownership links between them before deciding on a single shared registry.
- Entity map: list each legal entity, its role in the data flows and its ownership relationship to the deploying company.
- Shared or separate deployments: a shared registry across entities raises different questions than one registry per entity.
- Service arrangements: note any intra-group agreements under which one entity runs infrastructure for another.
- Charging between entities: determine whether any entity pays for, or is billed for, registry access.
- Questions for counsel: does the license treat our affiliates as part of the same user, and does an intra-group service agreement change that position?
Record the answers in the architecture decision record so that future entities added to the platform trigger a fresh review.
A company may ship software to customers that includes Kafka, or that exposes schema management as a feature. This is the situation where the competing-service restriction in the Community License needs the closest reading. The relevant questions are what the customer can do with the registry through your product, and whether that use resembles a Schema Registry service that you would be offering in competition with the licensor's commercial offering.
- Customer-facing functions: list any features that let customers create, read or manage schemas directly.
- Embedded or separate: decide whether the registry is bundled inside the product or provided as a distinct component.
- Hosting model: identify whether you host it for customers or they run it themselves.
- Commercial overlap: compare the functions you expose with the commercial registry products the licensor sells.
- Questions for counsel: does exposing schema management to customers fall within the competing-service restriction, and would removing that function or using an Apache 2.0 component change the answer?
This is the tab where an open-source replacement or Apache 2.0 serializer module is most often considered, so review those options at the same time.
Offering Kafka or a Schema Registry as a managed service to third parties is the situation most likely to meet the competing-service restriction directly. Customers pay you to run the registry, and the service may look like the licensor's own offering. Obtain a full legal review before you design the service, because the commercial terms, not just the technical setup, shape the outcome.
- Service definition: write down what customers buy, including schema storage, compatibility checks and API access.
- Tenancy model: determine whether customers share one registry or each get a dedicated instance.
- Pricing and support: note whether revenue depends on the registry function itself or on a wider platform.
- Alternatives: assess whether an Apache 2.0 licensed registry or a different service model avoids the restriction for your offering.
- Questions for counsel: would this offering compete with the licensor's commercial service under the license, and what changes would be needed to proceed?
Do not launch a third-party service on an assumed reading of the license, and ask counsel to confirm the position in writing for each version you run.
Schema Registry options and when each fits under the license
This table compares Confluent Schema Registry, Apache 2.0 serializer modules, Apicurio Registry and Karapace against the questions that matter for a self-hosted Kafka platform: license position, API compatibility, storage and fit. Treat every license cell as a point to confirm against the current license text and your legal review, not as a settled conclusion. The main takeaway is that the license question and the compatibility question are separate, so settle both before choosing.
| Option | License position to confirm | API compatibility with existing serializers | Storage and when it fits |
|---|---|---|---|
| Confluent Schema Registry | Distributed under the Confluent Community License. Confirm whether your internal use and any hosted or competing offering fall within its terms with counsel. | Native to Confluent serializers, the reference point other registries are measured against. Confirm version compatibility with your client libraries. | Stores schemas in an internal Kafka topic. Fits teams that already accept the license terms and want the reference behavior. |
| Apache 2.0 serializer modules | Serializer and deserializer code can be under Apache 2.0, but confirm which module you use and whether it depends on registry components under other licenses. | Serializers call a registry API, so they work only with a registry that exposes the API they expect. Confirm the exact client version and endpoints. | Storage depends on the registry you point them at. Fits when you need client code under a permissive license and will pair it with a registry chosen separately. |
| Apicurio Registry | Confirm the license of the version you deploy and whether your use case needs any review beyond the project's own terms. | Offers a Confluent-compatible API for existing serializers. Confirm which subjects, endpoints and schema ID behavior your clients rely on. | Choose storage in the registry configuration. Fits teams that want an open registry with Avro, Protobuf and JSON Schema support and a path away from the Confluent API. |
| Karapace | Confirm the license terms of the release you plan to run and check them against your internal and distribution use. | Targets API compatibility with Confluent Schema Registry, with its own limits on normalization. Test every serializer and REST call you depend on. | Stores schemas in a Kafka topic, so it depends on the same cluster it serves. Fits teams that want compatibility with existing clients and can accept Kafka-backed storage. |
| Keeping schema IDs stable | Not a license question, but it decides migration cost. Records already reference schema IDs, so the chosen registry must preserve them. | Confirm ID preservation during export and import before you choose a target. Plan a test with real serialized records. | Storage design affects backup and recovery planning for the registry as well as for Kafka. |
| Serialization format support | Format support is not a license term, but it limits your options. Check which formats each registry serves for your topics. | Confirm support for Avro, Protobuf and JSON Schema in the versions you run, since client libraries differ. | Mixed-format topics narrow the field, so list formats before comparing licenses. |
| Competing-service use | If you plan to offer schema management as a service to other organizations, treat this as a separate license review item for every option. | Client compatibility does not change the license answer, so do not assume a compatible API means a compatible license. | Ask counsel to review the restriction for your specific offering before you build on any option. |
| Upgrade and support path | Confirm the release history and security support window of each option with its maintainers. | Confirm how the registry tracks Confluent API changes over time, since compatibility can drift between releases. | Plan an upgrade test against your serializers and consumers for each registry you run. |
Which serializer code is Apache 2.0 and what that means for clients
The license on the Schema Registry server does not decide the license of the code your producers and consumers run. Serializer and deserializer modules, schema parsers and the wire format that frames each message are separate questions, and each artifact in your dependency tree needs its own check. Apache Kafka itself is released under the Apache License 2.0, but that covers the Kafka project, not a schema serializer library published from another repository or under another group ID. Treat the license as a property of each published artifact and version, confirmed from its own metadata and LICENSE file, not inferred from the product name.
Start with an inventory of every serialization package your applications load. Include transitive dependencies, shaded or fat jars, client libraries for each language in use, Kafka Connect plugins and any container image that bundles a converter. For Java builds, mvn dependency:tree or the equivalent Gradle report lists what actually ships, which is more reliable than the packages a developer remembers adding. For each entry, record the package name, the exact version, the license identifier stated in the artifact and the source it was downloaded from. Where the metadata is missing or ambiguous, ask the publisher for written confirmation before the artifact goes into production.
Store this list in the platform inventory next to the registry version and the Kafka release it serves, and make it part of upgrade review. A version bump can change the declared license or pull in a new transitive dependency, so the record is only useful if it is refreshed whenever a client library moves. Assign an owner, usually the platform team with sign-off from legal or procurement, and agree how often the scan runs. Your legal reviewer should decide whether each license is acceptable for internal use and for any distribution you perform, because that judgment depends on how your organization deploys and shares its software.
How to run a licensing review before you deploy
This sequence turns a licensing question into a dated, written decision that covers which Schema Registry components you run, who uses them, and why that choice is defensible. It produces a file your architecture, legal and procurement teams can all point to when the registry changes later.
Inventory current and planned schema registry use
Start by listing every place a schema registry is used or planned: production clusters, staging, developer laptops, CI pipelines, and any managed or vendor-hosted service that talks to your brokers. For each entry, record the product name, the version or image tag, the deployment owner, and whether it is a registry server, a serializer library, or a REST client. Done means every serializer and registry instance in use has a row in one table, and the table is reviewed by the platform team so nothing is missing.
Collect license texts for each component
For each row in the inventory, collect the license file from the exact version you intend to run, not from the project's main branch or a website summary. Store the files in your records repository with the component name, version, source URL, and retrieval date. Check that the license file header or version line matches the version you are deploying. Done means every component has a stored license file that matches its version number, and any component without one is flagged as an open question.
Map internal and external users of the registry
Document who reads and writes schemas and who consumes the registry's API. Separate employees, contractors, affiliates, customers and partners, and note whether any of them run a product or service that is built on Kafka data or on the registry itself. Record whether registry access is exposed through an API that external parties can call. Done means you have a user map that shows each group, its access path, and whether the use is internal to your organization or delivered to outside parties.
Obtain counsel's written position
Give counsel the inventory, the license files, and the user map, and ask for a written position on whether each planned use fits the license terms. Ask specifically about internal use, use by affiliates, and any use that could be read as offering a competing service. Keep the question scoped to your facts so the answer applies to your deployment. Done means you hold a signed or dated memo that names the components and versions it covers, and any conditions counsel attached are copied into your decision record.
Confirm Apache 2.0 serializer modules separately
Review the serializer and client libraries you plan to use as their own items, since their license terms can differ from the server component. Confirm the license identifier and the license file for each library version, and check the dependency tree for any transitive component under another license. Note which languages and build tools pull in each library. Done means each client library has its own line in the record with its license confirmed against the version in use, and any dependency with a different license is escalated to counsel.
Choose the registry against the written position
With counsel's position in hand, compare your options on the points that matter for your use: the license terms for internal and external use, the API compatibility your existing serializers need, and the formats you run. Options include keeping the Confluent Schema Registry under its license, or moving to an open-source replacement that offers a compatible API. Record the choice, the reason, and any follow-up work, such as a migration plan. Done means the decision is written with each option's license status and compatibility noted, and the platform owner and the legal owner have both approved it.
Record the decision and set checks for each step
Write the decision into a single dated record that links to the inventory, license files, user map, counsel memo and the chosen option. Add a recheck trigger for every change that could alter the answer: a version upgrade, a new user group, a new external-facing use, or a change in the registry's license. Assign an owner and a review date for each trigger. Done means the record is stored where auditors and engineers can both find it, and the review triggers are set in your change process so that a new version cannot reach production without the license file being compared again.
Governance and operational risks tied to the registry choice
Choosing a schema registry is a governance decision as well as a technical one. The risks below come from licensing terms that can change with a version, from client libraries that arrive through new services, from settings that few people review, and from the schema IDs that every serialized record carries. Each card names one risk and the control to put in place before it causes trouble.
License drift after upgrades
A registry that was compliant under one release can carry different license terms in a later version or in a newly added component, and an upgrade may pull in modules you did not evaluate. Before each upgrade, check the license file and notice files of every artifact you deploy, not only the one you installed first. Record the license version you approved, and reopen that review when the vendor's packaging changes. Ask your legal team to confirm whether the internal-use position still holds for the new release.
Unlicensed client libraries in new services
Serializer and deserializer libraries are often added by application teams without review, and some are published under different terms from the registry server. A new service that pulls a registry client from a package repository may add a dependency your approved list never covered. Keep an allowlist of permitted serializer packages per language, enforce it in dependency scanning and CI, and require a license check when a team adds a new registry client.
Access control on subjects and compatibility settings
Anyone who can change a subject's compatibility mode or register a new schema version can break consumers without touching a broker. Limit write access to the registry API by role, separate producer teams from platform administrators, and require authentication for every client. Review who can change global defaults as well as per-subject settings, since a global change affects every topic. Log every change to a subject or mode so that you can trace a breaking change to a person and a time.
Schema IDs and consumer impact during a registry change
Serialized Kafka records carry a schema ID that points to a registry entry, so a new registry that assigns different IDs can make existing records unreadable. Treat the registry switch as a change to the data path, not a server swap. Before cutover, confirm that the target registry keeps the IDs that stored records reference, test a consumer against records written before the switch, and keep the old registry readable until the retention period for those topics has passed.
Ownership of registry configuration
Without a named owner, the registry drifts: subjects accumulate, compatibility modes differ between teams for no stated reason, and nobody knows which license or support contract applies. Assign one platform owner for the registry service and one data owner for each subject. Keep the configuration in version control where the change is reviewed, and export subject and mode settings on a schedule so that a restore or a migration starts from a known state.
Questions buyers ask about Schema Registry licensing
Does the Confluent Community License allow internal use of Schema Registry?
For most internal use, the Confluent Community License permits running Schema Registry on your own Kafka cluster for your organization's producers and consumers, but the license text decides the question, not this page. The Confluent Community License is a separate license from the Apache License 2.0 that covers Apache Kafka itself, so the registry must be reviewed on its own terms. Ask your counsel to confirm the license version you download, whether any third party uses the registry, and whether an internal deployment could be read as offering the service to others. Document how the registry is exposed to each team so the review matches what you actually run.
What does the competing-service restriction mean for a platform team?
The competing-service restriction generally limits using the licensed software to offer a product or service that competes with the licensor's commercial offerings, so the platform team's question is whether its internal service could be read that way. Internal platforms serving your own business units usually raise a different question than a registry sold or hosted for outside developers, a managed copy provided to subsidiaries or partners, or a service bundled into a paid offering. The drivers are who consumes the registry, how it is described to them, and whether any customer-facing product depends on it. Have counsel read the defined terms in the license and map each consumer against them.
Do Apache 2.0 serializers avoid the Schema Registry licensing question?
Serializer libraries published under the Apache License 2.0 can be reviewed on their own terms, but they do not settle the registry question by themselves. Your build and deployment may pull in registry components, client packages or bundled artifacts that carry the Confluent Community License, and the license of each artifact matters. Build an inventory of every library, container image and jar your producers and consumers load, then record its license. Also confirm whether the serializers call a Confluent-licensed registry service, since that dependency is the part that brings the registry's terms into your architecture.
How long does a Schema Registry license review take, and what drives it?
No researched duration applies to this review, so ask any provider for a written estimate tied to a stated scope rather than relying on a general figure. The main drivers are the number of registry deployments, how many business units or external parties consume them, whether vendor license terms sit in procurement contracts, and whether your legal team already has a standing open-source review process. A review also takes longer when you must choose and test an alternative registry, because that adds migration work and new compatibility checks. Ask what is included, who signs off on the legal conclusion, and which decisions are still open.
Can our own team complete the license review without outside help?
Many platform teams can complete the first pass in-house if they assign clear owners for the license text, the deployment inventory and the legal decision. The engineering work is listing where the registry runs, which clients call it, which artifacts are bundled, and which teams depend on the current behavior. The legal conclusion should come from your counsel, not from an implementation partner. Outside help is most useful when the inventory is large, when several clusters or regions run the registry, or when you need a tested replacement plan. Confirm internally who will own the decision before any work starts.
What would a partner need from us to scope a licensing review?
A partner needs enough written detail to scope the technical inventory and any follow-on work. Prepare the following before the first conversation:
Does the Apache 2.0 license on Kafka itself change the registry analysis?
Apache Kafka is distributed under the Apache License 2.0 and the project offers no paid edition of its own, so the broker is not where the licensing question arises. The review concerns the schema registry and any Confluent packages you add around the cluster. Keep the Kafka license record separate from the registry record in your compliance file so auditors and counsel can see which component each conclusion covers. Check the Kafka downloads page for the supported releases you run, and record the version alongside the license decision.
How DeployOpen supports the registry decision and rollout
DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, including the Kafka cluster, the registry service and the surrounding access and network controls. For the Schema Registry decision, that means the work can cover standing up the chosen registry on your cloud accounts, data centers or restricted networks, wiring it to your Kafka clusters and identity provider, and documenting how it runs. Whether a given deployment fits the license is a separate question, and it sits with your counsel, as explained below. Most engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before work starts. Ask for a written list of which environments are in scope, which systems are being replaced, and who signs off on each deliverable.
DeployOpen does not give legal opinions. We do not interpret the Confluent Community License for your organization, and we do not decide whether a particular internal use, hosted offering or product feature falls inside its terms. Your legal counsel decides the license position, ideally before design begins, and records the answer along with the facts it relied on, such as which teams call the registry, whether any customer can reach it, and whether it is bundled into a product you sell. Give counsel the proposed architecture diagram, the registry version, and the list of serializer libraries in use so the opinion matches what will be built.
Once counsel has decided, the practical rollout items are concrete: which registry is deployed, how its schema storage and compatibility settings are configured, how clients authenticate, and how the migration of existing subjects and schema IDs is tested before cutover. A quote from DeployOpen should follow from that written scope and list one-time work (design, build, migration rehearsal, documentation) separately from recurring work such as upgrades and support, which can be handled under a retainer. Ask for the assumptions behind each line item, especially the number of environments and the number of subjects to migrate.
How DeployOpen scopes and delivers Kafka schema registry work
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Confluent Schema Registry licensing questions, we start by writing down which deployment and usage pattern your organization actually has, then design the registry choice around that written scope.
How we scope
- We record which teams, applications and Kafka clusters would use the registry and whether any use is offered to outside parties.
- The written scope states which license terms we review against your usage and which legal interpretation remains with your counsel.
- We list the serializer modules, client languages and registry APIs in use so the license review covers every component you run.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We build a comparison of the registry options against your usage pattern, covering license terms, API compatibility and operating model.
- We test serializer and client compatibility in a non-production environment that mirrors your Kafka and client versions.
- We configure the chosen registry with access control, TLS and storage settings, and verify schema registration and retrieval end to end.
- We document the license decision, the usage boundaries and the evidence supporting each conclusion for your legal and compliance reviewers.
How we hand over
- You receive the written license decision, the usage assumptions behind it and the list of components it covers.
- Runbooks cover registry deployment, client configuration, schema migration steps and rollback to the previous registry.
- We walk your platform and legal owners through the decision record and the conditions that would trigger a fresh review.
- Handover includes configuration, test results and an inventory of which teams depend on the registry endpoints.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the original engagement.
- Retainers can cover registry version upgrades, dependency review when serializer or license terms change, and periodic usage checks.
- Changes to usage, such as offering schemas to a partner or a new product, can be reviewed against the existing decision record.
- Ask any provider to confirm current license text with the vendor or project directly before relying on an interpretation.
