OreBolt-OS/LICENSE.md

OreBolt OS v1.7 -- 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
retro_input_mapper	GPL-2.0+	GPL-2.0-or-later	overlay/usr/bin/retro_input_mapper
liborebolt.a (static hw lib)	GPL-2.0+	GPL-2.0-or-later	liborebolt.a, src/modules/*.c
17 userland modules	GPL-2.0+	GPL-2.0-or-later	modules/orebolt-{vault,nettaps,...,proxalarm}/*.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 17 userland modules (vault, pauto, 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 17 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).

8. BitChat Naming: Nominative Fair Use

The bitchat module is an independent C implementation of the BitChat decentralized mesh protocol. It is not affiliated with, sponsored by, or endorsed by Permissionless Tech, LLC or the original creators of BitChat.

The name "bitchat" is used under nominative fair use -- it describes what protocol the module implements, not an attempt to imply sponsorship or endorsement. The module directory (orebolt-bitchat/) and the OreBolt OS project name provide clear branding distinction from any official BitChat product.

No official BitChat logos, icons, or visual assets are used. The wire protocol (BITCHAT_MSG_* message types) is implemented from the open-access BitChat protocol whitepaper and the permissively-licensed open-source client reference implementations (iOS: Unlicense/Public Domain; Android: MIT License).

This naming convention is consistent with industry practice for third-party protocol libraries (e.g., libbitchat, bitchat-c, bitchat-sys in Rust).

9. 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.