David Kastrup wrote: > [EMAIL PROTECTED] 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 _______________________________________________ gnu-misc-discuss mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-misc-discuss
