Suite à un message sur Framasoft, j'ai rédigé la réaction suivante. Il s'agissait de répondre à l'affirmation « l'art n'est pas libre tant que l'on n'autorise pas les modifications, car la clause ND est une discrimination, une volonté de garder le contrôle, tandis que les développeurs de logiciels libres s'en passent bien, eux ! ».
J'ai voulu faire un peu le point (de manière pas très organisée) entre les différences dans les processus de création entre art et logiciel.
Hop, je cite :
Pour commencer, et pour tâcher d'être pragmatique, ce qui autorise un auteur à restreindre l'utilisation de son œuvre, c'est la propriété intellectuelle. Celle-ci fait partie du contrat social. Elle n'est pas « naturelle » ou « évidente », mais c'est peut-être beaucoup demander aux artistes comme aux développeurs de devoir se justifier moralement de leur utilisation de la propriété intellectuelle.leviathan a écrit :Une deuxième chose est la différence de mentalité existant entre les "artistes" et les "développeurs". En effet, j'ai l'impression en lisant, ça et là, les argumentaires qui font l'éloge des CC avec clauses que j'appelle discriminatoire (NC, ND en particulier) que les "artistes" pensent être les seuls à mettre leur personnalité dans leurs créations ce qui les autoriseraient afin de ne pas perdre leur personnalité à restreindre l'utilisation de leurs oeuvres.
Ensuite, effectivement un développeur peut exprimer sa personnalité à travers un logiciel. Mais c'est rarement le but premier du logiciel. Le logiciel n'est pas qu'un outil, mais c'est généralement sa fonction première. Le programmeur code en visant cette fonction. L'artiste, lui… eh bien on peut difficilement trop généraliser, mais globalement il y a fondamentalement un désir de s'exprimer qui dépasse le simple divertissement. Même si, là aussi, il y a des œuvres de divertissement.
Je prendrais plutôt les choses autrement. Plutôt que de demander « Comment justifiez-vous le fait de restreindre l'utilisation de vos œuvres ? », je demanderais plutôt « Que pouvez-vous gagner à ne pas la restreindre ? ».
Pour un développeur, le développement mutualisé lui permet d'obtenir un logiciel de qualité, ce qui aurait été difficile seul. C'est valable également, dans certains cas, pour une entreprise.
Pour un artiste, autoriser les modifications ne représente pas forcément un grand intérêt. L'œuvre telle qu'il l'a conçue peut lui convenir, et il peut ne pas désirer en obtenir de version « amendée ». Et si des versions amendées sont intéressantes, c'est surtout pour le public, pas forcément pour l'auteur. Tant mieux pour le public, tant mieux pour les co-auteurs et auteurs d'œuvres dérivées, tout cela est bel et bon. Mais ça n'est plus l'œuvre d'origine, et ça, ça peut gêner l'auteur de cette œuvre.
L'auteur d'une œuvre doit donc peser le pour et le contre entre une plus grande richesse offerte au public (économiquement et culturellement parlant, une œuvre qui pourrait être à la fois objet et ressource est d'une plus grande valeur qu'une œuvre qui ne serait qu'objet figé), et la volonté de communiquer un message sans que celui-ci soit perturbé outre mesure (même sans aller jusqu'au cas du détournement flagrant, des petites modifications faites en toute bonne foi peuvent être mal reçues par l'auteur d'origine… voir à ce sujet les tensions autour de chaque projet d'adaptation !).
Permettre les modifications ne me semble pas être une bonne ou une mauvaise chose dans l'absolu.Dans le cas du logiciel, cela permet la mutualisation, et pour les utilisateurs cela garantit une plus grande indépendance (ou liberté) vis-à-vis de l'auteur d'origine. Permettre les modifications permet des corrections de bugs et des optimisations, ou l'ajout de fonctionnalités supplémentaires. Mais cela inclut aussi le risque du fork, du détournement de l'œuvre logicielle par rapport à la direction que voulait lui donner l'auteur d'origine. La question du fork est loin d'être simple à gérer, et on peut comprendre que certains développeurs l'aient mauvaise parfois, même si on reste attaché à l'indépendance offerte à l'utilisateur.
Mais en tout cas, malgré le risque de fork, la plupart des modifications iront probablement dans une direction qui conviendra à l'auteur d'origine, ou même une direction qu'il aura définie lui-même.
Enfin, dans les projets qui dès le départ sont très collectifs, les modifications sont acceptées sans doute plus sereinement.
Les modifications dans le domaine des œuvres d'art sont plus difficiles à cerner. Autant dans le logiciel une bonne partie des modifications possibles peuvent être classées comme positives ou globalement positives (correction de bug, ajout d'une fonctionnalité bien intégrée), autant pour une œuvre d'art il est difficile d'affirmer qu'une modification améliore l'œuvre. En quelque sorte, chaque modification d'une œuvre d'art est un fork ! Un fork qui ne disperse pas les ressources humaines, mais qui disperse les ressources en attention du public qui font auss la valeur d'une œuvre. Autoriser les œuvres dérivées peut donc avoir un coût non négligeable : l'effacement de l'œuvre d'origine par les œuvres dérivées.
Si les modifications apportées étaient des améliorations, il n'y aurait pas de raison « idéologique » (ou esthétique) de s'y opposer. Si l'œuvre d'origine est effacée par une ou des œuvres meilleures, alors tant mieux. Mais voilà : personne ne peut affirmer qu'une modification d'une œuvre améliore cette œuvre. On sait juste que cela produit une œuvre différente.
Le problème, c'est qu'on ne sait pas trop sur quoi se baser pour tracer des limites (même floues) entre logiciel et art. Il y a pléthore de cas particuliers, d'exceptions, de généralisations abusives, etc., qui font qu'il est impossible de donner des définitions acceptables.
Faut-il laisser aux développeurs de logiciels libres affirmer à quel point ils sont plus mieux car ils autorisent la vente et les modifications ? Ou bien peut-on démontrer que la décision d'accepter les modifications n'est pas la même dans le cas d'un logiciel que dans le cas d'une œuvre d'art ?
