Maintenant, comme dit dans un autre commentaire, dans le contexte de ce projet, ce n'est pas un sujet car l'outil est sous GPL mais c'est le résultat qu'on diffuse (et le résultat est sous la licence que l'on souhaite)
On est d'accord :-)
Malgré tout le sujet plus généralement me parait important, peut-être encore plus pour toi que pour moi.
si le client souhaite que tu lui fournisses les sources, tu es obligé.
Oui. Mais ce n'est pas une distribution au sens de la GPL. C'est une utilisation interne. C'est plus clair en se plaçant du point de vue du client.
Supposons que tu aies un besoin qui dépend d'un code GPL :
tu bricoles une solution que tu gardes pour toi. Pas de distribution, tu fais ce que tu veux.
tu paies un prestataire pour bricoler une solution que tu gardes pour toi. Pas de distribution, tu fais ce que tu veux.
En tant que prestataire, tu es un agent du client, tu n'es pas un éditeur de logiciel qui distribue un logiciel. C'est en fait la freedom 1 qui s'applique, pas la freedom 3.
C'est justement pour moi la force principale du logiciel libre : tu as un outil libre à ta disposition mais tu as un besoin un peu spécifique ou le monde a un peu changé : tu peux l'adapter pour tes besoins perso sans conditions (autres que la loi). Tu peux le faire toi même, ou, plus probablement, si tu n'en as pas les compétences ou les moyens, payer quelqu'un pour le faire. Dans ce cas, il n'y a pas de distribution au sens de la GPL et personne ne te force à distribuer ton code. Autrement dit : La GPL force un auteur de logiciel à distribuer le code sous copyleft à son utilisateur. Mais dans le cas d'une prestation, le client est "auteur" (au sens où il a les droits patrimoniaux sur le code, puisqu'il a payé la prestation) ET utilisateur. Le prestataire n'est qu'un "détail d'implémentation" (no offense). Il a écrit le code, mais pour le compte du client.
C'est d'ailleurs pour ça que le projet GNU et la plupart des distributions Linux ne considèrent pas la licence du compilateur du bios de virtualbox comme libre (la licence Sybase) :
This is not a free software license. It requires you to publish the source code publicly whenever you "Deploy" the covered software, and "Deploy" is defined to include many kinds of private use.
Tu n'as pas le droit de modifier ce code et l'utiliser en privé (dans trop de cas) sans le redistribuer, ce qui est trop restrictif.
Ça fait de la GPL une licence en réalité très raisonnable, même (et surtout) pour l'éditeur de logiciel ou le prestataire : on peut réutiliser son travail, mais il a la garantie de bénéficier des modifications de quelqu'un qui distribuerait le logiciel largement (caveat pour les situations à la red hat).
Alors que pour du code MIT, une telle garantie n'existe pas. En revanche, tu n'attireras pas les contributions de quelqu'un qui voudrais fermer ton code pour le distribuer à des utilisateurs finaux mais qui serait enclin à contribuer upstream puisqu'il ne pourrait pas utiliser ton code GPL pour ça.
C'est évidemment une histoire de compromis et je comprendrais très bien quelqu'un qui choisisse MIT dans l'espoir que plus de contributions arrivent, ou parce qu'il fait du business sur ce code et veut quand même des contributions externes. Il faut bien garder en tête que ça peut se retourner contre soi sévèrement. L'alternative serait GPL + CLA, mais c'est beaucoup moins accepté que contribuer à un projet sous MIT (certainement parce que d'un coup, la boite est la seule à pouvoir fermer le code comme bon lui semble, alors qu'en MIT, tout le monde peut le faire - c'est précisément le cas où je vois quelqu'un choisir une licence permissive pour des raisons philosophiques, et c'est probablement la position des projets *BSD).
D'autres cas méritent une licence permissive, comme les codecs. Tu veux que ton format se diffuse le plus largement possible, tant mis s'il atterrit dans un logiciel propriétaire : au moins, il y a un peu d’interopérabilité et une adoption du format.
[^] # Re: Je vais regarder ça, ça m'intéresse bien...
Posté par raphj (site web personnel) . En réponse au lien Ivre, il crée un générateur de sites statiques avec 300 lignes de python et django. Évalué à 4. Dernière modification le 07 janvier 2024 à 11:33.
On est d'accord :-)
Malgré tout le sujet plus généralement me parait important, peut-être encore plus pour toi que pour moi.
Oui. Mais ce n'est pas une distribution au sens de la GPL. C'est une utilisation interne. C'est plus clair en se plaçant du point de vue du client.
Supposons que tu aies un besoin qui dépend d'un code GPL :
En tant que prestataire, tu es un agent du client, tu n'es pas un éditeur de logiciel qui distribue un logiciel. C'est en fait la freedom 1 qui s'applique, pas la freedom 3.
C'est justement pour moi la force principale du logiciel libre : tu as un outil libre à ta disposition mais tu as un besoin un peu spécifique ou le monde a un peu changé : tu peux l'adapter pour tes besoins perso sans conditions (autres que la loi). Tu peux le faire toi même, ou, plus probablement, si tu n'en as pas les compétences ou les moyens, payer quelqu'un pour le faire. Dans ce cas, il n'y a pas de distribution au sens de la GPL et personne ne te force à distribuer ton code. Autrement dit : La GPL force un auteur de logiciel à distribuer le code sous copyleft à son utilisateur. Mais dans le cas d'une prestation, le client est "auteur" (au sens où il a les droits patrimoniaux sur le code, puisqu'il a payé la prestation) ET utilisateur. Le prestataire n'est qu'un "détail d'implémentation" (no offense). Il a écrit le code, mais pour le compte du client.
C'est d'ailleurs pour ça que le projet GNU et la plupart des distributions Linux ne considèrent pas la licence du compilateur du bios de virtualbox comme libre (la licence Sybase) :
https://www.gnu.org/licenses/license-list.html#Watcom
Tu n'as pas le droit de modifier ce code et l'utiliser en privé (dans trop de cas) sans le redistribuer, ce qui est trop restrictif.
Ça fait de la GPL une licence en réalité très raisonnable, même (et surtout) pour l'éditeur de logiciel ou le prestataire : on peut réutiliser son travail, mais il a la garantie de bénéficier des modifications de quelqu'un qui distribuerait le logiciel largement (caveat pour les situations à la red hat).
Alors que pour du code MIT, une telle garantie n'existe pas. En revanche, tu n'attireras pas les contributions de quelqu'un qui voudrais fermer ton code pour le distribuer à des utilisateurs finaux mais qui serait enclin à contribuer upstream puisqu'il ne pourrait pas utiliser ton code GPL pour ça.
C'est évidemment une histoire de compromis et je comprendrais très bien quelqu'un qui choisisse MIT dans l'espoir que plus de contributions arrivent, ou parce qu'il fait du business sur ce code et veut quand même des contributions externes. Il faut bien garder en tête que ça peut se retourner contre soi sévèrement. L'alternative serait GPL + CLA, mais c'est beaucoup moins accepté que contribuer à un projet sous MIT (certainement parce que d'un coup, la boite est la seule à pouvoir fermer le code comme bon lui semble, alors qu'en MIT, tout le monde peut le faire - c'est précisément le cas où je vois quelqu'un choisir une licence permissive pour des raisons philosophiques, et c'est probablement la position des projets *BSD).
D'autres cas méritent une licence permissive, comme les codecs. Tu veux que ton format se diffuse le plus largement possible, tant mis s'il atterrit dans un logiciel propriétaire : au moins, il y a un peu d’interopérabilité et une adoption du format.