gnu-misc-discuss
[Top][All Lists]
Advanced

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

Re: Can linux kernel claim it uses GPL v2?


From: kero552
Subject: Re: Can linux kernel claim it uses GPL v2?
Date: 7 Oct 2006 09:16:39 -0700
User-agent: G2/1.0

David Kastrup wrote:
> kero552@gmail.com writes:
> Kernel is pretty different than a library.  It has threads of its own.
Not necessary. Kernel with cooperative multitasking is easy to achieve
and on some platforms ony solution. Anyway read paragraphs starting
with "Another scenerio" in
http://www.ms.mff.cuni.cz/~havlj3am/mail2fsf-org.txt
Way o


> > 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.

FreeBSD http://packetstormsecurity.org/papers/unix/bsdkern.htm#I.6.
Linux http://www.lxhp.in-berlin.de/lhpsysc0.html

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).

> >> 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.
2. I said it because of you, I would say well documented public 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.
*********

Just a thought:
If you look at dlopen dlsym and dlclose you will see something quite a
similar to kernel syscall. No linking required, just dlopen(is library
there?), dlsym("give me pointer to function") and you have to call the
pointer with proper parameters... parameters documented somewhere else.

> > About using GPL library means GPL program or kernel.
> > The only difference I see is that calling kernel requires filling
> > certain registers and calling int 0x80 (on i386), while calling
> > function require pushing arguments on stack and jump to certain
> > adress.
>
> 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.
http://www.dwheeler.com/program-library/Program-Library-HOWTO/dl-libraries.html

Honza



reply via email to

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