Bitcoin-OS Licensing Strategy

A disciplined architectural approach to building an open-source platform that maximizes community contribution while managing intellectual property through atomic contracts.

Back to Issues Hub View Implementation

Executive Summary

Open Source Core

License: AGPL v3.0

Structural Goal: To build a robust, open-source platform that maximizes community contribution (via AGPL) while legally managing intellectual property contributions from the decentralized "Atomic Contracts System" (via CLAs).

Key Challenge: Managing the licensing boundaries between community contributions and commercial operations.

Dual Licensing Model

The Bitcoin Corporation employs a dual licensing strategy that allows it to:

Accept open-source contributions under AGPL
Re-license contributed code for commercial purposes via CLAs
Maintain clear licensing zones with API boundaries

Part 1: Architectural Mandate - The "AGPL Containment" Strategy

Core Principle: License Zone Separation

Bitcoin-OS must be architected with clear API boundaries that separate AGPL-licensed components from proprietary business logic. This enables dual licensing without viral license propagation.

AGPL Zone

• Core Bitcoin-OS platform
• Web shell interface
• Application framework
• Community contributions

API Boundary

• Well-defined interfaces
• RESTful APIs
• Message queues
• Service contracts

Proprietary Zone

• Business logic
• Payment processing
• Enterprise features
• Commercial services

Implementation: Microservices Architecture

Each Bitcoin-OS component must be deployed as an independent service with clear API contracts:

1
Service Isolation
Each service runs in its own process/container with defined network boundaries
2
API-First Design
All inter-service communication happens through documented APIs, never through shared code
3
License Boundaries
AGPL components can only be accessed through network APIs, preventing license contamination

Part 2: Jobs Queue & CLA Integration

The "Atomic Contracts" are not just technical tasks; they are legal agreements. Every piece of work farmed out must be managed via a system that ensures IP is properly transferred.

Contract Execution Requirements

1
Pre-Work CLA Acceptance
Before a developer can claim any job from the queue, they must digitally sign the Contributor License Agreement. This is a one-time process that grants The Bitcoin Corporation the necessary rights to all future contributions.
2
Automated Verification
The jobs queue system must automatically verify CLA status before allowing job claims. No exceptions can be made to this rule.
3
The contract execution system must not grant payment until the developer's work is successfully merged into the AGPL Zone repository and the accompanying CLA is verified as accepted

CLA Requirements

CLA Function

The CLA must explicitly grant The Bitcoin Corporation Ltd a non-exclusive, irrevocable, worldwide, royalty-free license (or full assignment) to the contributor's code, including the right to re-license the code.

Git Integration

Every commit must be tagged with CLA status. Use git commit signing or a bot that verifies CLA status before allowing merges.

Enforcement

No code can be merged without CLA verification. This must be enforced at the CI/CD level.

Part 3: Developer Implementation Guide

Code Submission Checklist

Requirement	Action
CLA Signed	Ensure you have signed the CLA before claiming any job
License Header	Must include a license header at the top of every new file, clearly stating `"Licensed under AGPL v3.0, and contributed under The Bitcoin Corporation CLA."`
API Boundaries	Ensure all service communication happens through documented APIs
No License Mixing	Do not mix AGPL code with proprietary code in the same service
Documentation	Document all API endpoints and service boundaries

Creating Service Boundaries

When building new features for Bitcoin-OS, always consider the licensing implications:

1. Service Structure

bitcoin-os/
├── services/
│   ├── core/           # AGPL Zone
│   │   ├── web-shell/
│   │   ├── app-framework/
│   │   └── file-system/
│   ├── api/            # API Boundary Layer
│   │   ├── rest/
│   │   ├── graphql/
│   │   └── websocket/
│   └── business/       # Proprietary Zone (separate repo)
│       ├── billing/
│       ├── analytics/
│       └── enterprise/

2. User-Facing Source Code Provision (AGPL Compliance)

Because Bitcoin-OS is an online service (SaaS), you must comply with the AGPL's most important clause:

AGPL Section 13: Remote Network Interaction

Users interacting with Bitcoin-OS remotely through a network must be provided an opportunity to receive the source code.

Action for Claude Code
Implement a visible link (e.g., in the footer of the Bitcoin-OS web shell) labeled"Get the Source Code (AGPL)"
Source Provision
Link must provide access to the exact version of the source code corresponding to the running instance (use git tags/releases)

3. API Documentation Template

"This API represents a licensed boundary. Consumers of this API should be aware that the code within this module is licensed under [MIT/OpenBSV/AGPL v3.0] and should ensure their client code is compliant with all relevant terms."

Implementation Checklist for Claude Code

Immediate Actions

Set up CLA signing infrastructure
Implement CLA verification in jobs queue
Add AGPL source code link to web shell
Create service boundary documentation

Ongoing Requirements

Review all new services for license compliance
Maintain clear API documentation
Enforce CLA requirements in CI/CD
Keep source code availability current

Legal Notice

This licensing strategy is designed to ensure compliance with open-source licenses while enabling commercial operations. It is critical that all developers and contributors understand and follow these guidelines.

Note: This document provides architectural guidance. For legal advice specific to your jurisdiction, consult with qualified legal counsel.