Skip to content

ADR 0101: Licensing and commercialization strategy

Status: Accepted
Date: 2026-04-26

ADR Role
0009 related ADR
0024 related ADR
0027 related ADR
architecture-policy.md outside numbered ADR

Summary

  • License matrix and dependency rules (copyleft, commercialization).
  • Guardrails for stack choice and artifact publication.
  • Governance — alongside 0100.

1. Context

CascadeIDE plans to remain open source while preserving commercialization options (cloud services, enterprise services, support, custom integrations).
The project also considers AI and runtime dependencies with different license models, including “strong” copyleft.

Without explicit policy, dependency decisions can drift and create future IP conflicts (distribution limits, re-licensing risk, due diligence risk, contributor uncertainty).

2. Decision

Adopt open source with commercial options licensing strategy:

  1. CascadeIDE code in this repository is distributed under MIT (see root LICENSE); commercial services and public contacts — COMMERCIAL-NOTICE.md.
  2. Default distribution path uses only licenses from the base allowed list.
  3. “Strong” copyleft components (GPL/AGPL family) are forbidden in core and runtime without separate approved ADR exception.
  4. Commercialization remains open via:
  5. managed cloud offerings,
  6. enterprise extensions,
  7. support/consulting/training.
  8. Each new external dependency is reviewed and recorded with license metadata.

3. License policy matrix

3.1 Allowed by default

  • MIT
  • Apache-2.0
  • BSD-2-Clause
  • BSD-3-Clause

3.2 Allowed with explicit review

  • MPL-2.0
  • LGPL family

Review criteria for this group: - linking and deployment model, - obligations on modified files/libraries, - impact on packaged desktop distribution.

3.3 Restricted (ADR exception required)

  • GPL family
  • AGPL family
  • SSPL
  • custom non-commercial / source-available terms limiting business use

4. Dependency management rules

For each new package or library:

  1. Record:
  2. package name,
  3. version,
  4. source URL,
  5. declared license,
  6. notable transitive license risks.
  7. Add and update project notices in docs/THIRD-PARTY-NOTICES.md.
  8. Ensure CI license checks fail on:
  9. forbidden licenses,
  10. unknown/unapproved licenses.

5. Architectural guardrail for forbidden licenses

If a component with forbidden license is considered:

  1. Start with PoC assessment outside core delivery path.
  2. Run legal and product review (obligations, distribution model, update policy).
  3. Allow only via separate ADR exception with rollback plan.

Do not assume “automatic safety” from process boundaries alone (e.g. sidecar/process split) without explicit legal review.

6. Commercialization model (non-exclusive)

Open source core is compatible with commercial scenarios via:

  • cloud and managed services,
  • enterprise add-ons,
  • paid support/SLA,
  • consulting and implementation.

This ADR does not fix a single monetization path; it preserves flexibility while supporting dependency hygiene.

7. Consequences

Positive

  • Clear contribution and dependency rules.
  • Cleaner IP chain for future due diligence.
  • Lower risk of accidental license blockers.

Negative

  • Some technically attractive libraries may be excluded from core.
  • More process load when adding dependencies.

8. Rollout plan

  1. ~~Add license-policy.md (short developer policy).~~ Done: ../../license-policy.md.
  2. ~~Add/maintain THIRD-PARTY-NOTICES.md.~~ Done: ../../THIRD-PARTY-NOTICES.md (copied on publish via CascadeIDE.csproj).
  3. Add CI license check as required gate.
  4. Run baseline dependency license audit and remediate findings.
  5. Track exceptions in separate ADRs.