ADR-001: Licensing Strategy
Status
Section titled “Status”Accepted (2025-03-01)
Context
Section titled “Context”paiOS is a commercial open-source project that needs to:
- Protect the core runtime from being forked without contributing back
- Allow proprietary extensions for any developer or commercial partner
- Ensure long-term sustainability: flexibility for future business models
- Maintain simplicity: avoid “Qt licensing pain”
The runtime communicates with extensions via gRPC over Unix Domain Sockets (IPC), similar to how Linux kernel syscalls create a boundary between the GPL kernel and user-space applications.
Decision
Section titled “Decision”We adopt a “Default AGPL, with Permissive Exceptions” model:
- Default: All files are licensed under AGPL-3.0 (per root
LICENSEfile). - Exception: Subdirectories with their own
LICENSEfile override the default.
pai-os/├── LICENSE (AGPL-3.0 = default for everything)├── NOTICE (Copyright & Trademarks)││ ✅ FREE TO USE (Apache-2.0)├── api/ ← All API definitions│ └── grpc/├── apps/ ← Your extensions go here││ 🔒 MUST SHARE CHANGES (AGPL-3.0)├── engine/ ← Runtime code├── os/├── scripts/└── docs/Contributor License Agreement (CLA)
Section titled “Contributor License Agreement (CLA)”We require a CLA (replacing DCO) to grant aurintex the right to:
- Ensure long-term sustainability: flexibility for future business models
- Maintain the project indefinitely with proper resources
- Protect the project’s right to defend its trademarks
IPC Boundary as License Boundary
Section titled “IPC Boundary as License Boundary”The gRPC/UDS communication between runtime and extensions creates a clear process separation:
flowchart TB
subgraph ext["✅ Your Extension"]
ext_node["Any license you want!<br/>Proprietary, MIT, Apache, closed..."]
end
subgraph runtime["🔒 paiOS Runtime"]
runtime_node["AGPL-3.0"]
end
ext_node -->|"gRPC over UDS<br/>(License Boundary)"| runtime_node This follows the same pattern as:
- Linux Kernel (GPL) + User-space apps (any license)
- Docker Engine (Apache-2.0) + Plugins (any license)
Shared Memory Constraint
Section titled “Shared Memory Constraint”Rule: Shared memory may only be used for raw byte buffers (images, audio PCM). Control signals and handles must go through gRPC.
Consequences
Section titled “Consequences”Positive
Section titled “Positive”- ✅ Clear separation: Runtime protected, extensions open
- ✅ B2B customers can write proprietary extensions
- ✅ Apache-2.0 provides patent protection for extension developers
- ✅ CLA enables future business model flexibility
- ✅ Simple: Only 2 licenses to understand
Negative
Section titled “Negative”- ⚠️ AGPL may deter some enterprise adopters (but this is intentional)
- ⚠️ CLA adds friction for contributors (mitigated by CLAassistant)
Related
Section titled “Related”- ADR-006: Extension Architecture: Why we use process isolation and gRPC (including why not shared memory for control)
- Licensing Guide: Practical FAQ for extension developers
- NOTICE file: Copyright and trademarks