thalabus Licensing and Architecture – Working Position Paper

1. Purpose and Status of This Document

This document captures the current state of discussion regarding the licensing, architectural boundaries, and governance model for thalabus. It is a working document, intended to make explicit what has already been decided and to clearly identify what remains open for further discussion.

The current license (AGPLv3) is described in Chapter 3. Several strategic and operational details are still under evaluation.

Definitions and Ownership (Current)

2. Copyright Ownership and Legal Control

Copyright over the thalabus source code is automatically acquired by its authors at the moment of creation. No registration with any authority is required to hold copyright.

Publishing thalabus as open source does not imply any loss of ownership. The copyright holders retain full and exclusive rights to:

These rights are held by the copyright holders; third parties must comply with AGPL for the thalabus core and any derivative works unless granted an alternative commercial license.

Exclusive control would only be diluted if external contributions were accepted without appropriate legal agreements governing ownership and licensing. For this reason, contributor governance is treated as a first-class concern elsewhere in this document.

Inbound Contribution Posture and Contributor Governance

thalabus accepts external code contributions under a Contributor License Agreement (CLA).

All contributors must sign one of the following before contributions are accepted:

Contributor License Agreement Terms

The CLA requires contributors to:

  1. Assign copyright of contributed code to thalabus (or the copyright holder)
  2. Grant dual-license rights: Contributors grant thalabus the right to distribute their contributions under:
  3. GNU AGPL v3 (the primary open-source license)
  4. Commercial licenses (as defined in Chapter 8), enabling thalabus to offer commercial licensing options for private core modifications, SaaS, OEM, and redistribution use cases
  5. Represent that contributions are original and do not infringe on third-party rights
  6. Accept future relicensing: Contributors acknowledge that their contributions may be relicensed under commercial terms consistent with the commercial strategy described in Chapter 8

Rationale

This CLA structure is essential to the long-term sustainability and flexibility of thalabus:

All contributed code that is accepted into the thalabus distribution must comply with the licensing policy described in Chapter 6 (for artifacts like prompts, models, datasets) or Chapter 7 (for extension mechanisms).

3. Choice of Open-Source License

Repository state note (added during documentation review): As of this review, the repository root does not contain a top-level LICENSE file declaring AGPLv3 for the thalabus core. ThalabusSDK/LICENSE exists and correctly declares the MIT License, consistent with Section 4.2's classification of the published Python SDK as a public, non-core interface. Adding a root-level AGPLv3 LICENSE file for the core is a documentation/repo-hygiene action that would make this chapter's stated license verifiable directly from the repository.

thalabus is licensed under the GNU Affero General Public License, version 3 (AGPLv3).

This choice is deliberate and aligns with the core objectives of the project:

AGPLv3 requires that any modifications to thalabus, including those deployed over a network, are made available under the same license when the software is conveyed or offered as a service.

The license applies to the thalabus core and to any derivative works that rely on its internal APIs or in-process integration mechanisms.

4. Open-Source Core vs Closed-Source Extensions

thalabus follows an open-core architecture with a strict and explicit boundary between the AGPL-covered core and external components.

4.1 AGPL-Covered Core

The thalabus core is licensed under GNU AGPL v3 and includes:

Any modification to the core, including networked use, must comply with AGPL obligations.

4.2 Stable / Public Interfaces

The following interfaces are considered stable and public and constitute the intended third-party integration boundary:

Third parties may:

Such usage does not create a derivative work of the thalabus core.

4.3 Internal Interfaces

The following are considered internal and are not part of the public extension boundary:

For purposes of this policy, any component relying on internal interfaces is considered a derivative work and must be licensed under AGPL if distributed.

4.4 Practical Evaluation Criteria for Boundary Cases

When evaluating whether an integration is within the public boundary or internal coupling, thalabus applies the following criteria:

4.5 Custom Agents and Custom Tools

thalabus is designed to be extended through custom agents and custom tools that third parties can define, implement, and distribute. Custom agents and tools follow the same licensing and extension boundary rules as other third-party integrations.

A custom agent or custom tool is permitted as closed-source and is not a derivative work of the thalabus core if it satisfies the boundary evaluation criteria in Section 4.4:

Important clarification on data structures: Custom agents and tools may interact with thalabus data structures (e.g., objects, schemas, types) through defined public interface abstractions (e.g., Python abstract base classes or published interface definitions) without violating this policy. What is forbidden is direct reliance on internal implementation details—the concrete Python classes, class instances, and private data structure implementations. If a custom agent or tool accesses thalabus data structures only via published abstract interfaces and versioned public API contracts, it respects the boundary. If it directly couples to internal implementations, it crosses the boundary.

Custom agents and custom tools that rely on internal thalabus implementations, in-process execution, or in-memory integration are considered derivative works and must be licensed under AGPL if distributed.

This applies equally to agents and tools implemented as:

5. Third-Party Open-Source Dependencies

thalabus may incorporate and be distributed together with other open-source licensed software, provided that such software is licensed under an OSI-approved license compatible with the GNU AGPL v3.

The use of third-party open-source software does not alter the AGPL obligations of the thalabus core.

5.1 Scope of Use

Third-party open-source software may be used in the following ways:

For clarity, the inbound license whitelist in Chapter 5.2 applies to dependencies that are incorporated into and distributed with the thalabus core. Optional external assets (e.g., third-party foundation models, weights, or datasets) may be used under their own license terms when obtained and operated separately, but must not be bundled into the thalabus distribution unless their license terms explicitly permit redistribution and they comply with the inbound whitelist.

Such software may be open-source under its original license and is not required to be relicensed under AGPL solely because it is used in conjunction with thalabus.

Third-party software must not rely on:

5.2 Inbound License Whitelist

The thalabus core accepts third-party dependencies only under an explicit inbound license whitelist.

Note: Some OSI-approved licenses (e.g., LGPL) are excluded as a policy choice to reduce compliance complexity and avoid ambiguity around linking/derivative-work boundaries in mixed deployments.

The following licenses are permitted without additional approval:

The following licenses are explicitly excluded, unless an explicit exception is granted:

5.3 License Compliance and Enforcement Phases

thalabus adopts a phased approach to license compliance, proportional to project maturity and ecosystem growth.

Phase 1 – Declarative and Manual Review (current phase)

Phase 2 – CI-Based Detection (planned)

Phase 3 – Enforced Compliance (optional, future)

6. Prompts, Models, and Data Assets

This chapter defines how prompts, models, datasets, and related artifacts are treated from a licensing and governance perspective within the thalabus project.

6.1 thalabus-Specific Artifacts and AGPL Scope

Artifacts that are created specifically for thalabus use are considered part of the AGPL-covered thalabus core, regardless of their technical form.

This includes thalabus prompts and prompt templates distributed with thalabus. The distinction is based on distribution location: prompts and prompt templates shipped as part of the thalabus distribution are AGPL-covered; document templates and reasoning templates authored and distributed independently as configuration inputs (outside thalabus) may remain under other licensing (see Chapter 8).

This includes, but is not limited to:

Any artifact contributed to and accepted into the thalabus distribution that is created with focus on or specialization for thalabus-specific use must be published under GNU AGPL v3 as part of the thalabus distribution.

This rule applies equally to artifacts implemented as:

The determining factor is intent and specialization, not format.

6.2 Non-thalabus-Specific Artifacts

Artifacts that are not thalabus-specific are not brought under AGPL solely because they are used in conjunction with thalabus.

Examples include:

Such artifacts may retain their original license and distribution model, provided they are not modified specifically for thalabus use.

In summary:

6.3 Definition of "Modification" for Models and Datasets

For the purposes of this policy, a modification of a model or dataset is defined as the creation of a:

that is explicitly intended for thalabus-specific use.

Accordingly:

7. Extension and Plugin Mechanisms

This chapter defines the technical extension mechanisms supported by thalabus and specifies which mechanisms are permitted, restricted, or forbidden in order to preserve the integrity and enforceability of the AGPL licensing model.

The intent of this chapter is not to limit extensibility, but to ensure that extensibility occurs across clear architectural and legal boundaries.

7.1 Design Principle

thalabus distinguishes extensions based on runtime coupling, not on packaging, language, or deployment format.

The decisive factors are:

For purposes of this policy, extensions that cross internal boundaries are considered derivative works of the AGPL-covered core.

7.2 Allowed Extension Mechanisms

The following extension mechanisms are explicitly allowed and may be implemented as closed-source or open-source, subject to their own licensing terms.

Configuration-Based Extensions

These artifacts must satisfy the following conditions to remain closed-source and avoid derivative-work status:

Out-of-Process Extensions

These extensions:

Other Open-Source Software

Other open-source software licensed under OSI-approved, AGPL-compatible licenses (e.g. Apache License 2.0, MIT, BSD) may be used as external tools, external services, or dependencies in external systems, provided they do not rely on internal thalabus interfaces.

7.3 Forbidden Closed-Source Mechanisms

The following mechanisms are explicitly forbidden when implemented as closed-source:

For purposes of this policy, such mechanisms are considered to create derivative works and therefore must be licensed under AGPL if distributed.

7.4 Explicit Non-Forbidden Mechanisms (Clarification)

For the avoidance of doubt, the extension mechanisms listed in Section 7.2 are explicitly not forbidden. When they remain within the stable/public interface boundary (Chapter 4) and satisfy the boundary evaluation criteria (Chapter 4.4), they do not create derivative works.

7.5 Enforcement Posture

At present, enforcement of this extension policy is policy-based, relying on documented architectural boundaries and licensing terms.

thalabus reserves the right to introduce technical safeguards, validation tooling, or runtime checks in the future to enforce extension boundaries and licensing compliance.

The absence of such tooling at a given time does not weaken or override this policy.

7.6 Summary

8. Commercial Strategy and Dual Licensing

Current Position

AGPL governs the distribution and network use of the thalabus core. In parallel, t2b AG (as steward and rights holder of thalabus) may offer commercial offerings that are independent of code licensing, including:

These offerings do not change the AGPL obligations of the thalabus core.

In addition, t2b AG (as steward and rights holder of thalabus) may offer a commercial license for customers whose intended usage cannot (or will not) comply with AGPL obligations. The default posture is:

When Customers Actually Require “Closed Source”

In practice, customers who ask for “closed source” usually fall into one of the following categories.

A) Private Modification of the thalabus Core

The customer expects to modify the thalabus core and wants to keep those modifications private, including when thalabus is used over a network.

Typical examples:

B) SaaS Providers (Network Use + Private Deltas)

The customer wants to provide a thalabus-powered service to their own end users, but does not want to disclose any changes they made to the thalabus core.

C) Redistribution / OEM / Embedded Product

The customer wants to bundle thalabus with a proprietary product and redistribute it (appliance, on-prem product, OEM embedding, marketplace distribution), and needs terms that allow closed-source distribution and/or bundling.

D) “We Think We Need Closed Source” (Often Solvable Without Dual Licensing)

Many customers can keep their own code closed-source under the current architecture policy if they:

In this case, the customer’s proprietary code remains outside the AGPL boundary, and dual licensing is typically not required.

Default Commercial Posture (Recommended)

thalabus aims to keep the commercial story simple and predictable:

This posture preserves the enforceability and ecosystem intent of AGPL while still enabling revenue capture from high-friction commercial deployments.

Commercial License Scope (Illustrative Tiers)

When and if dual licensing is offered, it will be packaged as standard tiers (minimizing bespoke legal negotiation). Illustrative tiers:

Unless explicitly stated otherwise, commercial licensing should not be interpreted as a commitment to support in-process closed-source plugin mechanisms. The recommended extension approach remains aligned with Chapter 5.3.

Packaging Strategy (Aligned With the Public Interface Boundary)

Even with (or without) dual licensing, t2b AG may offer proprietary commercial value as products that sit outside the AGPL boundary by using stable/public interfaces, such as:

This packaging is compatible with the open-core boundary while creating clear commercial upsell paths.

9. Compliance, Monitoring, and Enforcement

Current Position

thalabus relies on clear architectural boundaries and explicit policy to ensure that AGPL obligations are understandable and enforceable. Enforcement is intended to be predictable, fair, and proportionate.

Detection and Monitoring

t2b AG will identify likely non-compliance through the following methods:

Response Playbook

When a potential compliance issue is identified, t2b AG will follow a measured escalation:

  1. Education and clarification (30 days): Contact the party, explain the alleged non-compliance, clarify their obligations, and provide guidance on remediation paths (e.g., open-source the modifications, obtain a commercial license, or restructure to use public interfaces).

  2. Formal compliance request (30 days): If the party does not respond or refuses to engage, issue a formal written request for compliance, setting a deadline for resolution.

  3. Legal escalation (as needed): If the party continues to refuse or ignores the formal request, t2b AG may pursue legal action or refer the matter to legal counsel for further enforcement options.

This approach prioritizes education and good-faith resolution over adversarial enforcement.

Responsibility and Governance

License compliance and enforcement decisions are the responsibility of the thalabus maintainers (or a designated compliance committee, once governance is formalized). Decisions will be documented and made public when possible, to ensure transparency and consistency.

Tooling and Technical Safeguards

t2b AG reserves the right to introduce technical safeguards in the future, including:

At present, enforcement relies on documented architectural boundaries and licensing terms. The absence of such tooling at a given time does not weaken or override this policy.

10. Public-Sector Positioning

Rationale

Public administrations often prefer open-source solutions to reduce vendor lock-in risk and increase transparency. The thalabus licensing model is designed to support these objectives by ensuring forkability and the availability of improvements, including in networked deployments. AGPLv3 guarantees that public-sector users can:

Procurement Guidance

Upon request, t2b AG will provide clear, public-sector-ready guidance on procurement and licensing:

Operational Compliance Guidance

Upon request, t2b AG will provide practical deployment guidance for public administrations:

Risk Positioning and Long-Term Support

thalabus acknowledges common public-sector concerns and addresses them as follows: