Re: Les licenses courtes

Je suis pas non plus vraiment d'accord pour dire que ça rende tout si compliqué. Si c'était le cas, je pense qu'il y aurait plus de matos avec une variante de netbsd/freebsd plutôt que Linux. Surtout dans la mesure ou on arrête pas de dire que le code de Linux est pas claire, que les BSD ont une meilleur pile réseau et que la GPL est trop compliqué.

Je pense qu'une raison majeure de l'utilisation de la GPL est simplement l'effet de masse. C'est l'une des licences libres les plus célèbres, après tout, et encensée plus bruyamment que les autres.
En tout cas, ce sont les raisons pour lesquelles j'avais plus "d'affinités" pour elle quand je découvrais le logiciel libre. À l'époque, j'aurai surement pas dit ça, bien sûr. Mais si on s'était avisé de me poser des questions sur la LGPL, GPL ou AGPL, j'aurai été bien embêté. Oui, je connaissais les grandes lignes, mais, par exemple, je n'ai jamais su quelle est la différence entre la v1 et la v2 de GPL. Pour la v3, je crois que c'est un truc lié au code qui tourne sur du matos loué?
Malgré que je les aie lues, et plus d'une fois, j'ai découvert aujourd'hui cette histoire de devoir fournir le code pendant 3 ans... Mon cerveau à du le zapper à chaque lecture.

Maintenant que je me soucie vraiment de comprendre les autorisations liées à un bout de code, je préfère des licences courtes (BSD 2/3 clauses, MIT, zlib...) qui restreignent moins que la GLP&co. Moins complexes. Lisibles.
Sinon les licences CC me semblent bien aussi, même si j'admets ne jamais les avoir lues.

Pour faire comme toi le lien avec du code, il y à plus de systèmes qui tournent avec:

• la version GNU de coreutils
• libstdc++
• glibc

Alors que, sincèrement, pour avoir lu le code de 2 commandes (yes et echo, de mémoire. Des commandes relativement simples, quoi.) des coreutils GNU, FreeBSD, NetBSD et OpenBSD, le code GNU est le moins lisible et de très loin. Le plus lisible était NetBSD, puis OpenBSD.
Ça me fait penser que je n'ai pas lu le code de busybox, et qu'à l'heure actuelle, c'est le sort -n de busybox que j'utilise, celui de GNU ne fonctionnant pas comme je veux (et ajouter l'option -b, qui ignore les blancs d'en-tête, ne change rien):

% ps -orss,vsz,comm -A | sort -n | grep -C 3 'ssh-agent' 
 1108 4252 runsvdir
 1424 4256 acpid
 2116 8172 pager
 336 10700 ssh-agent
 1108 10928 dropbear
 1808 15492 init
 1900 15952 xinit

% ps -orss,vsz,comm -A | busybox sort -n | grep -C 3 'ssh-agent'
 0 0 writeback
 RSS VSZ COMMAND
 4 160 ngetty
 336 10700 ssh-agent
 672 5964 cat
 704 5964 cat
 720 4712 busybox

Pour ce qui est des lib C et C++, quand j'ai un doute sur un prototype ou une struct (parce que les manpages sont super mal branlées de ce point de vue, sans parler du fait qu'il n'y a rien pour la STL), je vais lire les header de la libc++ (de llvm) ou de muslc.
Les headers sont moins chargés, moins de branchements et inclusions, et accessoirement, la dernière fois que j'ai regardé, les espaces et les tabulations n'étaient pas mixés pour l'indentation. Contrairement au code GNU.

Dans la pratique, j'ai la flemme de recompiler ma Debian pour me débarrasser des outils GNU en faveur des alternatives plus propres. Et je parie que je ne suis pas le seul dans ce cas.
Donc, oui, vraiment, je doute que l'usage actuel des outils GNU (code comme licences) tiens énormément à un effet de masse et d'historique.
Absolument pas à des choix techniques éclairés.

Pour le code kernel (puisque tu as cité Linux), je n'en ai aucune idée, je n'ai pas encore osé mettre mon nez dedans. Les kernels restent des choses qui m'intimident, et de toute façon je n'aurai pas vraiment d'usage: je ne parviens pas à imaginer ce que je pourrai leur apporter :D