I want to start a company selling a piece of hardware I designed. The hardware needs a driver, and I'd like to give people who buy my thing the source code to the driver to let them modify stuff if they want to. The problem is that I'd be a small business, and as I see it, if I open source the driver to my product there's nothing preventing a larger electronics manufacturing company from building and selling something that uses the driver I wrote. So, to protect myself from that contingency, (obviously) I'd include something preventing the sale of hardware that uses that driver in the license to the code. So, I've got two questions:
1. Legalese; anybody law-knowledgeable here who can say how much protection provisions in the license to the code of the driver would offer?
2. Partial-drm solution: To reiterate, I'd really like to give customers the code, but I don't want to inadvertently help a competitor undercut me, anybody heard of a partially-proprietary driver created by a hardware company to solve the problem I'm describing?
Obviously, I don't mean to claim ownership to ideas, only their implementation; but if my thing gets popular I'd prefer it if the company that eventually undercuts me has to through the expense of designing their own stuff.
GPL the code if you are going to release it (that way you can sue if they modify your driver and only ship binary), keep the design of the hardware itself a trade secret.
If you can, integrate the design as much as you can (that makes it substantially harder to copy the design).
Another thing to remember is that if you use an embedded processor to blow the 'read' fuses so that you can no longer read back what goes on in the device.
In spite of all that, any piece of hardware can be reverse engineered.
http://www.cl.cam.ac.uk/~sps32/mcu_lock.html
I've seen a pretty nifty hack to read out programmable micro-controllers that were supposedly secure, it's only a delay tactic.
Legalese will only stop parties that are smaller than you and in a jurisdiction where they care about such things.
2) seems to be your best bet, stick some firmware on the board and have your driver talk to an 'abstract' and idealized version of your board.
Make sure you expose enough functionality for future development.