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.
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.
> Lire le journal (34 commentaires, moyenne: 3,5).
Vous avez demandé le commentaire #928134.
Run by 
Cette page a été générée par Templeet en 0.0505s (dont 0.0049 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Effectivement
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.
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
En effet, les morts sont souvent très réticents à un changement de licence.
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
Il me semble que la durée du droit d'auteur pour les logiciels est de 50 ans (c'était 20 ans avant, et le livre sur le droit d'auteur dans le code de la propriété intellectuel est truffé d'exception au droit d'auteur classique pour les logiciel, type copie privée: autant qu'on veut en classique, une seule copie de sauvegarde pour le logiciel).
[^]Re: Effectivement
Sinon, quelqu'un aurait une comparaison exhaustive des GPLv2 - v3 AGPL et LGPL ?
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
Sinon, quelqu'un aurait une comparaison exhaustive des GPLv2 - v3 AGPL et LGPL ?
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.