Pas de problème, ma réponse était peut-être inutilement agressive par contre.
J'ai bêtement assumé que la version aurait du être mentionné dans le README :/
Effectivement, ça aurait pu être le cas, mais souvent il faut aller voir directement dans les sources, car la licence d'un projet « au complet » n'est souvent pas si facile que ça à déterminer : on inclus souvent des bouts de code sous d'autres licence, plus permissives, et c'est bien de le mentionner. La FSF dans son guide d'utilisation de la GPL précise bien qu'il faut ajouter les éléments de licence « dans chaque fichier source ». Autre exemple, Debian fait bien attention de mentionner (de manière lisible par une machine !) les licences de chaque fichier d'un paquet : http://dep.debian.net/deps/dep5/.
Ces précautions sont dues, je pense, au fait qu'on peut facilement trimbaler un fichier à droite à gauche comme « unité de code », et que de noter sa licence dans un en-tête dans le fichier est le moyen le plus pratique pour ne pas perdre ces informations.
De même, comme on le voit dans ce thread sur la confusion sur le passage d'une licence à une autre, ajouter un patch GPLv3+ à un projet GPLv2+ ne transforme pas — d'une certaine manière — d'un coup « tout le projet » en GPLv3+ : toute modification du projet qui n'est pas déterminée comme un travail dérivé du patch en question peut tout à fait continuer à exister sous GPLv2+. Tout comme un bout de code BSD n'est pas « transformé » en GPL s'il est inclus dans un projet GPL : si on peut faire des modifications à ce bout de code en particulier, de manière indépendante du projet, et qu'on souhaite qu'il reste en BSD, on peut. Alors oui, ça n'est pas évident comme nuance, mais cela n'est pas dû à la GPL ni à la FSF, mais au droit d'auteur et au principe de travail dérivé, choses qui ne sont pas évidentes à appréhender. La BSD est plus simple non pas par ses clauses réduites, mais de part le fait qu'elle ne se soucie pas des travaux dérivés d'un code BSD, ce qui effectivement simplifie les implications légales.
[^] # Re: Pseudo drama juridique
Posté par benoar . En réponse à la dépêche Enemy Territory: Legacy, en résistance. Évalué à 3.
Pas de problème, ma réponse était peut-être inutilement agressive par contre.
Effectivement, ça aurait pu être le cas, mais souvent il faut aller voir directement dans les sources, car la licence d'un projet « au complet » n'est souvent pas si facile que ça à déterminer : on inclus souvent des bouts de code sous d'autres licence, plus permissives, et c'est bien de le mentionner. La FSF dans son guide d'utilisation de la GPL précise bien qu'il faut ajouter les éléments de licence « dans chaque fichier source ». Autre exemple, Debian fait bien attention de mentionner (de manière lisible par une machine !) les licences de chaque fichier d'un paquet : http://dep.debian.net/deps/dep5/.
Ces précautions sont dues, je pense, au fait qu'on peut facilement trimbaler un fichier à droite à gauche comme « unité de code », et que de noter sa licence dans un en-tête dans le fichier est le moyen le plus pratique pour ne pas perdre ces informations.
De même, comme on le voit dans ce thread sur la confusion sur le passage d'une licence à une autre, ajouter un patch GPLv3+ à un projet GPLv2+ ne transforme pas — d'une certaine manière — d'un coup « tout le projet » en GPLv3+ : toute modification du projet qui n'est pas déterminée comme un travail dérivé du patch en question peut tout à fait continuer à exister sous GPLv2+. Tout comme un bout de code BSD n'est pas « transformé » en GPL s'il est inclus dans un projet GPL : si on peut faire des modifications à ce bout de code en particulier, de manière indépendante du projet, et qu'on souhaite qu'il reste en BSD, on peut. Alors oui, ça n'est pas évident comme nuance, mais cela n'est pas dû à la GPL ni à la FSF, mais au droit d'auteur et au principe de travail dérivé, choses qui ne sont pas évidentes à appréhender. La BSD est plus simple non pas par ses clauses réduites, mais de part le fait qu'elle ne se soucie pas des travaux dérivés d'un code BSD, ce qui effectivement simplifie les implications légales.