According to the
NdisWrapper Wikipedia entry, it will not be ported to OpenBSD per the Project's anti-blob policy.
AFAICT, the statement was a fabricated assumption, produced without clear knowledge of Project policy.
It is true that blobs will never be allowed in the OS itself, /etc/firmware excluded. (Code in /etc/firmware is uploaded into peripheral hardware, and is not part of the executable OS.)
Ports that install binary objects have been available for OpenBSD for a long time. Opera is a prime example.
I know nothing about ndisulator, but a quick look at the major OpenBSD mailing lists and the OpenBSD Journal show no mention of it at all, other than a one-time reference regarding another subject, in misc@.
If someone were to develop and submit a port, it might very well be deemed acceptable and added to the tree. (At least until someone develops and submits one, this is conjecture of course.)
It may or may not be possible to port to the OS. But, if a functional port is crafted, blob acceptability should not be an issue. As it would be 3rd party software that is used to execute other 3rd party software, problems introduced are considered self-inflicted wounds. It doesn't matter if it was due to a blob in userland or a blob in a kernel module. Repairing the problem is the responsibility of the installing user, and perhaps with the voluntary and best-effort assistance of the port maintainer.