linux-kernel - Re: GPLv3 Position Statement

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.61.0609271051550.19438@yvahk01.tjqt.qr>
Date:	Wed, 27 Sep 2006 10:58:41 +0200 (MEST)
From:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
To:	Sergey Panov <sipan@...an.org>
cc:	James Bottomley <James.Bottomley@...elEye.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: GPLv3 Position Statement

>almost, surrounding_userland_applications = (operating_system - kernel) 
>
>> then yes, why should there be a problem with a GPL2 kernel and a GPL3 
>> userland? After all, the userland is not only GPL, but also BSD and 
>> other stuff.
>
>It was not a problem with GPL[0-1]/BSD/MIT license, but is it still true
>with GPL3? What is the difference between running application on the top
>of the kernel "A" and linked with the library "B"?

I think Linus once said that he does not consider the kernel to 
become part of a combined work when an application uses the kernel.

I tend to agree, it's gray (unless Linus explicitly colorizes it) -- 
IIRC the GPL allows a GPL and closed program to interact if they do so 
using 'standard' interfaces, i.e. passing a file as argument, or 
shell redirection, communicating over a pipe or a socket, etc.
But OTOH, linking code makes it a combined work.
And the question now is: Since the kernel is the one providing these 
standard services, what would apply? Do userland and kernel communicate 
by means of linking or by means of standardized interfaces (in this case -
fixed syscall numbers or thelike). I'd say the latter. An application 
does not link with the kernel IMHO, no symbol resolution is done.

>> >The last Q. is how good is the almost forgotten Hurd kernel?
>> 
>> Wild guess: At most on par with Minix.
>
>... ???. I am not so sure. Kernel is really a small thing. The VMWare
>proprietary hyper-visor was/is reusing Linux drivers with ease, why BSD or
>Hurd can not do the same? As a former (Linux) driver writer I like to show the
>following numbers to my friends:

Oh well I was rather interpreting the question as "What about Hurd?" and 
my answer was the same from the Hurd page last time I read it.
"It's not so complete to make up a production system." or similar.

>================================================================
>
>PS. Given that some of the sub-systems (e.g SCSI) in Linux still suck
>badly, other OS (not as in Operating Systems but as in Open Source)
>alternatives might eventually gain some ground in the enterprise
>environment.

Don't tell me you like the Solaris way of naming devices. :)

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