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 :
un module noyau distribué en GPL2 (avec dual BSD + GPL2+ pour le code — notre cas avec ueagle-atm — compatible GPL2 pour inclusion dans Linux)
des firmwares permettant le fonctionnement du module, distribués à côté du module noyau (d'où les paquets kernel-firmware-nonfree) avec leur propre licence (distribuable au mini pour des raisons évidentes, libre ou non libre selon les velléités de chacun)
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 BAud (site web personnel) . En réponse au journal GPL vs MIT, que choisir ?. É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)