Re: Developing non-commercial drivers ?

[lsorense@csclub.uwaterloo.ca (Lennart Sorensen)]

On Wed, Nov 19, 2008 at 11:32:04PM +0100, Fredrik Markstr?m wrote:
> Well, who knows ? If you read my email carefully enough you should see
> that that is not the question or issue here.
> This was my first question to this list ever and I'm impressed with
> the good and constructive answers I've gotten, but I really do not
> understand the purpose of your response.

I am one of the (apparently few) people that think when someone asks me
to do something counter productive and most likely misguided, I should
help them by educating them in how they are wrong, not just go do what
they want.

So if your client (or potential client) asks you to write a closed
source driver which would potentially be a licence violation (don't ask
me, ask a lawyer, etc), when there is no reason it should be closed
source, then you should go educate them about why it makes no sense to
make it closed source.  If they get educated and hence now know more,
hopefully they will be smart enough to now not ask for a closed source
driver, and now the legal problems evaporate and you don't have to deal
with lawyers at all (always a good thing).

The customer is NOT always right.  Sometimes the customer just doesn't
have all the facts to know what is the right choice.

So that was my point.

In the case of an ethernet mac, there can't be anything new that needs
protecting (not that reverse engineering the binary for the driver is
necesarily that hard either, so at best it is slowing down, not
protecting really), although I suppose for a wireless ethernet device
some people would claim the FCC and the like insist on not letting users
be able to change some stuff, and again they claim they are protecting
the device by using closed drivers.

You asked a good question, and got a bunch of answers.  I hope the end
result is another fully open source driver that can end up included in
the kernel.  That of course is another bonus worth pointing out.
Drivers included in the kernel are easily an order of magnitude less
work to maintain, since large kernel structure changes are done for you,
rather than you having to catch up later when it is harder to figure out
what they change was done and what you have to do to fix it.

-- 
Len Sorensen