[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Can linux kernel claim it uses GPL v2?

From: David Kastrup
Subject: Re: Can linux kernel claim it uses GPL v2?
Date: Sat, 07 Oct 2006 18:36:20 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) writes:

> David Kastrup wrote:
>> writes:
>> > Not really. I am looking for reason, why some programs using kernel
>> > can be not-GPL, while programs using GPL library has to be GPL.
>> It depends on whether the program can work without this _specific_
>> library or kernel.
> So... tell me about kernel I can easily switch to - without
> recompiling glibc AND changing source. System calls are very similar
> in FreeBSD and Linux, however system call 208 for example is
> different.

The law does not make a significant difference between dynamic and
static linking, and recompiling would probably be held to the same
standard as long as the headers don't contain significant
copyrightable material.

> This could work with OpenGl implementation, there are nvidia,
> mesa...  maybe somthing else. But kernel - not a chance. And even
> these OGl implementation differs in supported extension or standard
> OpenGl 2.0 (I am not sure, since I dont observe opengl
> implementation very often).

Whatever.  Don't see what you are trying to hint at.

>> >> Not really.  The reason is that there is a clear cut separation
>> >> of functionality with a _standard_ API between them.  Also glibc
>> >> works
>> > So you are saying if I make a standard API for GPL library, I can
>> > use different license.
>> Uh, you can't "make" a standard API for GPL library.  Look up the
>> definition of "standard" in a dictionary of your choice.
> 1. standards develop during time.

No, they don't.  Standards are _set_, they don't have a life of their

> 2. I said it because of you, I would say well documented public API.

That does not help in itself.  Creating an artificial API does not
create an independent work abstraction as long as the library remains
the only actual implementation of that API.

>> But you'll find that GNU libraries that are programmed according to
>> a preexisting (and probably standard) API are pretty much uniformly
>> licensed under the LGPL.  And while this is not the official reason
>> cited for this choice, it is one area where the FSF would not want
>> to have the "linking constitutes derivation" theory tested in
>> court.  So they use a license that explicitly does not pursue the
>> linking idea.
> *********
> Yes, but it is basically what *I* pursue. I want correct (="linking
> constitutes derivation" is either violated in kernel or unjust for the
> rest) answer.
> *********

"Correct answers" are given in the court, and then there still is
appeal.  Ask the respective copyright holders: that will not tell you
the correct answers, but it will give you a good idea for what acts
they will drag you before a court where you might get "more correct"

>> Not "certain address", but a symbolic entry point that will get
>> resolved by the linker and combined executable and library,
>> adapting the executable according to the actual memory layout of
>> the library.
> See man dlopen, dlsym and dlclose. No linking required by compiler.

Still address resolution.  But as I said, the technical details don't
matter that much, actually.  It is the functional relation.

David Kastrup, Kriemhildstr. 15, 44793 Bochum

reply via email to

[Prev in Thread] Current Thread [Next in Thread]