Explications et FAQ sur l'exception de la bibliothèque d'exécution de GCC

Introduction

Le 29 juin 2007, la Free Software Foundation a publié la GPLv3. Cette dernière a immédiatement été adoptée par quinze projets GNU, et d'autres ont fait la migration dans les mois qui ont suivi. La plus grande partie du code de GCC est passé à la nouvelle licence avec la version 4.2.2 et nous sommes sur le point de terminer le processus.

Les licences de certaines bibliothèques accompagnant GCC n'ont pas encore changé. Or ces bibliothèques sont utilisées automatiquement par le code objet produit par GCC. C'est pourquoi, si elles étaient simplement distribuées sous les termes de la GPL, tout le code objet produit par GCC devrait être distribué sous les mêmes termes. Cependant, la FSF a décidé il y a longtemps de permettre aux développeurs d'utiliser GCC pour compiler n'importe quel programme, quelle que soit sa licence. Développer du logiciel non libre n'est pas bon pour la société et nous n'avons aucune obligation de rendre cela plus facile. Nous avons décidé de le permettre parce que l'interdire semblait susceptible de se retourner contre nous, et parce que se servir de ces petites bibliothèques pour limiter l'usage de GCC aurait été aussi efficace que de demander à la queue de remuer le chien.¹

Par conséquent, ces bibliothèques ont toujours eu des exceptions de licence qui permettent aux gens de distribuer sous n'importe quelle licence le code objet produit par GCC. Nous faisons actuellement passer ces bibliothèques sous GPLv3 et nous mettons à jour leurs exceptions. Notre politique n'a pas changé fondamentalement ; la nouvelle licence est conçue pour permettre tous les usages de GCC qui étaient permis auparavant. Cependant, nous avons décidé de profiter de l'occasion pour mettre à jour l'exception afin de remplir trois objectifs :

• Tirer parti des nouvelles clauses de la GPLv3. La GPLv3 présente beaucoup de nouvelles clauses qui bénéficieront à tous les logiciels ; par exemple l'article 7, qui établit un cadre pour donner des exceptions de licence. Pour que GCC puisse profiter au mieux de la GPLv3, nous avons besoin de mettre à jour l'exception pour prendre en compte ces nouvelles clauses et travailler dans le cadre des paramètres de l'article 7.

• Jeter les bases d'une infrastructure de greffons [plugins] pour GCC. Depuis quelque temps déjà, les développeurs de GCC ont envisagé d'y ajouter un mécanisme de greffon. Cela faciliterait la collaboration avec d'autres sur ce projet, et accélérerait le développement de nouvelles techniques de compilation pour GCC. Cependant, certains ont aussi exprimé leur crainte de voir des développeurs peu scrupuleux écrire des greffons qui feraient appel à des logiciels privateurs² pour transformer le code compilé – ce qui aboutirait en pratique à créer des extensions privatrices pour GCC et irait à l'encontre des objectifs de la GPL. La mise à jour de l'exception empêche ces abus, et fait que l'équipe de GCC se réjouit à l'avance du développement de greffons.

• Homogénéiser les exceptions sur l'ensemble du code de GCC. Au fil des années, à mesure que de nouveaux fichiers ajoutés à GCC avaient besoin d'être couverts par cette exception, nous avons revu et mis à jour sa formulation pour aider à la rendre plus claire et répondre à de nouvelles préoccupations. Il en est résulté, dans GCC, de nombreuses rédactions de l'exception qui accordent les mêmes permissions de base. Désormais, tous ces fichiers vont pouvoir utiliser le texte unique que nous avons rédigé pour la nouvelle exception, ce qui facilitera l'examen juridique du code.

Comme avec la GPLv3, nous nous sommes efforcés d'écouter les diverses préoccupations des usagers au cours de l'étude préliminaire, puis d'y répondre de manière adéquate. En fin de compte, cette étape nous a pris plus d'un an. La Free Software Foundation et le GCC Steering Committee (Comité de pilotage de GCC) voudraient remercier Richard Fontana, Bradley Kuhn, et Karen Sandler du Software Freedom Law Center (Centre juridique du logiciel libre) pour leur travail acharné et leur assistance dans la mise au point de cette exception. Les modifications détaillées ici vont renforcer la communauté de GCC ; nous attendons avec impatience les développements du compilateur qu'elles rendront possibles.

GCC joue un tel rôle dans la vie des développeurs que nous nous attendons à une multitude de questions sur ces modifications. Nous voulons faire en sorte qu'elles soient traitées. Nous répondons ci-après à des préoccupations spécifiques que nous pensons être celles des utilisateurs. Si vous avez des questions sur la nouvelle exception qui ne sont pas mentionnées ici, n'hésitez pas à nous contacter à <[email protected]>.

Comment l'exception fonctionne

La permission dont vous avez besoin – pour transmettre le code objet provenant de ces bibliothèques GCC sous la licence de votre propre projet – est essentiellement contenue dans l'article 1 :

You have permission to propagate a work of Target Code formed by combining the Runtime Library with Independent Modules, even if such propagation would otherwise violate the terms of GPLv3, provided that all Target Code was generated by Eligible Compilation Processes. You may then convey such a combination under terms of your choice, consistent with the licensing of the Independent Modules.

Traduction non officielle :

Vous avez la permission de propager une création constituée de « code cible » obtenu en combinant la « bibliothèque d'exécution » avec des « modules indépendants », même dans des cas où, sans cette exception, sa propagation violerait les termes de la GPLv3, à condition que tout le code cible soit généré par des « processus de compilation éligibles ». Vous avez alors la permission de transférer une telle combinaison sous des termes de votre choix, compatibles avec les licences des modules indépendants.

Cet article utilise beaucoup de termes précis dont les significations spécifiques font partie intégrante du fonctionnement de l'exception. Nous allons maintenant examiner comment ces termes s'appliquent aux scénarios courants.

Quand vous écrivez votre logiciel, il consiste en un ensemble de fichiers de code source. Chaque fichier est un « module indépendant » tant qu'il ne contient aucun code source des bibliothèques de GCC.

Quand vous compilez ces fichiers de code source, ils passent habituellement par une série d'étapes : génération du code source, passage au préprocesseur, compilation dans un code de bas niveau, assemblage, et liaison. Toutes ces étapes ne feront pas partie de tous les projets, cela dépend du langage utilisé et de sa structure, mais elles se suivront toujours dans cet ordre ; en utilisant GCC, vous passez toujours par l'étape de compilation d'un code de haut niveau en un langage de bas niveau comme l'assembleur ou le bytecode Java. C'est au cours de cette phase que GCC combine ou lie votre propre code avec les bibliothèques de GCC. Nous appelons cette phase « processus de compilation ». On obtient en sortie ce que nous appelons le « code cible », dans la mesure où ce code n'est pas utilisé comme représentation intermédiaire par le compilateur et ne sert pas non plus à créer une telle représentation intermédiaire.

Pour profiter de cette permission, le processus de compilation que vous utilisez pour créer le code cible doit être « éligible », ce qui signifie qu'il ne doit pas impliquer à la fois GCC et du logiciel incompatible avec la GPL. Il est important de se rappeler que le processus de compilation démarre quand on donne à GCC du code de haut niveau à traiter, quel qu'il soit, et se termine dès que GCC a généré quelque chose qui peut être considéré comme du code cible. C'est pourquoi, pourvu que GCC ne produise pas de représentation intermédiaire sous une forme utilisable, votre processus de compilation peut encore être éligible même si vous utilisez GCC en conjonction avec des assembleurs, des linkers, ou des générateurs de source de haut niveau incompatibles avec la GPL : ces programmes ne sont pas impliqués dans le processus de compilation tel qu'il est défini ici. La seule phase où vous ne pouvez pas utiliser de logiciel incompatible avec la GPL en complément de GCC est celle qui correspond au travail de base du compilateur.

Donc si vous utilisez GCC seul ou avec des fonctionnalités supplémentaires compatibles avec la GPL, il s'agit d'un processus de compilation éligible. Si vous utilisez uniquement des outils incompatibles avec la GPL, c'est également un processus de compilation éligible (il n'est pas rare de voir des gens qui compilent des logiciels pour GNU/Linux faire des liaisons avec les bibliothèques de GCC même s'ils utilisent un compilateur différent). Cependant, si vous utilisiez GCC et du logiciel incompatible avec la GPL, conjointement, au cours du processus de transformation du code de haut niveau en code de bas niveau, ce ne serait pas un processus de compilation éligible. Cela arriverait par exemple si vous utilisiez GCC avec un greffon privateur.

Pourvu que vous utilisiez un processus de compilation éligible, vous avez la permission de prendre le code cible généré par GCC et de le propager « sous les termes de votre choix ».

Si vous aviez utilisé du logiciel incompatible avec la GPL conjointement avec GCC au cours du processus de compilation, vous ne pourriez pas profiter de cette permission. Comme tout le code objet généré par GCC est dérivé de ces bibliothèques sous GPL, cela signifie que vous seriez obligé de respecter les termes de la GPL en propageant tout ou partie de ce code objet. Vous ne pourriez pas utiliser GCC pour développer votre propre logiciel incompatible avec la GPL.

Foire aux questions

J'utilise une version standard de GCC (fournie par exemple par la FSF ou par mon système d'exploitation) pour compiler un logiciel incompatible avec la GPL. Comment ce changement m'affecte-t-il ?

Il ne devrait pas du tout vous affecter. À moins que vous n'ayez configuré GCC pour sortir des représentations intermédiaires, ce qui est rare, la nouvelle exception (de même que les anciennes) est conçue pour faire en sorte que vous n'ayez aucune obligation de licence lorsque vous faites cela.

Qui ce changement affecte-t-il ?

Il ne devrait affecter aucun des utilisateurs actuels de GCC. Les changements de politique ont pour seul but d'empêcher les développeurs d'apporter à GCC certaines modifications qui seront possibles à l'avenir. La FSF a travaillé en étroite collaboration avec les développeurs de GCC pour en apprendre plus sur ses différentes utilisations dans la pratique actuelle, et faire en sorte que toutes ces activités puissent continuer avec la nouvelle exception.

Pour compiler mon programme, j'utilise GCC conjointement avec des préprocesseurs privateurs et/ou des générateurs de source. Est-ce que je peux profiter de cette exception ?

Oui. Le processus de compilation peut démarrer avec « n'importe quel code représenté entièrement dans un langage de haut niveau, non intermédiaire ». Cela comprend le code généré par un préprocesseur ou autre logiciel privateur. Le processus de compilation proprement dit n'implique pas dans ce cas de logiciel privateur ; ce processus répond aux critères d'éligibilité, et donc l'exception s'applique à ce programme.

J'utilise GCC conjointement avec des assembleurs et/ou des linkers privateurs pour compiler mon programme. Est-ce que je peux tout de même profiter de l'exception ?

Oui. Le processus de compilation se termine quand le compilateur génère le code cible, ce qui inclut les résultats « appropriés à un traitement ultérieur par un assembleur, un chargeur, un linker ou une phase d'exécution » ; en d'autres termes, le processus de compilation est terminé quand vous avez le code assembleur ou les fichiers objet non liés provenant de GCC ; il ne fait donc pas intervenir de logiciel privateur. Il répond aux critères d'éligibilité, par conséquent l'exception s'applique à ce programme.

J'utilise GCC pour compiler certaines parties de mon programme, et un compilateur privateur pour compiler le reste. Les morceaux sont combinés par la suite, au cours des phases d'assemblage et de liaison. Est-ce que je peux tout de même profiter de l'exception ?

Oui. Dans ce cas, chaque module indépendant est transformé en code cible par un processus de compilation éligible. Bien que les différents modules soient traités par des processus différents, l'exception est toujours applicable à ce programme.

J'utilise pour compiler mon programme une chaîne d'outils de compilation privateurs sans aucune partie de GCC, et je le lie avec libstdc++. Mon programme lui-même ne comporte aucun code de la bibliothèque d'exécution, contrairement à un programme compilé avec GCC et libgcc. Est-ce que je peux tout de même profiter de l'exception ?

Oui. Bien que la combinaison de libgcc avec du code objet généré par GCC soit probablement la manière la plus courante d'utiliser l'exception, ni les clauses de la GPL, ni celles de l'exception de la bibliothèque d'exécution de GCC (GCC RLE), ne font de distinction entre liaison statique, liaison dynamique, et autres méthodes pour combiner du code. Les mêmes permissions sont à votre disposition, sous les mêmes termes, quelle que soit la méthode que vous utilisez.

Notez que si vous distribuez libstdc++ en tant que bibliothèque indépendante, vous aurez besoin de respecter les termes de la GPL. Par exemple, si vous distribuez la bibliothèque elle-même sous forme de code objet, vous devrez fournir le code source à vos destinataires en utilisant une des méthodes énumérées dans l'article 6 de la GPLv3. Mais dans la mesure où votre propre programme est éligible à la GCC RLE, les termes de la GPL ne s'appliquent pas à lui.

Pourquoi la représentation intermédiaire du compilateur est-elle exclue de la définition du « code cible » ?

Quand nous avons envisagé pour la première fois d'ajouter une infrastructure de greffons à GCC, un de nos soucis majeurs était la possibilité que quelqu'un écrive un greffon qui sauvegarderait simplement sur disque les structures de données de compilation de bas niveau internes à GCC. Une fois ceci fait, d'autres logiciels auraient pu optimiser ou améliorer d'autre façon ce code, sans être directement connectés à GCC. Il aurait pu nous être difficile d'argumenter que ces programmes devaient être soumis au copyleft de la GPL, aussi nous voulions décourager ce type de montage.

Nous faisons cela en excluant de telles sorties de données de la définition du code cible. Dans ces conditions, même si quelqu'un écrit un greffon qui sauvegarde cette information sur disque, tout programme qui modifie les structures avant que GCC ne sorte le code cible sous forme utilisable sera impliqué dans le processus de compilation. Si ce programme est privateur, l'exception ne sera applicable à aucun des logiciels qu'il aura contribué à compiler ; le code objet créé finalement par GCC devra être distribué sous les termes de la GPL.

Si j'écris du code en langage assembleur, puis-je le combiner avec un autre code objet compilé normalement et profiter tout de même de l'exception ?

Oui, pourvu que tout le code objet ait été compilé par un processus de compilation éligible. Le processus qui consiste à faire traiter par un assembleur du code écrit à la main en langage assembleur est un processus de compilation, puisqu'il « transforme du code représenté entièrement dans [un] langage[] non intermédiaire[] conçu[] pour l'écriture de code par l'homme… en code cible ».

Quelles bibliothèques la GCC RLE couvre-t-elle ?

La GCC RLE couvre tout fichier qui a dans ses en-têtes de licence un avis déclarant que l'exception s'applique. Cela comprend libstdc++, libfortran, libgomp, libdecnumber, libgcov et les autres bibliothèques distribuées avec GCC.

Est-ce que Classpath va utiliser cette nouvelle exception ?

Bien que l'exception actuelle de Classpath ait un objectif similaire, nous ne la mettons pas à jour tout de suite. Étant donné les développements récents dans la communauté Java du logiciel libre, les politiques de licence de Classpath ont des priorités différentes de celles des autres bibliothèques de GCC et nous sommes en train de les évaluer séparément.