Bonjour Nal !
Dans mon précédent journal concernant le passage de Redis a des licences "source available" (non opensource selon la définition de l'OSI), on a pu voir dans les commentaires de nombreux arguments qui peuvent se résumer à :
- n'importe quel logiciel sous MIT peut devenir propriétaire du jour au lendemain
- cela ne serait pas arrivé avec la GPL
Alors, je ne suis pas un avocat mais j'aimerais quand même clarifier 2-3 points :
Une licence s'applique au code qui a été délivré
Lorsque Redis, MongoDB, ElasticSearch, etc… change de licence, ce sont les nouvelles versions qui changent de licence. Les versions existantes restent sous la même licence (en l'occurence, pour Redis c'était la MIT).
Donc non, les logiciels ne "deviennent pas propriétaire" dans le sens ou tu ne peux plus utiliser $X en version 1.0 car $X en version 2.0 change de licence. Ce qui se passe souvent, c'est que la dernière version libre du logiciel va continuer d'être maintenue par la communauté :
- OpenSearch - fork d'ElasticSearch initié par Amazon
- Redict - fork de Redis
- FerretDB - Alternative "drop in" à MongoDB
- OpenTofu - fork de Terraform
- …
Pas de panique donc, continuez d'utiliser votre version libre de $X, et attendez le fork. Aucun changement cassant en théorie.
Une nouvelle version est elle un travail dérivé ?
Alors, la GPL empêcherait-elle un auteur de changer de licence pour une version future ?
Il faut se poser la question, est-ce qu'une nouvelle version du code dont je suis l'auteur peut être décrite comme un travail dérivé, qui devrait donc être contaminé par la GPL ?
La réponse simple est : on s'en fout. En tant qu'auteur du code, je suis propriétaire de celui ci, et je fais ce que je veux avec. A tout moment, je peux décider que les futures versions ne seront plus sous licence GPL.
Mais la GPL protège qui au final ?
Ce n'est pas l'utilisateur qui est protégé par la GPL ici, mais l'auteur. En choisissant la GPL, l'auteur se donne la garantie que toutes contributions faites à son logiciel resteront open-source. C'est une bonne chose pour l'utilisateur certes, mais cela n'empêche pas l'auteur de changer d'avis et de changer de licence.
Il faut noter que l'auteur ne peut changer la licence que du code dont il est auteur (ou code dont il a reçu la propriété via un "Contributor License Agreement" par exemple).
Si je décide de sortir $X en GPL, que toi tu décides de forker en $X2 (toujours GPL donc). Si je change la licence des futures versions de $X, cela n'impactera pas la licence de $X2 (ni des versions existantes de $X).
Conclusion
Choisissez ce qui vous correspond le mieux. Mais en tant qu'utilisateur, n'allez pas croire qu'une licence vous protège vous plus qu'une autre (tout du moins, dans ce cas précis de changement de licence).
# J'ai pas compris
Posté par flagos . Évalué à 5.
Mais, si la version future est basée sur la version actuelle, le copyleft s'applique, non ? Pour moi, la GPL est une garantie envers les utilisateurs que le code restera libre.
[^] # Re: J'ai pas compris
Posté par David Delassus (site web personnel) . Évalué à 6.
Non car l'auteur a tout les droits sur le code.
La GPL garantie que les autres contributeurs ne peuvent pas privatiser le code dont tu es l'auteur.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: J'ai pas compris
Posté par Frédéric Perrin (site web personnel) . Évalué à 8.
Dans l'autre sens, elle garantit aussi que l'auteur initial ne peut pas prendre les contributions externes et les re-distribuer sous licence propriétaire dans une version future. À moins de faire signer des CLA qui permettent cela.
Si tu es le seul auteur sans aucune contribution extérieure, oui tu peux changer la licence quand tu veux. Mais si tu n'acceptes aucune contribution externe, est-ce de l'open-source dans un sens utile du mot ?
[^] # Re: J'ai pas compris
Posté par David Delassus (site web personnel) . Évalué à 2. Dernière modification le 28 mars 2024 à 14:36.
Ce que tout les projets requiert quand ils deviennent suffisamment gros.
Le code est disponible et livré sous une licence libre. Il est par définition open-source.
La gouvernance du projet n'a rien à voir là dedans.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: J'ai pas compris
Posté par BAud (site web personnel) . Évalué à 3.
il faut le faire accepter à tous les contributeurs avant, les recontacter et leur faire accepter, sinon enlever / réécrire leurs contributions en cas de refus…
ce qui est distribué, plus exactement le plus souvent l'exécutable (le binaire — pas forcément le code) : c'est une différence d'application entre la MIT et la GPL
un peu tout de même :
[^] # Re: J'ai pas compris
Posté par David Delassus (site web personnel) . Évalué à 4.
Oui, et cela sera le cas peu importe la licence, GPL, ou MIT, ou proprio.
Quand je dis que la gouvernance n'a rien à voir, je parle de la définition d'opensource. Lua est un projet opensource, la gouvernance n'est pas ouverte.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: J'ai pas compris
Posté par EmmanuelP . Évalué à 3.
Tous ?
LibreOffice, GNOME, KDE, Linux, Debian, Aravis ?
Fedora avait un CLA, mais ils ont arrêté en 2011.
[^] # Re: J'ai pas compris
Posté par ted (site web personnel) . Évalué à 2.
Tous les projets sérieux
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: J'ai pas compris
Posté par BAud (site web personnel) . Évalué à 2.
tu as oublié le point d'ironie ;-)
[^] # Re: J'ai pas compris
Posté par raphj . Évalué à 9.
Pour enfoncer un peu le clou :
Oui, car la définition d'open source (de l'OSI), tout comme la définition du logiciel libre, garantissent toutes deux des droits aux utilisateurs. Ces définitions ne disent rien sur un hypothétique droit à la contribution ou au développement coopératif / communautaire. Même l'inverse : elles autorisent explicitement les gens à être perso.
Barmic, c'est exactement ce genre de confusions (de fond) auxquelles je pensais le 23 mars, et hier dans ce fil de discussion et pourquoi je suis tant attaché à un vocabulaire précis au risque de passer pour un pédant. Malgré moi, hein, je préfère avoir l'air bienveillant ; avec un peu d'espoir, j'y arrive un peu quand-même.
[^] # Re: J'ai pas compris
Posté par barmic 🦦 . Évalué à 3.
Je comprends, mais je pense que c'est plus que l'on met beaucoup beaucoup de choses derrière un même mot (ou 2). Le libre a tellement gagné que pour certains "libre" implique "bien" et "bien" implique "libre".
Du code libre il y a pleins de façon d'en faire et sans plus d'information tu as globalement 2 garanties :
et ça s'applique au code qui vient d'être publié l'avenir est toujours incertains. C'est globalement ce que décrivent avec plus de mots les 4 libertés fondamentales de la FSF ou les principes du logiciel libre selon Debian.
Le fait de trouver cool des projets communautaires qui sont libres produits une métonymie. C'est dommage parce que ça ne contribue pas à augmenter le vocabulaire et à avoir des mots pour décrire des concepts différents. Je parlais l'autre jour de commun pour des logiciels libres ouverts aux contributions avec partage de la propriété intellectuelle et diversité effectives des contributions.
En y réfléchissant c'est un problème qu'on retrouve en politique. Si tu parle de fascisme, tu rentre dans une discussion complexe sur qu'est-ce que le fascisme, alors que si tu parle de xénophobie, ça peut être bien plus factuel et sans problème d'interprétation.
Nommer les choses de manière pertinente n'est pas simple, mais c'est très utile (désolé j'ai un peu digressé).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: J'ai pas compris
Posté par raphj . Évalué à 3.
Tout à fait d'accord
# L'auteur ou les auteurs ?
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 4.
En effet, pour un logiciel qui n'a qu'un seul titulaire des droits, pas de problème pour changer de licence me semble-t-il. En revanche, si les titulaires sont multiples…
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: L'auteur ou les auteurs ?
Posté par David Delassus (site web personnel) . Évalué à 1. Dernière modification le 28 mars 2024 à 14:32.
C'est la que les projets mettent en place un "Contributor License Agreement" qui désigne une entité comme étant propriétaire du code, cela peut être une personne physique, ou une personne morale (association, entreprise, fondation, …).
Si ils ne le font pas, il faut effectivement l'accord de tout un chacun pour changer la licence.
EDIT: En fait, c'est plus une question de gouvernance du projet ça. Cela ne change pas le fait que la licence peut changer, même si c'était du GPL.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: L'auteur ou les auteurs ?
Posté par nud . Évalué à 5.
Ce qui devient de plus en plus compliqué avec la multiplication des contributeurs. Je me souviens d'un cas où tous les contributeurs avaient été contactés pour changer une licence de GPL2 à GPL2+ (ou GPL3+, je ne sais plus) car le logiciel initial était sous licence GPL2 uniquement et ça posait problème pour l'intégration avec d'autres trucs. Je ne me souviens plus de quel projet il s'agissait, mais c'est un beau merdier si on compte qu'il faut également l'accord des ayants-droits pour les décédés… Enfin ils ont réussi, modulo quelques contributeurs n'ayant pas réagi mais n'ayant apporté que des contributions triviales.
C'est d'ailleurs pour ça que la FSF encourage à utiliser "GPL 2 et ultérieures" et non "GPL2 uniquement". C'est aussi l'une des raisons pour lesquelles la FSF encourage à lui attribuer les contributions aux projets sous licence GPL, avec l'idée que la FSF est une organisation dans laquelle on peut avoir confiance pour prendre ce genre de décisions. Si on utilise GPL2+ ou GPL3+ on lui fait confiance de toute façon pour ne pas publier une GPL4 qui serait contraire à l'esprit des précédentes… ce qui est aussi une raison pour laquelle certains projets (dont Linux) ne veulent pas faire ça.
À savoir que la Software Freedom Conservancy fournit un service similaire d'attribution de copyright mais principalement dans l'optique d'obtenir le respect de la licence GPL (avec les cas médiatiques de busybox et Vizio). Je parle bien de copyright parce que ce sont des organisations américaines… donc en fait toutes ces simagrées ne veulent pas forcément dire grand chose en droit européen. En effet le copyright et la propriété intellectuelle sont deux choses différentes, demandez à votre juriste préféré.
[^] # Re: L'auteur ou les auteurs ?
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
Certains projets, oui, mais c'est loin d'être le cas partout. Linux n'a pas ça, Git non plus, je n'en trouve pas de trace pour Mozilla ou libreoffice, mais j'ai peut être mal cherché.
Les CLA sont très utilisés soit quand le logiciel est développé par une entrepôts qui veut garder le contrôle dessus (freemium, ou garder la possibilité d'une version propriétaire future) soit quand c'est une entité qui veut pouvoir défendre la licence elle même (FSF).
[^] # Re: L'auteur ou les auteurs ?
Posté par aiolos . Évalué à 4.
Je me souviens d'une intervention de Zenitram sur le sujet Copyleft vs Copyfree qui m'avait pas mal fait réfléchir. Je me permet de le paraphraser ici car il semble absent depuis un moment.
Sa position était que, pour une entreprise, publier en Copyleft avec CLA était s'accorder un droit qu'elle refusait à la concurrence : la possibilité de publier sous double licence (GPL, par exemple, et propriétaire). Si le même produit est publié sous licence copyfree (MIT, par exemple), l'entreprise offre à la concurrence les mêmes options qu'elle même, à savoir publier une version fermée du produit ou d'un dérivé.
Restent donc les projets sous GPL sans CLA, avec des contributions effectives et significatives, ce qui empêche la fermeture du code même par son auteur principal, et rétablissent donc l'équilibre des pouvoirs entre tous.
[^] # Re: L'auteur ou les auteurs ?
Posté par Zenitram (site web personnel) . Évalué à 4.
Je me sèvre un peu vu la "qualité" des interventions, et le journal sur le changement de licence de Redis n'a pas dérogé à la règle avec des gens saluant le passage en non libre face à des gens faisant l'affront d'utiliser les libertés du libre comme si il y avait de mauvaises façons d'utiliser les libertés du libre, et ce sur un site censé rassembler des gens libristes, la balance dans les interventions a pris un shoot ces dernières années, mais je viens confirmer que tu as fais un bon résumé, comme quoi il reste quand même un peu quelque chose de mes interventions :).
Toutefois un petit ajout : la GPL sans CLA est clairement l'idée derrière la GPL (que ça reste libre, alors que pas mal de gens utilisent la GPL comme un moyen de vendre la version non libre et donc présentant le libre comme moins bien que le non libre) mais a aussi son inconvénient, celui de ne plus pouvoir en sortir même si le monde change, ou difficilement (l'exemple de VLC a été donné, par exemple, on peut aussi citer Wikipedia qui a eu besoin que la FSF fasse une version spéciale de la GFDL pour qu'ils puissent passer en licence CC plus adéquate).
[^] # Re: L'auteur ou les auteurs ?
Posté par Faya . Évalué à 5. Dernière modification le 28 mars 2024 à 22:35.
Moi je vois un commentaire à +12 qui déplore le passage en non-libre : "[l'open source]ils l'aiment moins quand d'autres font du blé à leur place à cause de ces mêmes libertés."
Un autre à +13 qui déplore qu'ils "retirent cette liberté". etc…
En fait tu t'es pris le chou avec UNE personne et tu es moinssé juste parce que ton commentaire est un perpétuel réchauffé à base de "c'est chiant les gens qui…" Donc non il n'y a pas eu des gens qui saluent le passage en non-libre. Tu inventes.
Essayes juste de ne pas ternir tes interventions pertinentes en caricaturant ton interlocuteur. Mais bon tu le sais déjà.
[^] # Re: L'auteur ou les auteurs ?
Posté par nud . Évalué à 4. Dernière modification le 28 mars 2024 à 22:41.
Ben… pas vraiment vu que la FSF demande que les contributeurs lui cèdent le copyright, et la SFC fait pareil. Je ne sais pas si ça compte comme un CLA pour toi, car l'idée derrière n'est a priori pas d'avoir la possibilité de rendre le code propriétaire…
[^] # Re: L'auteur ou les auteurs ?
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 29 mars 2024 à 05:14.
J'aurai dû préciser en effet sans CLA ou CLA filėaune entité tierce reconnue pour gérer dû libre, on peut mettre aussi le " ou supérieur" dd la version de la GPL qui laisse tout pouvoir à la FSF, le principe étant que l'auteur principal du logiciel n'est pas un droit en plus (ou faible) sur les autres.
[^] # Re: L'auteur ou les auteurs ?
Posté par Gof (site web personnel) . Évalué à 2.
Note que Richard Stallman considère que la double licence est parfaitement acceptable: https://www.fsf.org/blogs/rms/selling-exceptions
Je ne vois pas en quoi la conclusion découle des prémisses.
[^] # Re: L'auteur ou les auteurs ?
Posté par Zenitram (site web personnel) . Évalué à 0. Dernière modification le 29 mars 2024 à 21:02.
Un peu rapide de traduire "mixed feelings" par acceptable, mais j'ai do´ne le bâton pour me faire battre avec ma phrase, soit, j'adapte par l'idée qu'on pourrait légitimement avoir du copyleft et RMS n'est pas à une incohérence près sur le libre (les sections invariantes de la GFDL, sa détestation du libre hors logiciel, etc).
Prendre les gens pour des idiots ça marche souvent certes, mais pas toujours quand tu fais gratuit en libre et payant en non libre, c'est bien que tu vois plus de valeur dans le non libre, par définition des mots : que vends tu donc, qu'est qui a de la valeur marchande? Je t'en prie, dit moi la différence et ce qui est valorisé.
On s'est déjà accroché sur le sujet et on sait ce n'est pas très objectif, de souvenir c'est le business model que tu utilises et ça serait pas trop dans le déroulé marketing que d'assumer ça ;-), passons donc.
Et j'essaye de retourner à mon sevrage.
[^] # Re: L'auteur ou les auteurs ?
Posté par BAud (site web personnel) . Évalué à 6.
moui, ça c'est absurde venant de lui, chacun ses incohérences ;-) c'est potentiellement vu comme un moyen de monétiser ce qu'il y autour du logiciel…
là c'est plutôt qu'il se répute incompétent sur les domaines hors-logiciel ou que ça ne l'intéresse pas (les brevets du vivant en biologie, la licence Art libre pour les graphistes et vidéastes…).
en même temps, FSF c'est pour Free Software Foundation : cela évite de diluer le message, il y a déjà suffisamment à faire dans le monde du logiciel ;-)
à chacun de gérer les types de ressources qu'il veut prendre en compte :p
[^] # Re: L'auteur ou les auteurs ?
Posté par Gof (site web personnel) . Évalué à 5.
Non, j'ai traduit "acceptable" par "acceptable". Tu as une meilleure traduction ?
Original:
[^] # Re: L'auteur ou les auteurs ?
Posté par Gof (site web personnel) . Évalué à 4.
Je vends un droit d'utilisation d'une bibliothèque. C'est la bibliothèque qui a de la valeur, quelque soit la licence. Le prix est différent en fonction du client. Si le client fait du libre, c'est gratuit parce que le libre c'est bien. Si le client veux faire du proprio, alors il doit payer plus.
Ça me rappelle une blague:
Il y a trois articles sur le menu:
- Un café …. 7€
- Un café s'il vous plaît …. 5€
- Bonjour un café s'il vous plaît …. 3€
Mais donc d'après ta logique, l'auteur de cette blague trouve que la politesse est moins bien car ça vaux moins ?
Si tu produit du CO2, il faut que tu paye pour des crédit carbone alors que si tu n'en produit pas, pas besoin de crédit carbone. Donc produire du CO2 c'est bien?
[^] # Re: L'auteur ou les auteurs ?
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4.
Imaginons que plus personne ne fasse de logiciel propriétaire. Ton modèle économique est mort.
C'est différent pour celui de Zenitram.
Dans l'exemple de ta blague - que je trouve hyper représentatif du sujet, plus les gens sont malpolis, plus tu gagnes d'argent. On ne peut pas dire que ça soit vertueux pour la politesse car tu n'as strictement aucune raison de les inciter à parler poliment.
C'est d'autant plus vrai que ton modèle tombe à 0€ de CA si on fait du libre.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: L'auteur ou les auteurs ?
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 3.
Économiquement son modèle devra s'adapter ; peut-être en vendant du service, comme d'autres. Mais du point de vue de son objectif social, il aura tout gagné ; il ne restera qu'à applaudir.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: L'auteur ou les auteurs ?
Posté par nud . Évalué à 3.
Il vend probablement déjà du service en facturant l'implémentation de ce que ses clients payants demandent.
# Mieux vaut une petite MIT qu'une grosse GPL
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Est-ce qu'il existe une licence "à copyleft" comme la GPL mais simple et concise comme la MIT ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mieux vaut une petite MIT qu'une grosse GPL
Posté par David Delassus (site web personnel) . Évalué à 3.
Mon intuition de béotien est que la MIT et les BSD sont concises car elles donnes des permissions sur un produit soumis aux droits d'auteurs (elles partent de "aucun droit" et en ajoutent), la ou la GPL par du domaine publique et ajoute des restrictions (pas de redistribution proprio, contamination, …).
En gros :
Les restrictions sont plus compliquées à préciser dans un texte légal, pour éviter les "loopholes" (trous de boucle en français ?)
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Mieux vaut une petite MIT qu'une grosse GPL
Posté par dr191 . Évalué à 6.
Des vides juridiques dans ce cadre la ?
[^] # Re: Mieux vaut une petite MIT qu'une grosse GPL
Posté par BAud (site web personnel) . Évalué à 7. Dernière modification le 28 mars 2024 à 17:13.
euh, non sur 2 points :
C'est ce que j'avais été amené à faire pour ueagle_atm : dual-licensing BSD-2 clauses et GPL-2+ => nos contributions bénéficiaient au pilote écrit pour FreeBSD et ont été intégrées au noyau Linux upstream suite à validation par Andrew Morton, merci -mm< _o/). Pour le firmware, les DSPcodes 1/2/3 sont restés sous licence non libre (mais redistribuables), la version 4 sous licence BSD-2 clauses (permettant la redistribution, mais on n'a jamais eu le code source :/)
Nous avons dû garder le firmware sous forme de blob et de binaire (DSPcode sans code source) chargé extérieurement :/
http://atm.eagle-usb.tuxfamily.org/wakka.php?wiki=NewsEn200611IkanosProvidesEagle4FirmwaresForFree
http://atm.eagle-usb.tuxfamily.org/wakka.php?wiki=FirmwareLicensing
suite à http://atm.eagle-usb.tuxfamily.org/wakka.php?wiki=AnnounceUeagleAtm
[^] # Re: Mieux vaut une petite MIT qu'une grosse GPL
Posté par David Delassus (site web personnel) . Évalué à 2.
Ok, merci pour les clarifications :)
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Mieux vaut une petite MIT qu'une grosse GPL
Posté par BAud (site web personnel) . Évalué à 4.
si tu veux approfondir (et que tu as du temps), tu peux aussi parcourir
une synthèsehttps://faq.tuxfamily.org/License/Fr qui aborde d'autres sujets complémentaires
# Quelques exemples
Posté par ChetManley . Évalué à 4.
Si tous (ou presque tous) les contributeurs à un projet GPL sont d'accord pour changer de licence, le projet peut changer de licence.
VLC et mpv sont tous deux passés de la GPL à la LGPL après un processus qui consistait à demander à un maximum de contributeurs leur accord. Ça a pris du temps (probablement plus que si le code était sous MIT), mais c'est possible.
Autre exemple: les applis Simple Mobile Tools qui sont passées de GPLv3 à une licence propriétaire quand leur principal développeur les a revendues à ZipoApps.
[^] # Re: Quelques exemples
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 5.
C'est possible si tu arrives à contacter l'intégralité des contributeurs. En pratique dès que ton projet dure un peu c'est compliqué (ou alors il faut réécrire des trucs, ce qui peut être compliqué selon les cas)…
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Quelques exemples
Posté par ChetManley . Évalué à 2. Dernière modification le 28 mars 2024 à 20:00.
Normalement, oui. En pratique, le seuil varie en fonction de à qui tu demandes.
Parmi les gros projets qui ont changé de licence: d'après Mozilla et Dolphin, 95% suffisent (tant qu'il n'y a pas d'objection des 5% restants) et d'après Videolan, c'est 99.99% du code et 99% des développeurs.
# J'avais compris l'inverse
Posté par purplepsycho . Évalué à 8. Dernière modification le 28 mars 2024 à 15:54.
En ce qui concerne ce point, j'avais compris l'inverse :
La GPL protège l'utilisateur dans la situation suivante : s'il à payé sont logiciel sous licence GPL, il peut demander à l'éditeur une copie du code source pour y appliquer ses 4 libertés.
Mais si l’utilisateur veut modifier le logiciel, rien ne l'oblige vis à vis de l'auteur original, il doit seulement fournir le code de sa version modifiée à ses propres utilisateurs s'ils en font la demande.
Ce que je décris est assez daté, mais l'idée est là je pense.
[^] # Re: J'avais compris l'inverse
Posté par aiolos . Évalué à 1.
C'est exactement ça.
[^] # Re: J'avais compris l'inverse
Posté par abriotde (site web personnel, Mastodon) . Évalué à -10. Dernière modification le 29 mars 2024 à 07:13.
La GPL est vu par la FSF (Free Software Foundation) comme ne respectant pas les 4 libertés car tu est obligé de reverser le code modifier et cette obligation est vu comme une certaine contrainte empêchant la liberté… bon il la condamné pas mais c'est une critique.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: J'avais compris l'inverse
Posté par fearan . Évalué à 10.
Gni???? Que dalle tu peux modifier n'importe quel code sous GPL et le garde pour toi, du moment que tu ne le redistribue pas. A partir du moment où tu refile un binaire avec du code modifié, tu est tenu de mettre ledit code à disposition de la personne a qui tu as refilé le binaire, et uniquement celle ci.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: J'avais compris l'inverse
Posté par David Delassus (site web personnel) . Évalué à 3.
Seulement si la personne le demande.
Tu peux garder le code chez toi et jamais le mettre sur Github/Gitlab/whatever
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: J'avais compris l'inverse
Posté par aiolos . Évalué à 4.
Alors là, j'aimerais bien une source !
[^] # Re: J'avais compris l'inverse
Posté par Marotte ⛧ . Évalué à 4.
C’est la FSF qui a publié la licence GPL…
https://en.wikipedia.org/wiki/GNU_General_Public_License
# pros / cons
Posté par abriotde (site web personnel, Mastodon) . Évalué à 2.
Il faudrait ajouter les bonnes raisons de choisir la licences Mit et celles de choisir la Gpl.
MIT rassure les entreprises privées car avec la GPL elles ont peur de la contagion. A savoir qu'elles ont peur de devoir mettre tous leur soft en GPL s'il y a un bout de GPL dedans. C'est faux mais le lobby anti-open-source joue dessus et les PME n'ont pas les moyens d'étudier plus la question. Résultat, si tu est en MIT, tu devrait avoir plus de contributions d'entreprises privé qui veulent intégrer leurs spécificités.
GPL à l'inverse rassure effectivement l'auteur car cela empêche une entreprises de partir du software et de le faire évoluer bien plus vite que l'auteur avec de gros moyens privé. Cela c'est vu dans les années 2000 mais aujourd'hui le risque est très limité car la communauté open-source est très reactive. On le voit dans l'IA.
La meilleure illustration de ceci est BSD vs Linux. Bsd est type MIT et on voit qu'il est soutenu par des entreprises très puissantes mais beaucoup plus discrètes que Linux.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: pros / cons
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 3.
Je veux bien que tu m'éduques. Qu'est-ce qui est faux ? Si tu mets du GPL, tout ce qui dérive (ou dépend exclusivement) doit être GPL. En tout cas c'est ce que je comprends.
Je suis preneur de ton explication ainsi que la raison pour laquelle la LGPL a été créée.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: pros / cons
Posté par Lutin . Évalué à 3.
Il y a une histoire une bibliothèque linkée dynamiquement qui ne contamine pas le reste du code (mais les modifications de ladite bibliothèque doivent rester libres).
[^] # Re: pros / cons
Posté par BAud (site web personnel) . Évalué à 4.
va falloir arrêter avec ce terme contamination : il n'y en a pas.
cf. mon commentaire traitant des bibliothèques incluses dans ce même journal
La LGPL permet d'avoir des bibliothèques qui n'obligent pas à hériter de la GPL pour l'exécutable distribué (et encore en compilation statique…) si on les utilise pour son code.
nVidia réussit bien à faire une glue entre le noyau Linux et leur pilote propriétaire… Les firmwares (non inclus à l'exécutable) peuvent avoir une version de licence différente et non héritée.
Tant qu'il y a séparation claire de ce qui est inclus dans ce qui est distribué, tu peux mixer des licences différentes :
Je peux multiplier les exemples, mais oui, il faut regarder au cas par cas (et c'est encore plus compliqué avec les licences propriétaires :p)
[^] # Re: pros / cons
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 3.
Du coup on est d'accord que ceci est faux :
?
Dit autrement : si on veut produire du code qu'on ne souhaite pas diffuser sous GPL, on ne peut pas s'appuyer sur des dépendances publiées en GPL ?
Je pose la question sérieusement, je pense ne pas être nase en licence mais j'attends mes limites, surtout s'il y a des distinctions à faire entre code source et version compilée …
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: pros / cons
Posté par BAud (site web personnel) . Évalué à 5.
bin, c'est pourtant de là qu'il faut partir et remonter la chaîne…
qu'est-ce qui est distribué : généralement un exécutable
la licence s'applique à la distribution : s'il y a de la GPL en amont,
et la GPL induit de fournir le code source amont (cf. plus bas)
pour le code :
pour les licences s'appliquant au code source :
c'est le paragraphe suivant de https://www.gnu.org/licenses/gpl-3.0.fr.html qui t'intéresse :
The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.
pour moi, si c'est dans des fichiers différents, ça peut avoir des licences différentes (mais IANAL) tant qu'elles sont compatibles entre elles. C'est le résultat (donc le binaire) qui héritera de la licence prévalente (dominante si tu préfères).
forcément, si tu inclus du code GPL dans un de tes fichiers source, ce fichier source est sous GPL (difficile de dire que ce n'est pas un travail dérivé si tu ne peux pas mettre le code GPL dans son propre fichier… sinon autant le faire et comme ça chaque fichier a bien sa propre licence).
l'idée c'est que les fichiers inclus soient sous une licence permissive ou la LGPL (ça simplifie la chaîne d'héritage des licences…) et que le programme principal porte la licence proéminente retenue.
si tu ne veux pas diffuser en GPL le résultat complet, tu mets dans des binaires différents ce qui se base sur de la GPL et ce qui se base sur les licences de ton choix. T'auras des portions en GPL (celles dérivées) et d'autres portions en non GPL.
après, tu as des outils de recensement des licences utilisées dans tes projets (conformité toussa), je ne sais pas s'il y a des fonctionnalités proposant un arbre des dépendances :/
cf. tag fossology et https://github.com/fossology/fossology/releases
[^] # Re: pros / cons
Posté par BAud (site web personnel) . Évalué à 3.
ça m'avait bien galéré pour la distribution de ueagle_atm, vu que nous souhaitions un dual-licensing au choix ; ce qui permettait d'éventuelles remontées de bugs aussi côté pilote FreeBSD. Au final, garder BSD aurait peut-être été plus simple…
[^] # Re: pros / cons
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
Moi justement je suis dans le cas du code interprété… On fait du python et du javascript.
Python est compilé en bytecode mais on fournit les sources et la compilation est faite au démarrage (mais si je ne me trompes pas on pourrait distribuer uniquement les pyc, ça marcherait aussi).
La partie frontend est en JS transpilé et minifié … Je ne sais pas si ça rentre dans le cadre de ce qu'on appelle "compilation".
Par contre ce que j'en comprends aussi c'est que si c'est du webassembly, ça s'applique (et c'est assez naturel).
Merci pour les explications en tout cas 👌
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: pros / cons
Posté par BAud (site web personnel) . Évalué à 1.
pour de l'interprété, la MIT et la BSD sont assez équivalentes à la GPL (hormis l'héritage de licence pour du code dérivé) vu que l'exécutable est le code source (hormis si transformé avant fourniture).
L'objectif de la GPL est bien de fournir les mêmes recettes à celui qui reçoit que ceux qu'utilise celui qui donne (donc source + description de la méthode de construction de l'exécutable ; tu peux utiliser du proprio lors de la construction : exemple avec Visual C++ qui peut être utilisé et n'est pas passé en GPL malgré tous les projets en GPL ne compilant qu'avec MSVC — mais sans MFC vu que inclus au code et pas sous la bonne licence).
ta partie backend peut donc être en GPL sans que cela impacte la licence du frontend ? (cela passe uniquement par des interfaces du backend)
hormis, si tu as des parties développées pour le backend qui sont poussées côté frontend ?
bin, un peu mon n'veu ;-) tu es censé filer les sources définis comme :
The “source code” for a work means the preferred form of the work for making modifications to it. “Object code” means any non-source form of a work.
tu ne travailles ni n'édites le résultat transpilé ni
obfusquéminifié ?es-tu sûr d'avoir au moins lu une fois la GPL ? :D
moui, après tu peux peut-être distinguer les différents points d'entrées (point d'entrée/URL différente, licence différente selon les portions concernées : le webassembly ne génère pas un gros binaire unique, j'imagine ?)
ton cas est intéressant pour l'AGPL qui revient à exposer quelque part le code source des services qui tournent en production, pour pouvoir instancier le service ailleurs (bon, pas le paramétrage, hein… ni le « contenu » : ne me fais pas dire ce que je n'ai pas dit :p).
J'ai vu peu de monde expliquer ce qui doit être effectivement exposé sur un exemple concret :D (perso, j'exposerais ce qu'il y a dans la forge permettant de travailler au jour le jour concernant le code et zou, mais pas forcément la CI/CD ni le paramétrage effectif des environnements).
[^] # Re: pros / cons
Posté par abriotde (site web personnel, Mastodon) . Évalué à -2.
Pour faire simple, tant que tu modifie pas le code sous GPL tu peux l'utiliser dans n'importe quoi sans conséquences. Si tu modifie le code tu dois publier juste tes modifications.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: pros / cons
Posté par Gof (site web personnel) . Évalué à 2.
Non c'est faux.
Si tu distribues un binaire, tu dois aussi distribuer les sources. Que tu aies fait des modifications ou non.
En conséquence:
Si tu modifies le code et que tu publies un binaire, tu dois aussi publier le code source de toute l'application, qui inclus tes modifications, à ceux à qui tu as distribué le dit binaire.
[^] # Re: pros / cons
Posté par David Delassus (site web personnel) . Évalué à 4.
La GPL ne requiert pas de publier le code source (aka: le mettre sur Github). Elle requiert seulement de le donner si l'utilisateur le demande.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: pros / cons
Posté par Marotte ⛧ . Évalué à 3.
C’est peut-être une autre manière de dire la même chose, ou bien à côté de la plaque, vous me direz.
Selon moi la raison d’être de la LGPL c’est de permettre d’utiliser la bibliothèque dans un logiciel propriétaire (qui est pourtant un travail dérivé du fait d’utiliser cette bibliothèque), tout en obligeant à redistribuer les modifications qui pourraient être faite au code de la bibliothèque elle-même en LGPL.
Pour résumer, ça permet l’utilisation/l’exploitation du code comme on le souhaite, tout en restant contraint pour sa modification/son amélioration.
# L'avocat du diable? Parlons business plan.
Posté par Jean Gabes (site web personnel) . Évalué à 4.
Vraie question:
Combien de projets rentables (donc avec une bonne pérennité, merci d'éviter les projets porté par une unique personne ici) en GPL-like (je mets AGPl dedans) ont eu un large succès ces dernières années?
C'est peu être un biais de lecture, mais aucun ne me vient à l'esprit, par contre des MIT et BSD là j'en vois des tonnes.
Donc à la question: "dois-je choisir GPL ou MIT/BSD", la vraie question devrait être le besoin avant les outils: "quel est ton business plan et tes ambitions?".
Si c'est avoir une énorme communauté et monter un gros business derrière, la GPL va entrer en contradiction au bout d'un moment, là où tu seras plus "libre" (ironie?) avec BSD/MIT.
Surtout que soyons un peu objectif, les utilisateurs s'en fichent un peu de ta licence. Eux voient que c'est gratuit, et c'est tout ce qui les intéresse au début, surtout par rapport à tout ce qui est gratuit à côté (sinon pourquoi utiliser ton outil? tu as révolutionné un domaine? il y a peu de chance désolé). C'est uniquement quand tu vas annoncer qu'il faut bien payer les factures que les utilisateurs vont se poser des questions (cf Redis dernièrement, même si là c'est des factures aux investisseurs qu'aux fournisseurs, mais ça revient au même au final).
Et je ne parle que pour les projets qui veulent en faire un business évidement, si c'est pour un projet perso ou semi-pro à petit échelle, la question du financement/rendement ne se pose pas vraiment (spoiler: ça sera à perte pure pour l'auteur dans 99% des cas, mais payé en gloire et satisfaction personnelle, ce qui est déjà très bien :) ).
[^] # Re: L'avocat du diable? Parlons business plan.
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Matomo ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: L'avocat du diable? Parlons business plan.
Posté par Gof (site web personnel) . Évalué à 2.
Juste quelques unes qui me viennent à l'esprit Mattermost, Cal.com, Nextcloud, Matrix, Matamo, Mastodon, Slint
Je ne sais pas si tous sont rentable par contre.
Sont-ils vraiment rentable?
[^] # Re: L'avocat du diable? Parlons business plan.
Posté par David Delassus (site web personnel) . Évalué à 4.
Mastodon fonctionne uniquement avec les dons et a récolté en 2022, d'après Wikipedia, 31 300€ de 9 400 donateurs. Pas de quoi payer un seul dev.
On appelle ça rentable ?
Les autres que tu as cité ont pour la plupart une entreprise derrière avec des revenus dans les millions annuels. C'est déjà un peu plus proche du projet avec un business plan ça.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: L'avocat du diable? Parlons business plan.
Posté par abriotde (site web personnel, Mastodon) . Évalué à 0. Dernière modification le 30 mars 2024 à 06:55.
Il ne faut pas compter uniquement les dons car il y a aussi toutes les contributions de salariés d'autres entreprises pour le business de ces entreprises, il y a aussi toutes les instances hébergé gratuitement par d'autres entité. Alors certes 30 000 euros c'est trop juste pour rémunérer ne serait-ce que le mainteneur mais le CA équivalent est peut être de 300 000 ou plus… En outre le mainteneur principal se rémunère peut être en prestation de conférences (çapeut être très cher)…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: L'avocat du diable? Parlons business plan.
Posté par cg . Évalué à 3.
Il y aussi les projets comme Samba, le noyau Linux, Git, QEMU, qui sont en GPL, et n'ont pas vraiment de business-model. La charge est distribuée sur plein d'entreprises.
On ne pas dire que ces projets n'ont pas d'importance ni ne rapportent d'argent :).
[^] # Re: L'avocat du diable? Parlons business plan.
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 5.
Dans quelle catégorie faudrait-il ranger Blender ?
[^] # Re: L'avocat du diable? Parlons business plan.
Posté par Jean Gabes (site web personnel) . Évalué à 4.
Ceux sans business plan propre, mais ayant assez d'intérêt en tant que "commun" pour que plusieurs acteurs réussissent à le financer. Bref, le cas idéal :)
[^] # Re: L'avocat du diable? Parlons business plan.
Posté par cg . Évalué à 3.
Bonne question.
Blender est principalement développé par la fondation Blender, qui est à but non lucratif. Mais Blender accepte des contributions de non-membres.
Et le financement est principalement par dons (page 96 du rapport annuel), Peut-être qu'on ne peut pas parler de "rentable", mais plutôt de "finances saines" ?
[^] # Re: L'avocat du diable? Parlons business plan.
Posté par Gof (site web personnel) . Évalué à 5.
Si je comprends bien ton argument c'est:
- Il y a plus de produit libre à succès connus qui utilisent une licence permissive que copyleft.
- Donc si tu veux avoir du succès, il faut que tu choisisse une licence permissive.
Mais je pense que même si la prémisse était vraie, ce dont je ne suis pas sûr (voir autre commentaires), le raisonnement est incorrect.
Je dirait même que les logiciels connus sous licence permissive auquel je pense ne sont pas connus à cause de leur licence, mais parce qu'ils sont fait et promus par des grosses boites, et ces grosses boites avaient d'autres raison pour choisir une licence qui ne sont pas forcément valide pour le lectorat de linuxfr.org.
Prenons par exemple Google, qui fait pas mal de produits sous licence permissive: Chormium, Android, Flutter, Go, …
Mais aucun de ces produit ne sont rentable en soit, ils rapportent juste indirectement grâce au fait que Google a derrière un gros business de publicité derrière.
(Une présentation intéressante à ce sujet: https://www.youtube.com/watch?v=XZ3w_jec1v8 )
[^] # Re: L'avocat du diable? Parlons business plan.
Posté par cg . Évalué à 2. Dernière modification le 29 mars 2024 à 18:28.
Quelques autres en GPL qui sont significatifs :
CEPH (LGPL en vrai)
GlusterFS
Proxmox (AGPL, ça compte ?)
Drupal
MySQL (en double licence, ceci dit)
VLC
Moodle
MediaWiki
Et un petit dernier pour la route : Wordpress, qui d'après certains sondages, représente plus de 40% des sites Internet à lui seul.
Mais oui, en license Apache/BSD/MIT, on en trouve beaucoup plus ! Déjà rien que dans les projets de la fondation Apache, c'est copieux.
[^] # Re: L'avocat du diable? Parlons business plan.
Posté par David Delassus (site web personnel) . Évalué à 4.
Beaucoup des logiciels que tu cites ne sont pas des logiciels "vendus" et donc ne génèrent aucun revenu, et n'ont aucune entreprise derrière avec un business model.
Le sujet du commentaire original était "il existe peu de logiciel GPL qui sont le produit phare d'une entreprise qui a fait son business model autour de ce dernier", et non "il existe peu de logiciel GPL avec une grande communauté".
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: L'avocat du diable? Parlons business plan.
Posté par cg . Évalué à 4.
Oui, certes, l'argent n'est pas forcément au niveau de la structure qui porte le projet. Il n'en reste pas moins que MySQL, Samba ou Wordpress permettent à beaucoup de gens de gagner leur vie.
Mais oui, je suis d'accord que c'est plutôt rare. Est-ce moins rare avec des licences à là BSD/MIT (TrueNAS, Kafka, PHP) ?
Au doigt mouillé, j'ai le sentiment qu'aujourd'hui les deux modèles dominants, c'est l'open core et la vente de services/formations.
[^] # Re: L'avocat du diable? Parlons business plan.
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 3.
Au niveau des éditeurs le modèle le plus largement étendu est l'opencore. Les cas comme Nextcloud, XWiki, Tracim, etc sont clairement pas la majorité.
Tout ce qui est vraiment libre (GPL) génère beaucoup d'économie de type service, mais la majorité du temps, il ne s'agit pas de contribuer en R&D et sans un éditeur solide derrière la solution, c'est compliqué. Combien de boîtes gagnent leur vie sans dépenser le moindre centime chez Nextcloud, gitlab, mattermost, etc ? L'éditeur a intérêt à avoir un modèle solide, pas pour sa propre survie (c'est une évidence) mais pour que toutes ces boîtes puissent continuer à assurer leur service.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# À propos de CLA
Posté par Gof (site web personnel) . Évalué à 4.
On a demandé conseil à un avocat pour la licence de notre projet qui est sous multi licences GPL + autres. Voici ce qu'il recommande comme CLA:
Et ensuite mettre le texte de la dite licence.
Ce qui a le mérite d'être simple.
Pour le contributeur, c'est l'équivalent de contribuer à un projet en MIT.
Note que notre CLA est un peu plus grand car nous avons rajouté un engagement de toujours garder une licence libre.
Un argument que j'entends souvent contre les CLA est qu'il y a une asymétrie entre les propriétaires du projet et les contributeurs externes. (Sous entendus, les contributeurs externes donnent plus de droits que les propriétaires.) Et effectivement il y a une asymétrie puisque les contributeur externes fournissent quelques changements sans garantie de maintenance, alors que les propriétaire fournissent un produit complet et sa maintenance, donc je ne pense pas que l'asymétrie des droits soit un problème.
[^] # Re: À propos de CLA
Posté par nud . Évalué à 3.
Ce n'est pas un problème pour le hobbyiste moyen (encore que signer un CLA c'est chiant et les clauses sont souvent invalide en Europe) mais je peux comprendre que ce soit un problème pour une société qui est en concurrence sur un même marché avec la société qui fait signer le CLA. Cette société aura alors une incentive pour ne pas contribuer ses changements car cela donne un avantage concurrentiel à la société qui fait signer le CLA.
Par exemple, imaginons une société A qui édite un logiciel de firewall et demande aux contributeurs de signer un CLA. En plus de la version "community" en GPL, cette société fournit également à ses clients une version propriétaire avec des fonctionnalités avancées. Une société A vend son propre produit basé sur le logiciel en question, en concurrence avec la version propriétaire de A, et apporte une amélioration. Bien que la GPL oblige à mettre à disposition les changements elle n'oblige pas à signer le CLA, donc la société A n'a probablement pas intérêt à céder les droits son code à la société A car cela anéantirait son avantage concurrentiel sans contrepartie de la part de A.
[^] # Re: À propos de CLA
Posté par Gof (site web personnel) . Évalué à 1.
Donc il y a deux sociétés A?
Effectivement, mais si les deux sociétés sont concurrentes, est-ce que il y aurait eu contribution sans CLA? Une motivation pourrait être la simplicité de maintenir le fork.
Mais si la société veux contribuer une fonctionnalité concurrente au produit propriétaire de la première société, cette société peut refuser de l'intégrer au produit libre car ce serait de la concurrence a l'offre payante. Et ce n'est pas de la faute du CLA.
[^] # Re: À propos de CLA
Posté par nud . Évalué à 2. Dernière modification le 29 mars 2024 à 14:48.
Le B est resté dans le clavier :-( Il faut lire "Une société B vend son propre produit basé sur le logiciel en question"
Sans CLA il y aurait pu y avoir une contribution car maintenir un soft fork est coûteux aussi. Mais sans CLA il n'y aurait pas d'offre propriétaire concurrente, les contributions étant sous licence GPL dans cet exemple.
[^] # Re: À propos de CLA
Posté par BAud (site web personnel) . Évalué à 2.
encore un clavier TOSHIB dont les touches se blo
# GPL/BSD, le débat sans fin
Posté par Marotte ⛧ . Évalué à 2. Dernière modification le 31 mars 2024 à 07:24.
Par rapport à la BSD, la GPL protège l’ensemble des utilisateurs, et pas chacun individuellement.
L’argument étant que globalement, aucun acteur ne peut, grâce à ses moyens, financiers, juridiques et humains, « enfermer » des logiciels qui sont libres à une date donnée.
Imagine que t’as bossé genre un an sur un logiciel innovant, seul ou à quelques uns, de manière totalement gracieuse, et quand tu le publies et que tu commences à avoir quelques utilisateurs, tu as une grosse boîte qui trouves que ton logiciel est effectivement assez astucieux, et donc, décide de récupérer ton code source, repackager ça dans un beau paquet-cadeau, et surtout, met toutes ses ressources marketing pour promouvoir ce logiciel. À tel point que six mois plus tard, dans la tête des gens, ce logiciel c’est cette grosse boîte qui en est à l’origine. En plus du marketing ils ont pu mettre une grosse équipe de développeur, de technicien pour faire le support. Tu as, toi et ta petite équipe réduite, aucune chance de lutter. Ta création deviendra un logiciel propriétaire de cette grosse boite.
C’est simple: ce logiciel ne t’appartient plus. Et BSD n’empêche pas ça, d’où la GPL.
C’est toute l’essence de la GPL : protéger l’ensemble de l’humanité, et donc les utilisateurs, que le libre ne puisse pas être vampirisé par des acteurs qui le peuvent techniquement, grâce à des ressources gigantesques.
Ce à quoi les BSD-istes rétorquent que laisser cette possibilité (ie: de fermer le logiciel, le code) c’est une liberté supplémentaire pour l’utilisateur. Ce qui est indéniable.
Il me semble d’ailleurs que dans la dernière version de la licence BSD, il n’est plus question d’obliger à laisser le nom de l’auteur (ou des auteurs) dans le source
La liberté de réduire les libertés des autres est-elle une liberté souhaitable ? C’est le nœud du problème, me semble-t-il.
Perso je ne vois pas trop quelle différence il peut y avoir entre la licence BSD et la licence WTFPL au final…
[^] # Re: GPL/BSD, le débat sans fin
Posté par BAud (site web personnel) . Évalué à 2.
source ?
ce serait non-applicable en France où le droit moral est perpétuel, inaliénable et imprescriptible
cf. Droit d'auteur
c'est dommage, cela introduirait comme pour la CC0 des difficultés d'application selon le pays d'origine des auteurs :/ (en France, l'on ne peut pas placer une œuvre directement dans le domaine public…)
[^] # Re: GPL/BSD, le débat sans fin
Posté par David Delassus (site web personnel) . Évalué à 2. Dernière modification le 31 mars 2024 à 14:55.
Tu dis que ça protège les utilisateurs, et ensuite dans l'exemple que tu donnes, tu parles de l'auteur et pas des utilisateurs.
De plus, dans l'exemple que tu donnes, la GPL n'aurait rien changé. Une grosse boîte peut reprendre ton logiciel, le vendre, et mettre beaucoup plus de moyens que toi, te "volant" (mauvais terme car c'est une liberté que tu donnes, mais c'est ce que tu insinues) ton public cible.
La seule différence ? Si un des utilisateurs de ce fork demande l'accès au code source, l'entreprise est obligé de lui donner. Ce qui n'est pas forcément problématique, après tout, ce n'est pas la technologie que se vend, mais le service autour.
Pour peu que l'entreprise ensuite, ayant "raflé" le marché, mette les moyens pour réécrire le code (dans un autre langage, ou le même langage) de 0, afin de s'affranchir de la GPL et sortir une version proprio, comment est-ce que les utilisateurs sont protégés ?
Je reste non convaincu que la GPL protège les utilisateurs, non elle protège l'auteur et son code source, c'est tout. Et encore, elle le fait très faiblement.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: GPL/BSD, le débat sans fin
Posté par Marotte ⛧ . Évalué à 3.
Ça fait quand même une différence.
En fait je viens de réaliser. La GPL ne protège ni l’auteur ni le l’utilisateur en première intention, elle protège le code, cet écrit de nature divine par essence ! ^^
[^] # Re: GPL/BSD, le débat sans fin
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 31 mars 2024 à 23:57.
Il n'y a pas mieux que les anti copyfree (donc style BSD) pour convaincre les hésitants que le copyfree est une bonne idée.
Ici, un anti copyfree donne une explication… Non négative sur le copyfree et montre donc qu'il n'a aucun argument contre le copyfree.
Parce que non, l'exemple donné n'a rien de négatif, un truc a été développé, d'autres ont fait évoluer (le marketing autour est une évolution), le logiciel a pris sa liberté par rapport à l'auteur initial, en fait c'est un super exemple pour donner des libertés aux logiciels.
Et le seul exemple qu'un anti copyfree arrive à donner, c'est le narcissisme (ouais, j'y vais à fond pour provoquer) des auteurs initiaux qui ne veulent pas vraiment perdre le contrôle de leur logiciel et veulent qu'on les applaudisse pour leur oeuvre. Ouais, que c'est "positif".
Faux, les acteurs mettant en non libre ne t'enlèvent aucune liberté de proposer en libre ta version. Faut juste que tu ais un truc à proposer en plus, bref que tu bosses au présent plutôt que de penser qu'on va t'applaudir pour le passé.
En fait, ce qui est montré ici est qu'il n'y a tellement pas d'argument contre le copyfree qu'il faut inventer un "grand méchant" pas du tout convainquant (il ne convaincra que ceux qui veulent voir dans ce "grand méchant" vraiment une méchanceté) vu qu'il ne retire absolument rien aux auteurs initiaux.
Faudrait que tu te renseigne mieux.
Il n'y a pas de "versions", mais des variantes (merci le texte en libre, contrairement à par exemple des textes non libre comme la GPL, notez que je n'ai pas dit que la GPL est non libre, on peut adapter à ses envies) comme la 0BSD mais ce n'est pas une "dernière version" de la BSD, juste une variante.
Exactement. Maintenant j'attends des raisons de ne pas le faire, ici ce qui a été donné est très loin d’être convainquant. Et rappelons que ce genre d'argumentation qui dit que trop de libertés c'est pas forcément bien, c'est un des arguments des anti libre parce que bon même la GPL permet de se passer des auteurs initiaux (vu que c'est l’intérêt du libre), par exemple "tu te rends compte l'autre il a patché mon code et livré le tout et a été payé pour ça sans rien me refiler, e n'est pas correct", ou comment se tirer une balle dans le pied.
Ici, ton exemple marche aussi très bien contre le copyleft, en fait. Pas vraiment de différence sur les sujets que tu abordes, juste que tu n'y as pas réfléchi et pas compris les conséquences de ta façon de voir.
Le libre, copyfree ou copyleft, ne te remercie pas.
PS : en fait j'ai déjà lu mieux sur l’intérêt du copyleft, ça peut se défendre… Mais vraiment, vaut mieux éviter la notion d'égo des auteurs ou de "grand méchant" inventé, c'est négatif… Sur les auteurs des utilisateurs de ces "arguments". Parce qu'en pratique tout l’intérêt du libre est bien de pouvoir ses passer des humeurs des auteurs initiaux, et ne pas voir ça alors que c'est tout le sujet est quand même bien fort.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.