It's not protected by the copy-left properties of the kernel D:
For the more technical points:
The kernel needs to have it available in a somewhat complex way to be able to mount the drive.
I.e. init becomes a lot more involved with an initram that first needs to load the driver (potentially loopback it?) and the mount actual root.
To some degree there can also be issues around syscall boundaries. I.e. the usual monolith vs. microkernel.
I haven't checked the API they hook into to provide the device to other components. But it likely requires the kernel to jump back into userspace in various "hot-ish" paths for IO.
Ok, it doesn't integrate with the system at all.
This provides a library to access the device.
I.e. it can only be used by a single consumer, that consumer doesn't get nice things like ther kernel's file systems or device mapper (raid/crypt/verity...) features.
This can be fine, e.g. when the consumer is a database that just needs a block device, or something like ceph/minio etc. that provides the storage api to its consumers.
It'd have to use something like NBD (~fuse for block devices) to actually integrate and then my previous post describes some of the downsides to that setup.
For the more technical points:
The kernel needs to have it available in a somewhat complex way to be able to mount the drive. I.e. init becomes a lot more involved with an initram that first needs to load the driver (potentially loopback it?) and the mount actual root.
To some degree there can also be issues around syscall boundaries. I.e. the usual monolith vs. microkernel. I haven't checked the API they hook into to provide the device to other components. But it likely requires the kernel to jump back into userspace in various "hot-ish" paths for IO.