OreBolt-OS/LICENSE.md

# OreBolt OS v1.4 -- Multi-Tier Licensing Strategy

> **TL;DR** -- bitchat mesh module is **AGPL-3.0-only**.  Everything else in
> OreBolt OS is **GPL-2.0-or-later**.  LVGL/lv_drivers stay **MIT** (upstream).
> The AGPL boundary is a single .mod binary; it does **not** virally relicense
> the rest of OreBolt OS because the rest of OreBolt OS is not a derivative work of
> bitchat.  See §4 for the boundary analysis.

---

## 1. Why AGPL for the bitchat layer

The bitchat mesh layer is the only OreBolt OS component that runs as a
**networked service** -- every other module is a local LVGL UI panel that
talks to hardware through `/dev` or GPIO.  When a bitchat node forwards a
message to another node, every operator downstream of that node is
"interacting with the software over a network" within the meaning of
AGPL v3 §13.  Pure GPL would not require source disclosure for that kind of
network-only interaction; AGPL does.

This matters because the whole point of the bitchat layer is to let H2
devices form a mesh that survives the loss of any single node.  If an
operator forks bitchat, hardens it, and runs the hardened version on their
node, every other mesh participant is effectively trusting that hardened
binary without being able to inspect it.  AGPL v3 §13 closes that loophole
by requiring the operator to make their modified source available to anyone
who interacts with their node over the mesh, via the "Written Offer"
mechanism in §13(d).

AGPL v3 §6 (User Product) is the second reason this license fits the H2.
Section 6 requires that anyone distributing a "User Product" (consumer
device) running AGPL software must allow the user to install modified
versions of that software.  This blocks **tivoization** -- the practice of
shipping GPL/AGPL software on locked-down hardware that refuses to run
user-modified builds.  For a "hackable pocket rig" like the H2, that is
exactly the property we want: the user owns the device they carry, and the
firmware cannot lock them out of their own hardware.

## 2. License matrix

| Component | License | SPDX | Files |
|---|---|---|---|
| LVGL v8.3.11 (upstream) | MIT | `MIT` | `lvgl/**` (cloned at build time) |
| lv_drivers v8.3.0 (upstream) | MIT | `MIT` | `lv_drivers/**` (cloned at build time) |
| liblvgl.so (shared) | MIT | `MIT` | `overlay/usr/lib/liblvgl.so` |
| h2_test (launcher) | GPL-2.0+ | `GPL-2.0-or-later` | `overlay/usr/bin/h2_test`, `main.c` |
| emulator_input_mapper | GPL-2.0+ | `GPL-2.0-or-later` | `overlay/usr/bin/emulator_input_mapper` |
| liborebolt.a (static hw lib) | GPL-2.0+ | `GPL-2.0-or-later` | `liborebolt.a`, `src/modules/*.c` |
| 15 userland modules | GPL-2.0+ | `GPL-2.0-or-later` | `modules/orebolt-{vault,nettaps,...,pwdb}/*.c`, `overlay/apps/*.mod` |
| **bitchat mesh module** | **AGPL-3.0-only** | **`AGPL-3.0-only`** | `modules/orebolt-bitchat/bitchat.c`, `src/modules/mod_bitchat_mesh.c`, `overlay/apps/bitchat.mod` |
| Init scripts | GPL-2.0+ | `GPL-2.0-or-later` | `overlay/etc/init.d/*` |
| Documentation | CC-BY-4.0 | `CC-BY-4.0` | `*.md`, `*.txt` |

## 3. The AGPL boundary -- what is and is not covered

The AGPL v3 §13 "Modified Corresponding Source" obligation extends to:
- the bitchat module source (`mod_bitchat_mesh.c` and `modules/orebolt-bitchat/bitchat.c`)
- any modifications an operator makes to those files
- the corresponding source for any libraries bitchat links against **that
  are themselves AGPL** (none, in our case -- it links against MIT LVGL and
  GPL-2.0+ liborebolt.a)

The AGPL obligation does **not** extend to:
- The other 15 userland modules (vault, ducky, etc.) -- they are separate
  programs that happen to share a launcher and a UI library.  They are not
  derivative works of bitchat.
- `liborebolt.a` -- bitchat links TO liborebolt.a, not the other way around.
  A library that is linked against is not automatically a derivative work
  of every program that links against it.  See FSF FAQ on aggregate vs.
  derivative works.
- `liblvgl.so` -- MIT, so AGPL's viral clause has nothing to grab onto.
- The H2 hardware itself -- software licenses do not license hardware.  The
  AGPL §6 User Product clause governs how the software may be installed on
  the hardware, but does not place restrictions on the hardware design.

## 4. Operator obligations when modifying bitchat

If you modify `mod_bitchat_mesh.c` or `bitchat.c` and run the modified
version on an H2 that other operators interact with over the mesh, you
must, under AGPL v3 §13(d):

1. Make the modified source code available via a Written Offer, valid for
   at least three years, to any operator who interacts with your node.
2. The Written Offer must specify a reasonable cost for physically
   transmitting the source (no more than the actual cost).
3. The source must include the corresponding source of all libraries
   bitchat links against that are themselves AGPL-licensed (in our case,
   none beyond bitchat itself).

The build embeds `BITCHAT_SOURCE_URL` (defined in `mod_bitchat_mesh.c`) in
every `bitchat.mod` binary.  Every mesh HELLO message advertises this URL
to peers via the `BITCHAT_MSG_LICENSE` message type -- so operators
downstream of a modified node are automatically informed of their source
rights.  **Before shipping, replace the placeholder
`https://example.invalid/orebolt-bitchat-src` with the actual Written
Offer URL.**

## 5. Why not AGPL the whole stack?

Three reasons:

1. **Anti-tivoization is already covered by GPL-2.0+ for the other 15
   modules.**  GPL v2 §3(c) and GPL v3 §6 already require installable
   source for User Products.  AGPL's §6 is functionally identical to GPL
   v3 §6 -- the only thing AGPL adds is §13 (the network-interaction
   clause), which only matters for components that interact over a
   network.  Only bitchat does that.

2. **AGPL §13 would actually hurt the other modules' adoption.**  If
   vault.mod were AGPL, anyone who set up a vault "service" (e.g. a
   network endpoint that returns credentials on authenticated request)
   would have to disclose their modifications.  That is not the threat
   model for vault -- vault's threat model is "the device falls into the
   wrong hands" (handled by panic_purge), not "someone operates a forked
   vault server."

3. **Clean module boundaries are a feature, not a bug.**  By isolating
   the AGPL boundary to a single .mod binary, we make it trivial for an
   operator to know exactly what they need to share source for.  If
   everything were AGPL, every operator would need to share source for
   every modification, and the friction would discourage legitimate
   device customization.

## 6. Practical compliance checklist

Before deploying a modified H2 with bitchat:

- [ ] Replaced `BITCHAT_SOURCE_URL` placeholder with a real URL pointing
      to your modified bitchat source (tarball, git repo, or Written
      Offer page).
- [ ] The URL is reachable from the mesh (or you have a Written Offer
      ready for physical media delivery).
- [ ] The URL stays valid for at least 3 years from first deployment.
- [ ] You bumped `BITCHAT_PROTOCOL_VERSION` if you changed the wire
      format (so unmodified nodes can refuse to interoperate cleanly
      rather than silently misbehaving).
- [ ] `make core` succeeds and `build.sh` Phase 7 verifies that
      `bitchat.mod` carries the `AGPL_BITCHAT` marker.
- [ ] The H2 firmware allows installing a modified `bitchat.mod` (i.e.,
      the device is not tivoized against AGPL §6).

## 7. If you want to relicense the whole stack

If a future version of OreBolt OS decides to put everything under AGPL, the
only blockers are:

1. Any GPL-2.0-only code (we deliberately used GPL-2.0-or-later to permit
   this upgrade path).
2. Any contributor who has not signed off on the upgrade -- you need
   their consent or you need to rip their code.  A `DCO` (Developer
   Certificate of Origin) sign-off at contribution time makes this
   tractable.

LVGL being MIT means there is no upstream-license blocker.  The bitchat
module is already AGPL-3.0-only, which is one-way (you cannot downgrade
to GPL).  Plan accordingly.