Re: Controversy over dynamic linking -- how to end the panic

Wei Weng (wweng@kencast.com)
21 Jun 2001 16:01:58 -0400


On 21 Jun 2001 13:46:48 -0500, Timur Tabi wrote:
> ** Reply to message from "Eric S. Raymond" <esr@snark.thyrsus.com> on Thu, 21
> Jun 2001 14:14:42 -0400
>
>
> > To calm down the lawyers, I as the principal kernel maintainer and
> > anthology copyright holder on the code am therefore adding the
> > following interpretations to the kernel license:
> >
> > 1. Userland programs which request kernel services via normal system
> > calls *are not* to be considered derivative works of the kernel.
> >
> > 2. A driver or other kernel component which is statically linked to
> > the kernel *is* to be considered a derivative work.
> >
> > 3. A kernel module loaded at runtime, after kernel build, *is not*
> > to be considered a derivative work.
>
> Although these are good things to add, I don't think they're compatible with
> the GPL. That is, Linus can't just state these "interpretations" and add them
> to the GPL, because it will weaken the GPL as a whole. I say that because you
> do not include any language that clarifies that from a legal sense.
Hell, why does the linux community need to care about other *greedy*
people who don't want to GPL their work anyway? If you want to protect
GPL as the principle in Linux, well, screw the device driver makers!

> I heard recently that kernel modules are technically, from the GPL
> point-of-view, a derivative work, because they include kernel header files.
> However, since Linus understands that this precludes binary-only modules, he has
> "made an exception" to the Linux kernel license.
>
> The problem with that is that I have never seen any written evidence of this.
>
> IANAL, but IMO, there are only two solutions:
>
> 1. License the Linux kernel under a different license that is effectively the
> GPL but with additional text that clarifies the binary module issue.
> Unfortunately, this license cannot be called the GPL. Politically, this would
> probably be a bad idea.
>
> 2. License the Linux kernel under TWO licenses, one the GPL, and another which
> talks about the binary module issue. Unfortunately, this would probably not
> work either, as technically these two licenses are incompatible.
>
> I guess what I'm trying to say is that this issue won't be resolve simply by
> some "interpretations" by Linus as to what is and is not a derived work. I
> think the FSF needs to be involved in this.
>
> To be honest, I disagree that #include'ing a GPL header file should force your
> app to be GPL as well. That may be how the license reads, but I think it's a
> very bad idea. I could write 1 million lines of original code, but if someone
> told me that but simply adding #include <stdio.h> my code is now a derivative of
> the stdio.h, I'd tell him to go screw himself.
What is the difference between including kernel header file and
including GPLed header file?

Best Regards,

Wei

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/