Bonjour,
J'ai un cas de réflexion relativement complexe. Un de mes clients nous demande de développer des fonctionnalités dans notre logiciel libre. Ces fonctionnalités sont pour certaines au coeur du logiciel.
Le client est ok pour faire du libre mais veut un droit d'utilisation pendant 2 années de manière à ce que ses investissements dans le développement de notre logiciel ne soient pas exploité gratuitement par un concurrent. Ce droit d'utilisation est du type "ce logiciel est libre sauf si vous l'utilisez dans l'optique de faire ceci ou cela - dans ce cas vous ne pouvez pas l'utiliser"
Le principe ne me dérange pas - il finance la R&D c'est donc assez naturel qu'il veuille garder une longueur d'avance face à ses concurrents. La réalisation me parait néanmoins complexe :
- soit les droits d'utilisation s'appliquent à l'ensemble de notre logiciel pour le cas envisagé par notre client et cela tue notre activité économique basée sur du libre (dit autrement, notre logiciel "redevient libre" après la période de 2 années)
- soit les droits d'utilisation s'appliquent à certaines fonctionnalités uniquement auquel cas le logiciel est partiellement libre (et il faut bien distinguer les parties de code pour que le code non libre soit désactivable)
- soit …
Quelqu'un a-t-il des idées ?
Si vous êtes spécialistes du droit des logiciels et que vous pouvez m'aider sur la meilleure stratégie à mettre en oeuvre pour :
- faire du libre à façon
- garantir au client une certaine exclusivité dans son périmètre de métier
- ne pas rendre le logiciel propriétaire
Je suis preneur, y compris si vous êtes professionnel.
# idée ?
Posté par xandercagexxx . Évalué à 3.
N'est-il pas possible d'avoir dans ce cas un fork de votre projet pour le faire avancer en parralèlle du reste du développement ?
# n'est pas la technique habituelle de l'openCore
Posté par NeoX . Évalué à 5.
on trouve ce modele régulièrement maintenant dans l'open source
la v10 est payée par les contributeurs/clients => toutes leurs fonctionnalités
la v9 est gratuite, dispo pour tous => certaines fonctionnalités sont manquantes
apres si tu veux limiter des fonctionnalités en fonction du client (droit d'usage pendant 2 ans, etc), c'est une question de licence logicielle, tu actives ou pas certains bout de ton logiciel selon la licence que tu délivres à l'utilisateur final
et là, ben tu fais bien ce que tu veux.
Gratuit => pas de licence => fonctionnalité A+B+C+D
Payant tel client => fichier de licence X => A+B+C+D + pack de fonctionnalité X
payant un autre client => fichier de licence Y => A+B+C+D + pack de fonctionnalité Y
etc
et pour le développement, tu as ta branche dev/master
tu peux avoir un branche "clientX" avec ses développements
et tu t'engages pendant 2ans à ce que les elements de la branche "clientX" n'intègrent pas master/dev
[^] # Re: n'est pas la technique habituelle de l'openCore
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 3.
ça pourrait mais c'est contre-productif car ça empêche tout un tas d'utilisateurs d'exploiter la fonctionnalité alors que ce n'est pas ce que demande le client (il veut juste que sur un cas d'usage qu'il envisage ses concurrents ne puissent pas utiliser les développements qu'il a financés - mais il est ok que ses concurrents exploitent les dév qu'il a financés si c'est pour une autre utilisation).
De plus ça empêche toute contribution externe pendant 2 ans sur des fonctionnalités qui sont potentiellement au coeur du logiciel, c'est pas top.
Mais c'est une piste.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: n'est pas la technique habituelle de l'openCore
Posté par NeoX . Évalué à 3.
ben les devs interdits aux concurrents => branche spéciale ou licence case à cocher X
et les devs autorisés aux concurrents => branche normale de dev/release
# Financement participatif
Posté par ted (site web personnel) . Évalué à 4.
Voici des idées pour garder le logiciel libre, mais je ne sais pas si elles sont réalisables:
Si les fonctionnalités peuvent être utile à plusieurs clients, est ce que vous pourriez imaginer un financement participatif? Le client qui a fait la demande initiale aurait ainsi moins de frais, et en contrepartie permettrait l'utilisation libre de ces fonctionnalités.
Une autre idée serait d'insérer une publicité discrète provisoire du genre "cette fonctionnalité a été financée par machin". En espérant qu'il concède alors de laisser ces fonctionnalités accessible à tous.
Je ne répond donc pas tout à fait à la question, désolé…
Un LUG en Lorraine : https://enunclic-cappel.fr
# C'est marrant...
Posté par Guillaume Smet (site web personnel) . Évalué à 10.
Ce que je trouve toujours marrant dans ces cas-là, c'est que ça ne leur pose aucun souci d'utiliser librement les fonctionnalités contribuées (directement ou indirectement) par tous vos autres clients.
Perso, pour des fonctionnalités dans le noyau, je dirais tout simplement que ce n'est pas possible. Pour le reste, tu peux toujours faire des plugins non libres si ça vous paraît acceptable.
Après, franchement, m'est avis que ça va être un peu pénible pour vous de gérer cela sur le long terme.
Le libre, on l'oublie souvent, c'est quand même hyper pratique en fait.
[^] # Re: C'est marrant...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 6.
En fait c'est plus subtile que ça. Le cas est un client qui développe une communauté. Il a besoin d'un outil et s'appuie sur un outil libre. Il finance (largement) le développement de fonctionnalités supplémentaires pour répondre à ses besoins. Il ne voit aucun problème à ce que les fonctionnalités soient utilisées par ailleurs y compris par ses "concurrents" mais pas pour le cas d'utilisation précis.
Ça se comprend dans la mesure où créer une communauté c'est "le premier arrivé est celui qui réussit" et qu'ils perdront en crédibilité si un concurrent fait le même travail au même moment sans avoir dépensé de manière conséquente pour le développement des fonctionnalités en question.
la question n'est pas "je ne veux pas qu'on utilise la fonctionnalité que j'ai financée" mais "je ne souhaite pas que mes concurrents utilisent l'ensemble des fonctionnalités que j'ai fait développer précisément pour me faire concurrence sur ce projet particulier que je mets en place - pour le reste je m'en fiche".
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: C'est marrant...
Posté par NeoX . Évalué à 3.
pour moi tu as ta réponse dans la phrase que tu formules est-ce celle du client ? là
donc pour le développeur aucun souci, il développe une appli qui a des fonctionnalités et les utilisateurs/clients utilisent les fonctionnalités
ca c'est pour l'avocat, pour protéger un business modele, et ce n'est pas au développeur de régler le souci.
si le client ne veut pas qu'un concurrent fasse le meme business que lui, il faut protéger le business modele => code fermé, licence
tu peux pas dire tout le monde s'en sert sauf s'il a le meme business que moi
[^] # Re: C'est marrant...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 3.
Ca se rapproche un peut du modèle Creative Commons - Non Commercial où la licence interdit explicitement certaines utilisations.
Mon problème n'est pas tant là que « comment bien combiner » des morceaux de licence libre et des limitations d'utilisation (et indirectement avoir des retours d'expérience).
Il y a 2 approches qui se trament pour le moment :
Je cherche à avoir une vue d'ensemble pour évaluer la situation est les possibilités.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: C'est marrant...
Posté par NeoX . Évalué à 5.
OK
donc mon avis en tant qu'utilisateur, ca ne me choque pas d'avoir 2 produits, l'un basé sur l'autre, avec une version par exemple full open source avec moins de fonctionnalité
et une version payante/licenciable avec des plugins par exemple.
du coup le dev de ton client, c'est un plugin spécifique, qui sera libéré dans X temps/versions.
tu as l'argent du beurre (un dev payé par le client), le beurre (une nouvelle fonctionnalité dans ton logiciel), le cul de la crémière (la restriction pour les autres clients car le plugin n'est pas encore dispo pour eux)
et ton client participe in-fine à ton logiciel opensource, les autres clients/utilisateurs auront le plugin dans 2 ans, dans la version opensource/grand public
[^] # Re: C'est marrant...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 5.
Oui c'est probablement le plus simple
C'est effectivement le cas ; mais c'est aujourd'hui la seule solution viable que j'ai en tête (dans la mesure où "faire totalement du libre" ne serait pas envisageable - je garde un peu espoir, surtout que le client est ok pour que ça soit libre à terme)
On est bien d'accord là dessus.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Licences multiples ?
Posté par _kaos_ . Évalué à 4. Dernière modification le 23 mars 2021 à 08:27.
Salut,
Certains logiciels utilisent différentes licences pour différents fichiers (exemple :
R).Le gode est gpl, sauf les headers qui sont lgpl pour pouvoir s'interfacer à du proprio.
Ça ne répond pas forcément exactement au besoin (2 ans), mais si tu fais une branche stable (ne prenant pas forcément encore en compte les-dits devs) et une branche de développement jouant sur ce principe (probablement dans l'autre sens ?), ça peut peut-être marcher ? Et dans 2 ans, tu change la licence pour harmoniser.
Dépend de ta licence de base…
Matricule 23415
[^] # Re: Licences multiples ?
Posté par _kaos_ . Évalué à 2. Dernière modification le 23 mars 2021 à 08:49.
Re-salut,
Pas bien réveillé et vu qui postait :)
Ok, donc tu peut garder la MIT pour tout et mettre que ce qui intéresse le client en gpl par exemple. Ton client aura toujours de l'avance, et si les concurrents veulent se démarquer, ils devront contribuer en… gpl, ce qui profitera à ton client aussi directement.
Matricule 23415
# logiciel lourd ou serveur?
Posté par freem . Évalué à 5.
Une chose que tu n'as pas précisée, c'est: le logiciel est-il un "client lourd", ou un serveur (ou un cgi ou … tu m'as compris)?
Dans le cas d'un serveur, pas de souci, après tout: le code est libre dès lors que le client à le code et les droits. Rien ne te force à diffuser le code au monde entier: la seule raison qui fait que les logiciels libres sont souvent aussi des gratuiciels, c'est parce que se baser sur l'espoir qu'aucun utilisateur ne diffuse le code serait… ridicule, donc impossible de monétiser l'accès au code (et aux droits).
Dans ton cas, et si la partie à développer est destinée à être hébergée sur «la machine de l'admin», il est possible que tu aies juste une version particulière pour ce client et qu'au bout de deux ans (ou période fixée par le mécène) tu merges.
Ça reviens effectivement à s'auto-forker, et à maintenir 2 branches, mais pas de problème du point de vue légal et coupeurs de cheveux: l'utilisateur (aka le mécène) de la version B dispose des 4 libertés et du code, il s'agit donc bien d'un logiciel libre. S'il diffuse, c'est son problème (reste évidemment la surcharge de travail de devoir maintenir 2 branches en permanence, mais tu as dis qu'il paye plutôt bien, alors à toi de voir si c'est rentable).
# Très (trop?) compliqué?
Posté par arnaudus . Évalué à 7. Dernière modification le 24 mars 2021 à 18:02.
Si j'ai bien compris, l'idée serait de diffuser le logiciel sous une licence "libre" permettant à tout le monde d'utiliser le logiciel, sauf dans un but précis.
Du style "vous pouvez utiliser ce logiciel pour dessiner tous les plans que vous voulez, sauf si vous êtes une entreprise et que vous dessinez des plans de fusée à destination de la Lune."
Sans être un pro des licences, quelques remarques:
1) une telle licence ne serait pas libre (selon toute définition raisonnable du libre)
2) en fonction de la licence de départ, une telle restriction peut ne pas être possible (par exemple, la GPL exlcut toute clause supplémentaire restreignant la liberté de l'utilisateur).
3) en fonction du pays où ça se passe et du droit des contrats que je ne connais absolument pas, une telle clause pourrait très bien ne pas être légale (par exemple, une clause telle que "vous êtes libre de modifier ce logiciel sauf si vous êtes une femme" n'a pas à être respectée, et il est fort probable que "vous pouvez vendre ce logiciel seulement après avoir passé 1h23 à sauter à cloche-pied sur le pied gauche" ne soit pas défendable devant un tribunal). En gros, ce n'est pas parce qu'on écrit quelque chose dans une licence ou dans un contrat que le signataire du contrat a l'obligation de la respecter, il peut choisir de ne pas la respecter et de choisir de régler ça au tribunal.
Au final, il semblerait quand même plus facile de maintenir une branche "privée" pendant 2 ans, diffusée seulement à la boîte qui a financé le développement, sous une licence non-libre. Je pense que je comprends pourquoi la question se pose, mais je ne suis pas convaincu par les solutions basées sur "je vous fournis la fonctionnalité, vous avez pas le droit de l'utiliser pour faire ceci mais pas cela".
En fonction de la fonctionalité en question, peut-être que de mentionner le sponsor de manière à ce que les clients le voient pourrait être assez dissuasif? Par exemple, si la fonction génère un rapport au format pdf, le fichier pourrait mentionner "Rapport généré par la méthode MaBoite", ce qui la fout suffisamment mal pour le concurrent pour éviter de refiler ça à un client. Bien sûr, on peut modifier le logiciel, on peut trouver plein de moyens de contourner, mais c'est quand même un peu la honte. Évidemment, ça va dépendre du service en question et ça n'est pas complètement applicable. Mais bon, quand on peut dire aux clients "oui oui, je sais que mon concurrent X vous fournit tel service, c'est nous qui l'avons développé et ils ne font qu'utiliser notre méthode sans savoir comment elle marche", ça a de la valeur…
[^] # Re: Très (trop?) compliqué?
Posté par vv222 . Évalué à 3. Dernière modification le 27 mars 2021 à 13:13.
Je pense que c’est le point le plus important ici : une licence libre ne permet pas de restreindre les cas d’utilisation du logiciel. Donc il n’y a pas d’autre choix que d’appliquer une licence non-libre au code fournissant les fonctionnalités à limiter.
Partant de là, la question est de savoir comment découper le logiciel de manière à n’appliquer cette licence non-libre que sur le bout de code concerné et pas sur l’intégralité du logiciel. Ce qui va fortement dépendre de l’architecture du logiciel et de sa licence actuelle.
S’il est possible de fournir la fonctionnalité non-libre via un module clairement distinct du reste de la base de code, c’est probablement la solution que je privilégierais dans ce genre de situation.
Dans tous les cas il faut bien garder en tête que « ce logiciel/fonctionnalité/module est libre, sauf pour… », ça n’existe pas ;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.