Ne faire que dans le libre

[fran.b]

[quote=“Grunt”]
Si tu as juste un driver propriétaire, tu n’as pas le choix. Ou alors il existe aussi des spécifications ou un pilote libre, auquel cas tu as le choix.[/quote]
Ici tu supposes qu’on n’a pas le choix du matériel (ce qui est souvent vrai)

[quote][quote=“Grunt”]
Donc tu veux utiliser un noyau 100% libre mais charger des blobs binaires? Là, désolé, mais je ne vois pas quel est ton but.
C’est comme si tu te plaignais que vrms t’indique que tu as des logiciels propriétaires: il est là pour ça. C’est son but, sa raison d’être.
De même que le noyau 100% libre a pour unique but et raison d’être de n’utiliser que du libre.

C’est toi qui décides “Je ne veux que du libre” en allant chercher un noyal totalement libre. ça me parait logique qu’il te bloque un module qui charge du code proprio: ce ne serait pas un noyal “totalement libre” sinon.[/quote][/quote]
…et là tu supposes qu’on a le choix de son matériel. Ton point de vue est contradictoire. La pratique est que tu n’as pas le choix de ton matériel et que modulo ces contraintes, tu peux vouloir faire tourner un noyau libre avec des firmwares externes éventuellement propriétaires si nécessaire. Tu as effectivement un point de vue intégriste en n’envisageant que les cas extrèmes (tout blanc ou tout noir), la volonté de séparer le code libre du code non libre est importante et constitue une motivation pour avoir un tel noyau. Je ne veux pas charger des firmwares binaires, mais je veux tout simplement utiliser ce noyau en utilisant le minimum strict de non libre et en le localisant très précisemment. C’était le but de BLAG au départ (que je sache, on peut installer Maple ou Matlab sur une BLAG)

Par ailleurs tu parles d’une erreur de conception mais pas du tout, si j’ai bien compris ce qu’a dit Junichiro, parce que un firmware propriétaire pouvait être utilisé, le module a été viré en connaissance de cause (du moins la décision de le virer a été maintenu si j’ai bien compris).

Mais bon, comme le dit ggoodluck, la discussion n’a pas vraiment d’intérêt car on tourne en rond

[Junichiro2]

Le module n’a pas été viré mais le noyau refuse de le charger. Et Alexandre a dit dans la même discussion que c’était une condition nécessaire pour que BLAG reste reconnue comme 100% libre par la FSF. Donc, toute distro qui n’aura pas un linux-libre conforme à cela (voir l’échange entre Alexandre est RMS) ne pourra recevoir l’approbation de la FSF.
Précision: Alexandre n’est pas seulement le mainteneur du kernel linux-libre, il est aussi un membre influent de la FSF Amérique latine.

[fran.b]

[quote=“Junichirô”]Le module n’a pas été viré mais le noyau refuse de le charger. Et Alexandre a dit dans la même discussion que c’était une condition nécessaire pour que BLAG reste reconnue comme 100% libre par la FSF. Donc, toute distro qui n’aura pas un linux-libre conforme à cela (voir l’échange entre Alexandre est RMS) ne pourra recevoir l’approbation de la FSF.
Précision: Alexandre n’est pas seulement le mainteneur du kernel linux-libre, il est aussi un membre influent de la FSF Amérique latine.[/quote]
Comment conçoit-il cela avec la liberté 0?
«La liberté d’exécuter le programme, pour tous les usages (liberté 0). w
En tout cas, cela signifierait que linux va arrêter d’être un produit libre… Bien vu pour la visibilité à l’extérieur. À un moment où le libre commence à réellement être pris au sérieux, ça n’est pas vraiment ce qu’on appelle une bonne idée…
Alexandre Oliva va reprécipiter linux dans la niche «outils au suivi non fiable spécial barbons folklos…»

[Grunt]

Je trouve ça marrant de rouscailler pour un noyau garanti 100% libre, alors que c’est une option réservée à ceux que ça intéresse de n’avoir que du libre.

J’aimerais voir ça plus souvent, tiens!
Si chaque constructeur de matériel disait "Bon, on a aussi un pilote 100% libre pour ceux qui y tiennent vraiment, si chaque éditeur de logiciel proposait “Bien sûr, nos formats sont ouverts, afin de proposer à ceux qui ne veulent que du libre de pouvoir malgré tout les lire.”

Ben non, y’a plein de gens qui ne laissent absolument pas le choix entre “libre” et “pas libre”.

Le noyau 100% libre est un choix supplémentaire offert par dessus une possibilité existante plus pratique, à savoir celle d’un noyau qui accepte les trucs propriétaires. Une option, un choix, pas une contrainte. Ses développeurs font ce qu’ils veulent, si ça te plait pas tu prends pas: contrairement à un matériel avec pilote proprio, ou à un fichier DRMisé, on ne t’impose absolument pas de te servir d’un code précis.

Et ce n’est pas incompatible avec la liberté 0: tu peux bien faire ce que tu veux avec le noyau déblobé, y’a des fois où il refusera de charger un module susceptible de charger du code proprio. ça n’empêche pas de l’utiliser, d’essayer de lui faire charger du code proprio, de le modifier pour qu’il l’accepte, ou d’utiliser autre chose.

[MisterFreez]

[quote=“fran.b”]Comment conçoit-il cela avec la liberté 0?
«La liberté d’exécuter le programme, pour tous les usages (liberté 0). w
En tout cas, cela signifierait que linux va arrêter d’être un produit libre… Bien vu pour la visibilité à l’extérieur. À un moment où le libre commence à réellement être pris au sérieux, ça n’est pas vraiment ce qu’on appelle une bonne idée…
Alexandre Oliva va reprécipiter linux dans la niche «outils au suivi non fiable spécial barbons folklos…»[/quote]
Il est bien le contrat social Debian n’est ce pas ?

Nous reconnaissons que certains de nos utilisateurs demandent à pouvoir utiliser des travaux qui ne sont pas conformes aux principes du logiciel libre selon Debian. Les paquets correspondant prennent place dans des sections nommées “contrib” (“contributions”) et “non-free” (“non libre”). Les paquets de ces sections ne font pas partie du système Debian, bien qu’ils aient été configurés afin d’être utilisés avec lui.[…]. Ainsi, bien que les travaux non libres ne fassent pas partie de Debian, nous prenons en compte leur utilisation et fournissons donc l’infrastructure nécessaire (à l’image de notre système de suivi des bogues et de nos listes de diffusion).

Ne t’inquiète pas. Linus a déjà tenu tête à la FSF d’autre fois il en feras de même.
Ce qu’il faut comprendre c’est que les contributeurs du kernel n’ont pas les même objectifs que les membre de la FSF.

[M3t4linux]

[quote=“MisterFreez”]
Ne t’inquiète pas. Linus a déjà tenu tête à la FSF d’autre fois il en feras de même.
Ce qu’il faut comprendre c’est que les contributeurs du kernel n’ont pas les même objectifs que les membre de la FSF.[/quote]

Et ce, parce que les contributeurs du kernel ont un objectif plutôt “technique” que “politique”??

[Junichiro2]

Je ne vois pas d’opposition. Si vous voulez une distribution 100% libre reconnue par la FSF vous devez avoir un kernel linux-libre. Sinon, vous utilisez votre distribution habituelle. Pourquoi chercher un affrontement qui n’existe pas?

[antalgeek1]

Je remonte le fil pour donner des nouvelles des symboles GPL_ONLY dans le noyau.

J’ai cherché à savoir si cette fonctionnalité pouvait être désactivée facilement. Je n’ai pas fait ça pour soulever un débat idéologique mais juste parce que j’ai les sources donc je peux essayer.

J’ai fait des modifications assez simples.

Dans kernel/modules.c

static bool gpl_only_unused_warning(bool gplok, bool warn, const char *name) { if (!gplok) return true; return printk_unused_warning(gplok, warn, name); }

Dans scripts/mod/modpost.c - fonction static void read_symbols(char *modname)

while (license) { if (license_is_gpl_compatible(license)) mod->gpl_compatible = 1; else { mod->gpl_compatible = 1; break; }

Le noyau s’est compilé sans soucis ainsi que le module.
Par contre au modprobe, ça coince comme le montre ce bout de dmesg

[  154.236331] mechant_module: Unknown symbol usb_alloc_urb
[  154.236377] mechant_module: Unknown symbol usb_free_urb
[  154.236433] mechant_module: Unknown symbol usb_register_driver
[  154.236510] mechant_module: Unknown symbol usb_find_interface
[  154.236540] mechant_module: Unknown symbol usb_clear_halt
[  154.236572] mechant_module: Unknown symbol usb_put_dev
[  154.236602] mechant_module: Unknown symbol usb_bulk_msg
[  154.236633] mechant_module: Unknown symbol usb_get_dev
[  154.236663] mechant_module: Unknown symbol usb_submit_urb
[  154.236715] mechant_module: Unknown symbol usb_control_msg
[  154.236745] mechant_module: Unknown symbol usb_register_dev
[  154.236793] mechant_module: Unknown symbol usb_deregister
[  154.236836] mechant_module: Unknown symbol usb_unlink_urb
[  154.236841] mechant_module: Unknown symbol usb_reset_configuration
[  154.236841] mechant_module: Unknown symbol usb_deregister_dev
[  154.236841] mechant_module: Unknown symbol usb_kill_urb
[  154.236841] mechant_module: Unknown symbol usb_buffer_free
[  154.236841] mechant_module: Unknown symbol usb_buffer_alloc

Manifestement je suis passé à côté de quelque chose.

Mais ça prouve quand même qu’il est possible de dégager la fonctionnalité GPL_ONLY, c’est juste que ce n’est pas aussi simple que je le pensais.

Affaire à suivre …

[antalgeek1]

Ca y est c’est bon

Il suffisait de modifier dans kernel/module.c la fonction

[code]/* Find a symbol, return value, (optional) crc and (optional) module

• which owns it */
  static unsigned long find_symbol(const char *name,
  struct module **owner,
  const unsigned long **crc,
  bool gplok,
  bool warn)[/code]

Il faut remplacer les occurrences de gplok par true, soit 2 modif

	/* Core kernel first. */
	ks = search_symarrays(arr, ARRAY_SIZE(arr), name, true, warn, crc);
	if (ks) {
		if (owner)
			*owner = NULL;
		return ks->value;

Au lieu de

	/* Core kernel first. */
	ks = search_symarrays(arr, ARRAY_SIZE(arr), name, gplok, warn, crc);
	if (ks) {
		if (owner)
			*owner = NULL;
		return ks->value;

Et

	/* Now try modules. */
	list_for_each_entry(mod, &modules, list) {
		struct symsearch arr[] = {
			{ mod->syms, mod->syms + mod->num_syms, mod->crcs,
			  always_ok },
			{ mod->gpl_syms, mod->gpl_syms + mod->num_gpl_syms,
			  mod->gpl_crcs, gpl_only },
			{ mod->gpl_future_syms,
			  mod->gpl_future_syms + mod->num_gpl_future_syms,
			  mod->gpl_future_crcs, warn_if_not_gpl },
			{ mod->unused_syms,
			  mod->unused_syms + mod->num_unused_syms,
			  mod->unused_crcs, printk_unused_warning },
			{ mod->unused_gpl_syms,
			  mod->unused_gpl_syms + mod->num_unused_gpl_syms,
			  mod->unused_gpl_crcs, gpl_only_unused_warning },
		};

		ks = search_symarrays(arr, ARRAY_SIZE(arr),
				      name, true, warn, crc);

Au lieu de

	/* Now try modules. */
	list_for_each_entry(mod, &modules, list) {
		struct symsearch arr[] = {
			{ mod->syms, mod->syms + mod->num_syms, mod->crcs,
			  always_ok },
			{ mod->gpl_syms, mod->gpl_syms + mod->num_gpl_syms,
			  mod->gpl_crcs, gpl_only },
			{ mod->gpl_future_syms,
			  mod->gpl_future_syms + mod->num_gpl_future_syms,
			  mod->gpl_future_crcs, warn_if_not_gpl },
			{ mod->unused_syms,
			  mod->unused_syms + mod->num_unused_syms,
			  mod->unused_crcs, printk_unused_warning },
			{ mod->unused_gpl_syms,
			  mod->unused_gpl_syms + mod->num_unused_gpl_syms,
			  mod->unused_gpl_crcs, gpl_only_unused_warning },
		};

		ks = search_symarrays(arr, ARRAY_SIZE(arr),
				      name, gplok, warn, crc);

Au final le module proprio compile et se charge, le périphérique fonctionne correctement.