Short notice
For designated future covered releases: personal and internal use is free; commercializing the platform requires an agreement with Orchestrum Technologies LLP. Agreements: sanjeev@orchestrum.in. Current Apache-2.0 rights remain unchanged. This policy is not an additional restriction on existing Apache-licensed software, specifications or SDKs.The workable licensing model
Use mixed licensing, with an explicit boundary rather than attempting to revoke an already published license:
The concrete candidate is
licensing/ORCHESTRUM-SELF-USE-COMMERCIAL-1.0-DRAFT.md; its proposed identifier is
LicenseRef-Orchestrum-Self-Use-Commercial-1.0. The adoption record is
licensing/scope.json. The text is approved for policy publication, not adoption.
The current scope has zero covered files, no release version and no effective
date. Owner publication and owner-attested legal approval are recorded; neither
designates code for adoption. Its reference baseline commit is a
source-review reference, not a licensing cutoff.
Prefer separately identifiable original modules that have not already been
distributed under Apache-2.0. Do not move old code into a new folder or change
its header and call that a new licensing right. For mixed or derived files,
document the retained material and obtain a specific rights/notice assessment.
This protects eligible new software and commercial service/brand arrangements
going forward. It does not stop someone commercializing an independent,
previously Apache-licensed implementation. Hosted plans and support can be
monetized separately without changing its source license.
What self-use means
Personal use, evaluation, development and an organization’s own operations would be royalty-free for the software covered by the finalized future license. This includes internal agents and a bank or merchant serving its own customers in its ordinary business. Revenue from that ordinary business, selling the merchant’s own goods, or using agent output does not by itself commercialize the platform. The proposed self-use permission would allow installing, running, copying and modifying covered software for those purposes, retaining applicable notices. It does not promise free hosted subscriptions, unlimited usage, infrastructure, model inference, messaging, telephony, payment processing or third-party services. Their applicable plans and charges remain separate.What would require an agreement
Before commercially offering covered platform software or capabilities to other parties, obtain a written agreement with Orchestrum Technologies LLP. Examples:- Reselling or sublicensing covered software as a paid product.
- Operating paid hosted or managed platform access for third parties.
- White-labeling the platform or embedding its agent/runtime capabilities in a product or service sold to third parties.
- Selling third-party access to a platform-based agent service.
Scope of a future license
Only an explicitly identified future release and material for which Orchestrum has the necessary licensing rights could adopt the finalized new terms. A release manifest must identify covered files, versions and artifacts, excluded Apache-licensed material, and third-party notices. The policy must not claim exclusive rights over external contributions without supporting rights records. Already-granted Apache-2.0 permissions remain in place for that material, including commercial rights, forks and copies. Republishing the same code or changing a footer does not withdraw those permissions. Future modifications may have different terms only where authorized; retained Apache components still carry their original license and notice obligations. Third-party dependencies retain their own licenses. Protocol specifications, published interoperability contracts, SDKs and examples must each have an explicit release-by-release licensing decision; this proposal does not silently relicense them. Ownership and trademark notices do not override any software license.Source availability and distribution
If adopted, a license restricting commercialization would be source-available, not an OSI-approved open-source license. Do not call it Apache-2.0 with an added commercial restriction or advertise restricted releases as unrestricted open source. The candidate text defines self-use, commercialization, noncommercial sharing, data/output boundaries, proposed patent permission, trademarks, separate hosted charges, disclaimers and a proposed notice/cure process. Publication approval is recorded, not software adoption or a guarantee of enforceability. Source-specific rights clearance, exact scope and release details are still required. Existing source-license disclaimers continue to apply to existing releases.Exact application to a future release
For each covered entry inlicensing/scope.json, record the exact repository
path, SHA-256 content hash, license identifier and non-sensitive rights-clearance
reference. Keep contracts and personal/legal evidence outside the public repository.
Record the approved release version, effective date and owner/legal approval
references before changing the manifest’s status to an active software adoption.
Only then apply the finalized custom-license header to the eligible new material
and publish matching package notices. Keep retained Apache notices where they
belong. Packages containing both types need an accurate mixed-license description,
not an Apache-only label or an unsupported claim of exclusive ownership.
Future contributors to that covered material must expressly agree to reviewed
contribution terms that let Orchestrum grant the intended self-use and commercial
permissions. Current Apache contribution terms do not automatically create those
rights or assign contributors’ copyrights.
Do not infer eligibility from an author name or from the reference baseline’s
date. Keep already Apache-distributed material outside the exclusive commercial
claim, even if its current file hash changes.
No licensing phone-home, agent transaction check, credential collection, runtime
lockout or billing change is introduced by this documentation work.
Before a software release adopts the license
- Publication and legal-review approval were supplied by the owner on 12 October 2026. Keep that approved text and its provenance distinct from source-specific rights clearance and software release adoption.
- Verify copyright ownership and contributor agreements for each covered item; preserve grants for material Orchestrum cannot relicense exclusively.
- Approve the exact release/file manifest, final license text and effective date. No effective date is implied by the preparation date above.
- Publish the final license and changelog; align covered file headers, package metadata, registries, documentation, READMEs and public notices. Do not alter third-party or legacy-license labels. Update contribution/header-check instructions for the approved covered scope, and include the applicable license texts/notices in images and distributions.
- Keep historic releases and their licenses accessible. Give hosted customers appropriate notice and obtain required contractual acceptance separately.
- Review the website’s quiet footer link for readability and discoverability; material terms must not be hidden or implied to be already accepted.