Licensing & the Open Commons
Today, our entire codebase is licensed under AGPL. We're changing that: extensions move to the permissive Apache 2.0 license, while the core stays AGPL. Here's what each part is, why we're making the change, and why it takes a few deliberate steps rather than a single switch.
The core stays AGPL 3.0 to keep the foundation open and un-closable. Extensions move to Apache 2.0 so anyone — researchers, clinicians, and companies — can freely build on and adopt them. Same open commons, more room to build.
Openwater is built in two layers. Each layer has a license chosen for what it needs to do.
Open-LIFU and Open-Motion — the engine everything else is built on.
Keeping the core AGPL protects the open commons. No one can take our foundation, make it proprietary, and close it off. This is what keeps Openwater "the Linux of medical devices."
Includes: Open-LIFU firmware & planning software, Open-Motion acquisition & imaging stack, the shared platform libraries.
Integrations and plugins that connect Openwater to other tools — e.g. the SlicerOpenLIFU extension for the 3D Slicer imaging platform.
Apache 2.0 is permissive, so researchers, clinicians, and companies can freely adopt and build on our extensions for both academic and commercial use.
Includes: SlicerOpenLIFU, tool integrations, SDK adapters, sample plugins, and reference connectors.
A single license can't do two jobs at once. Splitting the layers lets each one serve its purpose.
AGPL's copyleft on the core guarantees the foundation stays open. Improvements flow back, and the platform can never be quietly forked into a closed product.
AGPL's obligations can deter companies and some institutions from building on top. Apache 2.0 on extensions removes that friction, so the ecosystem around the platform can grow.
Like Red Hat with Linux, Openwater keeps the platform open and builds sustainable revenue through services. Permissive extensions are what make commercial adoption — and that model — viable.
Changing a license isn't a single switch. Doing it right protects contributors and keeps the project on solid legal footing.
Before anything can be relicensed, we clearly delineate what is foundational platform (stays AGPL) and what is an extension (moves to Apache 2.0) — repository by repository.
A CLA gives the project the rights it needs to relicense extension code cleanly. It's straightforward and standard, and it protects both the contributor and the project through the transition.
Code already contributed under AGPL needs contributor sign-off before it can move to Apache 2.0. We work through this history deliberately rather than assuming consent.
Once the groundwork is done, extension repositories are relicensed to Apache 2.0 with clear headers and NOTICE files, so everyone can see exactly what applies where.
The target model once the transition completes. Extensions are moving from AGPL to Apache 2.0 as the manifest and relicensing land — so while the switch is underway, always check the LICENSE file in the specific repository. It is the source of truth today.
| Component | Layer | License | What you can do |
|---|---|---|---|
| Open-LIFU platform | Core | AGPL 3.0 | Use, modify, and share — derivative works and network use stay open. |
| Open-Motion platform | Core | AGPL 3.0 | Use, modify, and share — derivative works and network use stay open. |
| SlicerOpenLIFU extension | Extension | Apache 2.0 | Adopt and build on it freely, including in commercial products. |
| Tool integrations & plugins | Extension | Apache 2.0 | Adopt and build on it freely, including in commercial products. |
| Hardware designs & docs | Reference | Open hardware / docs | See each repository's LICENSE; designs and documentation are shared openly. |
The short version, by how you work with the platform.
Nothing you rely on disappears. The core stays open under AGPL, and extensions become easier to adopt and integrate into your own tooling and pipelines.
You'll be asked to sign a simple CLA. It's standard, it protects your work, and it's what lets us relicense extensions cleanly. Core contributions remain AGPL.
Apache 2.0 extensions give you a permissive, commercially-friendly path to build on Openwater. The AGPL core keeps the shared foundation trustworthy and open.
The technology stays transparent and inspectable end to end. Open licensing is part of why you can trust what the device does and how it does it.
We're moving from "everything AGPL" to a two-layer model — one deliberate step at a time, not a single overnight switch.
Until now, the entire codebase — both the core platform and the extensions built around it — has been licensed under AGPL 3.0.
The work happening now: building the manifest that defines what counts as core (stays AGPL 3.0) versus an extension (moving to Apache 2.0), and putting the Contributor License Agreement in place. Until that manifest exists, everything remains AGPL.
Once the boundary is set, existing extension contributions are cleared and the extension repositories move from AGPL to Apache 2.0 with clear license headers.
A two-layer commons: an un-closable AGPL foundation with a permissive, build-friendly Apache 2.0 extension ecosystem around it.
No. The core stays under AGPL — the strongest guarantee of openness — and the extensions become more accessible by moving to a permissive license. Both layers remain open source.
The two layers have different jobs. AGPL's copyleft is ideal for protecting a shared foundation, but it can deter others from building on top. Apache 2.0 is ideal for encouraging broad adoption but wouldn't protect the core from being closed off. Using each where it fits gives us the best of both.
AGPL 3.0 is a strong copyleft license: derivative works — including software offered over a network — must also be shared under AGPL. Apache 2.0 is permissive: you can use, modify, and redistribute the code, including in proprietary and commercial products, with minimal obligations (mainly attribution).
For extension code that's moving to Apache 2.0, we'll ask you to sign a Contributor License Agreement and, where needed, confirm sign-off on your existing contributions. It's a standard, lightweight step that protects both you and the project. Core (AGPL) contributions are unaffected.
Yes — that's part of the point. Apache 2.0 extensions give you a clean, commercially-friendly path. If you build on or modify the AGPL core, the copyleft obligations of AGPL apply to that work. As always, review the LICENSE in the specific repository and consult your own counsel for your situation.
Check the LICENSE file at the root of that repository — it is the authoritative answer. The table above is a guide, but individual repos are the source of truth.
Reach the community team, or jump into the discussion on Discord — we're happy to walk through what applies to your project.
Explore the repositories, see the licenses for yourself, and start contributing.
This page is a plain-language overview of Openwater's licensing approach and is provided for general information. It is not legal advice. The LICENSE file in each repository is the authoritative and binding statement of the license that applies to that code.