Recommandations et expériences sur quelle licence choisir pour le logiciel?

Les développeurs de logiciels ont le choix de choisir une licence appropriée en fonction des objectifs du travail.

Quelqu'un peut-il donner des recommandations / expériences sur quelle licence choisir pour le logiciel?

Quels sont les avantages / inconvénients de "donner" tout le travail codé en tant que codes open source?

Comment traiter avec les acteurs industriels qui souhaitent bénéficier du code de la recherche?

Quelqu'un peut-il donner des recommandations / expériences sur quelle licence choisir pour le logiciel?

La licence que vous choisirez dépendra de la gratuité de votre code, mais la gratuité signifie différentes choses pour différentes personnes.

• Pour les partisans de permissives licences, libres moyens permettant aux gens maintenant d'utiliser le logiciel mais ils veulent en ce moment , ne pas se soucier de la façon dont sans dérivation future sont.
• Pour les partisans des licences de copyleft , la gratuité signifie que le logiciel et toute dérivation de celui-ci restent libres , étant prêt à sacrifier certaines libertés immédiates pour garantir cela.

Plus une licence est permissive, plus les gens pourront l'utiliser, mais moins vous en aurez le contrôle. Cependant, plus il est restrictif, plus vous risquez de dissuader les gens d'utiliser votre logiciel en premier lieu.

Il existe un certain nombre de licences libres et open source, notamment GPL <= 2, GPL 3 , LGPL , BSD , Eclipse et ainsi de suite. Il y a des avantages et des inconvénients à chacun, alors lisez les restrictions qu'ils imposent sur le code et décidez qui vous voulez pouvoir l'utiliser. Avertissement , selon votre choix quelqu'un se plaindra - c'est la guerre sainte territoire.

Dans l'ensemble, il s'agit d'un subtil équilibre, et cela dépend beaucoup du public cible de votre logiciel.

• Le différenciateur de licence interactif très complet d'Oxford Universities OSS Watch est une excellente ressource pour déterminer quelle licence vous convient le mieux .

À mon avis, les licences permissives et copyleft sont appropriées pour le code scientifique - l'important est que le code soit open source en premier lieu. Je pense que la science doit être ouverte, tout comme le code utilisé pour soutenir cette science.

Quels sont les avantages / inconvénients de "donner" tout le travail codé en tant que codes open source?

L'idée de donner votre logiciel est que si d'autres le trouvent utile, ils l'utiliseront.

S'ils l'utilisent, ils trouveront, rapporteront et corrigeront souvent des bogues, ce qui vous évitera de faire de même.

S'ils l'aiment et que votre logiciel fait presque ce qu'ils veulent, ils pourraient améliorer votre logiciel et apporter ces améliorations.

Cela fait beaucoup de ifs bien.

Comment traiter avec les acteurs industriels qui souhaitent bénéficier du code de la recherche?

Premièrement, si vous souhaitez interdire l'utilisation commerciale de votre code, vous pouvez sélectionner une licence avec une clause de non-réutilisation commerciale.

Deuxièmement, si vous pensez que quelqu'un pourrait utiliser votre logiciel pour alimenter un service, sans jamais réellement distribuer le code à quelqu'un d'autre, alors vous pourriez envisager l' Affero GPL qui comble cette faille particulière du copyleft.

Troisièmement, vous pouvez faire ce qui précède et offrir une option de double licence. Offrir des licences GPL ou AGPL pour le téléchargement public et des licences commerciales payantes vous offre le meilleur des deux mondes et signifie que vous pourriez même être en mesure de générer des revenus des ventes commerciales de votre logiciel qui peuvent aider à soutenir vos activités scientifiques.

Notez que si vous allez le faire, offrez-le dès le départ - cela causera probablement moins de friction de vos contributeurs open source que de commencer à offrir des licences commerciales plus tard. Si votre communauté devient populaire, vous ne voulez pas que les gens vous accusent de vendre si vous n'étiez pas sûr de la possibilité d'une exploitation commerciale plus tard. Idéalement, vous devez configurer un contrat de licence de contributeur (CLA) approprié avant de commencer à accepter des contributions de tiers dans votre base de code.

Cette réponse à cette question fournit également de bonnes informations sur cette option.

PETSc utilise cette licence , qui est une forme moins restrictive de BSD . La différence cruciale avec GPL, c'est que le logiciel peut être utilisé commercialement. Beaucoup de gens ont une objection de principe aux logiciels fermés, mais d'après mon expérience, aucune entreprise ne s'approchera de votre code s'il dispose d'une licence GPL. De plus, les utilisateurs industriels de PETSc ont été incroyablement précieux. Ils ont tendance à poser des problèmes assez complexes, que la plupart des universitaires trouveraient plus difficiles que ce qui est justifié pour une publication. Ils ont également contribué beaucoup de code à PETSc, afin qu'il entre dans la chaîne de support normale. Je déconseille toute licence sans potentiel d'utilisation commerciale et préconise en fait la licence la moins restrictive possible (vous pouvez certainement graver PETSc sur un CD et essayer de le vendre à la crédule).

J'utilise la GPL, principalement en raison du sentiment suscité par le mouvement open source d'origine (et j'espère donc qu'il contribuera à sa propagation). De plus, c'est paradoxalement le meilleur moyen de protéger vos revenus potentiels des capitalistes immoraux - en tant qu'auteur, vous pouvez toujours distribuer le code sur une licence différente en parallèle et ainsi conserver une version propriétaire pour une utilisation commerciale en marque blanche.
Cependant, cela peut également être un problème - votre source de financement pourrait faire une mise en garde que tout votre travail devrait devenir du domaine public, ce qui va au-delà de cette licence.

Quoi qu'il en soit, la chose la plus importante dans ce sujet est que toute licence est meilleure qu'aucune, ce qui est malheureusement assez souvent dans le monde du développement scientifique - et je déteste tout cela / * Volé du programme de John Smith qu'il n'a jamais rendu public * / ou CI pense que j'ai vu ça dans le billet de Jane Smith sur un groupe en 1995 ... ou peut-être 1993?

Premièrement, les avantages / inconvénients de l'open source:

Pro: plus de gens utiliseront votre code, fourniront des commentaires, des corrections, des améliorations, etc. Vous finirez par avoir un meilleur code et plus de gens qui lui feront confiance.

Inconvénient: si jamais vous voulez fonder une entreprise dans votre code, vous avez moins d'options (mais il y en a encore quelques-unes, comme la vente de services de conseil)

Quant au choix d'une licence, je procéderais dans l'ordre suivant:

1. Votre employeur / organisme subventionnaire impose-t-il quelque chose? Ensuite, vous n'avez pas le choix. Cochez cette case pour tous les contributeurs au code.
2. Réutilisez-vous du code qui a une licence particulière qui limite votre choix? Ensuite, vos choix sont également limités. En pratique, l'intégration de morceaux de code sous licence GPL est la source la plus fréquente de ces limitations.
3. Décidez de ce que vous appréciez le plus: la philosophie tout code devrait être ouverte derrière la licence GPL et les licences similaires, ou la philosophie d'utilisation la plus large possible derrière la licence BSD.
4. Dans chacune des deux grandes familles de licences Open Source, choisissez en fonction de ce qui est le plus courant / accepté dans votre communauté.

La plupart de mes recherches sont financées par des fonds publics, et je me sens donc obligé d'utiliser la licence la moins restrictive possible. Si d'autres personnes dans mon pays aident à payer pour cette recherche, ai-je vraiment le droit de leur dire qu'ils ne peuvent pas intégrer mon code dans une distribution logicielle fermée et / ou commerciale? Je m'attends à ce que la plupart des personnes qui utilisent mon code soient des scientifiques universitaires, mais je n'ai aucun problème philosophique avec les entreprises à améliorer mon logiciel en l'intégrant à d'autres logiciels (éventuellement commerciaux), en y mettant une interface graphique, etc., pour livrer un produit qui les aide à faire du profit.

Cela étant dit, j'essaie d'utiliser des licences qui nécessitent une attribution appropriée. Par exemple, si une entreprise plie mon code en un produit commercial plus grand, je veux qu'elle indique clairement que mon code peut être obtenu gratuitement auprès de moi. Mais à part ça, je veux imposer le moins d'exigences possible aux utilisateurs de mon code.

Pour le développement de logiciels qui n'est pas financé par l'argent des contribuables, je comprends que d'autres licences peuvent être plus appropriées.

Personne ne l'a expliqué très clairement, donc je pense que cela vaut la peine de dire:

Certaines licences open source (notamment: la GPL) sont "virales" dans le sens où chaque fois que le code est utilisé dans un nouveau projet, le nouveau projet doit être concédé sous licence de la même manière. De plus, le code ne peut pas être lié (à certains égards) à un code sous licence différent.

Une conséquence pratique est:

• Si vous implémentez une nouvelle méthode numérique en C, la licence ne permettra pas de l'appeler à partir de logiciels courants comme MATLAB ou Mathematica

• Si vous implémentez un nouvel algorithme de traitement d'image, la licence ne permettra pas d'en faire un plugin Photoshop

• etc ...

Cela empêchera non seulement la réutilisation commerciale, mais aussi la réutilisation pratique par d'autres universitaires (s'ils utilisent un logiciel fermé), et si quelqu'un s'appuie sur votre code, cela les empêchera de donner leur travail dans un "do" "ce que vous voulez".

C'est quelque chose que vous devez considérer avant de terminer la formulation de votre licence.

Je l'exprime ainsi parce que j'ai rencontré des gens (pas très familiers avec les licences open source) qui n'étaient pas au courant de cela, ou qui ne l'ont pas considéré sous cet angle.

^{(Ce n'est qu'une opinion personnelle, mais je pense que l'application de telles restrictions au travail qui vient du milieu universitaire (financé par les fonds publics) n'est pas appropriée. Donc, soit je garde le code, soit je le donne.)}

Quelle que soit la licence que vous choisissez, n'oubliez pas de parcourir attentivement tous vos accords de financement pour vous assurer qu'il n'y a pas de clauses qui dictent ou restreignent la façon dont vous pourriez procéder pour octroyer une licence pour votre logiciel.

Je sais que dans mon cas, beaucoup de mes projets sont construits à partir de plusieurs couches de financement, un peu ici et un peu là, et en gardant une trace de la façon dont je suis autorisé à autoriser mes affaires par les personnes qui gardent les lumières allumées et les machines en marche sont assez complexes.

Pour les grands corps de code, je choisis l'une des licences décrites dans les autres réponses, et généralement LGPL. Cependant, bien que ce ne soit généralement pas recommandé pour les logiciels , pour les petits scripts autonomes que je peux envoyer à un collègue de l'industrie, j'opte souvent pour une licence Creative Commons . En effet, ils ont tendance à être plus clairs pour la personne à qui j'envoie le code, ce qui évite tout problème potentiel de malentendu. Cela a bien fonctionné pour moi dans le passé.

Contrairement à la plupart des personnes qui répondent ici (qui travaillent dans des organisations académiques et / ou publiques), je travaille dans le domaine commercial.

Pour mes produits, le code est fermé et cela continue à présenter des avantages commerciaux majeurs. Mais il y a bien sûr d'autres façons de le faire (par exemple comme démontré par MySQL entre autres). Je vois souvent l'approche de licence commerciale LGPL + pour les bibliothèques. Je n'ai pas encore utilisé une telle bibliothèque dans un système commercial, mais je ne l'exclurais pas (jusqu'à présent, je n'ai utilisé que de telles bibliothèques, par exemple ALGLIB, au niveau de la R&D). Cela contraste avec un produit GPL - que je pourrais utiliser en interne mais que je n'utiliserais jamais dans un produit, principalement en raison de la nature virale.

Lorsque je publie du code source (exemples de procédures, programmes gratuits, etc.), j'utilise généralement la licence Berkeley. Cela semble être beaucoup plus dans l'esprit du code "libre", avec attribution mais sans les chaînes GPL et la politique. C'est peut-être la raison pour laquelle elle (ou des licences similaires telles que la licence MIT) sont si populaires auprès des universités et des organismes publics. Le code source est donné dans le vrai sens de `` gratuit '' (voici du code, faites ce que vous voulez avec lui) mais l'auteur obtient toujours un crédit / attribution.

C'est une vieille question, mais je pense que la licence publique de Mozilla mérite d'être mentionnée comme un compromis entre les licences permissives (BSD, MIT) et les licences copyleft fortes (GPL). Le code MPL peut être utilisé et redistribué, mais le code MPL et ses modifications doivent être disponibles. Par exemple, une entreprise peut prendre du code MPL, y apporter ses propres améliorations et le distribuer dans un progiciel propriétaire à code source fermé, tant qu'elle met à disposition sa version modifiée du code MPL d'origine. Ils ne sont pas obligés de publier tout leur propre code source, comme ils le feraient avec GPL.

Avec la licence BSD, il y a la crainte qu'une entreprise puisse prendre votre code et l'améliorer sans vous redonner ces contributions ou la communauté dans son ensemble, sous prétexte que les améliorations qu'elles lui apportent lui confèrent un avantage concurrentiel. (La réponse de Matt Knepley suggère cependant que tous n'agissent pas de cette façon). D'un autre côté, beaucoup de gens pourraient éviter complètement le code GPL. Le MPL évite ces deux pièges potentiels, du moins en principe.