>> 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.
You could link BSD or Artistic-licensed code, but NOT NPL/MPL code. You could
not link closed-source code with kernel code (except of binary-only drivers
NOT SINCE it's compatible with GPL, but since Linus said that he will allow
this; from formal viewpoint even linking existing kernel code with binary-only
drivers is violation of GPL but since God^H^H^HLinus said that it's Ok and
kernel-hackers agree with them it's Ok). Read GPL once more if you are in
doubt...
> 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.
This is not problem at all (see above). Since you already allowed link
closed-source drivers in kernel you could link UDI drivers as well. Of course
UDI layer itself must be GPL'ed (or released under any GPL-compatible license,
i.e. NOT under NPL/MPL) -- it's not driver and Linus's permission does not
extends on UDI layer (and Linus COULD NOT allow this without permissions from
bunch of kernel hackers -- hardly doable).
> 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.
I'm not sure. But may be you are right... Only court could really solve this
question...
> Not a problem, as long as they also distribute (or point to) the source.
If it's only driver (and not UDI layer itself) they could produce binary-only
drivers just fine... For UDI you must have GPL-compatible license (even not
all Open Source(tm) licensies could be used! NPL/MPL could not be used, for
example).
> 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 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.
We will not get free drivers at all. "Since you already had our great
binary-only UDI driver why you are needed sprecs ?".
> At least that is how I read things. TRMV (Your Reading May Vary),
IMNSHO it's clear try to make Linux vulnerable to the same problems then NT:
BAD closed-source drivers and no specs. Then you could not depend on your
comp since you could not fix things (and you could not get specs since "you
are not needed specs -- you have UDI driver" and this driver is buggy since
"*nix is niche OS while NT is mainstream; we could not even fix our driver for
NT and we definitelly does not have resources to fix UDI driver"). IMO the only
way to adopt UDI is to write in AS MOST PLACES AS WE CAN (in distributions
installation manuals, in FAQ's, in HOWTO's, etc): "USE CLOSED SOURCE UDI DRIVERS
AS "LAST RESORT" ONLY. BUY ONLY HARDWARE WITH NATIVE OPEN SOURCE(tm) LINUX(r)
DRIVERS OR OPEN SOURCE(tm) UDI DRIVERS IF YOU HAVE CHOICE. IF YOUR SYSTEM WILL
BE CRASHED BY CLOSED SOURCE UDI DRIVER THEN YOU ARE ON YOUR OWN LUCK AND YOU
COULD GOT HELP FROM KERNEL DEVELOPER AND THE ONLY HOPE FOR YOU IF YOUR
MANUFACTURER." We here (in linux-kernel list) are pretty aware about this
problem but new linux users are NOT aware about it. Since till now most
manufacturers does not bother itself with cration of drivers for Linux this
was not big problem but with UDI this could change in very short time.
What about open-source UDI drivers it's completely other story: if manufacturer
will produce open-source UDI driver then this will GREATLY simplify task of
creating native driver and if UDI layer will be efficient enough may be native
driver will not be needed at all.
-
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/