mold est un linker, un programme d’édition des liens pour des langages tels que C, C++ ou Rust, utilisable en remplacement de GNU gold et LLVM lld. Son point fort est qu’il est très rapide, bien plus rapide que les deux autres, d’après leurs benchmarks et quelques articles (comme cette entrée de blog ou cette analyse Why isn't ld.lld faster? sur la version 1.0).
La version 2 de mold est sortie hier. Cette sortie s’accompagne d’un changement de licence : de la double licence AGPL/MIT on passe à du MIT seul.
N. D. M. : précédemment, mold linker pourrait changer de licence pour une licence non open-source évoqué lors de la version 1.7.0 indiquant l’éventualité d’un changement AGPLv3 vers code source disponible uniquement, puis un abandon de cette idée en 1 7.1.
De mon côté je (Julien Jorge) n'ai pas encore testé ce linker mais il est dans la liste des trucs que je veux regarder ; je me demande d'ailleurs comment ça se met quand on active de la Link-time optimization (LTO), de l'optimisation à l'édition des liens.
Avec la double licence le linker était distribué en deux variantes : mold, bien sûr, et sold, une version commerciale de mold (et la seule des deux qui fonctionne pour macOS). Il semblerait que l'aspect commercial n'ait pas pris et les notes de versions de la 2 expliquent le changement comme suit :
With this release, we've transitioned our license from AGPL to MIT, aiming to expand the user base of our linker. This was not an easy decision, as those who have been following our progress know that we've been attempting to monetize our product through an AGPL/commercial license dual-licensing scheme. Unfortunately, this approach didn't meet our expectations. The license change represents our acceptance of this reality. We don't want to persist with a strategy that didn't work well.
Je suis un peu surpris qu'une licence AGPL puisse être la cause d'une petite base d'utilisateurs. Le linker n'est qu'un outil dans la chaîne de compilation et sa licence n'a pas d'impact sur le programme compilé. Par conséquent, les quelques utilisateurs pour qui ce changement est impactant sont ceux qui veulent prendre le logiciel, le patcher, et ne pas rediffuser leurs patchs. Par exemple, un éditeur qui souhaite fournir une chaîne de compilation fermée pour son matériel pourrait trouver un intérêt à utiliser un mold adapté à son architecture et à conserver ses modifications pour lui.
Personnellement j'aime assez l'intention de l'AGPL, « nous partageons avec vous et vous partagez avec nous », et je trouve que ça colle très bien à ce genre d'outil. C'est donc avec un peu de peine que je reçois la nouvelle de ce changement de licence même si cela ne change pas grand chose pour moi. Espérons pour l'auteur que cela lui permettra de lancer son activité commerciale.
Aller plus loin
- Code source du projet (56 clics)
- Téléchargement de la version 2 (34 clics)
# Licence Zero Clause BSD (0BSD)
Posté par Victor STINNER (site web personnel) . Évalué à 4. Dernière modification le 27 juillet 2023 à 17:28.
J'ai écrit un petit projet pythoncapi-compat qui est en gros un entête C (.h) de 800 lignes à copier dans son projet. Au début, j'avais mis une licence MIT, mais ça a posé de soucis sur certains projets qui respectent correctement les licences (ce qui est une bonne chose !). La licence MIT a par exemple une clause qui exige de faire figurer la licence:
Mon but n'est pas de monter une société sur un entête, mais de m'assurer qu'un maximum de projets puissent l'utiliser. Alors je suis passé à la licence "sans aucune condition" : Zero Clause BSD (0BSD). C'est différent du "domaine publique" qui je crois n'est pas reconnu partout.
Détails du changement : https://github.com/python/pythoncapi-compat/issues/19
Au passage, oups, j'avais copié le fichier COPYING d'un autre projet où j'avais noté : "Copyright 2016, Red Hat, Inc. and Google Inc."
Il est recommandé d'utiliser "Copyright Contributors to the pythoncapi_compat project." comme mention de copyright.
Par contre, j'ai refusé de signer un contributor agreement pour pouvoir utiliser mon fichier pythoncapi_compat.h.
Bonne chance pour bien gérer vos licences :-)
[^] # Re: Licence Zero Clause BSD (0BSD)
Posté par Zenitram (site web personnel) . Évalué à 0.
Pour info un CLA n'est pas un CAA il n'y a donc aucun transfert de droit, seulement une autorisation de faire ce qu'ils veulent sans t'enlever ce droit pour toi (mêmes droits que toi en pratique, donc).
Perso je trouve dommage de bloquer sa demande de merge sur ça comme si l'utilité de la PR était pas si important que ça, mais bon, chacun ses priorités.
# Le problème de l'AGPL
Posté par paulez (site web personnel) . Évalué à 1.
L'AGPL a des risques légaux trop importants, donc elle est bannie de pas mal d'entreprises. Donc forcément ça impacte la popularité des projets AGPL.
Un exemple avec Google :
[^] # Re: Le problème de l'AGPL
Posté par Gof (site web personnel) . Évalué à 6.
Google banni la AGPL parce que ils veulent profiter du code sans devoir contribuer en retour.
Alors dommage pour eux.
[^] # Re: Le problème de l'AGPL
Posté par MicP . Évalué à 2.
C'est cool ça ! car finalement ils font sans le savoir la publicité pour l'AGPL.
En râlant comme ça contre l'AGPL, tous ceux, et je pense qu'ils sont très nombreux,
qui n'avaient encore aucune idée de l'existence du logiciel libre et de ce qu'est l'AGPL
iront cliquer sur le lien pour voir de quoi il s'agit.
C'est pas sûr du tout que la seule lecture de la page Wikipedia suffise à leur faire prendre conscience de l'enjeu et des conséquences, mais je pense que certains auront la curiosité d'aller fouiller plus loin.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.