Je bosse dans un boite ou nous avons abordée la même question.
La première question à se poser est "pourquoi open-sourcer" ?
Tout code ouvert sur l'extérieur va être un communication sur votre travail. Si il est inélégant, mal documenté, inefficace .... sic de votre réputation (oui c'est un stagiaire qui l'a fait, mais in-fine ca vient de chez vous).
De bonnes raisons peuvent être :
- rassurer des clients développant en utilisant vos programmes (quand à leur dépendance envers vous),
- partager le coût de maintenance d'un sous-systême d'utilité publique avec d'autres boites/developpeurs (si vous réussissez à les séduire),
- showcase (regardez comme on est bons)
- et finalement philantropie (mais à vendre au management, ca n'est pas toujours évident).
Viennent ensuite les limitations : Avez vous le droit d'opensourcer ce code ?
Ca peut sembler simple, mais si vous reposez sur une librairie non libre, avez du signer un NDA sur une documentation ou des exemples de codes .... c'est à vérifier.
Il est quasiment certain que le nom de la société doive apparaitre car sauf cas exceptionnel, les droits d'auteur sont à leur nom ayant payé (ou même juste fournit le cadre de travail) le stagiaire (à vérifier tout de même si la convention de stage ne donne pas des droîts à l'école/université sur le code en question).
Inclure le nom du developpeur me semble au minimum polit (a moins qu'il ne renie son oeuvre ;-) ), j'ai plus de doute sur l'obligation légale.
Reste la licence, si votre travail est directement dérivé de code GPL (ou en inclus) la réponse est simple : GPL, sinon c'est plus un choix stratégique.
La GPL ou LGPL à un avantage indéniable pour une entreprise : si un de vos concurents change la librairie, corrige des bugs ... il est normalement obligé de publier les changements si il distribue le programme l'utilisant (mais irez vous voir franchement ?).
Enfin il ne faut pas attendre de "miracles" de la "libération" du code :
- la majorité des utilisateurs ne contribueront pas,
- maintenir la version opensource de votre lib et la faire vivre requiers du temps,
- vous n'allez pas trouver magiquement de contributeurs parceque votre lib est bonne, une communauté est longue à batir et repose souvent sur une paire de personnes dévouées...
Bref ouvrir du code avec l'idée de le péréniser a un coût (au minimum en temps) qui peut être conséquent.
Sans doute bien nettoyer votre code (s'assurer en particulier qu'il ne dépende pas de votre environnement interne pour fonctionner), le documenter et créer un projet sur SourceForge (qui poste automatiquement sur Freshmeat) est-il un bon début.
Mais le préalable indispensable est que vous ayez le feu vert de l'entreprise (et des juristes, souvent trés réticents).
# Vaste probleme
Posté par Christophe Renard . En réponse au message Open source et boite privée. Évalué à 3.
Je bosse dans un boite ou nous avons abordée la même question.
La première question à se poser est "pourquoi open-sourcer" ?
Tout code ouvert sur l'extérieur va être un communication sur votre travail. Si il est inélégant, mal documenté, inefficace .... sic de votre réputation (oui c'est un stagiaire qui l'a fait, mais in-fine ca vient de chez vous).
De bonnes raisons peuvent être :
- rassurer des clients développant en utilisant vos programmes (quand à leur dépendance envers vous),
- partager le coût de maintenance d'un sous-systême d'utilité publique avec d'autres boites/developpeurs (si vous réussissez à les séduire),
- showcase (regardez comme on est bons)
- et finalement philantropie (mais à vendre au management, ca n'est pas toujours évident).
Viennent ensuite les limitations : Avez vous le droit d'opensourcer ce code ?
Ca peut sembler simple, mais si vous reposez sur une librairie non libre, avez du signer un NDA sur une documentation ou des exemples de codes .... c'est à vérifier.
Il est quasiment certain que le nom de la société doive apparaitre car sauf cas exceptionnel, les droits d'auteur sont à leur nom ayant payé (ou même juste fournit le cadre de travail) le stagiaire (à vérifier tout de même si la convention de stage ne donne pas des droîts à l'école/université sur le code en question).
Inclure le nom du developpeur me semble au minimum polit (a moins qu'il ne renie son oeuvre ;-) ), j'ai plus de doute sur l'obligation légale.
Reste la licence, si votre travail est directement dérivé de code GPL (ou en inclus) la réponse est simple : GPL, sinon c'est plus un choix stratégique.
La GPL ou LGPL à un avantage indéniable pour une entreprise : si un de vos concurents change la librairie, corrige des bugs ... il est normalement obligé de publier les changements si il distribue le programme l'utilisant (mais irez vous voir franchement ?).
Enfin il ne faut pas attendre de "miracles" de la "libération" du code :
- la majorité des utilisateurs ne contribueront pas,
- maintenir la version opensource de votre lib et la faire vivre requiers du temps,
- vous n'allez pas trouver magiquement de contributeurs parceque votre lib est bonne, une communauté est longue à batir et repose souvent sur une paire de personnes dévouées...
Bref ouvrir du code avec l'idée de le péréniser a un coût (au minimum en temps) qui peut être conséquent.
Sans doute bien nettoyer votre code (s'assurer en particulier qu'il ne dépende pas de votre environnement interne pour fonctionner), le documenter et créer un projet sur SourceForge (qui poste automatiquement sur Freshmeat) est-il un bon début.
Mais le préalable indispensable est que vous ayez le feu vert de l'entreprise (et des juristes, souvent trés réticents).
En tout cas, bon courage ;-)