On Mon, 5 Mar 2001, Julie wrote:
> From: Thomas Dodd <[EMAIL PROTECTED]>
>
> > Julie wrote:
> > > My reading of the GPL is that you only get in trouble if you
> > > distribute a GPL'd work as an essential part of a larger non-GPL'd
> > > product. If you distribute the two separately, the terms of
> > > distribution of the non-GPL'd work have no bearing on the GPL'd
> > > work and vice versa. If you'd like an example of this, every
> > > proprietary OS that has had a GPL'd program ported to it
> > > should suffice. Proprietary OS vendors have been very careful
> > > not to distribute GPL'd software as parts of their proprietary
> > > OSes, but that hasn't kept GPL'd programs from being ported
> > > to use non-GPL'd libraries and OSes.
> >
> > My understanding is that hardware drivers (like a NIC or SCSI HBA)
> > are not "seperate works" but part of the complet work
> > know as the OS or kernel. Putting GPL code into that makes
> > the wole work GPL. But apps (like gcc, or gnumeric) are
> > seperate works in and of themselves, so only the app has to
> > be GPL. But if you take the gnumeric Excel filter or
> > the gcc C++ parser, and put them in another app, it
> > would be a derived work and need to be GPL'ed too.
>
> Then don't distribute them with the OS -- force the recipient to
> make them part of a "complete work". Then so long as the
> person who combines them (by loading the module into a
> running kernel ...) doesn't distribute their "complete work" (which
> is a running kernel ...) you're safe. There is no way someone
> can claim that my NIC driver (as an example) is a part of a work
> it wasn't even shipped with.
The problem with that scenario is that if you build a driver module it
will likely have an interface compatible to only the kernel it was
compiled with, therefore it's only linkable to that kernel. You distribute
a module that is tied to that specific kernel and thus practically linked
to it, because it is intended to be run with that kernel and nothing else.
If you have much luck, there might even be some proprietary parts in the
binary module (headers, inline functions, whatnot...).
Even if there weren't legal issues, I'd have an ethical problem not
respecting the wishes of the author of that piece of software.
> > > Again, I don't see how a restriction here could be enforced.
> >
> > It would require a lawsuit to find out, and so far nobody
> > has filed one that I know of. Most GPL software belongs to
> > people whyo don't have the time or money for one, and
> > the companies with the time and money, don't
> > release GPL software.
>
> I think there is a lot of mythology about what the GPL can and
> cannot do. I don't hear much talk about how the GPL is a
> virus anymore, but that's how I view it.
In short: nobody forces you to bring GPL'ed code and non-GPL'ed code
together, if you decide to do so, you're bound by both licenses, if you
can't comply with them by bringing both together, it's bad luck.
> The interpretation that a non-GPL'd NIC driver that's been loaded into
> a running kernel on a GPL'd OS is, IMHO, just another example of
> Stallman trying to "infect" everything he can get his hands on.
What is and is not allowed w.r.t. linking two pieces of software is
entirely up to the relevant "owners". A device driver is _worthless_ on
its own, it needs a kernel. Therefore I'd consider the act of compiling
the driver for that particular kernel as linking. More general: Linking is
always done at compile time, regardless of whether you compile a static
or a dynamic library. When a program has a shared library linked in, what
it does at program start time is _loading_ that library.
So in my eyes it is necessary that Linus exempts kernel module explicitely
from that rules in order not for people to run them, but for vendors to
build and ship proprietary drivers legally for Linux (not that I deem
proprietary drivers necessary, rather the opposite).
> > IANL either, so I just stay clear of these issues.
> > If I modify GPL code it stays with me. Nobody else ever
> > sees it, Or I send patches to the authors/owners and
> > let them decide weather it should become part of the normal
> > distributed code. Playing it safe keeps me out of trouble.
>
> I just avoid GPL'd software as best I can. I've found GPL'd
> software to be the least stable of the "open source"-like
> licensed software packages. It also tends to be the most
> bloated and suffer the most creeping featurism.
Bah. I can't see a connection between the quality or slim-/bloatedness of
a program and its license at all. Those properties of a program are
totally orthogonal to each other (try to prove the opposite).
Counter examples:
enlightenment (which has some BSD or MIT license) -- not really slim
XFree86 (MIT) -- not (cough) slim
efax (GPL) -- really slim, I haven't had an issue with it in years.
Linux, the kernel (GPL) -- big, but not bloated, stability (sadly) depends
on set of drivers used. Very stable when not
using drivers/components with known issues.
Hmm, I'd like to bring some examples of really crappy software too (with
whatever license), but do you know what -- I tend to avoid it.
Ahh, and last but not least: Of course this is my private opinion, in no
way endorsed by my employer, IANAL, yadda yadda.
Nils
--
Nils Philippsen / +49.711.96437.250 / [EMAIL PROTECTED]
Red Hat GmbH / Hauptstätter Straße 58 / D70178 Stuttgart
The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offence. -- Edsger W. Dijkstra
_______________________________________________
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
