FreeBSD est un système d'exploitation UNIX libre, lancé en 1993. L'objectif du projet est de fournir un système qui puisse servir à tout, avec le moins de restrictions possibles (dixit Wikipedia).
Après un cycle de bêta démarré le 5 février 2021, cinq versions candidates sont parues et FreeBSD 13.0-RELEASE est sortie le 13 avril 2021 (pour les architectures amd64, i386, powerpc, powerpc64, powerpc64le, powerpcspe, armv6, armv7, aarch64 et riscv64).
Cette dépêche mentionne quelques évolutions marquantes apportées par cette nouvelle version de FreeBSD.
Les utilitaires clang, lld, et lldb et les bibliothèques compiler-rt, llvm, libunwind, et libc++ ont été mis à jour en version 11.0.1.
La version obsolète du débogueur GNU qui était installée dans /usr/libexec pour être utilisée par crashinfo a été supprimée. Des informations détaillées sur les crashs du noyau peuvent être obtenues en installant un GDB moderne à partir des ports ou des paquets.
Les versions obsolètes 2.17 de binutils et 4.2.1 de gcc ont été supprimés de l’arbre. Toutes les architectures supportées utilisent maintenant la chaîne d’outils LLVM/clang.
La version BSD de grep est maintenant installée par défaut. La version GNU obsolète qui était auparavant le choix par défaut a été supprimée.
La prise en charge CU-SeeMe de libalias a été retirée.
Le pilote qat a été ajouté, supportant certaines des fonctions d’accélération cryptographique du périphérique Intel QuickAssist (QAT). Le pilote qat supporte les périphériques QAT intégrés aux plateformes Atom C2000 et C3000 et Xeon C620 et D-1500, et l’adaptateur Intel QAT 8950.
Plusieurs pilotes ont été portés sur l’architecture PowerPC64 alors que plusieurs pilotes obsolètes ont été supprimés.
Le noyau prend désormais en charge l’encapsulation et le chiffrement dans le noyau des données TLS (Transport Layer Security) sur les sockets TCP pour les versions 1.0 à 1.3 de TLS. Le déchargement de transmission via les pilotes cryptographiques du noyau est pris en charge pour les suites de chiffrement MtE utilisant AES-CBC ainsi que les suites de chiffrement AEAD utilisant AES-GCM. Le déchargement de la réception via les pilotes cryptographiques du noyau est pris en charge pour les suites de chiffrement AES-GCM pour TLS 1.2. L’utilisation de KTLS nécessite l’utilisation d’une bibliothèque SSL userland compatible avec KTLS. La bibliothèque OpenSSL incluse dans le système de base n’active pas le support KTLS par défaut, mais le support peut être activé en compilant avec l’option KERN_TLS. Cette fonctionnalité a été sponsorisée par Netflix qui l’utilise en production depuis plusieurs années.
L’architecture ARM 64 bits connue sous le nom de arm64 ou AArch64 est promue au statut Tier-1 pour FreeBSD 13.
Aller plus loin
- Annonce de la sortie de la version (72 clics)
- Le site de FreeBSD (149 clics)
# GDB ou LLDB?
Posté par alpha_one_x86 (site web personnel) . Évalué à 4. Dernière modification le 24 mai 2021 à 13:40.
Le noyau est compilé avec gcc? Si oui, pourquoi pas avec llvm/clang?
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: GDB ou LLDB?
Posté par Bapt (site web personnel) . Évalué à 8.
Le noyeau est compilé avec clang, la raison de gdb ici c'est que personne n'a écrit pour le moment d'équivalent de kgdb pour lldb.
# In-kernel framing
Posté par claudex . Évalué à 7.
Une vidéo expliquant l'intérêt d'avoir TLS dans le kernel. https://www.youtube.com/watch?v=la-ljVavd3c
En gros, cela permet d'envoyer des fichiers directement en restant dans le kernel, sans devoir faire des aller-retour vers l'userpace et donc avoir beaucoup plus de débit.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: In-kernel framing
Posté par Astaoth . Évalué à 4.
Est-ce que ca impliquerait de meilleures performances pour les VPN OpenVPN ? Ca ne serait pas du luxe ca !
Emacs le fait depuis 30 ans.
[^] # Re: In-kernel framing
Posté par claudex . Évalué à 5.
Je ne pense pas. C'est plutôt ciblé sur l'envoi de fichier si j'ai bien compris.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: In-kernel framing
Posté par barmic 🦦 . Évalué à 5.
Je crois que ça a beaucoup était poussé et expliqué avec
sendfile(2), mais je pense que ça reste utile pour tout usage où la source de données est dans l'espace kernel. haproxy pourrait par exemple établir la socket TLS puis établir un routage entre le serveur destinataire et le client via eBPF. Je parle là d'un cas d'usage où ça me paraît utile, je ne sais pas si c'est faisable ni dans linux ni dans freebsd.https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Obsolète
Posté par Sytoka Modon (site web personnel) . Évalué à 9.
Attention, ce ne sont pas les outils GNU qui sont obsolètes, ce sont les version que FreeBSD utilisait…
D'ailleurs, on voit bien que l'objectif est de virer tous les outils GPL petits à petits.
[^] # Re: Obsolète
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Corrigé, merci.
[^] # Re: Obsolète
Posté par Astaoth . Évalué à 6.
Si je ne m'abuse, les *BSD sont bloquées dans leurs mises à jours des outils GNU à cause de la GPL v3 qui n'est pas compatible avec l'écosystème BSD. La seule bonne solution est donc de mettre à jour ces outils par des versions sous licence BSD.
Le but de la démarche ne serait donc pas de remplacer l'ensemble des outils GNU ou GPL, mais juste de mettre des outils pouvant être utilisé dans les BSD de façon pérenne. Le remplacement de tout ces outils n'est en fait qu'une conséquence de la GPL v3 et sa tivoïsation des projets, qui d'une certaine façon s'avère contre-productive pour une partie des projets libres.
Emacs le fait depuis 30 ans.
[^] # Re: Obsolète
Posté par Sytoka Modon (site web personnel) . Évalué à 10.
La GPLv3 est compatible BSD… De mémoire, ce sont les BSD qui ne veulent pas de v3 et non l'inverse.
[^] # Re: Obsolète
Posté par Kaane . Évalué à 8.
Tout dépend de comment on défini compatible.
La GPLv3 est "compatible" avec BSD 2 clauses dans le sens ou on peut prendre tout le code écrit en BSD 2 clauses et le re-licencier en GPL (v2 ou V3)
Pareil pour la MIT, la WTFPL, et la plupart cas pour la Apache v2 si il n'y a pas de brevets ou de terminaison de licence impliqués.
Par contre le contraire n'est absolument pas vrai. Si on s'amuse à prendre du code GPL et à le mettre dans un autre source sous une autre licence reconnue comme compatible, ce source devient GPL immédiatement.
En Bref GPL + Compatible GPL => GPL
Et de gros soucis se posent sur des outils systèmes, car la licence GPL considère les bibliothèques systèmes comme différentes des bibliothèques non systèmes. Le check rapide que l'on est encouragé à faire est de se demander si le programme que l'on a créé aurait du sens si il n'était lié à la bibliothèque GPL.
Je fais un jeu vidéos qui utilise des bibliothèques de rendu GPL => je pourrais utiliser d'autre bibliothèques de modifier sans trop modifier mon code. Mon jeu n'est probablement pas nécessairement en GPL
Je fais un jeu vidéo qui utilise tout un framework GPL, moteur, rendu IA etc. => si je veux que mon jeu fonctionne avec un autre framework il faut probablement que je recode toute la logique. Mon jeu ne tient pas debout sans GPL, je suis obligé de le mettre en licence GPL.
Pour tout ce qui n'est pas système ça suffit généralement (même si mon exemple est caricatural et que c'est beaucoup plus complexe que ça en vérité). Pour ce qui est système par contre c'est plus compliqué: Le kernel, les pilotes et même certains outils bas niveau sont nécessaires à tous les programmes, et aucun programme ne peut tenir debout si il ne peut pas allouer de mémoire par exemple. Du coup il y a une exception dans la GPL qui dit que si on utilise que des bibliothèques système et/ou bas niveau on est quand même pas obligé de mettre son programme en licence GPL.
Mais rien ne dit que si on crée une bibliothèque système ou bas niveau qui utilise du code GPL, on peut lui donner une autre licence que GPL.
Et la GPLv3 a pas vraiment aidé, au contraire dans sa lutte contre la tivoisation qui se transforme lentement en lutte contre les logiciels dans le cloud non redistribués elle a tendance à générer pas mal de craintes, même chez des acteurs établis du libre.
Pour ces raisons, Linus Torvalds n'a pas fait la transition (si tant est qu'elle soit même raisonnablement faisable).
Et c'est aussi pour ces raisons que les systèmes BSD s'éloignent autant que possible de la GPL. Mais ils n'ont pas envie que l'on vienne leur expliquer que comme une lib quelconque sous GPL a été chain-linkée dans le kernel, les pilotes, les mécanismes de virtualisation ou de jail du coup un pan entier de leur système passe en GPL. Et surtout ils veulent rassurer leur clients institutionnels sur ce point.
TLDR : la GPLv3 n'est pas compatible avec BSD, c'est BSD qui est compatible vers GPLv3 et il existe un risque faible mais non nul que l'utilisation des outils et des bibliothèques GNU forcent mécaniquement la licence GPL sur le système BSD. Du coup par prudence les projets BSD s'éloignent de l'écosystème GNU.
[^] # Re: Obsolète
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Il y a le code noyau et le code utilisateur… Les deux sont bien distincts. Et la GPL concerne un code utilisateur. Un binaire GPL n'a aucune influence sur un autre binaire GPL. Ainsi le tar GNU n'a pas d'influence sur le grep et ainsi de suite.
La GPL est une licence héréditaire dont l'idée géniale est que si tu te link dessus (.so), alors ton code doit être libre (ce qui ne veut pas dire gratuit et disponible sur le web, juste disponible).
Donc cela me fait rire ces peurs sur la GPL ;-)
En pratique, Apple & Co (Google) aimerait bien virer la GPL car elle les fait bien chiée !
[^] # Re: Obsolète
Posté par Anthony Jaguenaud . Évalué à 7.
Juste une précision, le bon terme n’est pas libre, mais GPL. C’est bien ça le problème.
Si je code un soft sous BSD et que j’utilise une bibliothèque GPL, alors mon code doit devenir GPL… parce qu’il est déjà libre. Et ça, c’est une contrainte
troptrès forte.[^] # Re: Obsolète
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Oui, libre au sens GPL. Tu sais très bien qu'un code BSD peut-être intégré dans un code propriétaire sans rien demandé à personne… C'est pour cela d'ailleurs qu'Apple fait tout pour pousser LLVM et les licences BSD ;-)
Si tu codes sous BSD et te linke avec une bibliothèque GPL, tu dois te mettre sous GPL. Normal, elle a été faite faite pour ça ! Si on veut que tout le monde se linke et rester dans la philosophie GPL, on se met sous LPGL.
D'ailleurs, pendant des années, la bibliothèque Qt était GPL pour forcer les entreprises à prendre une licence.
[^] # Re: Obsolète
Posté par Anthony Jaguenaud . Évalué à 6. Dernière modification le 25 mai 2021 à 22:23.
Tu prends le problème dans l’autre sens. La discussion portait sur pourquoi les BSD veulent sortir les bibliothèques GPL de leur système.
Toi, tu expliques pourquoi c’est bien la GPL parce que c’est viral, alors que c’est ça le problème. Si c’est mon choix de mettre en BSD, pourquoi m’obliger à passer à la GPL ? Les problèmes posés par la GPL sont connus, certains sont pour d’autre contre.
C’est un peu comme si tu étais motard et tu dit à un automobiliste : « Pour pas tomber en moto, il faut mettre un casque. » Toi tu dis : « Pour pas avoir de problème, il faut mettre en GPL » (C’est la façon dont je comprends tes propos).
J’ai longtemps été plus GPL, mais avec l’âge, je vire de plus en plus vers la BSD et CCby pour les doc.
Question de maturité/sénilité ? (on n’est pas vendredi, c’est dommage ;-) )
[^] # Re: Obsolète
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
Non, je ne prends pas le problème à l'envers. Comme je l'ai dis, un exécutable GPL est indépendant d'un autre exécutable… Donc vouloir supprimer des exécutable GPL par des exécutables BSD est surtout philosophique (et cela va 100% dans le sens d'Apple).
Je ne parle pas d'ajouter des nouvelles bibliothèques GPL au coeur du système ;-)
[^] # Re: Obsolète
Posté par Psychofox (Mastodon) . Évalué à 7.
Pourquoi tu parles constamment d'Apple alors qu'il s'agit de FreeBSD?
C'est normal pour un projet BSD de ne pas vouloir "polluer" sa distrib avec du code GPL.
[^] # Re: Obsolète
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Parce qu'Apple a un noyau proche des BSD et qu'Apple fait tout pour basculer des projets sous BSD ;-) Donc mon avis perso, en bossant sur des remplaçants BSD des outils GNU, on bosse pas mal pour Apple !
Après, chacun est libre de faire ce qu'il veut ;-)
[^] # Re: Obsolète
Posté par Kaane . Évalué à 4.
En mettant sur des programmes en BSD 2 clauses, en MIT ou en WTFPL tu bosses pour tout le monde.
Apple est une très petite partie de "Tout le monde". En mettant des logiciels sous licence BSD tu bosses très très peu pour Apple.
[^] # Re: Obsolète
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Si tu le penses, tant mieux. Enfin, leur tél a une part de marché non nul… Et Google avec Fuchsia fait aussi un OS sous licence BSD / MIT.
Apple a repris Cups et avait mis beaucoup de bille dans le compilateur LLVM, ce n'est pas pour rien.
Mais bon, chacun fait comme il veut. Perso, je code aussi en MIT / BSD sur certains projets. Je sais très bien que sur certaines bibliothèques de protocole par exemple, cela permet de mieux propager ces protocoles sur tous les OS.
Mais perso, je ne vois pas l’intérêt de refaire un grep ou un tar en BSD alors que la version GNU fonctionne très bien. Il est plus intéressant de voir les projet de faire des alternatives en rust ou en go plus sécurisées que de refaire en C une autre implémentation.
A+
[^] # Re: Obsolète
Posté par Psychofox (Mastodon) . Évalué à 5. Dernière modification le 27 mai 2021 à 09:36.
Je n'utilises pas leurs produits, ça m'en touche une sans faire bouger l'autre.
[^] # Re: Obsolète
Posté par Kaane . Évalué à 8.
On peut éventuellement dire qu'il y a l'espace noyau et l'espace utilisateur. Mais pas vraiment de "code utilisateur" en tant que tel. Le code du noyau est "relativement" bien défini, mais si on ajoute tous les pilotes et tous les modules ça devient beaucoup plus flou.
La GPL concerne tous les codes, sinon je pourrais prendre le code du noyau et le passer dans la licence que je veux.
Un binaire GPL peut parfaitement avoir une influence sur la licence d'un autre binaire. Par exemple quand NVidia a voulu sortir des modules propriétaire qui utilisait certaines fonctionnalités de DMA exposées par le kernel, ils ont été invité à corriger leur code au plus vite ou à le rendre public sous la licence GPL. Ils ont corrigé.
Et une bibliothèque GPL userland peut parfaitement avoir une influence sur tous les logiciels qui l'utilisent, sinon on ne ce serait pas amusé à créer la LGPL.
Et bien déjà dans l'immense majorité des cas il doit non seulement être libre, mais encore en GPL et de la même version que celle utilisé par la bibliothèque. Cependant :
1 - Tu contredis toi même en disant qu'un binaire GPL (un .so) a un impact sur la licence d'un autre binaire. C'est d'ailleurs parfaitement exact, dans la majorité des cas le fait de linker, même dynamiquement, une bibliothèque GPL oblige mon code à être GPL
2 - Il y a une exception pour les bibliothèques systèmes. Par exemple : personne ne s'attend à devoir recoder l'ensemble des libs qui vont bien à chaque programme qui tente de lire ou d'écrire un fichier. Pourtant le code sous-jacent qui est linké est bien (en finalité) un module noyau. Très probablement sous licence GPLv2 du coup.
En bref quand tu utilises du code GPL (celui du noyau) via un binaire GPL (le noyau compilé de ta distribution) pour faire une opération de base (lire un fichier sur un device formatté en EXT4 par exemple) ça ne t'oblige pas à changer la licence de ton code. Et heureusement d'ailleurs, sinon on ne pourrait faire tourner que du code GPL sous Linux.
Et bien ça ne fait rire ni Linus Torvalds, ni l'ensemble des projets BSD. Et cette absence de rigolade, venant de gens dont on peut légitimement estimer qu'ils s'y connaissent un peu en licences, dure depuis 14 ans.
Peut-être qu'il y a réellement un soucis non ?
[^] # Re: Obsolète
Posté par Sytoka Modon (site web personnel) . Évalué à -1. Dernière modification le 25 mai 2021 à 16:18.
Apple veut se débarrasser de la GPL… Donc oui, elle ajoute une contrainte qui évite d'avoir des grosses boites qui intègre du code sans forcément donner en retour.
Dans le cas de NVidia, il s'agit de code noyau et NVidia ne joue pas le jeux depuis des années. Voir ce que Linus leur avait fait comme geste.
En parlant de binaire, je pensais à programme… Je le prenais comme synonyme. Donc les bibliothèques et les programmes, ce sont deux choses différentes au sens de la GPL (voir LGPL / AGPL).
Je ne pense pas que cela pose tant de problème que cela. Il y a surtout une volonté de virer toute trace de licence héréditaire de la part des grosses boites. Je suis très méfiant vis-à-vis d'elles !
[^] # Re: Obsolète
Posté par Kaane . Évalué à 9.
Non la GPL ne fait aucune distinction entre la notion de programme et la notion de bibliothèque. Et c'est d'ailleurs une très bonne chose parce que ça prend trente seconde d'exposer une fonction d'un programme sous forme d'export linkable. La GPLv2 avait bien anticipé ce soucis et avait une définition assez large de la notion de dépendance à un logiciel GPL.
Mais tout programme est potentiellement une bibliothèque, et c'est bien là le soucis principal contre lequel la GPLv3 essaye de lutter, parce que un des déclencheurs de l'obligation de distribution de code est la notion de distribution du programme.
En GPLv2 si un programme est distribué, il faut que le source le soit aussi. Certaines boites se sont infiltrées dans la brèche pour dire qu'ils ne distribuaient pas le binaire.
Par exemple à la sauce Tivo qui disait que le boitier restait leur propriété - y compris le logiciel inclus dedans.
Ou encore Free qui ont utilisé la sauce Tivo au début - mais qui se sont rabattu sur une méthode "on donne le code des modifs qui permet de charger des contenus binaires qu'on ne donne pas, et de toute façon si vous modifiez votre box on vous résilie votre accès"
Bref les libertés fondamentales ne sont pas respectées.
La GPLv3 a été crée en réaction épidermique a ces éléments. Et malgré une adoption massive a complètement échoué à rendre les libertés fondamentales aux utilisateurs.
Pas mal d'opérateurs, fournisseurs de contenus et opérateurs cloud ont adoptés une méthode en trois temps :
1- Faire des modifs sur le binaire GPL pour qu'il puisse recevoir et envoyer des commandes via un bus entreprise. On garde ce binaire non seulement logiquement, mais également physiquement dans les locaux de la société.
2- Faire un logiciel de bus société proprio, qui ne se lie pas vraiment à un programme GPL spécifique et qui tient debout tout seul même si il n'y a pas de logiciels GPL dans la boucle.
3- Faire une box, un service, une infra etc. qui passe par le bus société pour faire quoi que ce soit.
La GPLv3 est respectée, rien n'est distribué à l'utilisateur, le code source modifié reste fermé, 0 liberté utilisateur au final.
Et quand je dis bus entreprise, ca peut juste être un proxy qui reçoit des commandes REST et qui les retranscrit en mode 1 pour 1 dans un PTY. Ca marche très bien.
Donc les vraiment grosses boites, assez grosse pour avoir les moyens de bien compartimenter leurs devs, peuvent abuser de la GPLv3 sans soucis. La méthode est connue et largement publicisée (pas en ces termes là bien sur) pas de grande marques de cloud pas encore souverain.
Par contre les petites et moyennes boites vivent dans la crainte d'un dev qui fait un import (via npm, cargo, pip etc.) d'un truc en GPL et qui les oblige dans 6 mois, 8 mois un an à se prendre une volée de bois vert si ils ne libèrent pas le code. Code qu'ils ne peuvent absolument pas libérer pour des raisons contractuelles le plus souvent (il a été écrit avec les specs et les études d'un client, donc techniquement il ne leur appartient pas).
Bref tout programme est potentiellement une bibliothèque et c'est de plus en plus simple de faire la transformation. La GPLv3 a échoué à bloquer ce qu'elle voulait bloquer et les grosses boites rigolent presque autant devant les protections de GPLv3 que les pirates du dimanche devant la HADOPI.
[^] # Re: Obsolète
Posté par _kaos_ . Évalué à 2.
Et quand bien même un programme/une librairie n'était pas compilé, ça reste pareil.
Une version pour machine virtuelle (donc pas un
.so) : même traitement.Je triche car il y a compilation en truc, comme un
.jar?Ok. Un programme écrit dans un langage interprété est rarement fourni comme un binaire compilé. Et ça continue de s'appliquer.
Comme dit précédemment, c'est au runtime que la différence se fait : si un programme peut tourner sans le code GPL, il n'y a pas de contamination (règle très très approximative).
Matricule 23415
[^] # Re: Obsolète
Posté par Sytoka Modon (site web personnel) . Évalué à 9.
Le mot contamination viens de Microsoft qui voulait tuer le logiciel libre…
Encore une fois, je préfère le mot hérédité. Tu hérites d'un code qui propose de fournir le code source. C'est plutôt positif comme approche.
La GPL propage la transparence dans le code, je trouve cela très bien ;-)
[^] # Re: Obsolète
Posté par _kaos_ . Évalué à 5.
Le terme est peut-être mal choisi, soit.
Ce que tu présente comme un "atout" démontre aussi un dédain de ta part envers le reste du monde du libre. En caricaturant : si c'est pas GPL, c'est pas du vrai libre. Enfin, c'est comme ça que je le lis.
Matricule 23415
[^] # Re: Obsolète
Posté par Astaoth . Évalué à 4.
Non, la GPL v3 propage la GPL. Un code peut être libre sans avoir de licence compatible GPL (voir sans licence du tout en fait). La GPL v3 contrevient potentiellement aux souhaits des développeurs initiaux en imposant une licence. Dans le cadre d'un projet sous licence BSD, la contamination de la GPL contrevient à la vision initiales des développeurs.
Ainsi, le fonctionnement de la GPL v3 est contre-productive, car au final elle exclue d'office les bibliothèques qui sont en GPL v3 de projets, entre autres libres, qui ne sont pas produits avec une licence compatible.
Je trouve ça contre-productif pour l'écosystème libre. C'est en quelque sorte avoir une vision unique du logiciel libre.
Emacs le fait depuis 30 ans.
[^] # Re: Obsolète
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Si tu met un licence GPLv3, tu ne contrevient pas aux souhaits des développeurs initiaux, puisque ce sont eux qui l'ont mises !
Si tu ne met pas de licence, tu tombes sous le droit d'auteur, donc tu es 100% non libre. À mon sens, tu n'es pas bien renseigné. Si tu veux faire du domaine public, il faut mettre la licence WTFL ou du CC0 par exemple, mais surtout pas rien !
Il y a peu de bibliothèque en licence GPL en pratique, car c'est effectivement assez bloquant. En effet, une bonne bibliothèque propage par exemple des bonnes pratiques, des bons protocoles… En réalité, la grande partie des bibliothèques sont sous licence LGPL justement.
Globalement, cela fonctionne très très bien. Je fait et j'utilise du libre depuis plus de 25 ans. Le modèle est franchement bon.
Moi je vois qu'avec la BSD par exemple, Apple pousse à fond avec le compilateur LLVM, le même ne se gêne pas pour faire des systèmes bien fermés avec un contrôle total sur toutes ses machines…
Je préfère 1000 fois GNU/Linux avec son modèle GPL/LGPL/AGPL ;-) Je pense que le libre globalement y gagne bien plus avec ce modèle ! D'ailleurs, parti de rien en 1995, le noyau Linux est largement leader en 2021 sur les ordinateurs du monde entier. Et je pense que ce n'est pas pour rien que Google pousse son OS…
[^] # Re: Obsolète
Posté par Faya . Évalué à 3.
Vraie question : et tu penses que c'est la GPL qui l'a rendu leader ? Qu'il n'en serait pas là si il était libre mais sous BSD ? Il y a quand même de gros projets libres sous licence non-copyleft, comme tous ceux d'Apache par exemple.
Il est très curieux que Zenitram ne soit pas apparu dans ce fil, c'est l'un de ses sujets favoris…
[^] # Re: Obsolète
Posté par Michaël (site web personnel) . Évalué à 5.
On va finir par devoir le salarier :D
[^] # Re: Obsolète
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 27 mai 2021 à 05:28.
Il est très curieux qu'on ne lui octroie pas de vacances aussi.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Obsolète
Posté par Faya . Évalué à 8.
Vous passez vos vacances autrement qu'en moulant sur LinuxFR ? Me dites pas que vous prenez l'avion…
[^] # Re: Obsolète
Posté par Psychofox (Mastodon) . Évalué à 9.
Je crois que ça tient moins à la licence elle-même qu'au modèle de développement et au fait que linux a pris son essort à un moment ou BSD était empétrée dans des questions légales parce que la Berkeley Software Distribution avec la plainte lancée par AT&T à l'époque (et c'est ce qui rend les projets BSD particulièrement attentifs aux problème de licences).
Ça a freiné la release de 386BSD et Linus lui-même avait admit qu'il n'aurait probablement jamais commencé linux si 386BSD avait été disponible avant et que le principal frein était le mode de développement :
source: https://gondwanaland.com/meta/history/interview.html
[^] # Re: Obsolète
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Une partie de ton pb viens des import à la con ;-)
Historiquement, dans le CPAN de Perl, on mettait tous comme licence GPL V2 ou plus et Perl équivalent… (Artistic donc).
Mais les autres langages vont chercher à droite et à gauche et n'ont pas été capable de faire un CPAN ! Bilan, c'est le bordel !
Le soucis, c'est justement l'organisation de ces langages qui est bordélique et ne propose pas une licence à mettre sur tous les modules partagés. Moi je fais surtout des scripts en Perl et je dors tranquillou ;-)
[^] # Re: Obsolète
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Rassurez moi… une bibliothèque (donc un composant destiné à être intégré dans d'autres choses), justement tu la mets pas en GPLv3 (qui est viralement contagieuse) ni en GPLv2 (dont les failles et faiblesses sont corrigées par la v3…) mais en LGPL non ?
Par contre oui, si une bibliothèque est en GPLv3, ça va être compliqué de l'utiliser dans un autre système. Mais un programme comme un débogueur ne devrait pas impacter les autres programmes…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Obsolète
Posté par lasher . Évalué à 4.
Au début c'est ce qui était prévu, mais en fait, LGPL qui voulait dire « Library GPL » a été renommé en « Lesser GPL » : la FSF conseille officiellement d'utiliser la GPL tout-court même pour des bibliothèques. Un peu comme l'a expliqué Kaane, c'est en réaction au fait que tout un tas de gros acteurs tels qu'Apple, Google, Facebook, etc., ont construit une bonne partie de leur infrastructure avec des logiciels libres, mais les remplacent petit à petit par des outils maison qui utilisent des protocoles « ouverts ». Comme la communication en elle-même suit le protocole en question, les logiciels fermés et libres peuvent communiquer indépendamment de la licence.
Perso j'aime bien l'idée de garder la LGPL pour les bibliothèques : tu peux utiliser une bibliothèque dans un outil « fermé » mais il faut mettre à dispo le code des libs ouvertes qui ont permis la création de ton produit. Tout le monde n'est pas d'accord cependant…
[^] # Re: Obsolète
Posté par groumly . Évalué à 6.
Oula, non. Rien ne devient gpl automatiquement.
Si le binaire ou les sources ne sont pas distribués (utilisation interne), absolument rien ne se passe. Microsoft peut remplacer leur kernel par Linux, tant que c’est pas distribué en dehors de Microsoft, c’est parfaitement légal.
Si le binaire ou les sources sont distribués, alors les ayant droits du code gpl peuvent commencer a gueuler en justice.
A partir de la, un juge décidera de la culpabilité. Si culpabilité il y a, le goujat violeur de licence se verra probablement imposer, au choix:
Ceux qui ont reçu un binaire/source non gpl n’ont rien du tout. Pas un seul droit/devoir gpl. Ils ont reçu une IP “contrefaite”, et cette ip ne devient pas gpl rétroactivement par magie.
Et surtout, ils peuvent rien faire en justice, parce qu’il n’ont pas les droit sur le code initial.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Obsolète
Posté par Kaane . Évalué à 5.
Ah si. Comme la condition de distribution du binaire n'est pas déclenchée, tu peux garder ton code secret. Mais à l'instant ou tu fusionne du code GPL avec du code non GPL, que ce soit sous forme d'un fichier source unifié ou d'un binaire compilé, l'ensemble du code devient GPL.
Après effectivement les quatre liberté ne se déclenchent pas si tu ne distribues ni un source unifié ni un binaire compilé à un utilisateur extérieur. Et du coup tu n'as pas à divulguer le code à tes utilisateurs qui en font la demande. Ni à autoriser tes utilisateurs à utiliser, à adapter, à modifier ou à redistribuer le code. Mais seulement parce que tu n'as pas d'utilisateurs.
Une autre façon de voir les choses et de dire que tous tes utilisateurs ont les droits accordés par la GPL, mais comme ils sont exactement 0…
Mais le code GPL que tu as utilisé ne perds pas magiquement sa licence, et cette licence GPL fait que le reste du code est en GPL aussi.
[^] # Re: Obsolète
Posté par Thomas Douillard . Évalué à 4.
Non le code reste sous sa licence initiale, personne n’a les droit de le re-licencier que l’auteur/détenteur des droits, et c’est pas parce que tu signes la licence que les droits (d’auteur) te sont transférés. Le truc c’est que la GPL étant la licence la plus contraignante, bien souvent, ces conditions les plus restrictives s’appliquent de fait sur le composite de tous ces codes.
Mais tu peux toujours reprendre les parties initialement sous licence moins contraignante de ce projet sous la licence moins restrictive en prenant les fichiers initiaux si ils ont pas étés modifiés (ou si les modifications n’ont pas changé techniquement la licence du fichier)
[^] # Re: Obsolète
Posté par Kaane . Évalué à 3. Dernière modification le 27 mai 2021 à 10:28.
Nous sommes d'accord. Mais la GPL dit que le code mélangé avec du code GPL est en GPL. Du coup tu as trois options :
1°) Tu mélanges du code GPL avec du code libre compatible vers GPL => L'ensemble du code passe en GPL
2°) Tu mélanges du code GPL avec du code non compatible vers GPL mais qui t'appartient => L'ensemble du code passe en GPL, et tu viens implicitement de passer le code qui t'appartient sous licence GPL selon la loi américaine là ou elle s'applique (cela n'a jamais été testé en cour de justice européenne à ma connaissance, mais les licences CeCILL et EUPL ont été créées parce que certains pensaient que ça ne passerait pas vraiment.)
3°) Tu mélanges du code GPL avec du code non compatible GPL qui ne t'appartient pas => La licence GPL est violée, et tu n'as plus les droits pour utiliser le code ou les binaires obtenus de cette façon pour faire quoi que ce soit.
Bien entendu, le fait que le code passe sous GPL n'est pas exclusif, un code peut parfaitement avoir plusieurs licences.
Si tu préfères on peut dire le code passe aussi sous GPL en plus des ses licences précédentes. C'est ce que je voulais dire tout au long de mes différents textes, le code et les binaires si ils sont légaux sont instantanément sous licence GPL en plus des licences précédentes.
Mais bon "Sous licence GPL en plus des licences précédentes si l'intégration de code et/ou la production de binaire ne viole aucune des licences existantes" c'est un peu long à écrire à chaque fois.
[^] # Re: Obsolète
Posté par jyes . Évalué à 5.
Bah donc vous n’êtes pas d’accord (et moi non plus !). La GPL ne dit rien sur le « code mélangé », elle dit qu’un binaire produit avec du code GPL doit respecter les conditions de distributions de la GPL. Donc un binaire fait à partir de code BSD et GPL doit respecter les exigences de la GPL (plus strictes que celles de la licence BSD), ce qui est souvent formulé par abus de langage (mais assez juste) en « le binaire est GPL » (et donc le destinataire peut en demander les sources etc). Le mélange avec du code GPL ne relicencie rien du tout. Le code initialement BSD reste BSD, le code WTFPL reste WTFPL, et le code CDDL
reste… n’aurait jamais dû être utilisé avec du code GPL pour produire le binaire.[^] # Re: Obsolète
Posté par Kaane . Évalué à 3. Dernière modification le 27 mai 2021 à 11:11.
La GPL s'applique sur tous les programmes et tous les autres travaux qui contiennent l'entête GPL placée par le détenteur du copyright … Le Programme ci dessous se réfère à tous les programmes et travaux ainsi décrits, et "travail basé sur un Programme" se réfère soit au Programme soit tout travail dérivé dans le sens de la loi sur le copyright…
Bref dans l'article 0 de la GPL, on te dit bien
Donc ça s'applique sur les sources, les binaires, les traductions etc. Et ça te dit bien que si il y a un travail dérivé, la GPL s'applique (dans la limite des lois sur le copyright, avec possiblement des violations à la clef discutées dans les articles suivants).
Alors j'avoue que le terme "code mélangé" est de moi, et qu'il n'apparait pas verbatim dans le texte de la GPL, mais je ne voyais pas l’intérêt de partir dans des termes juridiques pédants et en plus enclins à apporter de la confusion.
Non le code initialement BSD devient BSD + GPL et le travail dérivé dans son ensemble est strictement GPL (ce que la licence BSD permet). Idem pour la WTFPL.
[^] # Re: Obsolète
Posté par Thomas Douillard . Évalué à 3.
Du code dérivé avec du code BSD devient de facto GPL si tu veux utiliser les modifs, techniquement tu peux pas utiliser la dérivation avec les termes de la licence BSD. Enfin faut préciser qu’il faut interpréter ton + comme un « faut respecter les termes d’à la fois les deux licences » et pas « je choisis ce que je veux » (mais c’est vrai de toutes les dérivations, ce serait pareil sur du BSD mélangé avec du Apache, en fait)
Faut préciser parce que sinon c’est pas forcément clair.
Mais le code initial, si tu enlèves le travail dérivé, il n’a pas changé pas de licence. Il n’y a pas de moyen juridique de vraiment le re-licencier, si tu n’en est pas l’auteur. La GPL ne s’applique qu’à ce code mélangé à sa dérivation, parce que l’auteur de la dérivation peut faire valoir ses droits d’auteurs sur la dérivation.
[^] # Re: Obsolète
Posté par Kaane . Évalué à 3.
En fait c'est impossible de respecter la GPL sans respecter aussi la BSD 2 clause ou la MIT. Si tu veux être ultra propre tu peux mettre la formulation des deux disclaimers en entête de ton code, mais de l'avis général (de juristes experts en la question) ça ne sert pas à grand chose.
Là c'est vrai et faux à la fois. Certes le code initial n'a pas changé de licence - mais une licence se "déclenche" différemment suivant les pays et le contenu de la licence. Si le code en question a été publié sous sa licence initiale, alors oui le licencié peut choisir d'utiliser celle des licences qu'il a reçu qui lui convient le mieux. Mais encore faut-il qu'il ait reçu la licence.
Par exemple si tu bosses en freelance aux US sur tes propres specs pour une société et que tu vends du code source sous licence BSD à un client avec un contrat d'exclusivité (donc tu t'engages à ne pas distribuer et à ne pas partager ce code de ton côté) - la société en question peut décider de distribuer les programmes issus de ce code sous la licence qu'ils veulent à leur clients, du moment qu'ils respectent les deux clauses de la BSD.
Les clients en question, même si ils savent que le code sous-jacent est en BSD, n'ont jamais reçu ce code avec cette licence et ne peuvent pas exploiter le programme sous licence BSD.
Donc même si c'est un programme verbatim (0 modification, 0 travail dérivé) tant qu'on n'a pas reçu au moins une fois la licence BSD - on ne peut pas utiliser les droits liés à cette licence.
Ceci dit le code initial, bien au chaud dans les serveurs de la société est toujours techniquement en BSD - ce qui fait une belle jambe au reste du monde.
En droit US du copyright, si la licence n'interdit pas les modifications, alors tu peux rajouter des clauses. Alors bien sur tu ne peux pas supprimer la licence précédente, mais ça te permet quand même pas de choses. Ça se fait d'ailleurs couramment, beaucoup de boites US demandent à leurs consultants de fournir leur code sous licence MIT justement parce qu'après ils peuvent en faire ce qu'ils veulent. (sous limite d'un disclaimer qu'ils auraient probablement mis de toute façon).
En Europe, ce n'est même pas sur que tu ais légalement le droit de mettre du code en BSD 2 clause ou en MIT. Même en GPL c'est tendu et ça n'a jamais été testé en cour de justice.
[^] # Re: Obsolète
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Pas du tout, tu peux très bien continuer à développer le code de la bibliothèque en BSD…
C'est le propre de la licence BSD que de pouvoir modifier le code et mettre le résultat sous la licence que tu veux, GPL ou propriétaire ou rester en BSD.
Bref, je vois pas trop le soucis.
D'ailleurs, dans le noyau Linux, il y a pas mal de code sous double licence afin de pouvoir partager du code entre les différents noyaux libres.
[^] # Re: Obsolète
Posté par groumly . Évalué à 4.
non, la gpl dit que tu as le droit de distribuer un code dérivé de code gpl tant que tu donnes les mêmes droit que la gpl. La gpl n’a pas la possibilité de changer la licence d’un code écrit par quelqu’un d’autre.
Si tu ne donnes pas les memes droits, tu viole la licence d’utilisation du code gpl que tu as reçu, et c’est tout.
Pour commencer, la licence ne s’applique pas au code en soit, mais à la distribution du code. C’est un contrat entre 2 parties privées, ca contraint les actions desdites parties, pas le code.
Ensuite, ca ne tient pas de bout comme raisonnement. Je prends Windows, je link un bout de code gpl au kernel, et paf, j’ai maintenant une licence gpl de Windows? Évidemment que non.
De même pour les double licences.
un binaire n’est pas légal ou illégal, il est, c’est tout. Le contrat de distribution peut enfreindre un autre contrat entre 2 autres parties, et donc l’action de distribuer le binaire peut être discutée devant un juge. Mais le binaire en lui même il a rien d’illégal.
le code ne devient pas instantanément sous gpl, t’inverses la cause et la conséquence. La distribution est en conformité avec la gpl parce qu’elle a été faite sous gpl. Pas le contraire.
Ben OuAis,mais ce genre de raccourcis, ca mène à des bêtises du genre “la gpl est un cancer”
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Obsolète
Posté par Kaane . Évalué à -1.
Non, relis l'article 0 de la GPL. La GPL s'applique immédiatement, les obligations de la GPL s'appliquent quand tu redistribue, mais le code, le binaire la traduction etc. passent en GPL dès que tu inclues du code GPL dans ton projet.
Un binaire, ou un code source si ils violent la licence qui t'a été donné deviennent illégaux. C'est à dire que tu ne peux pas t'en servir, tu ne peux pas le distribuer etc. Du coup tu ne peux que l'effacer.
Une fois de plus relis l'article 0 de la GPL. Le code est d'abord GPL et ensuite parce que la licence est en place elle t'impose des conditions d'utilisation. Et ce sont ces conditions qui font que si il y a distribution tu dois accepter de fournir le code, de le laisser être modifié, de le laisser être utilisé…
Tu as un code sur lequel deux licence s'appliquent, la licence GPL ET la licence windows. La licence GPL t'interdit de rajouter des limitations d'usage et de modification de code, la licence Microsoft t'interdit pleins d'usages et de modifications.
Les deux licences s'appliquent dès l'instant ou "le travail dérivé" est entamé. Mais comme il est bien entendu impossible de les respecter toutes les deux en même temps, le travail dérivé en question viole les deux licences. Du coup tu perds tous les droits sur le travail en question. Il devient "illégal" tu bosse sur la propriété de quelqu'un d'autre sur laquelle tu n'as ni droit ni titre.
Niveaux bêtises, de façon générale, et dans ce thread en particulier, je me sens plutôt du bon côté de la barrière.
[^] # Re: Obsolète
Posté par Pol' uX (site web personnel) . Évalué à 5.
Moi j'y lis :
Pas dit que ça entraîne des masses d'obligations immédiates.
Adhérer à l'April, ça vous tente ?
[^] # Re: Obsolète
Posté par groumly . Évalué à 4.
L’article 0 de la gpl ne fait que définir des termes, donc j’aimerais bien savoir de quoi tu parles. Si tu parles du préambule, c’est du blabla stallmanien qui se termine par “les conditions sont décrites ci dessous”.
La section 2 en revanche est assez explicite:
qui dit en substance “tu peux modifier sans conditions un travail dérivé que tu ne distribues pas”, cf la section 0 pour les définitions précises.
Ou encore:
la v2 est pas tellement différente non plus, la section 2 ne requiert le travail dérivé d’être en gplv2 seulement si le travail dérivé est distribué (la encore, langage explicite), et ell en rajoute une couche pour ceux du fond qui suivraient pas. La première phrase dit exactement le contraire de ce que tu dit.
donc j’aimerais vraiment voir où est ce que la gpl s’approprie le droit de changer une licence sur lequel elle n’a strictement aucun droit, parce que de ce que j’en voit, elle autorise explicitement de faire ce qu’on veut du code en privé.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Obsolète
Posté par Thomas Douillard . Évalué à 4. Dernière modification le 31 mai 2021 à 20:31.
La GPL passe après la loi, et n’a pas de pouvoir de relicencier le code original. Seul l’auteur original en a le droit.
[^] # Re: Obsolète
Posté par jyes . Évalué à 3.
La licence lie celui qui distribue le logiciel à celui qui le reçoit, et si la licence originale le permet, celui qui redistribue un logiciel peut le distribuer sous d’autres termes que ceux selon lesquels il l’a reçu, c’est à dire en changer la licence. C’est de ce contexte de re-distribution (avec du code GPL) que parle Kaane, aussi je ne pense pas que la loi s’y oppose. Le destinataire final pouvant n’avoir jamais reçu directement le code original, il n’a pas forcément accès à la licence originale, uniquement la licence de re-distribution.
Là où mon interprétation diffère de celle de Kaane, c’est que la GPL n’impose pas de re-licencier le code BSD distribué avec le code GPL, donc rien n’interdit du code BSD d’être distribué avec du code GPL tout en lui laissant la licence BSD. Par contre, des binaires ainsi construits doivent être eux-mêmes distribués sous une licence compatible avec la GPL, donc si un des destinataires demande le code, il doit lui être fourni. Par contre, qu’il lui soit fourni en (partiellement) BSD ou en GPL ne change rien : le code BSD distribué avec du code GPL peut mais ne doit pas forcément être re-licencié en GPL.
[^] # Re: Obsolète
Posté par Bapt (site web personnel) . Évalué à 10.
FreeBSD ne veut pas de GPLv3 c'est un fait, pour NetBSD et DragonFly il en va tout autrement, les deux ont de la GPLv3 dans leur sources.
Pour OpenBSD je crois bien qu'ils n'en veulent pas non plus et ils sont plus restrictifs que nous dans la liste des licenses acceptables pour base.
Rationnellement la seule raison qui pousse FreeBSD à ne pas utiliser/mettre a jour les outils vers leur version GPLv3, c'est que personne (meme des avocats spécialisés) ou presque ne comprends vraiment la GPLv3 et ses implications juridiques réelles (pas théorique)! Du coup on ne sait pas trop à quoi on expose potentiellement nos utilisateurs, donc on décide que dans base, on évite. ça ne va pas plus loin que ça!
[^] # Re: Obsolète
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 4.
C'est intéressant parce que le logiciel libre est, justement, censé apporter une sécurité juridique.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Obsolète
Posté par Michaël (site web personnel) . Évalué à 9.
Oui, mais malheureusement le droit c'est compliqué et piégeux quand, comme moi, on n'y connaît rien. Notamment si on se fie aux analyses qui ont présidé à l'élaboration des licenses CeCILL, les licenses communes (GPL, BSD, Apache, MIT, etc.) sont très dangereuses en France, parceque la clause de “non garantie, non responsabilité” est invalide et laisse donc place au code de la consommation habituel:
https://cecill.info/faq.fr.html#pourquoi-cecill
Heureusement, le gouvernement français qui a bien compris les enjeux sociaux, économiques, stratégiques et politiques du logiciel libre mène une politique volontaire pour faire connaître ce sujet et clarifier la situation!
[^] # Re: Obsolète
Posté par Michaël (site web personnel) . Évalué à 3.
Ce qui pour conclure mon propos, laisse penser que la grande majorité des logiciels libres dont l'utilisation relève du droit français ne sont pas dans une situation très sûre.
[^] # Re: Obsolète
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 5. Dernière modification le 27 mai 2021 à 13:28.
Sachant qu'en plus, d'après ce que j'ai vu, les gens hésitent en cas de litige entre attaquer en contrefaçon ou pour non respect des dispositions contractuelles. Et ce n'est pas du tout le même terrain de droit (se rappeler de finir la dépêche sur droit et jurisprudence).
Sur ce plan, les licences CC sont plus nettes qui établissent qu'elles sont un contrat passé entre émetteur et récepteur. Ça n'a pas toujours été le cas, il y a eu un moment un flou juridique à ce sujet.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Obsolète
Posté par Psychofox (Mastodon) . Évalué à 5.
Le problème c'est qu'une licence n'aide plus l'utilisateur (ou le développeur d'ailleurs) si elle est trop longue et qu'il faut avoir fait du droit pour la comprendre.
[^] # Re: Obsolète
Posté par claudex . Évalué à 5.
Toutes les licences nécessite de connaître un minimum le droit pour les comprendre.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Obsolète
Posté par Michaël (site web personnel) . Évalué à 10.
Un des objectifs de FreeBSD est d'avoir un système de base libre complet en license BSD (ou aussi libérale). C'est la raison 1 du “Why FreeBSD” dans le manuel:
https://docs.freebsd.org/en/books/handbook/introduction/#nutshell
Soit en français
(Je cite en anglais car ce passage est absent de la version française.)
C'est aussi mentionné dans la FAQ (1.3):
https://docs.freebsd.org/fr/books/faq/#_quels_sont_les_buts_de_freebsd
# Correction
Posté par HacKurx . Évalué à 5.
Il s'agit de l'option KERN_TLS.
[^] # Re: Correction
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Corrigé, merci.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.