Modules noyau

Il est très vite devenu évident que nous voulions développer un système aussi modulaire que possible. Le modèle de développement à Sources Libres l'impose, parce que sinon, vous ne pouvez pas facilement laisser plusieurs personnes travailler simultanément. Il est vraiment pénible d'avoir plusieurs personnes qui se gênent les unes les autres parce qu'elles travaillent sur la même partie du noyau.

Sans modularité je devrais vérifier tous les fichiers modifiés afin de m'assurer que ces changements n'affectent pas autre chose. Cela représenterait un travail énorme. Avec la modularité, quand quelqu'un m'envoie des corrections pour un nouveau système de fichiers et que je ne lui accorde pas confiance a priori, je peux toujours être certain que si personne n'utilise ce système de fichiers, il n'aura aucun impact sur d'autres parties.

Ainsi, Hans Reiser développe un nouveau système de fichiers, et vient d'arriver à le faire fonctionner. Je ne pense pas qu'il vaille la peine d'être inséré dans le noyau 2.2 dès maintenant. Mais, grâce à la modularité du noyau, je le pourrais si je le voulais vraiment et ce ne serait pas trop difficile. Il s'agit surtout d'empêcher les gens de se marcher sur les pieds.

Avec le noyau 2.0, Linux a vraiment pris du poids. C'est le moment où nous avons ajouté les modules dans le noyau. Ceci a de façon évidente amélioré la modularité en donnant une structure explicite pour écrire des modules. Les programmeurs pouvaient travailler sur différents modules sans risque d'interférence. Je pouvais garder le contrôle de ce qui était écrit dans le noyau à proprement parler. Ainsi, encore une fois, la gestion des intervenants et celle du code ont amené à prendre la même décision de conception. Pour que les personnes travaillant sur Linux restent coordonnées, nous avions besoin d'une solution ressemblant aux modules noyau. Mais du point de vue de la conception, c'était aussi la chose à faire.

L'autre aspect de la modularité est moins évident, et plus problématique. Il s'agit du chargement dynamique, que tout le monde apprécie mais qui pose de nouveaux problèmes. Le premier problème est d'ordre technique, et est donc, comme d'ordinaire, (presque) toujours le plus simple à résoudre. Le problème le plus important concerne les parties non techniques. Par exemple, à quel point un module est-il un travail dérivé de Linux et par conséquent sous GPL ?

Quand la première interface des modules a été faite, des personnes ayant écrit des pilotes pour SCO ne voulaient pas en publier le code source, comme requis par la GPL. Néanmoins, ils étaient prêts à le recompiler pour fournir des binaires pour Linux. À ce point, pour des raisons morales, j'ai décidé que je ne pouvais pas appliquer la GPL à ce genre de situation.

La GPL impose que les travaux « dérivés » d'un travail sous GPL soient protégés par elle. Malheureusement, la définition d'un travail dérivé est assez vague. Dès que vous essayez de tracer une frontière pour les travaux dérivés, le problème se transpose immédiatement au choix de l'endroit où placer la frontière.

Nous avons fini par décider (à moins que ce soit moi qui aie fini par décréter) que les appels systèmes ne seraient pas considérés comme un lien au noyau. Tout programme fonctionnant au-dessus de Linux ne pouvait donc pas être considéré comme couvert par la GPL. Cette décision a très rapidement été prise et j'ai même ajouté un fichier spécial LISEZMOI (voir Annexe B) pour en informer tout le monde. Pour cette raison, les éditeurs commerciaux peuvent écrire des programmes pour Linux sans avoir à s'inquiéter de la GPL.

Le résultat, du point de vue des programmeurs de modules, était qu'on pouvait écrire un module propriétaire si l'on n'utilisait que l'interface normale pour le chargement. Il s'agit cependant toujours d'une zone d'ombre du noyau. Ces zones d'ombre laissent peut-être toujours des occasions aux gens pour abuser de la situation et c'est en partie à cause de la GPL qui n'est pas particulièrement claire à propos de thèmes tels que l'interface de modules. Si quelqu'un devait passer outre en utilisant les symboles exportés dans le seul but de contourner la GPL, alors je pense qu'il y aurait une possibilité de poursuites en justice. Mais je ne pense pas que quiconque veuille utiliser le noyau de façon malhonnête ; ceux qui ont montré un intérêt commercial dans le noyau l'ont fait parce qu'ils étaient intéressés par les avantages apportés par le modèle de développement.

La puissance de Linux réside autant dans la communauté qui coopère afin de l'améliorer que dans le code lui-même. Si Linux était détourné —  si quelqu'un voulait faire et distribuer une version propriétaire —  son attrait, qui est principalement le modèle de développement à Sources Libres, serait perdu dans cette version propriétaire.