This is a bit of an ill posed question as a "nonROS" machines are hard to define. As soon as you install or implement something that talks the ROS protocol it then makes it a non-"nonROS", or just a ROS machine.
As with any protocol you can implement it in different ways or with different languages. This is very clear as we have pure C/C++ implementations, pure python impelementations and pure java implementations to name a few.
If you were to implement on top of your DDS library enough to talk to the ROS system, you would effectively be writing a partial ROS 2 Client Library like the existing rclpy or rclcpp. Thus you wouldn't be using the most common implementation but you'd still be talking the ROS(2) protocol and thus from your question you'd be a "ROS machine". To that end though I would
It's also quite possible to bridge to another communication protocol such as a websockets based stream (ala rosbridge) or any other custom protocol (such as rosserial)
These are not talking the pure ROS protocol but are designed to be able to communicate ROS messages over another channel.
So for any generic machine that you want to communicate with a ROS system you can choose to use an existing ROS client library and integrate that into your system, implement your own client library(or partial implementation for the subset of features you need), or bridge to another protocol and forward messages back and forth.
From a practical standpoint it's is quite possible to communicate with ROS 2 just using pure DDS messages. But in reality you will effectively need to implement all of the functionality built into the existing client libraries, validate and test them. We've worked hard and have extensive testing to validate and cross validate all the of the existing implementations. There are a lot of corner cases under the hood that can catch you off guard until you get into the nuts and bolts of the implementation. In most cases it will be noteably more work to reimplement it all versus installing the ROS2 libraries necessary and integrating them. If you want to use a different DDS vendor there is an abstraction at the middleware level to allow adding support for a different vendor. And there are quite a few projects in the community for adding new language bindings on top of the core impelementation that the language specific implementations can leverage.
