Personnellement je pense que, derrière ce terme de « viralité », il y a quelque part une petite envie de revanche, ou a minima de règlement de compte.
D'ailleurs, tu n'es probablement pas sans savoir que ton analogie est douteuse, car si tu ne considères que « faire #include "truc.h" », tu as raison de considérer que « notre travail n'est pas une modification de cette bibliothèque ».
Scoop : tu peux même publier ton source contenant ton include, sans aucune préoccupation vis à vis de la licence du projet truc (GPL ou non), et sans aucune inquiétude de quelque sorte.
Mais revenons à la GPL. On peut étudier la justesse de l'équité de la relation que tente d'établir la GPL entre un « auteur fournisseur » et un « auteur usager » d'un code. Et dans ce cas ce n'est certainement pas la quantité d'effort fournie par l'auteur usager qui nous indique si le programme engendré sera « plutôt » une œuvre dérivée ou « plutôt » une œuvre originale. Et donc retenir cet aspect pour juger de si cette relation est équitable ou non me semble fallacieux.
Je ne connais pas de métrique parfaite pour ça (et je suppose que ça n'existe pas) mais je pense qu'il faut partir de l'effort de substitution.
Si pour mener son projet à bien l'auteur usager devait réécrire le projet truc depuis zéro, on peut imaginer à la louche trois situations :
d'hérédité : cas où l'auteur usager est plutôt consommateur du code initial car l'utiliser a permit de réduire très fortement le temps de développement de son projet ; moralement on sent que le programme engendré est une œuvre dérivée de l'original ;
de réciprocité : cas où l'auteur usager apporte une grosse pierre à l'édifice ; à part comparable avec l'auteur fournisseur ; moralement on sent que le programme engendré reste une œuvre dérivée (même si fort dérivée) de l'original ;
de « viralité » : cas où l'auteur usager a mené l'essentiel de l'effort requis ; l'apport de l'auteur fournisseur étant largement dilué ; et moralement on sent que le programme engendré est une œuvre originale.
Concernant la situation qu'on pourrait qualifier de « viralité », il faut avoir à l'esprit que l'auteur fournisseur a fait une offre publique de licence, engageant la réciprocité, indépendamment de savoir qui en ferait quoi. L'auteur usager à accepté l'offre et en a profité mais est libre de ne pas le faire. Si l'auteur usager se sent lésé par ce contrat dans cette situation, il lui est de fait facile de le rompre ; puisque la part considérée du logiciel fournie est minimale ; et que sa substitution peut se faire sans grand effort.
Ainsi, jamais la GPL ne force la main de personne d'une façon qualifiable de virale, parasite, pandémique ou autre. Et qualifier la GPL de « virale » parce que des personnes de mauvaises fois peuvent se sentir lésés d'une offre qu'ils n'ont aucune obligation d'accepter ... ça sent un peu l'arnaque intellectuelle.
PS: Perso je développe en python/django. L'ordre de grandeur de mon apport sur des projets réels, c'est 1 pour 50 entre juste mon repos et juste mon virtualenv contenant le framework et quelques apps. Je fais l'impasse sur le code de cpython et les nombreuses bibliothèques système activée par ailleurs... En vrai, je pense que nous sommes des nains consommateurs de logiciels juchés sur les épaules des géantes communautés.
[^] # Re: Sémantique toxique
Posté par Pol' uX (site web personnel) . En réponse au journal SSPL: All your service are belong to us. Évalué à 5.
Personnellement je pense que, derrière ce terme de « viralité », il y a quelque part une petite envie de revanche, ou a minima de règlement de compte.
D'ailleurs, tu n'es probablement pas sans savoir que ton analogie est douteuse, car si tu ne considères que « faire
#include "truc.h"», tu as raison de considérer que « notre travail n'est pas une modification de cette bibliothèque ».Scoop : tu peux même publier ton source contenant ton include, sans aucune préoccupation vis à vis de la licence du projet truc (GPL ou non), et sans aucune inquiétude de quelque sorte.
Mais revenons à la GPL. On peut étudier la justesse de l'équité de la relation que tente d'établir la GPL entre un « auteur fournisseur » et un « auteur usager » d'un code. Et dans ce cas ce n'est certainement pas la quantité d'effort fournie par l'auteur usager qui nous indique si le programme engendré sera « plutôt » une œuvre dérivée ou « plutôt » une œuvre originale. Et donc retenir cet aspect pour juger de si cette relation est équitable ou non me semble fallacieux.
Je ne connais pas de métrique parfaite pour ça (et je suppose que ça n'existe pas) mais je pense qu'il faut partir de l'effort de substitution.
Si pour mener son projet à bien l'auteur usager devait réécrire le projet truc depuis zéro, on peut imaginer à la louche trois situations :
Concernant la situation qu'on pourrait qualifier de « viralité », il faut avoir à l'esprit que l'auteur fournisseur a fait une offre publique de licence, engageant la réciprocité, indépendamment de savoir qui en ferait quoi. L'auteur usager à accepté l'offre et en a profité mais est libre de ne pas le faire. Si l'auteur usager se sent lésé par ce contrat dans cette situation, il lui est de fait facile de le rompre ; puisque la part considérée du logiciel fournie est minimale ; et que sa substitution peut se faire sans grand effort.
Ainsi, jamais la GPL ne force la main de personne d'une façon qualifiable de virale, parasite, pandémique ou autre. Et qualifier la GPL de « virale » parce que des personnes de mauvaises fois peuvent se sentir lésés d'une offre qu'ils n'ont aucune obligation d'accepter ... ça sent un peu l'arnaque intellectuelle.
PS: Perso je développe en python/django. L'ordre de grandeur de mon apport sur des projets réels, c'est 1 pour 50 entre juste mon repos et juste mon virtualenv contenant le framework et quelques apps. Je fais l'impasse sur le code de cpython et les nombreuses bibliothèques système activée par ailleurs... En vrai, je pense que nous sommes des nains consommateurs de logiciels juchés sur les épaules des géantes communautés.
Adhérer à l'April, ça vous tente ?