Cette clause d'absence de garantie est à mettre en balance avec le coût du logiciel. S'il est avéré que l'entreprise l'a obtenu à frais réduits, voire pratiquement nuls, un juge peut décider que la clause est acceptable car l'auteur n'a pas été explicitement payé pour son travail par ce "client".
A contrario, un fournisseur de services peut s'engager à fournir une garantie sur le logiciel, alors que l'auteur original n'en donne pas, et il n'est pas exclu qu'il soit tenu responsable en cas de problèmes.
Evidemment, cette clause reste problématique, et au final, c'est l'interprétation du juge qui importera.
Le vrai problème de la GPL réside dans sa viralité forte, qui peut être vue comme une restriction du droit d'auteur d'autres personnes, en extrapolant sur la notion d'oeuvre dérivée. Ainsi, lier du code à une librairie en GPL ne produit pas forcément du code dérivé au sens juridique du terme, car l'expression originale de l'auteur du programme n'est pas en tant que telle basée sur la librairie (qui n'est utilisée que comme boîte noire pour traduire certains concepts). L'absence de jurisprendence en la matière rend cependant la question difficile, et si la FSF considère qu'il y a bien production d'oeuvre dérivée (d'où l'existence de la LGPL), même les juristes américains divergent sur la question. Ainsi, l'avocat de l'Open Source Initiative (OSI), L. Rosen, affiirme clairement qu'il n'y pas alors production d'oeuvre dérivée. A titre d'exemple, devrions-nous considérer qu'utiliser la librairie standard C pour ses entrées-sorties signifierait qu'on produit une oeuvre dérivée de celle-ci? Un juge pourrait invalider cette clause, mais garder le reste de la licence valide (en particulier, le code de la librairie doit rester ouvert et distribuable, avec ou sans modifications).
[^] # Re: À Munich, la GPL a gagné
Posté par slashbin . En réponse à la dépêche À Munich, la GPL a gagné. Évalué à 1.
A contrario, un fournisseur de services peut s'engager à fournir une garantie sur le logiciel, alors que l'auteur original n'en donne pas, et il n'est pas exclu qu'il soit tenu responsable en cas de problèmes.
Evidemment, cette clause reste problématique, et au final, c'est l'interprétation du juge qui importera.
Le vrai problème de la GPL réside dans sa viralité forte, qui peut être vue comme une restriction du droit d'auteur d'autres personnes, en extrapolant sur la notion d'oeuvre dérivée. Ainsi, lier du code à une librairie en GPL ne produit pas forcément du code dérivé au sens juridique du terme, car l'expression originale de l'auteur du programme n'est pas en tant que telle basée sur la librairie (qui n'est utilisée que comme boîte noire pour traduire certains concepts). L'absence de jurisprendence en la matière rend cependant la question difficile, et si la FSF considère qu'il y a bien production d'oeuvre dérivée (d'où l'existence de la LGPL), même les juristes américains divergent sur la question. Ainsi, l'avocat de l'Open Source Initiative (OSI), L. Rosen, affiirme clairement qu'il n'y pas alors production d'oeuvre dérivée. A titre d'exemple, devrions-nous considérer qu'utiliser la librairie standard C pour ses entrées-sorties signifierait qu'on produit une oeuvre dérivée de celle-ci? Un juge pourrait invalider cette clause, mais garder le reste de la licence valide (en particulier, le code de la librairie doit rester ouvert et distribuable, avec ou sans modifications).