Il y a un an et demi, 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é. Ces bibliothèques sont automatiquement utilisées 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 se serait probablement retourné contre nous, et parce que se servir de ces petites bibliothèques pour limiter l'usage de GCC, c'était comme si la queue remuait le chien.1
Par conséquent, ces bibliothèques ont toujours eu des exceptions de licence qui permettent aux gens de distribuer le code objet produit par GCC sous n'importe quelle licence. Nous faisons actuellement migrer ces bibliothèques vers la 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 la section 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 la section 7.
Jeter les bases d'une infrastructure de plugins pour GCC. Depuis quelques temps déjà, les développeurs de GCC ont envisagé d'y ajouter un framework pour les plugins. 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 plugins qui feraient appel à des logiciels privateurs2 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 plugins.
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 un même texte que nous avons préparé, ce qui facilitera l'examen juridique du code.
De même qu'avec la GPLv3, nous avons fait notre possible, pendant l'étude préliminaire, pour écouter les diverses préoccupations des usagers et 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 aide à propos de cette exception. Les modifications détaillées ici vont renforcer la communauté de GCC, et nous attendons avec impatience les développements du compilateur qu'elles rendront possible.
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 aux 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 à <licensing@fsf.org>.
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 pour l'essentiel contenue dans la section 2 :
Vous avez la permission de propager une œuvre contenant du « code cible » [Target Code] formé en combinant la « bibliothèque d'exécution » [Runtime Library] avec des « modules indépendants » [Independent Modules], même si cette propagation viole par ailleurs les termes de la GPLv3, pourvu que tout le code cible soit généré par des « processus de compilation éligibles » [Eligible Compilation Processes]. 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.
Cette section utilise beaucoup de termes précis, et leurs 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, ils 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 de code source, passage au préprocesseur, compilation dans un code de bas niveau, assemblage, et liaison. Tous les projets ne suivent pas toutes ces étapes, cela dépend du langage que vous utilisez 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 code 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 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 ou ne sert pas à 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 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 plugin 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.
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.
Il ne devrait affecter aucun des utilisateurs actuels de GCC. Les seuls changements de politique ont pour 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 ces activités puissent continuer avec la nouvelle 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 peut donc être qualifié d'éligible, et l'exception peut lui être appliquée.
Oui. Le processus de compilation se termine quand le compilateur génère le code cible, y compris les résultats appropriés à un traitement ultérieur par un assembleur, un chargeur, un linker et/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 conditions d'éligibilité, par conséquent l'exception peut s'appliquer à ce programme.
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.
Oui. Bien que la manière la plus courante d'utiliser l'exception soit de combiner libgcc avec du code objet généré par GCC, ni la GPL, ni l'exception de la bibliothèque d'exécution de GCC ne font la distinction entre liaison statique, liaison dynamique, et autres méthodes pour combiner du code dans ces conditions. 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 la section 6 de la GPLv3. Mais dans la mesure où votre propre programme est éligible à l'exception de la bibliothèque d'exécution de GCC, les termes de la GPL ne s'appliquent pas à lui.
Quand nous avons envisagé pour la première fois d'ajouter une infrastructure de plugin à GCC, un de nos soucis majeurs était la possibilité que quelqu'un écrive un plugin 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 les arrangements de cette sorte.
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 plugin 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 logiciel qu'il aura contribué à compiler ; le code objet créé finalement par GCC devra être distribué sous les termes de la GPL.
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 ».
L'exception de la bibliothèque d'exécution de GCC couvre tout fichier qui a dans ses en-têtes de licence un avis déclarant que l'exception s'applique. Cela inclut libstdc++, libfortran, libgomp, libdecnumber, libgcov, et les autres bibliothèques distribuées avec GCC.
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.