En effet, la GNU GPL protège contre la fermeture du code jusqu'a ce que les auteurs en décident autrement.
La meilleur protection est celle du noyau Linux: Il n'est pas possible de changer les droits du code sans l'accord de tous les contributeurs. Or de nombreux contributeurs ne se laisseront pas faire si il y a une tentative de dilution de la protection apportée par la GNU GPL. Cette protection est à double tranchant: Linus T. l'a illustrée en prenant le cas d'un changement de la licence du noyau Linux vers une GNU GPLv3.
Il existe pourtant de nombreux contournements, et il s'agit que toi, contributeur qui ne souhaite pas que ton code puisse être fermé (cad, pas toi bisounourse donc tu peux t'arrêter de lire ce journal), soit très vigilant.
Prenons le cas de MySQL AB: Ce document vous force à attribuer vos droits au conseil d'administration de MySQL AB. Tout cela permet au conseil d'administration d'avoir les droits sur l'ensemble du code de MySQL et donc de pouvoir changer les licences à souhait, comme le montre l'existence de la version binaire sous licence propriétaire.
Ce n'est pas limité au cas de MySQL AB, en effet on retrouve le même genre d'accords sur openoffice.
Bon les linuxiens avertis auront remarqués que les exemples précédents concernent des logiciels supportés par des entreprises possédées par Sun. Mais cela peut concerner d'autres entreprises, comme TrollTech avec Qt... mais eux auraient signé un accord avec la communauté comme quoi quelque soit la composition du conseil d'administration de TrollTech, si il est décidé d'arrêter le développement de Qt sous GNU GPL, la dernière version open source de Qt serait placé en licence de type BSD.
Bon, je passe sur les autres contournements plus visibles comme les dual licences GNU GPL/BSD Like. En effet, il ne faut pas oublier que les licences BSD autorisent la fermeture du code. Donc du moment que le code est disponible sous ce genre de licence... bref le piège à c... est évident. Ici il suffit de prendre les exemples des OS d'apple, les morceaux de code BSD dans les OS de MS, ou encore la myriade de forks propriétaires des *NIX BSD qui a laissé MS s'imposer, etc.
Mais certains rétorqueront qu'il y a des modules propriétaires dans le noyau Linux?
Et bien, ces modules ne respectent pas la GNU GPL du noyau Linux. En effet, la GNU GPL concerne tout le code ayant la faculté de fonctionner avec le noyau Linux (avec l'exception du mode utilisateur). Donc c'est avec le pragmatisme des développeurs du noyau et "la pression du marché" que ces modules sont tolérés (cf nvidia).
Bref... pour dire que le sujet n'est pas simple et particulièrement miné. Il s'agit d'être vigilant et de ne pas se laisser trop faire.
Journal La GNU GPL est-elle suffisante?
4
mai
2008
# Re:
Posté par Tonton Benoit . Évalué à 10.
Après ce dont tu parle, la propriété du code la GPL n'a pas a s'en meler, le contributeur qui cède les droits sur son code en accepte les conséquences ou ne contribue pas (il fournit son patch à pars ou fait un fork)
D'ailleurs tu n'en parle pas mais la FSF elle-même réclame les droits sur le code pour l'intégration au projet GNU.
[^] # Re: Re:
Posté par un_brice (site web personnel) . Évalué à 6.
Non. Ce qui est vrai en revanche c'est que certains projets du GNU le requièrent. Mais l'assignation de copyright à la FSF contient un engagement de la FSF que toutes les versions du travail qui leur est assigné seras distribué sous licence copyleft. Et bien d'autres encore, genre la FSF s'engage à envoyer au gars qui signe toutes les softs dérivant de son code dès qu'il en fait la demande.
[^] # Re: Re:
Posté par MrLapinot (site web personnel) . Évalué à 4.
# La GPL est elle trop restrictive ?
Posté par Gof (site web personnel) . Évalué à 8.
Et n'oublie pas que même si une boite a le droit de changer la licence de son code, les versions qui on été publiée en GPL le sont encore, et qu'il est donc possible de forker à partir de là.
[^] # Re: La GPL est elle trop restrictive ?
Posté par mtg . Évalué à 1.
En fait même cela est discutable: il y a des zozos qui essayent de "reprendre" leur code de manière retro-active ...
http://blog.milkingthegnu.org/2008/05/dual-licensing.html
[^] # Re: La GPL est elle trop restrictive ?
Posté par Zenitram (site web personnel) . Évalué à 2.
Bon courage devant les tribunaux "oui, il obéit à ce que j'ai dit, mais je veux plus qui fasse ce que j'ai autorisé"... Le juge risque de rigoler!
[^] # Re: La GPL est elle trop restrictive ?
Posté par mtg . Évalué à 1.
Bon courage devant les tribunaux "oui, il obéit à ce que j'ai dit, mais je veux plus qui fasse ce que j'ai autorisé"... Le juge risque de rigoler!
En fait ça fait si peu rigoler rms et Eben Moglen qu'ils ont rajouté le mot "irrevocable" dans la GPLv3 ...
# L'accord sur Qt...
Posté par Pinaraf . Évalué à 10.
Pourquoi l'emploi du conditionnel ? Tu doutes donc de cet accord ?
Il est signé sur papier, disponible en version numérisée sur le site de KDE.
http://www.kde.org/whatiskde/kdefreeqtfoundation.php
Plus exactement :
http://www.kde.org/whatiskde/images/agreement1.png
http://www.kde.org/whatiskde/images/agreement2.png
http://www.kde.org/whatiskde/images/agreement3.png
http://www.kde.org/whatiskde/images/agreement4.png
[^] # Re: L'accord sur Qt...
Posté par mtg . Évalué à 1.
Je en vois pas bien l'interêt de releaser sous BSD puisque le code est déjà sous GPLv3 de toute façon. C'est une ouverture pour qu'une autre boîte reprenne le flambeau du "dual-licensing"?
[^] # Re: L'accord sur Qt...
Posté par Pinaraf . Évalué à 3.
# Effectivement
Posté par Sébastien B. . Évalué à 6.
En effet, les morts sont souvent très réticents à un changement de licence.
Sinon, quelqu'un aurait une comparaison exhaustive des GPLv2 - v3 AGPL et LGPL ?
[^] # Re: Effectivement
Posté par Christophe --- . Évalué à 6.
Alors là, je m'insurge: c'est un faux problème. Il suffit d'attendre un peu (oh, pas bien longtemps, à peine 70 ans) et le problème se résoud de lui-même. (et puis bon, que sont 70 ans en informatique, trois fois rien hein ?)
[^] # Re: Effectivement
Posté par Earered . Évalué à 2.
[^] # Re: Effectivement
Posté par mtg . Évalué à 1.
En gros la GPLv3 reprend les termes de la GPLv2 et repare un certain nombres de "flous juridiques" (par exemple elle introduit explicitement l'irrevocabilité de la GPL, elle precise la definition de distribution etc.) et elle ajoute:
- La clause anti-tivo (l'obligation de pouvoir modifier ET executer le code sur une boite "fermee" contenant du GPL)
- La clause anti-DRM (si un soft de DRM est ecrit avec la GPLv3 alors le DMCA ne peut pas s'appliquer si on crack le DRM ecrit en GPLv3)
- La clause anti-brevet (aucun des auteurs ne peut opposer à aucun des utilisateurs un brevet couvrant du code qu'il a releasé en GPL)
Enfin la GPLv3 fournit un moyen de se mettre en accord qui n'est pas juste tout ou rien. Si la societe qui n'applique pas la GPL (distribution) alors qu'elle devrait, elle eput retrouver ses droits (vis a vis de la GPL) apres s'être executée.
Pour plus de details:
GPLv3 for dummies: http://blog.milkingthegnu.org/2008/04/gnu-gpl-for-dum.html
[^] # Re: Effectivement
Posté par Zenitram (site web personnel) . Évalué à 2.
L'esprit des licences est le même (défense des 4 libertés), mais avec des "domaines" d'utilisation :
- LGPL : pour une librairie (tu ne veux pas imposer un choix de licence à celui qui utilise ton produit dans son application)
- GPL pour une appli normale (le libre s'applique à celui qui a le logiciel, pas ses entrées-sorties)
- AGPL pour un serveur avec des clients (genre un SPIP) (le libre s'applique à celui qui va sur ton site web, en tant qu'utilisateur il a le droit au source, contrairement à la GPL)
Donc finalement tu n'as pas grand chose à choir, tu cas ton "produit" dans un des 3 domaines et tu as ta licence.
Pour te donner un exemple, je développe un shared object en LGPL (quiconque peut se connecter à se shared object sans se poser de question sur la licence, mais si modifs du so alors diffusion du source a celui qui recoit le soft), le GUI et CLI s'y collant sont en GPL (quiconque peut utiliser la sortie du logiciel sans se poser de questions, si modif du soft diffusion du source a celui qui recoit le soft), et je pense que je ferai le logiciel faisant tourner le site web en AGPL (le visiteur d'un site qui utilise mon soft devra fournir le source au visiteur)
Après, tu peux changer de licence si tu as envie d'être "activiste du libre" (comme empêcher les applis à se connecter à ta librairie si pas GPL), mais après tu risques de perdre en diffusion de ton projet... A toi de mesurer les risques.
# Ben voyons
Posté par Jerome Herman . Évalué à 8.
Ben si il faut l'oublier parceque c'est faux. Les licences de type BSD ne force pas la redistribution du code source modifié avec la distribution du binaire, mais en aucun cas elle ne permet la fermeture du code. Donc si un code source a été distribué sous licence BSD il reste utilisable ad vitam eternam quelques soient les volontés des propriétaires du code.
[^] # Re: Ben voyons
Posté par IsNotGood . Évalué à 3.
Par exemple BSD est très brevet / DRM / tivolisation friendly (ces derniers points ont été pris en compte par la GPL v3).
C'est volontaire de la part de la BSD.
Donc une boite peut faire du BSD, y foutre des brevets, et quelques temps après dire qu'il faut payer pour utiliser le programme.
Avec la GPL, ce n'est pas le cas. Si MS met des brevets à lui dans un programme GPL, ben la GPL s'applique totalement.
[^] # Re: Ben voyons
Posté par Gniarf . Évalué à 5.
> C'est volontaire de la part de la BSD.
non : la licence BSD date de 1990 et à cette époque, ces concepts n'existaient pas, pour la plupart. dire que c'est une conséquence naturelle ou prévisible de cette licence serait plus juste.
> Donc une boite peut faire du BSD, y foutre des brevets, et quelques temps après dire qu'il faut payer pour utiliser le programme.
son programme à elle ? elle peut le faire de suite. celui d'origine ? prior act si ce ne sont pas ses ajouts, et si ce sont ses ajouts, je ne vois pas où est le problème, la version juste-avant-le-brevet sera propre sur elle.
si c'est encore un fantasme, un cas de jalousie maladive "les méchants (genre Apple, Google) volent le code et ne rendent rien en retour", c'est raté, le code n'est pas volé.
[^] # Re: Ben voyons
Posté par Romeo . Évalué à 2.
http://www.gcu.info/2536/2008/05/04/ils-parlent-pas-mais-que(...)
[^] # Re: Ben voyons
Posté par mtg . Évalué à 1.
Non c'est pas vraiment un fantasme, c'est meme là-dessus qu'est basé l'accord entre Microsoft et Novell
L'idée c'est que quelqu'un releases du code (disons sous BSD, MIT ou meme GPLv2) et que plus tard, quand tout le monde utilise la contrib en question une société qui pretend avoir des brevets là-dessus va voir ceux qui ont des sous pour leurs reclamer des royalties.
Evidemment le pire c'est que la société qui a les brevets peut meme "inciter" un developpeur à introduire sciemment le code "breveté" pour ensuite collecter sur un projet qui a du succés ... d'ou la clause anti-patente de la GPLv3 ...
Y en a meme qui veulent en faire un business model ...
si vous etes interessés
http://blog.milkingthegnu.org/2008/04/patent-based-op.html
[^] # Re: Ben voyons
Posté par Jerome Herman . Évalué à 2.
Va dire ca à l'université de Berkley qui possédait une grosse partie du code BSD4 au début. Quand il se sont rendu compte de ce qu'ils avaient fait ils ont tentés de faire marche arrière. Peine perdue, NetBSD a fait appliquer la licence et a gagné.
C'est volontaire de la part de la BSD
L'utilisation de code BSD est libre pour tous, absolument tous quelques soient les conditions de redistribution. La philosophie ici est de ne pas faire d'exception à leur licence, et donc de ne pas bloquer en quoi que ce soit même pas les DRM !
Donc une boite peut faire du BSD, y foutre des brevets, et quelques temps après dire qu'il faut payer pour utiliser le programme.
Ben il peuvent le dire oui, mais si ils ont relaché eux-mêmes volontairement un code avec une licence qui dit que tout le monde peut utiliser le code gratuitement, ils vont avoir du mal à trouver des gens pour les écouter. La BSD est une licence de copyright, c'est à dire qu'elle expose les droits (rights) que l'on a pour faire des copies (copy) du produit, et elle définie aussi les conditions d'utilisation.
Et dans un cas comme dans l'autre elle est très très claire : il n'y a aucune contrainte ci ce n'est celle de garder un en-tête.
La grosse différence avec la GPL c'est que tu n'es pas obligé de redistribué les sources avec un binaire, et que tu peux redistribuer des sources ou du binaire sous licence BSD avec n'importe quoi quel que soit sa licence.
[^] # Re: Ben voyons
Posté par Zenitram (site web personnel) . Évalué à 2.
La BSD dit que tu a le droit d'utiliser le code.
La BSD ne dit rien sur les brevets. Ce n'est pas parce que tu as le droit de diffuser du code que tu as le droit de diffuser un produit soumis à brevet sur le produit.
Pour te donner un exemple (GPL, mais c'est pareil pour les brevets), ce n'est pas parce que tu diffuses XviD que tu ne devras pas payer des royalties pour les brevets sur le codec MPEG-4 Visual.
Ne mélange pas le code avec la fonctionnalité, l'un est libre dans le cas de la BSD, mais ne dit rien sur les droits sur la fonctionnalité. Diffuser en licence BSD un truc soumis à brevet est un beau cheval de troie qui marche sans problème devant un juge... Tu perdras en beauté.
[^] # Re: Ben voyons
Posté par Jerome Herman . Évalué à 3.
La licence BSD est une licence copyright, si le propriétaire d'un brevet te donne une licence sur le code qui te permet d'utiliser le dit code comme bon te semble (ce qui est à peu près le cas avec une licence BSD) alors tu as le droit d'utiliser le code comme bon te semble.
Tu as une licence.
C'est le propriétaire du brevet qui te l'a donné.
C'est bon tout va bien tu peux y aller.
Au cas ou tu aurais le moindre doute, l'Université de Berkley qui possédait des brevets sur le système BSD a déjà tenté le coup de "on peut faire ce qu'on veut avec le code sauf si ils couvrent des brevets". Le truc c'est que la licence ne fait pas mention du "sauf si ils couvrent des brevets", donc la licence te permet implicitement d'utiliser les brevets couvert par le code (sous reserve que ce soit bien le propriétaire des brevets qui relache le code bien sur).
Ca a déjà été testé devant les tribunaux. L'université de Berkley a perdu et c'était il y a plus de dix ans. Il y a donc une jurisprudence solide.
[^] # Re: Ben voyons
Posté par mtg . Évalué à 1.
Donc une societe qui possede un brevet sur X peut tres bien inciter un contributeur à releaser du code MIT, GPLv2, BSD qui en fait couvre le brevet.
Le projet de vient un gros succes.
La societe qui detient le brevet va collecter chez tout le monde ...
[^] # Re: Ben voyons
Posté par Jerome Herman . Évalué à 2.
Ben dans ce cas quelque soit la licence (même proprio) l'utilisateur l'a dans l'os. Je ne vois pas en quoi la BSD serait défavorisée par rapport à une autre licence sur ce point là.
[^] # Re: Ben voyons
Posté par mtg . Évalué à 1.
C'est aussi le cas de la X/MIT etc.
# modules propriétaires dans le noyau
Posté par regdub . Évalué à 5.
Je suis sûr que des lecteurs pressés ou anti-linux vont comprendre que le noyau fournit par kernel.org contient des modules propriétaires, ce qui n'est pas le cas.
[^] # Re: modules propriétaires dans le
Posté par Barnabé . Évalué à 4.
Le noyau fourni par kernel.org contient bien des logiciels propriétaires, des firmwares pour la plupart.
Par exemple :
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6(...)
C'est en partie sur ce point que le travail que fait gNewSense est utile : identifier les bouts non libres d'une distribution.
Attention, je ne fais pas forcément partie des promoteurs d'un noyau sans firmware propriétaires, je pense juste que le travail d'identification est utile.
[^] # Re: modules propriétaires dans le
Posté par regdub . Évalué à 3.
[^] # Re: modules propriétaires dans le
Posté par Barnabé . Évalué à 3.
[^] # Re: modules propriétaires dans le
Posté par regdub . Évalué à 3.
Je pensais que c'était les distributions qui ajoutaient ces blobs, pas qu'il y en avait dans le kernel original.
ex: Documentation/networking/README.ipw2100
As the firmware is licensed under a restricted use license, it can not be included within the kernel sources.
Vu comme ça, je trouve le README trompeur.
# interet du journal ?
Posté par Anonyme . Évalué à 5.
Non, rien ne t'oblige à attribuer tes droits à MySQL AB. C'est uniquement le cas si tu veux que ton code soit integré à la version officielle de MySQL, mais rien ne t'interdit un fork par exemple. Heureusement, chacun est encore libre d'accepter ou non les contributions qu'il recoit sur les criteres qu'il veut. Et pour le rapport avec ton titre qui est "la GNU GPL est-elle suffisante?" je ne vois pas bien ce que la GPL vient faire la dedans. Chacun est egalement libre de choisir la licence qu'il veut pour distribuer son code, donc si la GPL interdisait ce genre de chose, il leur suffirait de choisir une autre license.
Ce genre de choses n'est pas l'ideal pour avoir une bonne communauté de contributeurs par ce que ca complique les choses, mais je ne vois pas non plus pourquoi il faudrait l'interdire.
En fait, je n'ai pas bien compris le but de ton journal ...
Ici il suffit de prendre les exemples des OS d'apple, les morceaux de code BSD dans les OS de MS, ou encore la myriade de forks propriétaires des *NIX BSD qui a laissé MS s'imposer, etc.
Oui oui, bien sur, si MS s'est imposé c'est uniquement grace à du code BSD, c'est evident.
En effet, la GNU GPL concerne tout le code ayant la faculté de fonctionner avec le noyau Linux (avec l'exception du mode utilisateur)
Non, ca concerne le code qui peut etre consideré comme "oeuvre derivee". Ca inclut en general les modules noyau, mais pas forcement, tout depend du module et de la facon dont il est fait.
[^] # Re: interet du journal ?
Posté par mtg . Évalué à 1.
Monty et Marten bossent pour SUN et ils ont meme sous leur chapeau pleins de mecs clefs de PostgreSQL ...
Sur le sujet:
http://blog.milkingthegnu.org/2008/05/exisiting-dual.html
# hm
Posté par Guillaume Knispel . Évalué à 3.
Chacun choisira en son âme et conscience les conditions sous lesquels il souhaite contribuer.
Le logiciel libre permet, ne l'oublions pas, le fork.
Concernant le multi-licensing copyleft + (libre non copyleft ou proprietaire), je crois pour ma part que refuser sans conditions ce modèle ferait plus de mal que de bien au Logiciel Libre. Par contre je suis assez contre le modèle de logiciel distribué bridé ou en retard en libre et complet ou en premier en propriétaire, aussi bien pour des raisons pratiques que parce que le Logiciel Libre ne doit pas se transformer en simple argument commercial d'appel.
À part ça attention tu te répètes un peu... ( https://linuxfr.org/~GPL/26461.html )
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.