Choisir une licence pour des projets open source

J'ai réalisé des projets open source et je prévois d'en faire plus à l'avenir. Jusqu'à présent, j'ai publié tout mon code sous GPL, mais j'ai lu quelques articles qui prétendent que la GPL est trop restrictive pour qu'un code soit utilisé dans un environnement d'entreprise. Ceci, soi-disant, réduit les contributions.

Voici ce que je voulais accomplir:

Pour des applications complètes :

• aucune utilisation commerciale à l'exception de la vente de support pour l'application (c'est-à-dire que l'application ne peut pas être vendue, mais tout ce qui l'entoure peut)

Pour les bibliothèques (composants, plugins, ...):

• peut être inclus dans des projets commerciaux sans modifications
• toute modification de la bibliothèque / du composant doit être open source (contribution en retour) - le reste du projet, commercial ou non, n'est pas affecté

Pour les applications, la GPL semble toujours le choix logique. Pour les bibliothèques, ma compréhension primitive des licences me fait penser que LGPL est un bon match, mais je ne suis pas sûr. J'ai regardé la licence MIT, et cela semble trop permissif.

La plupart du temps, je veux que les gens utilisent mon code où ils le souhaitent, tant que les améliorations sont apportées en retour.

Cela m'amène à ma (mes) question (s): LGPL est-il un choix logique pour les bibliothèques open source, les composants, les plugins, etc.? Y a-t-il une meilleure alternative? La GPL est-elle un bon choix pour mes applications ou y a-t-il quelque chose de mieux?

Mise à jour:

Pour ceux qui sont intéressés par ma décision finale, j'ai décidé de publier mes bibliothèques sous un régime multi-licences, MPL, LGPL et GPL. Cela permet à pratiquement tout le monde d'utiliser mon code sans aucune obligation, à moins qu'il ne le modifie sous MPL, auquel cas il devrait être réintroduit.

Cela signifie que le code peut être utilisé à la fois par la FSF et les logiciels propriétaires, mais une «mauvaise» exploitation commerciale est empêchée (ou du moins j'aimerais le penser).

Il me semble que GPL et LGPL sont ce que vous voulez pour vos projets.

• aucune utilisation commerciale à l'exception de la vente de support pour l'application (c'est-à-dire que l'application ne peut pas être vendue, mais tout ce qui l'entoure peut)

Attention, la GPL n'interdit pas de vendre l'application, et l'interdire rendrait en effet votre licence non libre, comme l'a observé Huperniketes. La seule chose que la GPL garantit est que l'entreprise qui vend le logiciel devrait également fournir gratuitement la base de code. Mais ils ne doivent pas fournir le logiciel package que-est gratuit. C'est une grande différence, car le code source d'un logiciel n'est pas un produit facilement utilisable.

Si vous voulez empêcher l'utilisation commerciale de votre logiciel, GPL ne le coupera pas. La GPL a tendance à être évitée par les entreprises commerciales dans les produits qu'elles vendent en raison de l'obligation de redistribuer la source modifiée, mais elles sont libres d'utiliser le logiciel GPL en interne. Cela ne veut pas dire que les entreprises ne sont pas configurées pour vendre des logiciels GPL ou construire du matériel autour des logiciels GPL (LinkSys, par exemple), mais la plupart des entreprises préfèrent ne pas partager leur produit avec leurs concurrents.

Je ne sais pas si la licence Creative Commons Attribution Non-Commercial No Derivatives est ce que vous voulez (la seule restriction que vous avez mentionnée est l' utilisation commerciale ), mais sinon, vous devrez peut-être préparer une licence pour vous par un avocat qui contient la langue octroyant les droits que vous souhaitez que les titulaires de licence aient.

De plus, une fois que vous commencez à inclure des restrictions telles que l'utilisation non commerciale et la non-modifiabilité , vous ne pouvez plus satisfaire aux critères d'une licence open source tels que définis par l' Open Source Initiative . Leur site répertorie également d' autres licences OSS approuvées . Peut-être qu'il y en a déjà un qui correspond à vos objectifs.

Et la définition adéquate de vos objectifs sera essentielle avant de sélectionner les droits et limitations que vous accordez aux utilisateurs de votre logiciel. La popularité est-elle plus importante que la modifiabilité ou la distribution ou l'utilisation ou…? Pensez à vos objectifs en publiant le code pour commencer, et dans quel esprit vous le faites ou les conditions dans lesquelles vous accordez l'accès peuvent avoir l'effet inverse.

Si vous vous souciez de vous assurer que votre code reste gratuit, de récupérer des améliorations et d'être sûr que tout le monde peut l'utiliser, alors MPL est la bonne licence pour vous. Il est gratuit à utiliser dans n'importe quel produit, y compris les logiciels commerciaux, sans restrictions de liens étranges et mystérieuses comme la LGPL l'impose. Il nécessite que quiconque utilise votre code et le modifie libère les modifications sous MPL, mais il ne touche ni ne restreint aucun des autres codes du projet.

Si vous avez écrit tout votre code (c'est-à-dire si vous êtes propriétaire de votre code), vous pouvez également le concéder sous licence double : publiez votre code dans GPLv3 par exemple et proposez de le vendre (avec une autre licence) à ceux qui souhaitent l'utiliser de manière moins restrictive.

(ceci est particulièrement pertinent pour une bibliothèque, car une bibliothèque éditée sous GPL ne peut être utilisée que sur un logiciel GPL).

Faites attention aux contributions externes ou aux correctifs que vous incorporez à votre code (puisque vous ne les possédez pas).

Que vous puissiez réellement postuler pour MPL ou uniquement GPL dépend d'une différence critique:

Les "droits ci-dessous" incluent le droit accordé aux destinataires de lier le "Code couvert" MPL à un code privé non MPL pour former une "Œuvre plus grande" (MPL 3.7 Œuvres plus grandes). GPL ne donne aucun droit à ses destinataires. Par conséquent, le destinataire ne peut pas modifier les conditions de licence pour appliquer la GPL au lieu de MPL.

Regardez ça .

Ce que cela signifie pour vous, c'est que si vous utilisez un composant qui est lui-même sous GPL, vous (probablement) ne pouvez pas libérer de code (qui l'utilise) sous MPL; MPL tentera à tort d'autoriser la redistribution du code GPL sous MPL, ce qui est incorrect. C'est très bien, si vos dépendances sont dans l'ordre de la licence MIT ou Apache.

En général, si vous ne faites pas mieux en choisissant MPL plutôt que GPL seul, sauf si vous utilisez déjà des trucs MPL. GPL s'assurera également que les contributions seront également publiées.

Il n'y a que le changement critique que MPL apporte, c'est la protection contre les atteintes aux brevets induites sans le savoir. Comme le dit la licence:

Il n'est pas acceptable pour quelqu'un de créer une modification pour laquelle il ou elle a un brevet, de rendre la modification disponible gratuitement comme l'exige la licence, puis de revenir et d'essayer de facturer à tous les droits de brevet.

MPL et GPL ne sont pas tout à fait compatibles.

Vous pouvez voir ici: MIT contre BSD contre double licence pour une discussion sur l'implication des doubles licences.

Personne ne semble en parler, mais vous pourriez envisager une licence Creative Commons. Ils ont une gamme de licences (ou une que vous adaptez à vos besoins, envisagée différemment).