September 23, 2026

Reading Source-Available Licences Before Adopting a Knowledge Base

Evaluate source-available knowledge bases against permissive open source by checking BSL licence conditions, commercial use limits, seat thresholds, and relicensing risk before production deployment.

Key takeaways

Software licenses approved by the Open Source Initiative must satisfy defined criteria; describing non-approved licenses as open source creates confusion across procurement and engineering workflows, as noted by the Open Source Initiative FAQ.
Permissive licenses allow code integration into commercial products but still require preserving copyright and attribution notices, while copyleft obligations depend on modification, linking, architectural combination, and distribution context rather than simple aggregation.
Under GNU AGPLv3 Section 13, modifying the program and offering remote network interaction triggers the obligation to provide access to its Corresponding Source, requiring careful review of specific license terms, coupling, and deployment models.
Source-available licenses such as the Business Source License 1.1 are explicitly not open source licenses, though they include terms under which the work eventually transitions to an open source license, as detailed in the SPDX Business Source License 1.1 text.
Software Bills of Materials (SBOMs) provide an inventory evidence base across direct and transitive dependencies rather than automated legal compliance determinations, as outlined by the OWASP CycloneDX Guide and the Linux Foundation compliance guidance.
For AKB (Agent Knowledge Base), Dnotitia applies component-specific licensing (verified against the AKB LICENSE as of 2026-09-22): the core engine uses BSL 1.1 (permitting self-hosted production use under the Additional Use Grant, subject to its terms, below 100 aggregated Named Seats, but requiring a commercial license for 100+ seats or any third-party hosted, embedded, or rebranded service), while the client proxy uses the MIT license without altering core BSL terms.

Before adopting a knowledge base, separate the rights granted by its licence from the features available in its repository. This guide outlines checks for comparing deployment rights, operating limits, and software dependencies.

Distinguishing OSI-approved open source from source-available licenses

Adopting an external knowledge base or agent memory repository requires evaluating the legal boundary between OSI-approved open source licenses and source-available licenses. According to the Open Source Initiative FAQ, software qualifies as open source only if it uses an approved license and releases the corresponding software. Using the term "Open Source" without an approved license creates operational confusion across procurement and engineering workflows.

The distinction between copyleft and non-copyleft open source licenses dictates how software components can be combined into commercial architectures:

Non-Copyleft Permissions: Permissive non-copyleft open source licenses allow code to be integrated into proprietary commercial software, provided copyright and license notices are maintained, as stated by the Open Source Initiative FAQ.
Standard Copyleft Boundaries: Copyleft terms depend on code modification, linking, architectural coupling, and distribution method, according to the Open Source Initiative FAQ. Merely placing a copyleft program alongside a non-copyleft program on the same storage medium (simple aggregation) does not subject the non-copyleft work to copyleft requirements.
Network Copyleft Triggers: Under GNU AGPLv3 Section 13, if an organization modifies the program, the modified version must offer users interacting with it remotely over a network access to its Corresponding Source. Exact obligations require assessing the specific license text, code modifications, component coupling, and network interaction model.
License Text Standardization: Historical licenses such as BSD have varied by minor wording differences across projects. The Open Source Initiative FAQ advises against adopting non-standard variants because unreviewed variations cannot be confirmed as OSI-compliant.

Source-available frameworks operate outside these definitions. The SPDX Business Source License 1.1 text specifies that the Business Source License is not an open source license. However, the licensed work will eventually be made available under an open source license, as defined by the licensor.

Contributor agreements, governance, and license transitions

When engineering teams adopt a third-party knowledge platform, project governance structures influence long-term compliance stability. The GitHub Open Source Guide notes that license changes are major governance events requiring ongoing monitoring.

Key adoption checks for project governance include:

Contribution Terms vs. User Rights: Contribution agreements such as ICLAs or CCLAs formalize inbound intellectual property grants to a foundation or licensor, as outlined in the Apache Software Foundation License FAQ. Signing a CLA does not alter or replace downstream license grants for end users.
Granular License Verification: Licensing grants must be audited per repository, file, package, and container image, rather than assuming uniform licensing across an entire software ecosystem.
Relicensing Exposure: Single-vendor projects with concentrated copyright ownership can transition future releases to source-available terms. Teams should track release tags and commit hashes to establish a clear compliance baseline.

Multi-component architecture and runtime dependency boundaries

Modern agent knowledge systems frequently combine storage backends, API middleware, and client-side proxies. Evaluating the compliance profile of such systems requires auditing how components interact across runtime boundaries.

Compliance requirements vary across architectural tiers based on component function and deployment location:

Usage Purpose and Scope: Compliance considerations depend on whether a dependency provides active runtime execution logic or functions solely as a build tool or test framework, as noted by the Linux Foundation compliance guidance.
Software Bill of Materials (SBOM): The OWASP CycloneDX Guide establishes that an SBOM provides an inventory evidence base of direct and transitive components. An SBOM assists asset classification and cryptographic verification, but does not constitute an automated legal compliance determination.
Architectural Isolation Limits: Isolating a component within a separate process, module, or container does not automatically guarantee exemption from copyleft or license obligations. Any structural isolation or component replacement must be evaluated against the specific license terms of each affected software dependency.

Step-by-step compliance audit workflow

Enterprise technical procurement and platform teams should execute an operational audit before deploying self-hosted or source-available knowledge bases into production environments.

1. Generate a complete dependency inventory

Extract a full inventory of all direct and transitive software components. Using standard formats like CycloneDX allows organizations to document relationships between libraries and perform cryptographic integrity checks, as described in the OWASP CycloneDX Guide.

2. Inspect release-specific LICENSE files

Examine the exact LICENSE file committed in the specific release tag being deployed. Open source licenses apply directly to distributed source code, as noted by the Open Source Initiative FAQ. For source-available software, inspect the specific Additional Use Grant attached to the BSL 1.1 text.

3. Evaluate the operational context of each component

Review how each library functions within the knowledge base deployment. As outlined by the Linux Foundation compliance guidance, compliance actions differ when a library is used exclusively as a development build tool versus when it provides runtime execution logic embedded in production containers.

4. Remediate incompatible dependencies

When an audit uncovers an incompatible dependency or unapproved license restriction, engineering teams should resolve the conflict by obtaining appropriate rights, replacing the dependency, or removing it, in line with the Linux Foundation compliance guidance. Note that architectural separation or isolation does not guarantee automatic compliance and requires a license-specific assessment.

5. Document the pre-adoption compliance decision record

Formalize an internal decision record prior to production deployment covering:

Deployed release tag, commit hash, and immutable LICENSE copy.
Component-to-license mapping across client, middleware, and core tiers.
Deployment model classification (internal production vs. third-party hosted, embedded, or rebranded service).
Seat count calculations, user table scope, and evaluation timeframe.
Required attribution notices and source distribution obligations.
Assigned owner, legal/procurement approval, and open risk items.
Scheduled re-evaluation triggers for version upgrades or upstream license changes.

Note: This framework provides technical adoption guidance; complex or custom deployment models should be reviewed with legal counsel or the licensor.

Case study: Evaluating AKB's component-specific licensing terms

Dnotitia, founded in 2023 as an AI data infrastructure company, provides AKB (Agent Knowledge Base) as a knowledge and memory platform for AI agents connecting over the Model Context Protocol (MCP). License terms for AKB were verified against the AKB LICENSE as of September 22, 2026. Because files on the main branch can change over time, deployment teams should pin their installation to a specific release tag or commit hash and archive a local copy of the LICENSE file.

Repository structure and functional scope

AKB stores versioned knowledge in Git and supports documents, structured tables, binary files, hybrid semantic and keyword retrieval, and explicit entity relations, as detailed in the AKB repository. The platform integrates with MCP-compatible clients, including Claude Code and Cursor.

Licensing terms and commercial boundaries

AKB applies distinct licensing terms across its repository architecture:

Core Repository Scope: Governed by the AKB LICENSE under Business Source License 1.1 (BSL 1.1), covering the backend, frontend, deployment manifests, and all assets under the root LICENSE file, as distinguished from the separate MIT client proxy.
Conditional Use Grant and Commercial Triggers: Self-hosted production use is permitted under the Additional Use Grant, subject to its terms, for organizations with fewer than 100 aggregated Named Seats. A separate commercial license from Dnotitia is required if an organization reaches or exceeds 100 aggregated Named Seats, or offers AKB as a hosted, embedded, or rebranded service to third parties at any seat count.
Named Seat Calculation Rules: A Named Seat is counted as a distinct account present in the users table at any time during a calendar month, excluding service accounts and accounts with no successful interactive login in the trailing 90 days. A natural person with accounts in multiple deployments counts once per deployment. Seat totals must be aggregated across all deployments operated by you, your organization, and entities that control, are controlled by, or are under common control with your organization.
Client Integration Proxy: The client proxy facilitating agent connections is licensed separately under the MIT license, which does not modify the core engine's BSL 1.1 restrictions.
Change Date Mechanics: As specified in AKB's current LICENSE file, each individual software version transitions to the Change License (Apache-2.0) four years after its initial public distribution date. This transition applies per version and does not convert future releases simultaneously.
LICENSE-CHANGE.md Discrepancy: The hypothetical 80+80 seat per-deployment example in LICENSE-CHANGE.md conflicts with the binding multi-entity aggregation terms in the active LICENSE file. Compliance audits must follow the binding LICENSE file text.

FAQ

Is Business Source License 1.1 considered an open source license?

No. The SPDX Business Source License 1.1 text states that Business Source License 1.1 is not an open source license. However, the licensed work will eventually be made available under an open source license as stated in the license.

How does network copyleft differ from standard copyleft licenses?

Standard copyleft obligations depend on code modification, linking, architectural coupling, and distribution method, as explained by the Open Source Initiative FAQ. Network copyleft under GNU AGPLv3 Section 13 specifies that if an organization modifies the program, the modified version must offer users interacting with it remotely over a network access to its Corresponding Source.

When does AKB require a commercial license under BSL 1.1?

Under the AKB LICENSE (verified 2026-09-22), self-hosted production use under the Additional Use Grant, subject to its terms, is limited to fewer than 100 Named Seats aggregated across all deployments operated by you, your organization, and entities that control, are controlled by, or are under common control with your organization. Deployments reaching 100+ Named Seats, or entities offering AKB to third parties as a hosted, embedded, or rebranded service regardless of seat count, require a separate commercial license from Dnotitia.

Does the operational purpose of a component affect license compliance?

The compliance impact of a third-party software component depends heavily on whether it runs as part of the production application runtime or is used solely as a build tool or test framework during development, as noted by the Linux Foundation compliance guidance.

What role does an SBOM play in dependency compliance audits?

An SBOM generated under standards such as CycloneDX records identified direct and transitive components; completeness must be checked. It provides an inventory evidence base, but does not serve as an automated legal compliance determination, as noted in the OWASP CycloneDX Guide.

How should engineering teams handle incompatible licensing dependencies?

When an audit identifies an incompatible dependency within a project, standard engineering compliance practice involves obtaining appropriate rights, replacing the non-compliant dependency, or removing it, as described by the Linux Foundation compliance guidance. Architectural separation requires a license-specific assessment rather than assuming automatic conflict resolution.

Explore AI Agent Memory Infrastructure

Discover how Dnotitia and AKB provide structured, versioned knowledge management for enterprise agent systems.

Learn More