[3303] in linux-net channel archive
Re: Binary Driver Issues
daemon@ATHENA.MIT.EDU (Mike Kilburn)
Tue Jun 18 17:47:17 1996
Date: Tue, 18 Jun 1996 20:08:10 +0200 (SAT)
From: Mike Kilburn <mike@lserv.conexio.co.za>
To: Doug Ledford <dledford@dialnet.net>
cc: Dennis <dennis@etinc.com>, linux-net@vger.rutgers.edu
In-Reply-To: <XFMail.960618131316.dledford@dialnet.net>
On Tue, 18 Jun 1996, Doug Ledford wrote:
> about. ET could do the same thing. Allow a driver for their card in linux.
> Don't include the bandwidth management features and such with that driver.
> Allow the basic Frame Relay driver in 2.0.0 to be the higher layer to their
> card. Then, if someone wanted the full functionality of their current driver
> they could buy the enhancement module in binary only form from ET. This module
> could be made in such a way that it interfaces with the card driver in a static
> fasion so that kernel upgrades and version changes would not effect it. I
> would see this as a perfectly acceptable solution to the problem. It would
> protect the intellectual property of ET, while at the same time providing a
> basic driver for linux, and giving source for the basic driver so that it could
> grow and change with changes in the kernel structures.
But what I am saying is the opposite. The low level board driver can
be binary only since that is an extension of the firmware (or lack of)
for the card. While the "value-added" kernel enhancements should require
source. I know this will never happen with ET. But *new* companies can
plan from the start to make a profit and be free.
