We use self-hosted Matomo analytics. By default we measure anonymously with no cookies. Enable cookies to give us a clearer picture and help us improve your experience. You can change this anytime.
Engineering · Linux Driver
GPL code, in the open, free to audit
We are asking you to load our code into the kernel of a production server and let it sit in the write path of a live disk. That is not something anyone should accept on a vendor's word. So the driver, its test harness, its build pipeline and its documentation are all published under strong copyleft licences, and the issue tracker that triages bugs in them is the same one our engineers work from.
The strongest copyleft each part can legally carry
We deliberately chose the most restrictive licensing the code is allowed to have, on the reasoning that infrastructure people are asked to trust should stay free for everyone downstream — including from us. That produces two licences rather than one, and the split is not arbitrary.
The kernel module
GPL-2.0-only
kernel/ — the .ko that loads into your running kernel
Not a preference. Linux itself is GPL-2.0-only, and a module that links against kernel headers and exported symbols has to be GPL-2.0-compatible to be distributable at all. MODULE_LICENSE("GPL") is the same assertion made to the kernel at load time, and it is what grants access to GPL-only exported symbols. A proprietary or AGPL-licensed .ko would be neither lawful nor loadable on the terms the kernel offers.
Everything in userspace
AGPL-3.0-only
the control CLI, the C++ integration library, the Python bindings, the test harness, the packaging and the examples
These are separate programs that talk to the driver through ioctls rather than linking into the kernel, so they are free to carry stronger terms — and AGPL-3.0 is the strongest copyleft the GPL family offers. It closes the network loophole: anyone who takes this code, modifies it, and offers backup as a service over a network owes their users the modified source, whether or not they ever ship a binary.
Why not AGPL for the whole thing
Because it would not be valid. AGPL-3.0 and GPL-2.0-only are not compatible in either direction, and the Linux kernel is GPL-2.0-only with no upgrade clause. A kernel module released under AGPL could not lawfully be distributed as a derivative work of the kernel, and would fail the MODULE_LICENSE check that gates the GPL-only symbols the driver depends on. Vendors who claim an AGPL kernel module are either wrong about the law or shipping something that will not load. We would rather be accurate about what each file can carry than uniform and unenforceable.
Only, never "or later"
Both halves are pinned with -only rather than -or-later. An "or later" grant hands recipients the terms of a licence version nobody has read yet. Pinning means the bargain cannot be loosened by a future revision.
Network use counts as distribution
AGPL section 13 is the clause the GPL lacks. A competitor who builds a hosted service on our userspace tooling cannot keep their modifications private by never handing anyone a binary.
Patent retaliation and anti-tivoization
AGPL-3.0 carries GPLv3's patent grant and its installation-information requirement, so a vendor cannot ship the code on hardware that refuses to run a modified copy of it, nor sue you over patents they contributed.
No CLA, no dual licence
We do not ask contributors to sign copyright away, which means we could not quietly relicense this proprietary later even if a future version of us wanted to. The copyleft is structural, not a promise.
What this means for you as a user
You may read, build, modify and run the driver on any machine you like, with or without a ShadowCradle subscription.
You may keep private modifications private, as long as you do not distribute them or offer them as a network service.
We cannot take it back. There is no contributor licence agreement letting us relicense this proprietary later.
Every file states its licence in an SPDX header, so an automated compliance scan of your fleet gets a straight answer.
Licence questions that need an answer in writing: legal@shadowcradle.com.
What is actually open
"Open source" often means a published tarball and a private build. Here the tests, the pipeline and the failures are in the same repository as the code, which is the part that lets you check our claims rather than read them.
The driver source
Roughly 7,200 lines of C and 1,900 of headers, including every path that touches a write on your production disk.
The full test harness
All five suites, the QEMU runner, the crash-consistency scenarios and the fault-injection framework — not just the results.
The CI definition
The pipeline that builds, boots and packages every commit, readable line by line, including which failures are allowed to be soft.
The kernel matrix
Which kernels are covered and, in comments, exactly why each one is in the list.
What has not been proven yet is written down in the repository, because a gap nobody records is a gap nobody closes.
You can also reproduce it. ./sandbox.sh doctor tells you what your host is missing, and ./sandbox.sh all builds the module, boots it in a throwaway VM and runs every suite. Nothing loads into your host kernel at any point. How that pipeline works →
Report it where the engineers are
Bugs in the driver go straight to the project tracker and are triaged by the people who wrote it. A report does not travel through a support queue first, and you do not need to be a customer to file one.
1
File it in the repository
Issues go to the project tracker, not to a support inbox that forwards them. Anyone can open one — customer, contributor, or someone who has never spoken to us.
2
Triaged by the engineers who wrote it
The same people who maintain the driver read the tracker. There is no tier-one layer between a kernel bug report and a kernel developer.
3
Reproduced as a test
A confirmed bug becomes an assertion in one of the suites before it is fixed, so the fix is proven and the regression cannot come back unnoticed.
4
Fixed in public
The commit, the test that proves it and the pipeline run that booted it on every supported kernel are all visible on the issue.
What to put in a report
Kernel version and distribution (uname -a), and whether the module came from a package or was built locally
The filesystem and device layout underneath the traced device
Everything the module logged — dmesg output around the failure is usually the whole story
What you expected to happen, and what happened instead
A reproducer if you have one; a description of the workload if you do not
A vulnerability in code that runs in ring 0 should not be described in a public tracker before there is a fix. Send those to security@shadowcradle.com instead. We will confirm receipt, work the fix privately, and publish both the issue and the patch once a release carrying it exists.
Patches are welcome on the same tracker. A change that touches the write path is expected to arrive with the assertion that proves it, and the pipeline will boot it on every supported kernel before anyone argues about it.