Mise sous licence et licence custom

Framasoft & Vous
1

Bonjour,
Deux petites questions d’ordre juridique :

  • Que faut-il faire pour mettre un logiciel sous licence ? Je veux dire, je crée ma fenêtre, avec un petit menu « à propos » indiquant qu’il est sous licence GNU, ça suffit à ce qu’il soit reconnu comme logiciel sous licence GNU ? Si un commentaire dans le code source indique une autre licence, qu’est-ce qui prévaut ? Y-a-t-il un procédure d’ordre juridique pour faire reconnaître la licence du logiciel ?
  • Peut-on rédiger des licence custom ? Par exemple une GNU agrémentée d’un paragraphe ? Est-ce que cela à une validité juridique ?

Je pensais par exemple une licence de type « future-GNU » (ou appelez là comme vous voulez) : un dev (ou plusieurs, ou une entreprise) crée un logiciel qui reste sous licence privée jusqu’à la version 1.0. Seul les béta-testeur volontaires ou rémunérés auraient accé au logiciel code avec interdiction de le distribuer. Une fois la version stable prête, le dev pourrait lancer une campagne de dons, avec un seuil minimal correspondant à la valeur qu’il estime être celle de son travail. Lorsque le seuil est atteint, le logiciel et son code passent automatiquement sous licence libre (dans notre exemple GNU) et sont diffusés. Je sais pas ce que ça vaut comme idée.

2

Bonjour,

Attention, Licence GNU ça ne veut pas dire grand chose. Je suppose dans la suite que tu parles des GPL (GNU Public Licence) 2 ou 3, mais sache qu’il existe des variantes comme AGPL ou LGPL, qui ont des utilisations spécifiques – on peut discuter de ton projet pour voir ce qui peut s’appliquer ou non.

Pour mettre un logiciel sous licence, il faut le dire, et respecter la licence. Dans le cas des licences GPL par exemple, cela implique de livrer une copie de la licence avec le logiciel.

On peut mettre un logiciel sous plusieurs licences – je n’ai jamais vu plus de 2, mais ça ne veut pas dire que ça n’existe pas. Dans ce cas, il faut préciser si l’utilisateur a le choix, ou bien dans quelle cas quelle licence s’applique. Attention, là encore, il faut que les conditions respectent la licence bien sûr.
Cela se fait par exemple pour mettre des logiciels sous 2 licences incompatibles, afin que plus de projets puissent utiliser ton logiciel : ceux qui sont compatibles avec la licence 1 ainsi que ceux qui sont compatibles avec la licence 2.

Pour ce qui est de changer une licence, je le déconseille si tu n’es pas juriste. En effet, le choix du moindre mot est important, et si la GPL ne tient pas en 3 lignes, si elle a 3 versions, ce n’est pas pour rien. De même pour la licence Apache (https://www.apache.org/licenses/LICENSE-2.0.txt).

Par contre, sur la page du projet ou dans un fichier livré avec le logiciel, tu as le droit d’écrire un truc du genre :
Avant la version 1.0, le logiciel est sous licence X
À partir de la version 1.0 et supérieures, le logiciel est sous licence Y

Mais se pose la question de pourquoi tu ne veux pas que les testeurs aient accès à un logiciel sous licence GPL. Visiblement, c’es par crainte qu’ils ne forkent ton logiciel. OK, mais quelle différence par rapport à la V1 ? Ne crois-tu pas qu’il serait dans leur intérêt d’attendre la V1 dans tous les cas pour forker un logiciel avec plus de fonctionnalités et moins de bugs ?

Après, tu peux tout à fait imaginer un contrat à passer avec les testeurs, mais je ne suis pas certain que ce soit vraiment une bonne idée.

Désolé pour cette longue réponse, mais le sujet est compliqué :slight_smile:

3

C’est par exemple ce que fait cette extension pour MkDocs (un système de gestion de documentation). Les gens paient pour financer des fonctionnalités, qui sont débloquées dans la version libre en fonction de la cagnotte. Ce n’est pas forcément le modèle le plus vertueux, mais c’est un modèle qui peut être acceptable si on a besoin d’un modèle économique.

Il n’y a pas spécialement besoin d’avoir une licence spéciale pour faire ce genre de chose. Le code est propriétaire dans la version restreinte, et libre dans la version publique. En revanche, c’est à priori incompatible avec la viralité des licences de la famille GPL.

4

Peu importe, GNU c’est pour l’exemple, ça pourrait être MIT ou apache.

D’accord, donc n’importe quel texte fourni avec le logiciel fait l’affaire ? Un truc cliquable dans l’interface, un txt fourni avec le exe, un papier fourni avec la disquette ? Du moment qu’il n’y a pas d’incohérence avec ce qui est écrit dans la licence, c’est valable ?

En gros l’idée, c’est de permettre au dev de garantir une rémunération pour son travail, tout permettant aux utilisateurs d’avoir un logiciel accessible financièrement qui soit pas complètement vérolé de drm en tout genre. La différence entre la v1 et la v0 et que lors du développement de la v0, le dev n’as pas encore touché ses sous. Donc si son projet se fait diffuser à ce stade, il perd le fruit de son travail. Ça n’as pas trop d’importance pour un mec qui code quelques heures le week-end, mais pour une personne dont c’est le boulot, ça peut être plus compliqué.

Pas de mal.

Oui, ça à l’air d’être à peu près la même chose que ce à quoi je pensais. Pour ce qui est d’être vertueux, vu ce qui se fait dans le monde de l’entreprise, c’est en tout cas un pas dans le bon sens de mon point de vu. Et le modèle du développeur qui contribue à la communauté dans sa chambre le week-end, pourquoi pas pour uBlock, mais pour des usines à gaz qui mettent des années à être développées, le problème de la rémunération se pose forcément.

Pourquoi ça ? Le principe de la viralité c’est juste que les forks héritent de la licence non ? Ou tu parles du cas ou tu veux faire une release v2 ?

5

Si tu redistribue un logiciel en version « améliorée » qui contient du code sous licence virale, alors cette amélioration est aussi sous cette licence, et donc n’importe qui a le droit de redistribuer cette version qui se voulait restreinte.

6

C’est plus compliqué que cela.

Prenons la GPL v3 (qui a été créée car la V2 est trop imprécise sur certains points, et les avis des spécialistes n’ont pas permis de trancher), et de la L-GPL (lesser GPL), voici quelques exemples :

  1. Je fais un projet P, et j’embarque le code source de ton logiciel L → P doit être sous licence GPL ou une licence compatible
  2. Je fais un projet P et j’utilise ton logiciel ou ta librairie L directement
    ** L est sous GPL : P doit être sous GPL ou compatible
    ** L est sous L-GPL : P peut-être sous n’importe quelle licence

Pour résumer, le principe de la GPL est d’être contaminante, c’est à dire que tout ce qu’elle touche doit être GPL.
C’est pour ça qu’il y a des licences un peu moins contaminantes, comme la LGPL ou la AGPL. En gros, l’idée est de dire que si tu ne fais qu’utiliser le logiciel, tu n’es pas contaminé par sa licence.

Je ne suis pas certain que tu aies le droit de licencier un logiciel sous 2 licences, une GPL et une incompatible. Tu trouveras les licences compatibles sur le site de GNU : Various Licenses and Comments about Them - GNU Project - Free Software Foundation

Pour résumer, la gestion des licences est complexe :slight_smile: Mais il faut s’accrocher, car c’est une vraie protection.
Si on considère l’exemple de Insiders (plugin MkDocs mentionné ci-dessus), ce qui est écrit sur leur site est clairement une violation de la licence MIT qu’ils utilisent : la licence donne la permission à tou·te·s de distribuer, et ils demandent de ne pas le faire. Légalement ça ne tient pas – en droit français, la clause de leur site sera considérée comme non-écrite.

7

Si, il y a un certain nombre d’entreprises qui font ce genre d’opération avec une double licence libre et une propriétaire. Les contributeurs sont alors obligés de concéder leur droits dans la version propriétaire pour que l’entreprise ait le droit de distribuer leur travail. C’est par exemple ce que fait ownCloud, sous licence AGPL et propriétaire.

Mais ce genre de situation n’est généralement pas bien vu par la communauté, et ça a été une des raisons du fork Nextcloud.

La licence donne à toute⋅s la permission de distribuer ce qui est sous code MIT, ce qui ne s’applique donc pas à la version Insiders, qui est sous licence propriétaire (les gens n’auraient le droit de redistribuer que les morceaux sous licence MIT).

8

Merci de cette précision, je ne connaissais pas. J’avoue que je comprends le point de vue de la communauté

Ben… ce n’est pas ce que je comprends de ce qui est écrit sur le site – et si je le dis ici, ce n’est pas pour troller ou dire que j’ai raison ou quoi que ce soit de négatif, mais bien pour montrer à quel point les discussions sur les licences sont systématiquement compliquées
Sur leur site, je vois ceci :

image
image866×355 37.7 KB

Ce que je comprends (et je peux tout à fait me tromper) : le plugin est sous licence MIT, et il est demandé de ne pas distribuer le code source – ce qui va à l’encontre de la licence.

Donc pour en revenir au problème 1er : comment faire pour avoir un projet open-source qui ne soit pas copiable tant que ce n’est pas en V1 :

  • Mettre la V0.x sous une licence closed-source, en précisant que la V1 sera open-source
  • Faire comme ownCloud, avec le risque que cela déplaise à une partie de la communauté, qui forke ton projet
  • Faire comme Insiders, même si j’avoue que j’ai plus de doutes – mais c’est peut-être que je n’ai pas compris
9

Salut, voici mon grain de sable dans les rouages des pensées ci-établies.

Primo, rien n’oblige dans la GPL à ouvrir publiquement l’accès au développement d’une version d’un logiciel basé sur du code sous cette licence. C’est pas parce que la version N d’un logiciel est disponible sous licence GPL que le développement de la version N+1 doit obligatoirement être mise à disposition du publique. La licence GPL ne s’applique que lorsque le logiciel est initialement mise à disposition de manière publique. La sphère du développement peut garder son statut privateur. Cependant, la version N+1 ne pourra pas avoir une autre licences que GPL du fait que la version N est sous GPL.

Tout ça pour dire que restreindre l’accès aux « bêta-testeurs volontaires ou rémunérés » permet de ne pas rendre public la version N+1. Je suppose que les gestionnaires de dépôts permettent ce genre de finesse dans les embranchements. Sinon, il faudra travailler avec deux dépôts, l’un pour le dev, l’autre pour la mise à disposition du public.

Mais dès ce point, commence la notion de confiance. En effet, la licence est telle que les développeurs ou bêta-testeurs pourraient légalement redistribuer, modifier, … le logiciel. Donc, soit on a une totale confiance… soit pas.

Dans la positive, tout le monde il est beau. Dans la négative. Il faudrait mettre des contraintes. Le mieux serait de passer par une définition d’une licence restrictive au développement avec accord de non-divulgation, etc. Et de faire passer l’ensemble vers une licence libre lors de la mise à disposition du publique. Mais là, ça ne colle pas réellement avec le principe du libre. Mais bon, nous n’habitons pas non plus sur un planète où le libre est le modèle économique par défaut. Je veux dire par là, que tout le monde ne joue pas le jeu du libre même si nombre d’entre nous (moi y compris) aimerai que ce soit le cas.

Maintenant, il y a d’autres modes de pensées. Car je crois saisir que le principal soucis est de ne pas se faire voler l’idée alors qu’on a produit un effort de développement et que cet effort ne sera dès lors jamais récompensé. Ça, c’est une histoire d’économie. Sans solution simple et stricte. Ce pourrait être le cas mais, comme dit avant, tout le monde ne joue pas le même jeu. Et pire, tous les parties des différents jeux se jouent en même temps…

Bref ! Dans cette éventualité (I.e. récompense d’effort), la recherche d’investisseur est une autre approche. Mais là, il faut définir des plans d’évolution, des strates de développement, un cahier des charges ou tout autre informations qui pourraient faire en sorte que les personnes qui pourraient s’y investir soit intéressées. Cela demande des efforts de conception et de planification. Mais c’est également le grand inconnu.

Autrement, il est possible de faire également appel aux dons. A ce moment là, il faut tenir un carnet de bord pou que les donateurs savent qu’ils ne donnent pas sur du vent. Peut-être même mettre une jauge qui indique le niveau de compensation de l’effort. En d’autres mots une jauge tirelire qui détermine si le montant de dons atteint la somme estimée de l’effort consacré à la production du logiciel. Quand je dis production, je pense à tout ce qui il a eu comme travail afin de fournir le produit (conception, développement, merchandising, etc.)

Mais là, encore on en revient au point principal de tout ceci: la confiance. Car là, on peut dire n’importe quoi. Gros ou petits mensonges, peu importe. Alors pour limiter cette méfiance, à mon avis (ou dans mon idéal d’honnêteté), il faudrait avoir une transparence complète. Du style, un tableau avec un détail de chaque activés fournie (par exemple: temps de dév pour la correction d’un bug particulier, temps pour test une fonctionnalité, coût mensuel du serveur web pour le dépôt, … ), de ce qui a déjà été amorti, etc. Cela permettrait au public de savoir ce a été réellement fait et peut-être faire notion de considération en faisant un don.

En fait, ce n’est pas si simple, malheureusement. Je ne prétends pas avoir répondu à toutes les question. Et il y a certainement des lacunes dans mes propos. J’aimerai pourvoir dire: « Allez, j’ai une cool idée, j’ai besoin d’aide, mais j’ai pas une tune. C’est pas grave, le monde m’aidera comme je veux l’aider » Or…

1 « J'aime »
10

Merci, ça réponds déjà pas mal à la question. Bon, pour résumer :

  • Pour donner une licence à un logiciel, il suffit de distribuer le texte d’une manière ou d’une autre avec le logiciel et de respecter cette licence
  • au-delà des considérations morales, il est compliqué de modifier une licence, mais il est possible de distribuer un logiciels sous multiples licences, sous réserve de préciser sans ambiguïté les cas dans lesquelles chacune s’applique.

C’est bien ça ?

11

Tu as tout à fait raison, j’ai lu trop vite cette section.

12

Salut !

Tout est expliqué là : How to Use GNU Licenses for Your Own Software - GNU Project - Free Software Foundation

Bien sûr, mais c’est considéré comme une mauvaise pratique de nos jours :

C’est parfaitement faisable avec n’importe quelle licence libre existante.

Le copyright ou le droit d’auteur et donc les licences, libres ou non, associées, ne s’appliquent qu’à la publication (ce que tu appelles la distribution dans ton texte). Il n’y a donc aucun besoin de licence durant la phase de développement, puisque tu souhaites à huis-clos.

L’éthique du Libre n’impose pas un développement « ouvert », « communautaire » aux développeurs. Elle impose juste de conférer les quatre Libertés à tous les utilisateurs… mais un logiciel non publié, et même pas encore fonctionnel, n’a pas d’utilisateurs proprement dits ! ^^

Je ne pas trouvé de meilleure référence que la suivante ce matin. Je suis pourtant certain d’avoir lu mieux quelque part…

13

Cela importe car le droit, comme l’informatique, requière un minimum de précision.

Licence Apache n’est pas assez précis. Les licences Apache 1.0 et Apache 1.1 sont incompatibles avec la GPL, elle doivent être évitées. Tandis que la licence Apache 2.0 est considérée comme la meilleure licence permissive/laxiste par la FSF, elle-même, qui la recommande avant même la GNU GPL dans le cas des micrologiciels par exemple.

Licence MIT n’est pas assez précis. Derrière ce terme se cachent au moins deux licences : la licence Expat et la licence X11.

Tu aurais donc du au moins du écrire « une des licences (du projet) GNU », puisqu’il y a beaucoup de licences, surtout si on compte les versions historiques, et si on compte les deux manières de les appliquer : seule ou en ajoutant la mention recommandée : « ou ultérieure ».

14

Privateur est ici mal exprimé. Tu aurais du écrire « La phase de développement peut se faire de manière confidentielle. On ne prive ici aucun utilisateur de liberté, puisqu’un programme n’ont publié n’a pas vraiment d’utilisateurs !

En fait, ça « colle » au Libre aussi bien que si le développement était public, « ouvert ». Peut-être associes-tu trop étroitement les principes philosophiques (politiques) du Libre avec les recommandations techniques de l’Open Source :

Il y a aussi tout simplement le besoin de bidouiller du code tranquillou dans son coin, sans pression, et de ne publier que lorsqu’on est à l’aise avec cette idée.

Le raison de @9d4f1d70c5, fournir le logiciel libre que lorsque les développeurs estiment avoir reçu assez de monnaie en échange, me semble relativement courante également. D’ailleurs, n’est-ce pas, prise au sens large, l’une des raisons de tous les développeurs non-bénévoles du Libre ?! :wink: