Discussion:
Nog een GPL vraag
(te oud om op te antwoorden)
Paul van der Vlis
2008-08-28 12:56:37 UTC
Permalink
Hallo,

Stel een leverancier verkoopt een apparaat met Linux, dan moet hij de
broncode vrijgeven. OK.

Maar stel, hij gebruikt een driver van een leverancier die niet open
source is, maar closed source. Die code kan hij niet vrijgeven.

Mag een dergelijk apparaat dan gewoon niet in de handel komen?

Met vriendelijke groet,
Paul van der Vlis.
--
http://www.vandervlis.nl/
Martijn van Buul
2008-08-28 13:09:32 UTC
Permalink
Post by Paul van der Vlis
Hallo,
Stel een leverancier verkoopt een apparaat met Linux, dan moet hij de
broncode vrijgeven. OK.
Maar stel, hij gebruikt een driver van een leverancier die niet open
source is, maar closed source. Die code kan hij niet vrijgeven.
Mag een dergelijk apparaat dan gewoon niet in de handel komen?
Waarom zou dat niet mogen? Het moet niet gekker worden.

Linux valt onder de GPLv2, en alhoewel het een heet hangijzer is mag er
geen twijfel over bestaan dat het gebruik van binary-only drivers *geen*
inbreuk op de GPL is, mits alles correct gebeurt.

Er zijn voldoende Linux-distributies die allerlei non-free drivers
meeleveren. Dat wordt niet anders als het opeens om een embedded toepassing
gaat.

Hetzelfde geldt voor userland applicaties. Een voorbeeld is een stukje
speelgoed waar ik zelf mee aan het spelen ben geweest: een Freecom MusicPal.
Internet radio/streamer ding, draait Linux. Sources zijn beschikbaar[1], en
er is zelfs een toolchain beschikbaar (wat niet vereist is door de GPL).
Het belangrijkste stuk software (de userland applicatie) is echter *niet*
open source, en is dus ook alleen maar beschikbaar als binary. Vervelend,
en een beetje nutteloos, maar volledig in overeenstemming met de verschillende
licenties.


[1] Lopen wel wat achter, FreeCom verschuilt zich achter het woordje "beta".
--
Martijn van Buul - ***@dohd.org
Paul van der Vlis
2008-08-29 07:39:11 UTC
Permalink
Post by Martijn van Buul
Post by Paul van der Vlis
Hallo,
Stel een leverancier verkoopt een apparaat met Linux, dan moet hij de
broncode vrijgeven. OK.
Maar stel, hij gebruikt een driver van een leverancier die niet open
source is, maar closed source. Die code kan hij niet vrijgeven.
Mag een dergelijk apparaat dan gewoon niet in de handel komen?
Waarom zou dat niet mogen?
Het gaat om een GPL programma, je moet de sources willen geven van je
uitbreidingen.
Post by Martijn van Buul
Het moet niet gekker worden.
Linux valt onder de GPLv2, en alhoewel het een heet hangijzer is mag er
geen twijfel over bestaan dat het gebruik van binary-only drivers *geen*
inbreuk op de GPL is, mits alles correct gebeurt.
Als dat mag, wat biedt de GPL dan voor bescherming?

Stel ik ben fabrikant en wil een closed-source patch meeleveren. Ik
ontwikkel dat maar vraag mijn vriendje of die dat officieel willen
uitgeven, als binary. Die lever ik mee en klaar is kees.
Post by Martijn van Buul
Er zijn voldoende Linux-distributies die allerlei non-free drivers
meeleveren.
Mmm. Klopt.
Post by Martijn van Buul
Dat wordt niet anders als het opeens om een embedded toepassing
gaat.
Zou kunnen.
Post by Martijn van Buul
Hetzelfde geldt voor userland applicaties.
OK, maar dat is wat anders.

Met vriendelijke groet,
Paul van der Vlis.
--
http://www.vandervlis.nl/
Martijn van Buul
2008-08-29 07:59:25 UTC
Permalink
Post by Paul van der Vlis
Post by Martijn van Buul
Post by Paul van der Vlis
Hallo,
Stel een leverancier verkoopt een apparaat met Linux, dan moet hij de
broncode vrijgeven. OK.
Maar stel, hij gebruikt een driver van een leverancier die niet open
source is, maar closed source. Die code kan hij niet vrijgeven.
Mag een dergelijk apparaat dan gewoon niet in de handel komen?
Waarom zou dat niet mogen?
Het gaat om een GPL programma, je moet de sources willen geven van je
uitbreidingen.
Ah, maar daar hebben we het roemruchte "Derived work" weer. Zoals Robert al
had aangegeven is dit een grijs gebied. Het FSF heeft in deze een behoorlijk
extreem standpunt (zoals altijd, eigenlijk), en vindt *alles* een derived
work, maar dat valt waarschijnlijk niet hard te maken. De werkelijkheid
is wat genuanceerder.

Daar komt nog eens bij dat Linus *zelf* meerdere malen heeft aangegeven
dat hij binary kernel modules goedkeurt. Zie bijvoorbeeld

http://lkml.org/lkml/2006/12/13/370
Post by Paul van der Vlis
Post by Martijn van Buul
Het moet niet gekker worden.
Linux valt onder de GPLv2, en alhoewel het een heet hangijzer is mag er
geen twijfel over bestaan dat het gebruik van binary-only drivers *geen*
inbreuk op de GPL is, mits alles correct gebeurt.
Als dat mag, wat biedt de GPL dan voor bescherming?
Dat is dan ook mijn bezwaar tegen de GPL. De GPL beschermt niets, beperkt
vanalles, en schept (zeker in de GPLv3) een bijzonder onvriendelijke sfeer.
Post by Paul van der Vlis
Stel ik ben fabrikant en wil een closed-source patch meeleveren.
Maar dit is geen patch. Dit is een module, een plugin. Dat is een *heel*
belangrijk verschil.
Post by Paul van der Vlis
Post by Martijn van Buul
Hetzelfde geldt voor userland applicaties.
OK, maar dat is wat anders.
Nee, dat is eigenlijk hetzelfde.
--
Martijn van Buul - ***@dohd.org
Paul van der Vlis
2008-08-29 11:43:54 UTC
Permalink
Post by Martijn van Buul
Post by Paul van der Vlis
Stel ik ben fabrikant en wil een closed-source patch meeleveren.
Maar dit is geen patch. Dit is een module, een plugin. Dat is een *heel*
belangrijk verschil.
Mmm. Misschien. Je laad hem ook zelf.
Post by Martijn van Buul
Post by Paul van der Vlis
Post by Martijn van Buul
Hetzelfde geldt voor userland applicaties.
OK, maar dat is wat anders.
Nee, dat is eigenlijk hetzelfde.
Niet als het om gewoon een afzonderlijke applicatie gaat, die helemaal
niet onder de GPL valt.

Met vriendelijke groet,
Paul van der Vlis.
--
http://www.vandervlis.nl/
Martijn van Buul
2008-08-29 14:55:51 UTC
Permalink
Post by Paul van der Vlis
Post by Martijn van Buul
Post by Paul van der Vlis
Stel ik ben fabrikant en wil een closed-source patch meeleveren.
Maar dit is geen patch. Dit is een module, een plugin. Dat is een *heel*
belangrijk verschil.
Mmm. Misschien. Je laad hem ook zelf.
Daar gaat het niet zozeer om. Een patch wijzigt code, een plugin doet dat
niet. Een plugin maakt gebruik van een interface die uitdrukkelijk bedoeld
is om functionaliteit uit te breiden, *maar het programma wordt niet
gewijzigd*.

Het is bijzonder twijfelachtig of een plugin "derived work" is, en de mening
van het FSF hierin is niet heiligmakend. Integendeel. Sterker nog, de
mening van het FSF is niet bijzonder consequent, en laat het afhangen van
implementatiedetails of het wel of niet "mag".

Ik ben het niet zo heel vaak eens met Linus, maar hier slaat hij de spijker
op z'n kop als hij stelt dat dit behoorlijke overlap heeft met de DRM-
discussie, en het standpunt van het FSF is dan ook behoorlijk
hypocriet.

(Nu geloof ik allang niet meer in de goede bedoelingen van het FSF, dus..)
Post by Paul van der Vlis
Post by Martijn van Buul
Post by Paul van der Vlis
Post by Martijn van Buul
Hetzelfde geldt voor userland applicaties.
OK, maar dat is wat anders.
Nee, dat is eigenlijk hetzelfde.
Niet als het om gewoon een afzonderlijke applicatie gaat, die helemaal
niet onder de GPL valt.
Als het aan het FSF had gelegen, was een applicatie die onder Linux draait
een 'derived work'. De enige reden dat een applicatie geen GPL hoeft te zijn
ondanks dat het toch onder een Linux kernel draait, is omdat Linus zegt dat
het mag, en hij in COPYING uitdrukkelijk aangeeft dat het FSF de pot op kan wat
dit betreft.

Het verschil tussen "Applicatie onder !GPL in kernel" en "!GPL module in
kernel" is dan alleen maar "Iedereen is het met Linus eens" en "Niet iedereen
is het met Linus eens".
--
Martijn van Buul - ***@dohd.org
Fred Mobach
2008-08-29 12:02:01 UTC
Permalink
Post by Martijn van Buul
Post by Paul van der Vlis
Post by Martijn van Buul
Post by Paul van der Vlis
Hallo,
Stel een leverancier verkoopt een apparaat met Linux, dan moet hij
de broncode vrijgeven. OK.
Maar stel, hij gebruikt een driver van een leverancier die niet
open source is, maar closed source. Die code kan hij niet
vrijgeven.
Mag een dergelijk apparaat dan gewoon niet in de handel komen?
Waarom zou dat niet mogen?
Het gaat om een GPL programma, je moet de sources willen geven van je
uitbreidingen.
Ah, maar daar hebben we het roemruchte "Derived work" weer. Zoals
Robert al had aangegeven is dit een grijs gebied. Het FSF heeft in
deze een behoorlijk extreem standpunt (zoals altijd, eigenlijk), en
vindt *alles* een derived work, maar dat valt waarschijnlijk niet hard
te maken. De werkelijkheid is wat genuanceerder.
Daar komt nog eens bij dat Linus *zelf* meerdere malen heeft
aangegeven dat hij binary kernel modules goedkeurt. Zie bijvoorbeeld
http://lkml.org/lkml/2006/12/13/370
Zolang de auteurs van de Linux kernel, waaronder Linus, het nog steeds
niet met elkaar eens zijn over dit onderwerp en er regelmatig patches
verschijnen en verdwijnen om bepaalde zaken als GPL only te maken zijn
naar mijn idee dit soort discussies vrijwel vruchteloos. :-)

En voor wie twijfelt of dit soort gevallen acceptabel is, is er nog
altijd http://gpl-violations.org/ met een mailinglist over dit
onderwerp.
--
Fred Mobach - ***@mobach.nl
website : http://fred.mobach.nl
.... In God we trust ....
.. The rest we monitor ..
houghi
2008-08-29 12:24:04 UTC
Permalink
Post by Fred Mobach
Zolang de auteurs van de Linux kernel, waaronder Linus, het nog steeds
niet met elkaar eens zijn over dit onderwerp en er regelmatig patches
verschijnen en verdwijnen om bepaalde zaken als GPL only te maken zijn
naar mijn idee dit soort discussies vrijwel vruchteloos. :-)
Ideaal voor iets als ncol.discussie dus. :-D

houghi
--
Remind me to write an article on the compulsive reading of news. The
theme will be that most neuroses can be traced to the unhealthy habit
of wallowing in the troubles of five billion strangers. -- Heinlein
unknown
2008-08-29 12:43:04 UTC
Permalink
Zoals Robert al had aangegeven is dit een grijs gebied. Het FSF heeft in
deze een behoorlijk extreem standpunt (zoals altijd, eigenlijk), en vindt
*alles* een derived work...
In dat kader quote ik nog even een stukje van de discussie waarnaar ik
verwees:
- > I've been exchanging e-mail with Richard Stallman for a couple of
- > weeks about the finer points of the GPL.
-
- I feel your pain.

:)
--
robert
houghi
2008-08-29 14:05:53 UTC
Permalink
Post by unknown
Zoals Robert al had aangegeven is dit een grijs gebied. Het FSF heeft in
deze een behoorlijk extreem standpunt (zoals altijd, eigenlijk), en vindt
*alles* een derived work...
In dat kader quote ik nog even een stukje van de discussie waarnaar ik
- > I've been exchanging e-mail with Richard Stallman for a couple of
- > weeks about the finer points of the GPL.
-
- I feel your pain.
:)
LOL. Ik heb diene mafkees ene keer bezig gehoord en had zin om een OEM
Windows te kopen en te instaleren, gewoon om Richard Stallman te kloten.

Had ik hem gekend voor ik Linux kende zou ik NOOIT met Linux begonnen
zijn.

houghi
--
Remind me to write an article on the compulsive reading of news. The
theme will be that most neuroses can be traced to the unhealthy habit
of wallowing in the troubles of five billion strangers. -- Heinlein
houghi
2008-08-29 08:36:13 UTC
Permalink
Post by Paul van der Vlis
Post by Martijn van Buul
Post by Paul van der Vlis
Hallo,
Stel een leverancier verkoopt een apparaat met Linux, dan moet hij de
broncode vrijgeven. OK.
Maar stel, hij gebruikt een driver van een leverancier die niet open
source is, maar closed source. Die code kan hij niet vrijgeven.
Mag een dergelijk apparaat dan gewoon niet in de handel komen?
Waarom zou dat niet mogen?
Het gaat om een GPL programma, je moet de sources willen geven van je
uitbreidingen.
Stond er niet duidelijk bij dat het om een GPL programma ging, enkel dat
het een driver maakt. Iets heel anders dus.
Post by Paul van der Vlis
Post by Martijn van Buul
Het moet niet gekker worden.
Linux valt onder de GPLv2, en alhoewel het een heet hangijzer is mag er
geen twijfel over bestaan dat het gebruik van binary-only drivers *geen*
inbreuk op de GPL is, mits alles correct gebeurt.
Als dat mag, wat biedt de GPL dan voor bescherming?
Het was niet duidelijk dat het over een GPL programma ging. Enkel dat
het over een Linux programma ging.
Post by Paul van der Vlis
Stel ik ben fabrikant en wil een closed-source patch meeleveren. Ik
ontwikkel dat maar vraag mijn vriendje of die dat officieel willen
uitgeven, als binary. Die lever ik mee en klaar is kees.
Dat is WEER wat anders. Je bent nu een GPL programma aan het aanpassen
en dan valt het dus onder GPL.
Post by Paul van der Vlis
Post by Martijn van Buul
Er zijn voldoende Linux-distributies die allerlei non-free drivers
meeleveren.
Mmm. Klopt.
Post by Martijn van Buul
Dat wordt niet anders als het opeens om een embedded toepassing
gaat.
Zou kunnen.
Post by Martijn van Buul
Hetzelfde geldt voor userland applicaties.
OK, maar dat is wat anders.
Verwarring komt omdat het uitgangspunt niet helemaal duidelijk was. Het
ging over Linux, waar dat tegenwoordig gezien wordt als distributie,
niet als monoliete kernel.

houghi
--
Remind me to write an article on the compulsive reading of news. The
theme will be that most neuroses can be traced to the unhealthy habit
of wallowing in the troubles of five billion strangers. -- Heinlein
houghi
2008-08-28 13:14:58 UTC
Permalink
Post by Paul van der Vlis
Hallo,
Stel een leverancier verkoopt een apparaat met Linux, dan moet hij de
broncode vrijgeven. OK.
Maar stel, hij gebruikt een driver van een leverancier die niet open
source is, maar closed source. Die code kan hij niet vrijgeven.
Mag een dergelijk apparaat dan gewoon niet in de handel komen?
Ik zie het probleem niet. Enkel de GPL code moet vrijgegeven worden.
Andere code moet dat niet. Op de gemiddelde distro staan er
verschillende licenties naast elkaar. Sommigen strikter en andere vrijer
dan GPL.

houghi
--
Always listen to experts. They'll tell you what can't be done,
and why. Then do it.
-- Heinlein : Time Enough For Love
Paul van der Vlis
2008-08-29 07:27:23 UTC
Permalink
Post by houghi
Post by Paul van der Vlis
Hallo,
Stel een leverancier verkoopt een apparaat met Linux, dan moet hij de
broncode vrijgeven. OK.
Maar stel, hij gebruikt een driver van een leverancier die niet open
source is, maar closed source. Die code kan hij niet vrijgeven.
Mag een dergelijk apparaat dan gewoon niet in de handel komen?
Ik zie het probleem niet. Enkel de GPL code moet vrijgegeven worden.
Linux staat onder de GPL.

Groet,
Paul.
Post by houghi
Andere code moet dat niet. Op de gemiddelde distro staan er
verschillende licenties naast elkaar. Sommigen strikter en andere vrijer
dan GPL.
houghi
Met vriendelijke groet,
Paul van der Vlis.
--
http://www.vandervlis.nl/
houghi
2008-08-29 09:48:11 UTC
Permalink
Post by Paul van der Vlis
Post by houghi
Post by Paul van der Vlis
Hallo,
Stel een leverancier verkoopt een apparaat met Linux, dan moet hij de
broncode vrijgeven. OK.
Maar stel, hij gebruikt een driver van een leverancier die niet open
source is, maar closed source. Die code kan hij niet vrijgeven.
Mag een dergelijk apparaat dan gewoon niet in de handel komen?
Ik zie het probleem niet. Enkel de GPL code moet vrijgegeven worden.
Linux staat onder de GPL.
Ik lees hier 'Linux' als 'Linux distributie' niet als 'De Linux Kernel'.
Dit komt omdat het gaat over 'een apparaat met Linux' waardoor je kunt
aannemen dat er een Linux distributie op zit.

Laten we verder even aannemen dat er openSUSE op zit, omdat ik die het
beste ken. Daar zit dan ook Opera op. Opera is niet open. Wel gratis,
maar niet open.

Stel verder dat er een NVidea kaart in zit en de leverancier zo
vriendelijk geweest is om de PC te configureren. Je kunt er dan zeker
van zijn dat de niet-vrije drivers van NVidea er op staan.

Zolang het deel dat onder GPL valt de regels van GPL volgt zie ik geen
enkel probleem om zaken die niet onder GPL vallen ook op de PC te
zetten. Dat deze GPL software gebruiken en/of aanspreken maakt niet veel
uit.

Pas als er GPL code gebruikt wordt en die wordt niet vrijgegeven, dan
zit je met een probleem.

Om het even simpel te houden, Opera is gewoon een binary. Onder welke
licentie die valt moet de maker van de binary weten, zolang ze geen
gebruik maak in de code van licenties die dat verbieden, zoals GPL.


houghi
--
Remind me to write an article on the compulsive reading of news. The
theme will be that most neuroses can be traced to the unhealthy habit
of wallowing in the troubles of five billion strangers. -- Heinlein
Paul van der Vlis
2008-08-29 11:39:32 UTC
Permalink
Post by houghi
Post by Paul van der Vlis
Post by houghi
Post by Paul van der Vlis
Hallo,
Stel een leverancier verkoopt een apparaat met Linux, dan moet hij de
broncode vrijgeven. OK.
Maar stel, hij gebruikt een driver van een leverancier die niet open
source is, maar closed source. Die code kan hij niet vrijgeven.
Mag een dergelijk apparaat dan gewoon niet in de handel komen?
Ik zie het probleem niet. Enkel de GPL code moet vrijgegeven worden.
Linux staat onder de GPL.
Ik lees hier 'Linux' als 'Linux distributie' niet als 'De Linux Kernel'.
Ik bedoelde de Linux kernel en geen distributie.
Post by houghi
Dit komt omdat het gaat over 'een apparaat met Linux' waardoor je kunt
aannemen dat er een Linux distributie op zit.
Laten we verder even aannemen dat er openSUSE op zit, omdat ik die het
beste ken. Daar zit dan ook Opera op. Opera is niet open. Wel gratis,
maar niet open.
Opera valt niet onder de GPL, en is dus niet zo'n goed voorbeeld.
Post by houghi
Stel verder dat er een NVidea kaart in zit en de leverancier zo
vriendelijk geweest is om de PC te configureren. Je kunt er dan zeker
van zijn dat de niet-vrije drivers van NVidea er op staan.
Dat is wel een goed voorbeeld.
Post by houghi
Zolang het deel dat onder GPL valt de regels van GPL volgt zie ik geen
enkel probleem om zaken die niet onder GPL vallen ook op de PC te
zetten. Dat deze GPL software gebruiken en/of aanspreken maakt niet veel
uit.
Naar mijn gevoel zijn kerneldrivers onderdeel van de kernel, maar
blijkbaar vinden anderen van niet.
Post by houghi
Pas als er GPL code gebruikt wordt en die wordt niet vrijgegeven, dan
zit je met een probleem.
Linux is GPL code, dus zou er een probleem zijn. Ware het niet, dat
mensen een kernelmodule blijkbaar niet bij het kernel vinden horen.

Met vriendelijke groet,
Paul van der Vlis.
--
http://www.vandervlis.nl/
houghi
2008-08-29 12:00:12 UTC
Permalink
Post by Paul van der Vlis
Naar mijn gevoel zijn kerneldrivers onderdeel van de kernel, maar
blijkbaar vinden anderen van niet.
Post by houghi
Pas als er GPL code gebruikt wordt en die wordt niet vrijgegeven, dan
zit je met een probleem.
Linux is GPL code, dus zou er een probleem zijn. Ware het niet, dat
mensen een kernelmodule blijkbaar niet bij het kernel vinden horen.
Als het niet IN de kernel zit, maar als module erbuiten, dan is het een
aparte binary en kun je er in stoppen wat je wil. Het deel dat in de
kernel zit moet natuurlijk wel GPL zijn.

Het enige wat een module doet is hardware aansturen. Opera maakt ook
gebruik van de kernel, net zoals een module dat doet. Ik zie niet in
waarom het ene wel zou mogen en het andere niet.

houghi
--
Remind me to write an article on the compulsive reading of news. The
theme will be that most neuroses can be traced to the unhealthy habit
of wallowing in the troubles of five billion strangers. -- Heinlein
unknown
2008-08-29 12:49:24 UTC
Permalink
Post by houghi
Post by Paul van der Vlis
Linux is GPL code, dus zou er een probleem zijn. Ware het niet, dat
mensen een kernelmodule blijkbaar niet bij het kernel vinden horen.
Als het niet IN de kernel zit, maar als module erbuiten, dan is het een
aparte binary en kun je er in stoppen wat je wil.
Een kernelmodule wordt *in* de kernel geladen.
Post by houghi
Het deel dat in de kernel zit moet natuurlijk wel GPL zijn.
Het enige wat een module doet is hardware aansturen. Opera maakt ook
gebruik van de kernel, net zoals een module dat doet. Ik zie niet in
waarom het ene wel zou mogen en het andere niet.
Het verschil is dat een module in feite onderdeel gaat uitmaken van de
kernel zodra hij geladen wordt, i.t.t. Opera dat altijd volledig buiten de
kernel draait.

Aan de andere kant maakt een kernelmodule gebruik van een bepaalde API die
voor zulke modules wordt aangeboden, net als Opera gebruik maakt van een
bepaalde API om met de kernel te kunnen communiceren.

Al met al blijft het grijs :)
--
robert
houghi
2008-08-29 14:03:53 UTC
Permalink
Post by unknown
Post by houghi
Als het niet IN de kernel zit, maar als module erbuiten, dan is het een
aparte binary en kun je er in stoppen wat je wil.
Een kernelmodule wordt *in* de kernel geladen.
Geladen is wat anders dan dat hij er genecodeerd staat.
Post by unknown
Het verschil is dat een module in feite onderdeel gaat uitmaken van de
kernel zodra hij geladen wordt, i.t.t. Opera dat altijd volledig buiten de
kernel draait.
GPL gaat over de source code. Niet over de binary op zich.
Post by unknown
Aan de andere kant maakt een kernelmodule gebruik van een bepaalde API die
voor zulke modules wordt aangeboden, net als Opera gebruik maakt van een
bepaalde API om met de kernel te kunnen communiceren.
Al met al blijft het grijs :)
Ik zie het wel als heel-erg-donker-antraciet-grijs.

houghi
--
Remind me to write an article on the compulsive reading of news. The
theme will be that most neuroses can be traced to the unhealthy habit
of wallowing in the troubles of five billion strangers. -- Heinlein
houghi
2008-08-29 14:25:52 UTC
Permalink
Post by houghi
Geladen is wat anders dan dat hij er genecodeerd staat.
En genecodeerd is weer wat anders dan ge-encodeerd, mafkees.

houghi
--
Remind me to write an article on the compulsive reading of news. The
theme will be that most neuroses can be traced to the unhealthy habit
of wallowing in the troubles of five billion strangers. -- Heinlein
unknown
2008-08-29 14:30:06 UTC
Permalink
Post by houghi
Post by unknown
Post by houghi
Als het niet IN de kernel zit, maar als module erbuiten, dan is het
een aparte binary en kun je er in stoppen wat je wil.
Een kernelmodule wordt *in* de kernel geladen.
Geladen is wat anders dan dat hij er genecodeerd staat.
Dat klopt.
Post by houghi
Post by unknown
Het verschil is dat een module in feite onderdeel gaat uitmaken van de
kernel zodra hij geladen wordt, i.t.t. Opera dat altijd volledig buiten
de kernel draait.
GPL gaat over de source code. Niet over de binary op zich.
De GPL heeft het over beiden ('The Program' en 'the source code'). Zie ook
deze uitleg van hoe de FSF denkt over 'modules':
http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLAndPlugins
--
robert
Martijn van Buul
2008-08-29 15:01:03 UTC
Permalink
Post by unknown
Post by houghi
Post by Paul van der Vlis
Linux is GPL code, dus zou er een probleem zijn. Ware het niet, dat
mensen een kernelmodule blijkbaar niet bij het kernel vinden horen.
Als het niet IN de kernel zit, maar als module erbuiten, dan is het een
aparte binary en kun je er in stoppen wat je wil.
Een kernelmodule wordt *in* de kernel geladen.
Een applicatie ook. Interactie gebeurt op een manier waarvan het FSF zegt
dat het niet mag.
--
Martijn van Buul - ***@dohd.org
unknown
2008-08-30 07:10:47 UTC
Permalink
Post by Martijn van Buul
Post by unknown
Een kernelmodule wordt *in* de kernel geladen.
Een applicatie ook.
Ja, uiteindelijk komt alles ook in dezelfde geheugenstickjes terecht :)
Post by Martijn van Buul
Interactie gebeurt op een manier waarvan het FSF zegt dat het
niet mag.
Ik dacht dat het verschil kernelspace <-> userspace voor de FSF een
voldoende grote barriere was, maar dat is dus ook al niet zo? Tsk.
--
robert
Martijn van Buul
2008-09-01 07:55:00 UTC
Permalink
Post by unknown
Ik dacht dat het verschil kernelspace <-> userspace voor de FSF een
voldoende grote barriere was, maar dat is dus ook al niet zo? Tsk.
Tsja, ik ook, maar waar staat dat? De FSF laat in het midden wat ze onder
een derived work verstaan, en het enige wat in de FAQ staat en in de buurt
komt is een plug-in. Welbeschouwd is dat ook eigenlijk het geval - en al
helemaal aangezien het eerder in de thread over het verschil tussen een
module en een userland programma ging:

" If a program released under the GPL uses plug-ins, what are the requirements
for the licenses of a plug-in?

It depends on how the program invokes its plug-ins. If the program uses fork
and exec to invoke plug-ins, then the plug-ins are separate programs, so the
license for the main program makes no requirements for them. "

Maar hier gaat het al mis. Een kernel gebruikt *nooit* fork en exec om een
proces te starten, dus deze conditie is niet van toepassing.

Wat *WEL* van toepassing is, is dit:

" If the program dynamically links plug-ins, and they make function calls to
each other and share data structures, we believe they form a single program,
which must be treated as an extension of both the main program and the
plug-ins. This means the plug-ins must be released under the GPL or a
GPL-compatible free software license, and that the terms of the GPL must be
followed when those plug-ins are distributed."

Van "dynamically linking" is waarschijnlijk wel sprake, ze maken onderling
function calls bij de vleet (syscalls, anyone?) en een willekeurig userland
proces staat vol van datastructuren die door de kernel zijn bedacht. Dit
geldt zowel voor userland processen als kernel modules.

Het "grote" verschil is blijkbaar dat kernel modules in kernel space draaien,
en programma's niet, maar dat verschil is helemaal niet groot, en is slechts
een technisch detail. Als je een systeem zou hebben zonder protected mode
(ELKS, bijvoorbeeld!) dan *is* er niet eens een verschil, en is het dus
pure willekeur van de FSF om het "overduidelijk" als een ander proces te
beschouwen. Het feit dat de license file van iedere Linux kernel begint met
te vertellen dat userland processen *NIET* als afgeleid werk dienen te worden
beschouwd geeft aan dat het blijkbaar niet zo 'overduidelijk' is.
--
Martijn van Buul - ***@dohd.org
unknown
2008-09-01 20:06:25 UTC
Permalink
Post by Martijn van Buul
Post by unknown
Ik dacht dat het verschil kernelspace <-> userspace voor de FSF een
voldoende grote barriere was, maar dat is dus ook al niet zo? Tsk.
Tsja, ik ook, maar waar staat dat? De FSF laat in het midden wat ze onder
een derived work verstaan...
Ik denk dat ze dat aan de plaatstelijke auteurswet overlaten.
Post by Martijn van Buul
" If the program dynamically links plug-ins, and they make function calls
to each other and share data structures...
Van "dynamically linking" is waarschijnlijk wel sprake, ze maken
onderling function calls bij de vleet (syscalls, anyone?) en een
willekeurig userland proces staat vol van datastructuren die door de
kernel zijn bedacht. Dit geldt zowel voor userland processen als kernel
modules.
Alles hangt op dat 'dynamic linking', want al het andere kan b.v. ook
plaatsvinden tussen een SOAP-server en -client. In de terminologie van
shared libraries vind ik het inladen en uitvoeren van een applicatie door
de kernel geen dynamic linking, in termen van dat de kernel functies bevat
die door die applicatie direct aangeroepen kunnen worden.

Overigens zou 'de ene kant op' ook 'de andere kant op' moeten betekenen, en
zou je dus ook geen GPL-applicatie op een niet-GPL-kernel mogen draaien.
--
robert
Martijn van Buul
2008-09-02 07:37:23 UTC
Permalink
Post by unknown
Alles hangt op dat 'dynamic linking', want al het andere kan b.v. ook
plaatsvinden tussen een SOAP-server en -client.
Check. En wat mij betreft is dat een kwestie van tijd voordat het FSF hier
dankbaar misbruik van gaat maken, liefst door hele horden slashdot geeks
de callcenters van bedrijven die SOAP gebruiken lam te laten leggen met domme
vragen...
Post by unknown
In de terminologie van shared libraries vind ik het inladen en uitvoeren van
een applicatie door de kernel geen dynamic linking, in termen van dat de
kernel functies bevat die door die applicatie direct aangeroepen kunnen
worden.
Tsja, mwaar waarom zou dat dan voor een kernel module wel gelden? Wat mij
betreft is het verschil tussen een kernel module en een applicatie heel dun,
dat is wat ik heb willen aangeven.
Post by unknown
Overigens zou 'de ene kant op' ook 'de andere kant op' moeten betekenen, en
zou je dus ook geen GPL-applicatie op een niet-GPL-kernel mogen draaien.
Dat hangt van de licentie van die niet-GPL kernel af (geen probleem op een
BSD-licensed kernel), maar het zou inderdaad wel de doodsteek van de GPLv3
zijn als iemand dat kon afdwingen :) De GPLv2 is namelijk niet compatible
met de GPLv3..
--
Martijn van Buul - ***@dohd.org
unknown
2008-09-02 07:50:30 UTC
Permalink
Post by Martijn van Buul
Post by unknown
In de terminologie van shared libraries vind ik het inladen en
uitvoeren van een applicatie door de kernel geen dynamic linking, in
termen van dat de kernel functies bevat die door die applicatie
direct aangeroepen kunnen worden.
Tsja, mwaar waarom zou dat dan voor een kernel module wel gelden?
Omdat die wel directe toegang heeft tot kernelfuncties en -datastructuren.
Post by Martijn van Buul
Post by unknown
Overigens zou 'de ene kant op' ook 'de andere kant op' moeten betekenen,
en zou je dus ook geen GPL-applicatie op een niet-GPL-kernel mogen
draaien.
Dat hangt van de licentie van die niet-GPL kernel af (geen probleem op
een BSD-licensed kernel), maar het zou inderdaad wel de doodsteek van de
GPLv3 zijn als iemand dat kon afdwingen :) De GPLv2 is namelijk niet
compatible met de GPLv3..
Mooi he? ;)
--
robert
Martijn van Buul
2008-09-02 08:08:40 UTC
Permalink
Post by unknown
Post by Martijn van Buul
Post by unknown
In de terminologie van shared libraries vind ik het inladen en
uitvoeren van een applicatie door de kernel geen dynamic linking, in
termen van dat de kernel functies bevat die door die applicatie
direct aangeroepen kunnen worden.
Tsja, mwaar waarom zou dat dan voor een kernel module wel gelden?
Omdat die wel directe toegang heeft tot kernelfuncties en -datastructuren.
Userland ook, alleen is de procedure subtiel anders.

Weet je hoe je een ELKS (embedded Linux voor 8086) *applicatie* test? Door
hem te draaien als kernel module op een i386 systeem. Nuff said.
--
Martijn van Buul - ***@dohd.org
unknown
2008-09-02 09:14:19 UTC
Permalink
Post by Martijn van Buul
Post by unknown
Omdat die wel directe toegang heeft tot kernelfuncties en
-datastructuren.
Userland ook, alleen is de procedure subtiel anders.
Weet je hoe je een ELKS (embedded Linux voor 8086) *applicatie* test?
Door hem te draaien als kernel module op een i386 systeem. Nuff said.
Voor zover ik begrijp heb je een kernelmodule nodig om het executable
formaat van ELKS-binaries te kunnen gebruiken op je Linuxbak, maar de
ELKS-app die je wilt testen wordt zelf niet in de kernel geladen. Maar dat
is wat ik zo uit de FAQ opmaak, ik ga er van uit dat jij meer verstand hebt
van embedded zaken dan ik :)
--
robert
Martijn van Buul
2008-09-02 09:29:23 UTC
Permalink
Post by unknown
Voor zover ik begrijp heb je een kernelmodule nodig om het executable
formaat van ELKS-binaries te kunnen gebruiken op je Linuxbak, maar de
ELKS-app die je wilt testen wordt zelf niet in de kernel geladen.
Verrek, scheef gelezen. Mea culpa.
--
Martijn van Buul - ***@dohd.org
Huub Reuver
2008-09-02 16:47:20 UTC
Permalink
Post by Martijn van Buul
Post by unknown
Post by Martijn van Buul
Post by unknown
In de terminologie van shared libraries vind ik het inladen en
uitvoeren van een applicatie door de kernel geen dynamic linking, in
termen van dat de kernel functies bevat die door die applicatie
direct aangeroepen kunnen worden.
Tsja, mwaar waarom zou dat dan voor een kernel module wel gelden?
Omdat die wel directe toegang heeft tot kernelfuncties en -datastructuren.
Userland ook, alleen is de procedure subtiel anders.
Weet je hoe je een ELKS (embedded Linux voor 8086) *applicatie* test? Door
hem te draaien als kernel module op een i386 systeem. Nuff said.
Even buiten ELKS (want niet van toepassing voor de i386 en beter):
Als je directe geheugentoegang toelaat tot kernelfuncties en -datastructuren
creeer je dan niet een ongelovelijk potentieel aan exploits?

Ik heb wel eens gelezen dat er mensen zijn die vinden dat directe
toegang waar mogelijk voorkomen moet worden. Natuurlijk kost dit snelheid,
maar minder dan de downtime die je kwijt bent met een bughunt, forensic
analysis of herinstallatie.

Met vriendelijke groet,
Huub Reuver
unknown
2008-09-02 18:38:16 UTC
Permalink
Post by Huub Reuver
Als je directe geheugentoegang toelaat tot kernelfuncties en
-datastructuren creeer je dan niet een ongelovelijk potentieel aan
exploits?
Waarom denk je dat je root moet zijn om een kernelmodule in te kunnen
laden? :)
Post by Huub Reuver
Ik heb wel eens gelezen dat er mensen zijn die vinden dat directe toegang
waar mogelijk voorkomen moet worden.
Zulke mensen werken b.v. aan GNU Hurd.
--
robert
Huub Reuver
2008-09-02 19:29:40 UTC
Permalink
Post by unknown
Post by Huub Reuver
Als je directe geheugentoegang toelaat tot kernelfuncties en
-datastructuren creeer je dan niet een ongelovelijk potentieel aan
exploits?
Waarom denk je dat je root moet zijn om een kernelmodule in te kunnen
laden? :)
In de lijn van het verhaal las ik toch dat er praktisch geen verschil
was tussen kernelspace en userspace. Of dat die grens vaag is.
Misschien verkeerd gelezen?

En nog altijd zijn er mensen in staat een gaatje te vinden om middels
zo'n exported kernelvariabele een opstapje te krijgen naar root-rechten.
Post by unknown
Post by Huub Reuver
Ik heb wel eens gelezen dat er mensen zijn die vinden dat directe toegang
waar mogelijk voorkomen moet worden.
Zulke mensen werken b.v. aan GNU Hurd.
Zouden dergelijke mensen ook niet te vinden zijn bij OpenBSD?
En bij Linux lopen er ook genoeg rond (maar volgens mij was Linus zelf er
niet een van).

Voor GNU Hurd geld nog steeds het aloude verhaal "It is not ready for
production use, ...". Dus om die nou bij de haren erbij te slepen lijkt
me een beetje vergezocht.

Ik meen dat ergens in de linux-kernel een optie was om geen variabelen
te exporteren. Meer volgens de redenatie "er komt toch niets goeds van".
Alleen al door zo'n optie wordt impliciet beweerd dat er standaard toch
veel variabelen ge-exporteerd worden (of in elk geval publiek zijn).

Met vriendelijke groet,
Huub Reuver
Martijn van Buul
2008-09-02 20:06:28 UTC
Permalink
Post by Huub Reuver
Post by unknown
Post by Huub Reuver
Als je directe geheugentoegang toelaat tot kernelfuncties en
-datastructuren creeer je dan niet een ongelovelijk potentieel aan
exploits?
Waarom denk je dat je root moet zijn om een kernelmodule in te kunnen
laden? :)
In de lijn van het verhaal las ik toch dat er praktisch geen verschil
was tussen kernelspace en userspace. Of dat die grens vaag is.
Misschien verkeerd gelezen?
Ik heb nooit gezegd dat er geen verschil was. Ik heb gezegd dat het
verschil een *practisch* verschil is, een implementatieverschil, en een
technisch detail die wat mij betreft geen enkel verschil uitmaakt wat betreft
de licentie. *daar* ging het mij over.

Er is een hemelsgroot verschil tussen OGG en MP3, en toch is dat maar
een implementatiedetail. Er is een levensgroot verschil tussen een child
process en een child process in een chroot, wat betreft security, maar dat
maakt totaal niet uit voor de discussie.
Post by Huub Reuver
En nog altijd zijn er mensen in staat een gaatje te vinden om middels
zo'n exported kernelvariabele een opstapje te krijgen naar root-rechten.
Natuurlijk, maar daar ging het dan ook niet over.
--
Martijn van Buul - ***@dohd.org
unknown
2008-09-03 05:38:43 UTC
Permalink
Post by Huub Reuver
Post by unknown
Zulke mensen werken b.v. aan GNU Hurd.
Zouden dergelijke mensen ook niet te vinden zijn bij OpenBSD?
Dat natuurlijk ook, maar een 'echt' microkernel-OS als Hurd is - in theorie
- een stuk veiliger dan een monolitische kernel omdat er bij die eerste een
stricte scheiding is tussen alle onderdelen van de kernel.
Post by Huub Reuver
Voor GNU Hurd geld nog steeds het aloude verhaal "It is not ready for
production use, ...". Dus om die nou bij de haren erbij te slepen
lijkt me een beetje vergezocht.
Het was ook meer een grap hoor :)
--
robert
Martijn van Buul
2008-09-02 20:11:43 UTC
Permalink
Post by Huub Reuver
Als je directe geheugentoegang toelaat tot kernelfuncties en -datastructuren
creeer je dan niet een ongelovelijk potentieel aan exploits?
Ja.
Post by Huub Reuver
Ik heb wel eens gelezen dat er mensen zijn die vinden dat directe
toegang waar mogelijk voorkomen moet worden. Natuurlijk kost dit snelheid,
maar minder dan de downtime die je kwijt bent met een bughunt, forensic
analysis of herinstallatie.
Mensen die denken dat het ontzeggen van directe toegang *voorkomt* dat er
vervelend te vinden bugs ontstaan, programmeren vaak in java of een andere
speelgoedtaal.
--
Martijn van Buul - ***@dohd.org
Huub Reuver
2008-09-02 21:02:32 UTC
Permalink
Post by Martijn van Buul
Post by Huub Reuver
Als je directe geheugentoegang toelaat tot kernelfuncties en -datastructuren
creeer je dan niet een ongelovelijk potentieel aan exploits?
Ja.
Post by Huub Reuver
Ik heb wel eens gelezen dat er mensen zijn die vinden dat directe
toegang waar mogelijk voorkomen moet worden. Natuurlijk kost dit snelheid,
maar minder dan de downtime die je kwijt bent met een bughunt, forensic
analysis of herinstallatie.
Mensen die denken dat het ontzeggen van directe toegang *voorkomt* dat er
vervelend te vinden bugs ontstaan, programmeren vaak in java of een andere
speelgoedtaal.
Ik dacht dat dergelijke mensen de sprookjesboeken nauwelijks ontgroeid waren.
Wacht, dat zijn er vele.

Voorkomen is hier een erg groot woord.

Zoals altijd met security is het werken aan veiligheid en mogelijke
zwakke punten elimineren. Een zwak punt eliminineren staat volgens mij
nog altijd niet gelijk aan het probleem oplossen. Het probleem wordt
hooguit overzichtelijker/beter beheersbaar.

Security blijft spijkers op laag water zoeken. En de zwakste schakel...

Directe geheugentoegang staat voor sommigen bijna gelijk aan de deur
openzetten. Op z'n minst wordt de drempel voor een exploit een stuk
lager.


Met vriendelijke groet,
Huub Reuver
unknown
2008-08-29 07:46:05 UTC
Permalink
Post by Paul van der Vlis
Maar stel, hij gebruikt een driver van een leverancier die niet open
source is, maar closed source. Die code kan hij niet vrijgeven.
Mag een dergelijk apparaat dan gewoon niet in de handel komen?
Lees hier de mening van Linus (weliswaar alweer enige jaren oud):
http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html

Kortom: het is een grijs gebied. Volgens de GPL mag het niet, volgens
'copyright law' mag het misschien wel.
--
robert
Loading...