Sans être un militant de la licence BSD au mépris de la GPL (j'aprécie les deux licences), je vais quand même intervenir en sa faveur parcequ'elle a aussi de bons cotés, et que les lecteurs de linuxfr (que je suppose majoritairement linuxiens) pourraient ne pas les connaitres, et tirer des conclusions hatives en lisant des messages comme le tien (qui sont fréquents ici).
Certains apprécient la licence BSD (3 clauses, et aussi la MIT) justement parcequ'elle offre une grande très compatibilité avec les autres logiciels (elle est compatible avec la GPL -et la réciproque n'est pas vraie-, la LGPL, la MPL, avec n'importe quelle licence close source et proprio etc.).
Pour ceux-là, le fait de voir son code repris par un autre logiciel (eventuellement GPL ou propriétaire) n'est pas forcément génant (c'est plutôt une bonne chose, à minima un gage de reconnaissance).
Celà permet par exemple une large adoption d'un concept ou d'un protocole au départ developpé par un petit groupe peu influent.
Par exemples, le choix de X11 par les divers unix (propriétaires ou pas) est une très bonne chose permise par la licence à l'époque très ouverte de XFee ; idem pour la couche TCP/IP: l'implem d'origine, sous licence BSD, a permis à celle-ci de d'être adoptée aussi par les OS proprios, à une époque où les couches réseau maison en concurence étaient légions (et je suis heureux de ne pas vivre dans un monde netbeui ;) ; voir aussi, aujourd'hui, le travail de kame autour d'IPv6, ou de l'ISC avec bind, dhcpd et inn.
Quand une implémentation libre, (très) ouverte et documentée devient un standard de fait, en lieu et place de solutions propriétaires, c'est toute la communauté du libre qui en bénéficie (y compris le projet GNU). Dans ce cadre la licence BSD a toute sa place.
On peut aussi se réjouir du choix de licences permissives pour PHP, python, perl et ruby qui permet l'utilisation de ces logiciels en entreprise (eg. pour faire d'autres softs, close source). (histoire de rechauffer le tro^H^H la dépeche sur le choix de la licence de java par sun ;).
Dans le même ordre d'idées, le projet OpenBSD (dont les developpeurs maintiennent aussi OpenSSH) milite pour un internet sécurisé. Le fait que Cisco utilise maintenant le code d'OpenSSH (sous licence BSD) rend les réseaux plus sûr, et par conséquent diminue le risque d'attaques pour tout le monde (y compris les utilisateurs d'Open). Donc le choix de la licence contribue à l'objectif de sécurité (comme s'ils disaient "volez notre code, il est robuste et audité, et nous ne voulons pas que nos voisins aient la peste").
Concernant le risque de voir un projet BSD disparaitre à cause de la fermeture du code, il est plutôt théorique sur les gros projets (ormi apache et son abominable nouvelle licence). MacOSX et BSDOS n'ont pas tué FreeBSD, les developpeurs ont déserté le projet XFree lorsqu'il a changé de licence (et X.org semble bien se porter), etc. Bref, il est probable que les logiciels propriétaires utilisant du code BSD améliorent les projets BSD plus souvent qu'ils ne leur font du tort.
Pour finir, l'auteur (detenteur du copyright) d'un projet GPL peut lui aussi décider de refermer son travail. Au moins pour "ses" fichiers. Mais c'est là aussi très théorique.
[^] # Re: alors là bravo
Posté par herodiade . En réponse à la dépêche PC-BSD : Un système FreeBSD pour le grand public. Évalué à 10.
Certains apprécient la licence BSD (3 clauses, et aussi la MIT) justement parcequ'elle offre une grande très compatibilité avec les autres logiciels (elle est compatible avec la GPL -et la réciproque n'est pas vraie-, la LGPL, la MPL, avec n'importe quelle licence close source et proprio etc.).
Pour ceux-là, le fait de voir son code repris par un autre logiciel (eventuellement GPL ou propriétaire) n'est pas forcément génant (c'est plutôt une bonne chose, à minima un gage de reconnaissance).
Celà permet par exemple une large adoption d'un concept ou d'un protocole au départ developpé par un petit groupe peu influent.
Par exemples, le choix de X11 par les divers unix (propriétaires ou pas) est une très bonne chose permise par la licence à l'époque très ouverte de XFee ; idem pour la couche TCP/IP: l'implem d'origine, sous licence BSD, a permis à celle-ci de d'être adoptée aussi par les OS proprios, à une époque où les couches réseau maison en concurence étaient légions (et je suis heureux de ne pas vivre dans un monde netbeui ;) ; voir aussi, aujourd'hui, le travail de kame autour d'IPv6, ou de l'ISC avec bind, dhcpd et inn.
Quand une implémentation libre, (très) ouverte et documentée devient un standard de fait, en lieu et place de solutions propriétaires, c'est toute la communauté du libre qui en bénéficie (y compris le projet GNU). Dans ce cadre la licence BSD a toute sa place.
On peut aussi se réjouir du choix de licences permissives pour PHP, python, perl et ruby qui permet l'utilisation de ces logiciels en entreprise (eg. pour faire d'autres softs, close source). (histoire de rechauffer le tro^H^H la dépeche sur le choix de la licence de java par sun ;).
Dans le même ordre d'idées, le projet OpenBSD (dont les developpeurs maintiennent aussi OpenSSH) milite pour un internet sécurisé. Le fait que Cisco utilise maintenant le code d'OpenSSH (sous licence BSD) rend les réseaux plus sûr, et par conséquent diminue le risque d'attaques pour tout le monde (y compris les utilisateurs d'Open). Donc le choix de la licence contribue à l'objectif de sécurité (comme s'ils disaient "volez notre code, il est robuste et audité, et nous ne voulons pas que nos voisins aient la peste").
Concernant le risque de voir un projet BSD disparaitre à cause de la fermeture du code, il est plutôt théorique sur les gros projets (ormi apache et son abominable nouvelle licence). MacOSX et BSDOS n'ont pas tué FreeBSD, les developpeurs ont déserté le projet XFree lorsqu'il a changé de licence (et X.org semble bien se porter), etc. Bref, il est probable que les logiciels propriétaires utilisant du code BSD améliorent les projets BSD plus souvent qu'ils ne leur font du tort.
Pour finir, l'auteur (detenteur du copyright) d'un projet GPL peut lui aussi décider de refermer son travail. Au moins pour "ses" fichiers. Mais c'est là aussi très théorique.