Vendre son logiciel mais le distribuer ?

est-il possible de diffuser les sources en restant les seuls possibles à pouvoir commercialiser notre produit ?

La réponse courte : légalement, c’est possible, mais pas avec les licences libres existantes, et moralement, ça va très certainement décourager les contributions.

La réponse plus longue en edit.

EDIT : la réponse longue, donc.

Si le libre et l’open source sont des concepts différents, ce n’est pas pour rien : il est parfaitement possible d’être open source sans être libre au sens de la FSF. En gros, il faut une licence qui :

• autorise la diffusion de votre code source ; note bien que ce n’est même pas totalement nécessaire, tu peux parfaitement mettre tes sources à disposition sans pour autant autoriser d’autres gens à les diffuser ailleurs ;
• interdise toute diffusion ou utilisation commerciale de votre code source ;
• autorise la contribution de code (on dira création d’un programme dérivé) à condition de vous accorder l’intégralité des droits patrimoniaux portant sur ces contributions.

C’est une combinaison assez spécifique, et qui n’existe pas dans les licences FOSS que l’on trouve usuellement, qu’elles soient françaises ou américaines. Donc si vous partez sur une solution comme ça, il vous faudra écrire la licence vous-mêmes.

Maintenant se pose la question de la « morale ». Premièrement, si votre code est open source, ça veut dire que les gens peuvent tout à fait se servir de votre logiciel sans vous l’acheter, a fortiori si vous autorisez la diffusion gratuite par des tiers.

Deuxièmement, en autorisant les contribution, mais en vous réservant le droit de commercialiser les versions améliorées, vous dépossédez les contributeurs de leur travail pour en tirer, vous, un bénéfice commercial. Dit autrement, vous demandez aux gens de corriger votre code pour qu’il soit de meilleure qualité et mieux bankable. Ce qui n’encourage évidemment pas à la contribution.

Sachant qu’il n’est pas envisageable d’intéresser les contributeurs aux revenus commerciaux du logiciel, c’est beaucoup trop compliqué à gérer.

D'un point de vue purement légal, ça me semble tout à fait possible d'avoir un outil entièrement open-source commercial. En revanche, c'est peu courant puisqu'il devient techniquement impossible de forcer les gens à payer.

Si tu connais l'anglais, je suis tombé sur un article qui donne quelques exemples de jeu/logiciels qui sont open-source mais payant, ce qui pourra te donner de l'inspiration sur comment gérer la chose : Open-source software is not always freeware. Les commentaires sont aussi assez intéressants.

Salut, ce que tu peux faire aussi c'est faire payer les installations, la maintenance en cas de problème et support utilisateur. Éventuellement le développement de modules spécifiques peut aussi être vendu.

Si tu dev le produit et que tu laisses pas un lien tout prêt pour une installation, je ne suis pas sur que beaucoup de personnel soignant s'amuseront à chercher pour l'installer de leur côté. La plupart des utilisateurs cherchent des solutions clés en main (ou font appel au service informatique si c'est une plus grosse structure).

Tu peux essayer de te positionner sur des petites structures, sans personnel dédié informatique (petit cabinet avec presta info), chez des indépendants (psychologue spécialisé dans le handicap ?), voir même sur des plus grosses structures. Tu les contactes, leur propose un entretien téléphonique pour discuter de l'outil. Ensuite s'ils sont intéressés tu leur proposes une démo (par Teamviewer ou autre) ou en direct tu te déplaces chez eux et tu projettes une démo de ton outil. Puis il faut se faire un nom tranquillement.

Si tu as d'autres infos à donner prochainement sur ton projet je suis preneur, je travaille dans le milieu de la santé (plus particulièrement du handicap).

Bon courage et tiens nous au courant

Le modèle économique mentionné par Aurel_B_ se rapproche de celui adopté par RedHat dans le domaine des distributions Linux.

• En premier lieu il y a un projet libre et gratuit, destiné à tous les publics, c'est Fedora. RedHat sponsorise Fedora et paye des développeurs pour que le projet avance, mais c'est surtout une communauté bénévole qui porte la distribution. Les innovations sont rapides et fréquentes.
• Ensuite, il y a le système d'exploitation commercial RedHat Enterprise Linux, orienté entreprises. Il est basé sur Fedora, mais se veut le plus stable possible. RHEL est payant parce que RedHat offre des garanties à ses clients : support personnalisé, binaires "prêts à installer", etc.
• Tout un chacun peut recompiler gratuitement RHEL et le diffuser. C'est le cas de CentOS, une distrib orientée entreprise, libre et gratuite. Le support pour CentOS est effectué par la communauté, sans les garanties de RedHat.

En gros, transposé à votre projet, on peut imaginer que vous lanciez un projet libre et gratuit, avec des contributeurs externes bénévoles, puis que vous proposiez en parallèle une version payante, plus stable et avec support technique.

• Les pros bien installés préféreront avoir les garanties de la version payante, surtout qu'ils ne voudront pas s'embêter à configurer eux-mêmes le logiciel. En plus d'offrir un certain confort, payer peut être vu comme une manière de remercier les développeurs (vous) pour leur travail.
• Ceux qui ne peuvent pas s’offrir la licence pourront se tourner vers le projet ouvert et gratuit. En tant que développeur bénévole, je sais que mon travail ne sert pas qu'à vous enrichir, mais qu'il va servir à des gens qui ont peu de moyens.

Voilà, je ne sais pas si cela fait avancer le schmilblick. Bonne chance pour la suite

Edit : conjugaison

Seulement voilà : est-il possible de diffuser les sources en restant les seuls possibles à pouvoir commercialiser notre produit ?

Bien sûr. A la différence de mes VDD je vais pas pondre un pavé mais répondre par l'exemple.

Si je mets une photo sur flickr, je la diffuse mais je reste le seul à pouvoir la commercialiser*.

Si j'écris un article sur mon blog, je le diffuse mais je reste le seul à pouvoir le commercialiser*.

Si je mets les sources d'un logiciel que j'ai créé sur github, je les diffuse mais je reste le seul à pouvoir les commercialiser*.

* C'est à dire vendre le truc, en vendre les droits d'exploitation, l'exploiter commercialement, etc.

Il y a un paquet de produit open-source où la boite derrière commercialise elle le support ou des version +. En vrac : MongoDb, PyCharm, sentry, Qt, etc.

Si tu vend une version "+", les contributions externent risquent d'etre faible. Si tu vend du support, là il devrait moins y avoir de problèmes. Mais de toute façon vu la niche que tu vise, je doute que tu ai des tonnes de dev externe pour t'aider. Les conditions de commercialisation ça se règle par la licence, tu peux la choisir pour faire ce que tu veux.

Hello, je vais répondre sur la partie technique.

• Si tu t'orientes sur un projet commercial vaudrait mieux partir sur bitbucket (ça t'évitera déjà de payer pour un dépôt privé -tu en aura besoin si tu veux faire les chose bien- ) contrairement à Github
• En terme de serveur d'intégration, Travis-ci est bien, mais je le trouve un peu limité dans les architectures proposés. Dans la solution gratuite tu n'aura le choix qu'entre Ubuntu 12.10 et os x (qui ne fonctionne qu'une fois sur deux), autant dire que ce n'est pas très représentatif du parc de tes potentiels clients. Je te conseillerai plutôt Shippable qui a de très bon avantages. Mais ceux qui devraient t'intéresser c'est surtout qu'étant basé sur docker tu profites de sa flexibilité. C'est à dire que tu peux builder ton app sur toutes les versions de linux de que tu souhaites (debian, fedora, ubuntu, etc.). Une autre fonctionnalité très utile est qu'a la fin de ton build, tu peux pousser automatiquement ton image docker sur AWS, OpenShift et cie et hop, ton application est mise à jour.

Comment s'orchestrent Ansible (ou tout autre type Puppet ou Chef), Docker et disons AWS ? Est-ce que je peux configurer Ansible pour qu'il créé le conteneur Docker et le déploie sur une instance AWS ou Azure ?

Il y'a des pattern qui essayent de mélanger Ansible (et ses homologues) avec Docker, mais je trouve que les deux se marchent un peu sur les pieds. Ansible, tu fait surtout de la gestion de configuration (pour ton infrastructure et/ou tes middlewares), Docker quant à lui vient marcher sur ses plates bandes tout en faisant un peu plus que Ansible. Je dirais qu'il vaut mieux faire du Ansible + AWS ou Docker + AWS, mais pas les trois ensemble.

Pour ce qui est de l'orchestration, AWS te fournit la doc de déploiement dont tu as besoin. Et si tu utilise Shippable, le déploiement se fait de manière transparente.

Je cherche des solutions libres et gratuites si possible (sauf pour AWS / Azure). Ansible me semble mieux sur ce point que Chef et Puppet ? Vous confirmez que c'est un choix pertinent ? CFEngine se place-t-il dans ce cas-là ?

Puppet et Chef aussi sont gratuit, donc là n'est pas le souci. Ansible à le gros avantage de ne pas avoir besoin qu'un agent soit installé sur la machine distante pour pouvoir déployer en plus du fait que si tu fais du Django, tu fais tu python et que Ansible c'est aussi du python. Donc je dirais que de ce point de vue ton choix est pertinent. Après si tu m'a bien compris plus haut, tu ne devrais même pas avoir besoin de Ansible.

Voilà, j'espère que ça t'aidera.

J'ai quand même une question : en quoi Docker et Ansible se marchent-ils sur les pieds ?

Ansible n'est pas là uniquement pour installer en One Shot quelque chose sur ton serveur, il est là pour s'assurer que la configuration que tu souhaites soit déployée correctement sur ton serveur quand le besoin s'en fait sentir et que tout ça est reproductible sur n'importe quel environnement.

Dans ton cas, tu auras un fichier de configuration par environnement (test, de prod, etc.) dans lequel tu dis en gros : installes moi nginx, python 3, postgresql et configure les ainsi. C'est là que tu as besoin d'un dépot privé pour la conf de ta prod. Et du coup, la ou tu te marches avec les pieds avec Docker c'est que tu pourrais très bien avoir un DockerFile pour nginx, une autre pour python 3, une autre pour postgresql, … avec un DockerFile pour ton env de test, prod, etc.. Tes DockerFiles portent donc le même type de configuration que pourrais te porter Ansible.

Tu semble penser que tu as besoin de Ansible pour au moins installer Docker, mais n'oublie pas que tu as besoin de python pour Ansible aussi. Dans tous les cas, si tu t'oriente sur du AWS, pas besoin de devoir installer Docker et tout roule.