Erik Andersen writes:
> On Fri, 18 Sep 1998, Pavel Machek wrote:
>
> > Hi!
> >
> > > The other obvious reason that SCO wants UDI to succeed is that Linux
> > > has tonnes of drivers and SCO does not, and SCO wants to invent some
> > > plausible way of leeching off the Linux drivers.
> >
> > Even with UDI, SCO can not use Linux drivers: linux drivers _have to_
> > be GPL in order to link with kernel. And unless SCO is going GPL, they
> > can not link with GPL code... (Unless they find way to insert GPL code
> > as a module - that might be legal.)
> >
> > Pavel
>
> Two issues though:
> 1) Why can't BSD, NPL, Artistic, and other free code be linked
> with the kernel? As I read the GPL, this isn't a problem, and
> unless I am mistaken, there are a number of linux drivers that have
> made use of *BSD code, which is not GPL. I think you are mistaken
> in your statement.
>
> 2) It is reasonable to consider a device driver running under a UDI layer
> as an "independent and separate works in themselves", and in that context,
> there is no problem using it under a non-free OS. It is just a program
> that runs on the OS (in kernel space), and as such it is no different
> then running gcc under SCO or solaris, etc. Not a problem, as long as
> they also distribute (or point to) the source.
> Remember, "mere aggregation of another work not based on the Program
> with the Program (or with a work based on the Program) on a volume of
> a storage or distribution medium does not bring the other work under
> the scope of this License." If we write it, they can ship it -- but it
> will be free, and can be fixed.
I think to continue this discussion sensibly, some terms probably need
to be defined. I haven't read the UDI specs yet (they're available
from www.sco.com/udi or something - they're actually on an HP ftp
server though!), so I may be duplicating effort here:
UDI driver: an OS-neutral piece of code supplied by an OEM to handle a
family of devices.
UDI interface: A chunk of code in a *NIX kernel that allows it to
load, unload, and interface with, a UDI driver. Analogous to the
modules stuff in Linux already.
Now, IANAL, but surely the UDI drivers, despite having 'plug-in'-like
characteristics (and thus falling under rms' statement about such
things) actually appear, to me at least, to be more like, say, a
non-Free perl script; just because Perl is Free, it doesn't mean that
all perl scripts have to be Free also! Equally, having non-Free perl
scripts doesn't make Perl any less Free, especially if some vendor
decides to author a proprietary, non-Free, implementation of the perl language!
Also, and I don't know whether it's too late to influence this, but I
think it would be very cool to have a UDI driver written in some
abstract language (Forth, perhaps?!) and have it compiled at load-time
to native code. With that in mind, a UDI driver becomes nothing more
than a data file, even if the data file is some arbitrary binary
format. Of course, having it in plain ascii would be nicer. :)
> I say we have everything to gain by supporting this, and little to lose.
> We get binary only drivers for unsupported devices, and then when we get a
> free driver that is better written, everyone will use it because of the
> inherent advantages of a free driver.
As has already been pointed out, a potential lossage would be using the
argument that "I, and hundreds of others won't buy your hardware
because it doesn't work with Linux" to encourage OEMs to release
programming information. However, that can just as easily
be replaced with "I, and hundreds of others ARE buying a competitors'
device because it works better with Linux right now. I'd like to buy
your device because the hardware specs are better, but right now your
UDI-only driver sucks, so I won't". This may, in fact, work better.
>
> At least that is how I read things. TRMV (Your Reading May Vary),
>
> -Erik
>
> --
> Erik B. Andersen Web: http://www.inconnect.com/~andersen/
Best Regards,
Alex Butcher.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/