Harpy OS is an experimental operating-system project exploring a capability-based microkernel architecture built around isolation, least authority, user control, and software freedom.
The project is intentionally being defined from first principles rather than as a distribution or repackaging of an existing general-purpose operating system.
Phase 0 — Architecture, requirements, and design decisions.
Harpy OS is currently pre-bootstrap. There is no production-ready implementation yet. This repository establishes the public architecture, security model, freedom requirements, licensing scheme, and development milestones before substantial source code is introduced.
Harpy OS aims to explore an operating system in which:
- authority is explicit rather than ambient;
- services and drivers are isolated wherever practical;
- the trusted computing base remains small and reviewable;
- the legitimate owner remains the highest authority over the machine;
- normal local operation does not require telemetry, cloud accounts, or remote vendor authorization;
- original project software remains Free Software;
- components are inspectable, replaceable, and reproducible where technically practical.
Applications
────────────────────────────────────
System APIs / libraries / runtimes
────────────────────────────────────
User-space system services
────────────────────────────────────
User-space drivers
────────────────────────────────────
Capability-based microkernel
────────────────────────────────────
Hardware
Higher-level policy is intended to live outside the kernel whenever practical. Components should receive only the authority and resources necessary for their roles.
Harpy OS is not intended to be:
- a Linux distribution;
- a Linux From Scratch derivative;
- a desktop environment placed on top of an otherwise conventional system;
- a Linux virtual machine presented as the native operating system architecture.
Compatibility with existing software may be explored later, but compatibility mechanisms must not replace the native security model.
The current direction is:
- capability-based microkernel architecture;
- user-space drivers and major system services;
- explicit resource ownership and delegation;
- Rust preferred for new Harpy-specific components when practical;
- C and assembly retained where required by low-level interfaces, hardware work, or interoperability.
Implementation details remain subject to validation through small prototypes and recorded design decisions.
The project has adopted a category-based licensing scheme:
| Artifact | Default project license |
|---|---|
| Original Harpy OS system software | GPL-3.0-or-later |
| Harpy libraries explicitly intended for application linking | LGPL-3.0-or-later |
| Project documentation | CC-BY-SA-4.0 |
| Future original RTL / PCB / hardware design sources | CERN-OHL-S-2.0 |
| Third-party material | Upstream license retained |
See Licensing Policy and License Notice for scope and exceptions.
- Manifesto
- Architecture
- Security Model
- Design Decisions
- Roadmap
- Licensing Policy
- Technical References
- Freedom Requirements
- Requisitos de Liberdade — pt-BR
- Freedom Bill of Materials
The repository grows only when corresponding artifacts exist. Implementation directories such as services/, drivers/, libs/, and userland/ will be introduced when implementation work reaches those areas.
HARPY-OS/
├── README.md
├── ROADMAP.md
├── LICENSE.md
├── CONTRIBUTING.md
└── docs/
├── MANIFESTO.md
├── ARCHITECTURE.md
├── SECURITY_MODEL.md
├── DESIGN_DECISIONS.md
├── LICENSING.md
├── REFERENCES.md
└── freedom/
├── README.md
├── FREEDOM_REQUIREMENTS.md
├── FREEDOM_REQUIREMENTS.pt-BR.md
└── FREEDOM_BOM.md
The owner of a machine should remain the highest authority over that machine.
Security mechanisms should protect the owner from unauthorized parties, not make a manufacturer or remote service a permanent authority over the owner.