Les développeurs de la bibliothèque système GNU C Library (glibc) ont modifié les règles d'acceptation des contributions et de cession des droits d'auteur, annulant l'obligation de transmettre à la Fondation SPI les droits de propriété sur le code. À l'instar des modifications précédemment adoptées dans le projet GCC, la signature de l'accord CLA avec la Fondation SPI dans Glibc est devenus une opération non obligatoire, effectuée à la discrétion du développeur. Les changements de règles, permettant l'acceptation des patchs sans cession de droits à la fondation SPI, entreront en vigueur le 2 août et concerneront toutes les branches de développement disponibles de Glibc, à l'exception du code utilisé via Gnulib en collaboration avec d'autres projets GNU.
En plus de la cession des droits de propriété à la Fondation SPI, les développeurs ont la possibilité de confirmer leur droit de transfert de code au projet Glibc à l'aide du mécanisme du Developer Certificate of Origin (DCO). Conformément au DCO, le suivi de l'auteur est assuré par l'attachement de la ligne « Signed-off-by : nom et email du développeur » à chaque modification. En ajoutant cette signature au patch, le développeur confirme son autorité sur le code transféré et accepte sa distribution dans le cadre du projet ou comme partie du code sous une licence libre. Contrairement aux actions du projet GCC, la décision dans Glibc n'a pas été imposée par le conseil de gestion, mais a été prise après une discussion préalable avec tous les représentants de la communauté.
L'annulation de la signature obligatoire de l'accord avec la Fondation SPI simplifie considérablement l'intégration des nouveaux participants dans le développement et rend le projet indépendant des tendances de la Fondation SPI. Si la signature de l'accord CLA par des participants individuels ne faisait que gaspiller du temps avec des formalités superflues, pour les entreprises et les employés de grandes sociétés, la cession des droits à la Fondation SPI était accompagnée de nombreuses complications juridiques et de validations, qui ne se terminaient pas toujours avec succès.
L'abandon de la gestion centralisée des droits sur le code consolide également les conditions de licence initialement acceptées, car le changement de licence nécessitera désormais le consentement personnel de chaque développeur n'ayant pas transféré ses droits à la Fondation de Logiciels Libres. Le code de Glibc continue d'être fourni sous la licence « LGPLv2.1 ou une version plus récente », ce qui autorise le passage à des versions plus récentes de la LGPL sans accord supplémentaire. Étant donné que les droits sur la majorité du code restent entre les mains de la Fondation de Logiciels Libres, cette organisation continue de jouer le rôle de garant de la diffusion du code Glibc uniquement sous des licences copyleft libres. Par exemple, la Fondation de Logiciels Libres peut bloquer les tentatives d'introduction d'une licence double/commerciale ou de publication de produits propriétaires fermés par un accord séparé avec les auteurs du code.
Parmi les inconvénients de l'abandon de la gestion centralisée des droits sur le code, on note la confusion qui peut survenir dans le traitement des questions liées aux licences. Alors qu'auparavant toutes les réclamations concernant des violations des conditions de licence étaient résolues par l'intermédiaire d'une seule organisation, la gestion des violations, y compris celles non intentionnelles, devient désormais imprévisible et nécessite un accord avec chaque participant individuel. À titre d'exemple, on mentionne la situation avec le noyau Linux, où des développeurs individuels du noyau intentent des poursuites judiciaires, y compris dans le but d'enrichissement personnel.
Source : opennet.ru
