mais j’atteins mes limites, surtout s'il y a des distinctions à faire entre code source et version compilée ...
bin, c'est pourtant de là qu'il faut partir et remonter la chaîne...
qu'est-ce qui est distribué : généralement un exécutable
compilé en statique ?
compilé en dynamique ?
code interprété ?
la licence s'applique à la distribution : s'il y a de la GPL en amont,
la résultante sera en GPL pour du compilé en statique (puisque ça inclus de la GPL)
la résultante ne sera pas forcément en GPL pour du compilé en dynamique
pour du code interprété, ça dépend...
et la GPL induit de fournir le code source amont (cf. plus bas)
pour le code :
si tu modifies un fichier source GPL, il reste GPL
si tu modifies un fichier source BSD ou MIT et que tu y ajoutes du code provenant d'un fichier sous GPL, tu gardes les en-têtes BSD ou MIT (tu ne peux pas les enlever) et tu ajoutes l'en-tête GPL et au final le fichier sera sous GPL, vu que ça devient un travail dérivé de la GPL
si tu modifies un fichier source BSD ou MIT, sans ajouter de code GPL, pas besoin de citer la GPL...
pour les licences s'appliquant au code source :
c'est le paragraphe suivant de https://www.gnu.org/licenses/gpl-3.0.fr.html qui t'intéresse :
The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.
pour moi, si c'est dans des fichiers différents, ça peut avoir des licences différentes (mais IANAL) tant qu'elles sont compatibles entre elles. C'est le résultat (donc le binaire) qui héritera de la licence prévalente (dominante si tu préfères).
forcément, si tu inclus du code GPL dans un de tes fichiers source, ce fichier source est sous GPL (difficile de dire que ce n'est pas un travail dérivé si tu ne peux pas mettre le code GPL dans son propre fichier... sinon autant le faire et comme ça chaque fichier a bien sa propre licence).
l'idée c'est que les fichiers inclus soient sous une licence permissive ou la LGPL (ça simplifie la chaîne d'héritage des licences...) et que le programme principal porte la licence proéminente retenue.
si tu ne veux pas diffuser en GPL le résultat complet, tu mets dans des binaires différents ce qui se base sur de la GPL et ce qui se base sur les licences de ton choix. T'auras des portions en GPL (celles dérivées) et d'autres portions en non GPL.
après, tu as des outils de recensement des licences utilisées dans tes projets (conformité toussa), je ne sais pas s'il y a des fonctionnalités proposant un arbre des dépendances :/
cf. tag fossology et https://github.com/fossology/fossology/releases
[^] # Re: pros / cons
Posté par BAud (site web personnel) . En réponse au journal GPL vs MIT, que choisir ?. Évalué à 5.
bin, c'est pourtant de là qu'il faut partir et remonter la chaîne...
qu'est-ce qui est distribué : généralement un exécutable
la licence s'applique à la distribution : s'il y a de la GPL en amont,
et la GPL induit de fournir le code source amont (cf. plus bas)
pour le code :
pour les licences s'appliquant au code source :
c'est le paragraphe suivant de https://www.gnu.org/licenses/gpl-3.0.fr.html qui t'intéresse :
The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.
pour moi, si c'est dans des fichiers différents, ça peut avoir des licences différentes (mais IANAL) tant qu'elles sont compatibles entre elles. C'est le résultat (donc le binaire) qui héritera de la licence prévalente (dominante si tu préfères).
forcément, si tu inclus du code GPL dans un de tes fichiers source, ce fichier source est sous GPL (difficile de dire que ce n'est pas un travail dérivé si tu ne peux pas mettre le code GPL dans son propre fichier... sinon autant le faire et comme ça chaque fichier a bien sa propre licence).
l'idée c'est que les fichiers inclus soient sous une licence permissive ou la LGPL (ça simplifie la chaîne d'héritage des licences...) et que le programme principal porte la licence proéminente retenue.
si tu ne veux pas diffuser en GPL le résultat complet, tu mets dans des binaires différents ce qui se base sur de la GPL et ce qui se base sur les licences de ton choix. T'auras des portions en GPL (celles dérivées) et d'autres portions en non GPL.
après, tu as des outils de recensement des licences utilisées dans tes projets (conformité toussa), je ne sais pas s'il y a des fonctionnalités proposant un arbre des dépendances :/
cf. tag fossology et https://github.com/fossology/fossology/releases