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

26

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?

Allan P. Engsig-Karup
la source
Bonne question, je me posais aussi la question.
milancurcic
Ce n'est pas pertinent pour ce site. Je recommanderais de publier sur quelque chose comme Stack Overflow.
aterrel
Je veux juste corriger la déclaration de Matt selon laquelle les logiciels sous licence GPL / LGPL ne peuvent pas être utilisés commercialement. Ça peut aussi! Les logiciels sous licence GPL peuvent être utilisés pour tout ce qu'une entité commerciale veut, ils ne peuvent tout simplement pas créer un produit logiciel dérivé et le vendre (distribuer) en tant que source fermée (ce qui devrait être suffisant si l'entité commerciale n'est pas une société de logiciels). La LGPL est plus permissive et permet de vendre des produits logiciels fermés qui sont liés à la bibliothèque d'origine. Je suis d'accord avec Matt sur le fait que l'industrie a peur de toucher au logiciel GPL mais il est basé sur une conception erronée de la GPL. Nous avons utilisé à l'origine
Anders Logg
1
Je ne suis pas d'accord. Beaucoup de gens investissent beaucoup de temps et d'efforts dans le développement de nouvelles bases de code pour résoudre des problèmes complexes en science informatique. Dans le cadre de cet effort, il peut être utile d'avoir une stratégie pour partager le travail avec les autres.
Allan P. Engsig-Karup,
2
Oui et beaucoup de gens en informatique passent du temps à cuisiner, mais la cuisine est hors sujet ici. Il existe d'autres échanges empilés pour les problèmes logiciels de base.
aterrel

Réponses:

18

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.

À 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.

Mark Booth
la source
12

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).

Matt Knepley
la source
Comment le développement du PETSc a-t-il été financé? et comment est-il soutenu (par le financement) aujourd'hui? Comment cela fonctionne-t-il avec la maintenance de la base de code pour PETSc?
Allan P. Engsig-Karup,
2
Voici le financement . Nous avons un référentiel ouvert et de nombreux contributeurs.
Matt Knepley
À propos de votre déclaration sur le code GPL: OpenFOAM est GPL et largement utilisé dans l'industrie. La raison en est que le code GPL ne doit être rendu public que si le logiciel doit être distribué. Seules les entreprises qui souhaitent vendre leur code à un large public seraient concernées par la licence GPL.
akid
3
@akid Je ne trouve pas d'informations sur les utilisateurs d'OpenFOAM sur le site Web, mais je suis sceptique quant à la caractérisation "largement utilisée". Je peux vous dire que des gens de grandes entreprises (Shell, Boeing, MS) ont déclaré que la politique de l'entreprise en matière de code de recherche est de ne jamais toucher à la GPL. Peut-être que les petites entreprises ont plus de latitude, mais les plus grandes veulent simplement éviter même l'apparence d'une irrégularité (en regardant le code GPL et en codant autre chose).
Matt Knepley
2
@Tshepang GNOME et Linux sont utilisés comme des fournitures de bureau, ce qui n'arrivera jamais à votre code scientifique. Je veux dire lorsque votre code est utilisé à des fins directement liées à l'entreprise.
Matt Knepley
5

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?

mbq
la source
1
N'oubliez pas que si le code n'a pas de licence, dans la plupart des pays (qui ont adhéré à la convention de Berne ), il est toujours couvert par le droit d'auteur, il ne peut donc pas être légalement utilisé par une personne autre que le titulaire du droit d'auteur, et encore moins redistribuée.
Mark Booth
@MarkBooth C'est mon point.
mbq
5

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é.
Khinsen
la source
5

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.

Daniel Standage
la source
5

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.)

Szabolcs
la source
4

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.

Fomite
la source
4

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é.

qubyte
la source
4

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.

winwaed
la source
Je ne suis pas celui qui a voté contre, et je voudrais en fait voter comme il semble que vous préférez la licence BSD et plus de détails sur les raisons pour lesquelles cela pourrait être intéressant. Cependant, il a un problème. Le langage utilisé est provocateur. Exactement, les mêmes informations peuvent être communiquées sans la bile, et vous obtiendrez probablement plus de personnes avec votre message.
qubyte
@ MarkS.Everitt: Mis à part le commentaire sur la politique, qu'est-ce qui est exactement ici provocateur?
aeismail
Ouais, aucune bile n'était destinée. Mon commentaire sur la politique GPL est une opinion personnelle mais aussi une observation - j'ai supposé que le vote
négatif
Prenez par exemple votre phrase d'ouverture. C'est un moi immédiat contre vous , qui se poursuit dans la phrase "Contrairement à quoi ...". Cela ne devrait pas avoir d'importance, mais malheureusement c'est le cas. C'est également une pente glissante pour générer des arguments, et un jeune SE n'en a pas besoin.
qubyte
La première phrase définit le contexte de ma réponse - TOUS écrivent à partir de leurs propres expériences, qu'ils l'admettent ou non. Le contexte est important - et je pensais que c'était particulièrement vrai pour moi. J'essaierai de modifier le paragraphe suivant, mais je peux simplement abandonner et supprimer le tout. Je pensais avoir quelque chose d'utile à dire ...
winwaed
0

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.

Daniel Shapero
la source