La différence c'est que les licences BSD mettent tout le monde à égalité, pas le CLA Canonical.
Supposons que A est un contributeur majeur au projet LeChat de Canonical (supposons que A et Canonical ait contribué 50% du code chacun) sous GPLv2
A et Canonical ont exactement les mêmes droits dans le cadre de la licence GPLv2 de LeChat
A possède le copyright sur le code qu'il a contribué et peut en faire de qu'il veut (idem pour Canonical)
A cède une licence perpétuelle, irrévocable, transférable et sans royalties à Canonical sur son code (idem pour les brevets possédés par A couvrant le code en question). Canonical fait donc ce qu'il veut de l'ensemble de l'œuvre. Aucune symétrie pour A qui reste limité par la GPLv2 pour la partie du code contribuée par Canonical
Cette asymétrie explique déjà pourquoi bon nombre de sociétés gravitant dans le monde de l'open source sont rebutés à l'idée de collaborer sur des projets Canonical d'autant plus qu'en pratique, elles peuvent mettre plus de ressources que Canonical sur les projets en question.
On a eu le même problème avec le CLA FedoraProject.org et il a été modifié pour que la licence par défaut pour le code soit MIT (les contributeurs peuvent choisir une licence libre acceptable par le projet) et CC-By-SA 3.0 pour tout ce qui n'est pas code, afin de garantir cette symétrie. La plupart des projets initiés par RH évite de devoir requérir ce genre de CLA asymétrique afin d'encourager les contributions externes (personnels ou corporate), par exemple systemd ou libvirt n'en ont pas.
Un exemple à la con: OpenStack exige un CLA similaire (principalement pour des raisons légales), mais il offre une licence Apache 2.0 qui garantit que tout les contributeurs aient les mêmes droits sur l'œuvre, et depuis l'année dernière la gouvernance est partagée par tout les contributeurs. Résultat: ça encourage les contributions externes.
Canonical a décidé que sa couche de compatibilité Amazon pour OpenStack (AWSOME) serait sous Affero GPLv3 + CLA pour les contributeurs. Résultat: personne ne s'est intéressé au projet, les gens ont préféré directement contribuer sur la couche de compatibilité AWS d'OpenStack pourtant bien moins avancée. Ou Deltacloud de RH qui est un projet Apache Top Level qui exige un CLA Apache. On revient donc au problème de l'acteur de confiance, il est plus facile de faire confiance à la Fondation Apache qu'à Red Hat pour céder une licence perpétuelle etc … et la licence est suffisamment permissive pour ne "léser" personne.
[^] # Re: Mouais
Posté par GeneralZod . En réponse au journal Canonical/Ubuntu ou l'allégorie de la grenouille. Évalué à 4.
La différence c'est que les licences BSD mettent tout le monde à égalité, pas le CLA Canonical.
Supposons que A est un contributeur majeur au projet LeChat de Canonical (supposons que A et Canonical ait contribué 50% du code chacun) sous GPLv2
A et Canonical ont exactement les mêmes droits dans le cadre de la licence GPLv2 de LeChat
A possède le copyright sur le code qu'il a contribué et peut en faire de qu'il veut (idem pour Canonical)
A cède une licence perpétuelle, irrévocable, transférable et sans royalties à Canonical sur son code (idem pour les brevets possédés par A couvrant le code en question). Canonical fait donc ce qu'il veut de l'ensemble de l'œuvre. Aucune symétrie pour A qui reste limité par la GPLv2 pour la partie du code contribuée par Canonical
Cette asymétrie explique déjà pourquoi bon nombre de sociétés gravitant dans le monde de l'open source sont rebutés à l'idée de collaborer sur des projets Canonical d'autant plus qu'en pratique, elles peuvent mettre plus de ressources que Canonical sur les projets en question.
On a eu le même problème avec le CLA FedoraProject.org et il a été modifié pour que la licence par défaut pour le code soit MIT (les contributeurs peuvent choisir une licence libre acceptable par le projet) et CC-By-SA 3.0 pour tout ce qui n'est pas code, afin de garantir cette symétrie. La plupart des projets initiés par RH évite de devoir requérir ce genre de CLA asymétrique afin d'encourager les contributions externes (personnels ou corporate), par exemple systemd ou libvirt n'en ont pas.
Un exemple à la con: OpenStack exige un CLA similaire (principalement pour des raisons légales), mais il offre une licence Apache 2.0 qui garantit que tout les contributeurs aient les mêmes droits sur l'œuvre, et depuis l'année dernière la gouvernance est partagée par tout les contributeurs. Résultat: ça encourage les contributions externes.
Canonical a décidé que sa couche de compatibilité Amazon pour OpenStack (AWSOME) serait sous Affero GPLv3 + CLA pour les contributeurs. Résultat: personne ne s'est intéressé au projet, les gens ont préféré directement contribuer sur la couche de compatibilité AWS d'OpenStack pourtant bien moins avancée. Ou Deltacloud de RH qui est un projet Apache Top Level qui exige un CLA Apache. On revient donc au problème de l'acteur de confiance, il est plus facile de faire confiance à la Fondation Apache qu'à Red Hat pour céder une licence perpétuelle etc … et la licence est suffisamment permissive pour ne "léser" personne.