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.
Vous ne pouvez plus rajouter de commentaires! (trop vieux)
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).
Run by 
Cette page a été générée par Templeet en 0.041s (dont 0.0019 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Re: L'accord sur Qt...
la dernière version open source de Qt serait placé en licence de type BSD.
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"?
[ Répondre ]