When we talk about device driver interface, there should be three styles, not two:
1. Source code level interface.
2. Binary code level interface.
3. interface for user process device driver interface.
According to what I believe, 1 is usually good idea. Having 1 with full GPL, will prevent non-open device driver availability, and help device driver programmer for they do not have to re-write driver whenever internal interface changes.
2, on other hand, is somewhat little bit more disgusting. You can make it from 1, if you designed the interface. But usually not necessary.
3, lastly, I belive, is something we SHOULD have. This interface will give driver programmer to do debugging at user space, can test long run test to see for memory leak, etc.
Since user process device drivers performance are usually terrible due to lots of system calls required, if proprietary device drivers are being released in binary-only user process style, there shall be only three cases:
1) user choose different HW, for it performs terrible in Linux
2) HW vender will give up, and make program open
3) they decide Linux not to be their market
Any case seems OK to me.... I mean, it's really TRAP for those who do not make device driver source code open. Once they choose 3 for solution, Marketing and Sales persons will start helping community, by forcing development section to SPEED UP the device driver.
If source code could not be open due to BUSINESS reason, we should give them the reason why it is better. Not by giving ideal, broad view. By showing concrete vantage.