Pour développer un projet open-source il faut du temps et comment trouve-t-on ce temps :
- le soir et le week-end à la maison. (La vie familiale en prend un coup)
- en négociant un mi-temps (cette fois c'est le salaire qui déguste)
- au travail, en négociant que certaines parties non critique d'un projet puisse devenir open-source. (il faut avoir un patron sympa, ou travailler chez Google ou Facebook).
- on sinon, dernière possibilité, on se lance à 100% dans le projet en espérant recueillir quelques sous plus tard.
Ok donc supposons que l'on choisisse la dernière possibilité. On code pendant quelques mois, puis après on libère le code. Mais sous quelle license ? Et comment gagner de l'argent pour rentabiliser ses quelques mois de développement ?
License BSD, Apache, MIT ou équivalente : sans copyleft (voire LGPL)
Tout le monde peut intégrer le code dans son logiciel, même si c'est un logiciel propriétaire fermé. Bon courage pour gagner de l'argent.Si le code est populaire, les dons, vendre du conseil, de la formation, de l'expertise, des certifications sont à mon avis, les meilleurs solutions. Mais dans ces cas là, il faut être à la fois un bon développeur (pour que le produit devienne célèbre) et un bon communiquant (pour gagner de l'argent).
Pour les dons on peut citer :
http://www.postgresql.org/about/sponsors
http://www.apache.org/foundation/thanks.html
http://www.python.org/psf/donations/
http://pledgie.com/campaigns/1776#donor_list pour Raphael JS
On peut également rajouter le support 24h/24, 7j/7 avec la garantie d'avoir une réponse en moins de 2 heures (au-revoir les vacances et les nuits, sinon il faut trouver des associés aux 4 coins du globe pour assurer les différents fuseaux horaires.)
Voici un exemple pour le support :
http://www.scalablesolutions.se/support.html
Les doubles licences
C'est la seule façon de gagner de l'argent grâce au code du logiciel.Le principe de la double license, est un modèle commercial assez fréquent.
Le code est proposé avec deux licences : une license opensource assez restrictive et une license commercial qui permet de passer outre les restrictions.
Seul la personne qui détient l'intégralité du copyright du logiciel peut proposer son logiciel avec une double licence. Par exemple on ne peut pas prendre une librairie GPL existante (MySQL par exemple) et dire que l'on va gagner de l'argent en vendant ce logiciel sous une licence commerciale sans copy-left.
Le fait de posséder le copyright nous permet également de proposer une version commerciale avec plus de fonctionnalités. Les fonctionnalités supplémentaires n'étant pas sous licence open-source.
Dans cette catégorie je liste les licences à utilisation Non-Commertial et les licences virales.
License Open Source non commercial
Pour l'instant je ne connais que le Creative Commons Non Commercial.Le code est Open-Source, et toute utilisation au sein d'une entreprise est interdite. Donc pour utiliser le code, il faut soit être une association ou une université, ou simplement pour un usage personnel.
Par conséquent, si une entreprise souhaite utiliser ce produit, elle devra utiliser une autre licence qui sera payante.
Citons par exemple :
http://www.highcharts.com/license
Licenses GPL, Creative Commons ShareAlike : les licenses virales avec copy-left
Tout code dépendant d'un code GPL devient GPL. Donc dans le cas d'une librairie, ce type de license devient très contraignant. On n'a pas envie qu'à cause de l'utilisation d'une librairie GPL que l'ensemble d'un programme devienne GPL.C'est donc pour cela qu'une licence commerciale est souvent proposée :
http://www.gridgain.com/services.html
http://itextpdf.com/terms-of-use/index.php
Un peu de lumière sur la licence Affero GPL ou AGPL
http://en.wikipedia.org/wiki/Affero_General_Public_LicenseLe monde des licences est souvent obscure, et c'est le cas de la license GPL.
D'après ce que je comprend, le copyleft de la license GPL ne s'applique QUE SI le logiciel est distribué. Dans le cas, où l'on utiliserait une librairie GPL pour construire un site web, le site web n'étant hébergé que sur nos serveurs, le code n'est pas distribué à d'autre entreprises, nous ne sommes pas contraint de rendre notre code GPL.
Par contre si la license de la libraririe que nous utilisons est AGPL, nous sommes contraints de fournir le code source de notre application sous license AGPL si notre application est visible sur Internet. Attention ça peut faire très mal.
Licenses virales et contributions extérieurs / forks
Dans le cas d'une double licence, si on choisi une licence virale de type GPL + une licence commerciale.Tant que l'on est les seul à coder sur le programme, il n'y a pas de problème. Le code nous appartient et on est maître de choisir la licence que l'on veut.
Si un mec se présente à nous en disant j'ai rajouté une super fonctionnalité et qu'il nous envoi le code.
Le code envoyé était basé sur la version GPL de notre logiciel, il est donc normal que ce bout de code soit GPL. Le patch ne nous appartient pas, nous n'avons pas le copright. Nous ne pouvons donc pas intégrer ce patch dans notre logiciel sous licence commerciale.
La seule possibilité qui nous reste, pour continuer à faire vivre notre double-license est de demandé au contributeur de bien vouloir nous donner son copyright. Ceci à causé quelque problèmes chez MySQL Par exemple.
http://www.threadingbuildingblocks.org/wiki/index.php?title=Licensing#Why_is_there_a_contribution_process.3F
http://producingoss.com/en/copyright-assignment.html#ftn.id432631
Dans le cas d'un fork, il est bien rare que les contributeurs du forks veillent bien donner leur copyright à la version commerciale.
Les licences incompatibles GPL
Récemment j'ai découvert le logiciel Magento de création de site de e-commerce opensource http://en.wikipedia.org/wiki/MagentoCe logiciel possède plusieurs licences, dont une commerciale et deux open sources.
Les deux licences opensource ne sont pas compatible GPL et pourquoi?
La version commerciale propose plus de fonctionnalités que la version opensource, dont un service de CMS.
Or actuellement les princiapux CMS (Joomla, Drupal) existant en PHP sont sous license GPL.
Comme Magento est sous license GPL-incompatible il n'est donc pas possible de combiner un CMS GPL avec Magento. Nous sommes obligé d'utiliser la version commerciale pour avoir un CMS intégré à Magento.
A mes yeux les licences incompatibles-GPL forcent les utilisateurs à payer des services qui aurait été disponible dans l’écosystème GPL.
j'aurai plutôt mis : le soir et le week-end à la maison. (La vie de colloc' qui en prend un coup)
RépondreSupprimer:'(
Je rajoute un commentaire intéressant qui vient de Framagora :
RépondreSupprimerBonjour,
Merci de partager ce billet :-)
Quelques rapides retours :
pour information, il existe déjà quelques ressources sur le sujet (de mémoire : les guides de l'AFUL, l'April et le Guide Open Source FniLL/Syntec)
"posséder le copyright" n'a pas réellement de sens, il serait plus juste de distinguer le titulaire des droits d'auteur de ses licenciés
quant aux licences : il est fortement déconseillé d'utiliser des Creative Commons sur du code (les sites de Creative Commons ou de la FSF sont assez claires sur ce sujets, mais il suffit de dire que ces licences ne sont pas rédigées avec les logiciels à l'esprit (juridiquement et/ou techniquement) et qu'une telle utilisation auraient des conséquences incertaines).
J'essaierai de prendre un peu plus de temps pour lire ce billet durant les quelques jours qui me restent, mais c'est en tout cas agréable de voir de tels partages d'expériences
Amicalement,
_________________
Mben
Veni, Vidi, Libri — Diffuseurs de Licences Libres
http://venividilibri.org
http://mben.fr
En parlant de BSD, MIT, Apache et LGPL, vous dites : « Tout le monde peut intégrer le code dans son logiciel, même si c’est un logiciel propriétaire fermé. Bon courage pour gagner de l’argent. ». Difficile de faire un commentaire s’appliquant à toutes ces licences. Par exemple BSD autorise la création de logiciel propriétaire commerciaux. La LGPL, qui ne s’applique qu’aux librairies, ne le permet pas, en parlant d’un travail sur la librairie, et même impose certaines limites avec les applications utilisant la librairie, comme impossibilité de faire une liaison statique.
RépondreSupprimerLa BSD convient tout à fait aux logiciels commerciaux, la LGPL, non. On pourrait faire des commentaires tout aussi distincts sur Apache et MIT (quoique MIT et BSD me semble être les mêmes dans ce contexte).
De plus j’ai envie d’ajouter pour être pragmatique, que le plus gros problème n’est pas les licences. Les utilisateurs se moquent des licences, et les seuls critère est « est‑ce gratuit ? ». On peut bien prendre soin de choisir une licence adapté, on fera toujours face au seul et unique critère d’appréciation de la « qualité » d’une logiciel, qui est « gratuit c’est bien, payant c’est nul ». Et cela, quelque soit le prix, même dérisoire, même un cent ou un dixième de cent.