It should be the same info to make a Windows driver; We need to know how to talk to the hardware (hardware protocol). Then, once we can talk to the hardware, we need to know what to say to make it do it's thing. I realize the latter part is actually done from the userland app, but that info is needed for driver devel purposes in order to verify that it actually works
In Wine the Software install works all but the USB part due to the Serial USB driver that is needed by the controller FTDI chip, best I can tell. Linux has the FTDI support there just not sure why it can't assign the controller a module. You can see the manufacture code but when I tried to load a module manually it would not recognize the device. It has been a long while so I may be missing something here, so don't quote me.
As a rule, there are two main distros that everyone supports: Fedora/Red Hat, and Ubuntu/Debian. Most other distros are built off of those. For the distros that don't meet their dependency requirements we can also make the source available for the user to compile themselves (which means they have to take care of all the dependencies).
The kernel module would likely be done as a dynamically built module, much like VirtualBox does. Here, the install script compiles a kernel module against the running kernel at install time, and installs kmod as a dependency. kmod ensures that if a future system update installs a new kernel version, a new module will be built against the new kernel at the first boot of the new kernel. If the module is stable (which requires the Flashscan V2 hardware protocol to be stable) and licensed under GPLv2 it may be possible to get it put into the mainline kernel tree. If that happens, then a module build would no longer be required for any distros that are based on a kernel version the same or newer than the version where the driver was introduced into the tree.
Are you thoroughly confused yet?