Est-ce important pour vous qu'un logiciel soit «source disponible» mais pas «open source»

Vous connaissez probablement la liste des licences open source officiellement approuvées par l'OSI. Plus particulièrement, je suppose que ce serait la GPL, le MIT, [insérez votre licence préférée ici].

J'ai récemment rencontré un projet qui, bien qu'il soit open source (le créateur a mis à disposition tout le code source), n'était pas officiellement open source sous l'une de ces licences officielles.

• Il a publié la source, mais n'a fait aucune promesse de publier la source à l'avenir.

• Il a permis des suggestions de modification, mais n'a fait aucune promesse d'accepter les correctifs et a interdit la distribution externe des versions corrigées en externe.

• Il a permis l'utilisation du logiciel dans des projets commerciaux ou payants, mais a interdit la vente du logiciel lui-même.

Je suppose que cela pourrait être appelé "source disponible" et non open source comme nous aimons y penser.

Je peux voir pourquoi l'équipe de direction d'une entreprise ne voudrait pas faire des affaires avec ce logiciel. Ils ne peuvent pas le débourser, ils ne peuvent pas le vendre, ils ne peuvent pas créer leur propre version du logiciel et le distribuer ou le vendre.

Mais est-ce important pour vous en tant que membre d'une équipe d'ingénierie logicielle qui n'utilise que ce logiciel? Je peux toujours faire mon travail avec, je peux l'utiliser dans un projet pour lequel je suis payé (mais je ne peux pas vendre le logiciel lui-même, ce que je ne fais pas de toute façon), et je peux apporter des modifications au code pour qu'il se comporte différemment selon mes besoins (mais je ne peux pas rendre ces modifications publiques), et si je veux que ces modifications soient officiellement mises à la disposition des autres, l'approbation appartient au projet lui-même et ils choisissent si pour les incorporer dans une version officielle ou non.

Nous savons donc qu'une entreprise qui souhaite baser son activité sur ce logiciel «source disponible» ne peut pas le faire, mais en tant que membre de l'équipe d'ingénierie logicielle, ces différences vous importent-elles ou semblent-elles moins pertinentes?

Curieux de savoir ce que les autres en pensent.

Pour les projets qui auraient dû développer à partir de zéro les fonctionnalités fournies par ce logiciel, il est très pratique de ne pas le faire.

Mais si un package open source comparable serait meilleur dépend d'autres facteurs:

• sera-t-il utilisé pour fournir un service ou le regrouper dans le cadre d'un autre produit?
• ont-ils les ressources nécessaires pour améliorer et maintenir le produit indépendamment?
• y a-t-il un avantage concurrentiel à utiliser ce logiciel par rapport à la version open source (soit dans le code, soit dans la gestion de projet)?

Répondre à ne à aucun de ces facteurs indique l'OSS est un meilleur choix.

La plupart du temps, le code lui-même n'est pas le facteur déterminant. Il faut examiner la situation dans son ensemble.

Les projets SIDEBAR OSS ne peuvent pas légalement garantir qu'ils garderont les futures versions ouvertes ou qu'il y aura de futures versions. C'est une des raisons pour lesquelles avoir une licence ouverte est si avantageux. De plus, les projets OSS ne sont pas tenus d'accepter les correctifs des contributeurs (en particulier sans transfert de propriété ou de droits).

La question pour cela et pour toute autre bibliothèque externe est la maintenance .

Quelle est la durée de vie de votre application et quelle est la durée de vie apparente de cette bibliothèque? Espérons que le vôtre soit le plus court.

Qui fera les corrections de bogues pour cette bibliothèque? À partir d'ici, votre entreprise devrait allouer explicitement des ressources à l'avenir pour la maintenance de ce logiciel, car vous ne pouvez pas compter sur d'autres bogues de correction pour vous. Vous ne pouvez pas partager le fardeau de la maintenance avec quelqu'un d'autre car vous ne pouvez pas partager la source. Vous voulez traquer un bug de condition de course insaisissable dans un code que vous ne connaissez pas?

Cette seule pensée pourrait rendre la bibliothèque trop coûteuse à utiliser.

Cela peut ne pas être pertinent si la bibliothèque est très solide et robuste et facile à travailler au niveau source, mais mon expérience est que la pression des pairs de véritables projets open source améliore simplement le code parce que vous avez tendance à faire de votre mieux à ce moment-là.

Personnellement, je penserais très attentivement si j'adoptais ce code ou tout autre code externe, car toute la raison d'utiliser le code d'autres peuples est que vous n'avez pas à vous en occuper vous-même . Pensez également aux futurs responsables - vous devriez faire des exercices d'incendie en changeant le code dans la bibliothèque pour voir si cela peut être fait du tout. Il pourrait y avoir de TRÈS mauvaises surprises ici.

Êtes-vous libre de discuter de la bibliothèque en question?

Pour être honnête, je ne vois pas pourquoi l'équipe de gestion d'une entreprise aurait des problèmes à utiliser une telle bibliothèque «source disponible». En ce qui concerne l'intégration dans leur propre produit, ils peuvent simplement le considérer comme une bibliothèque open source.

Pour moi, en tant que programmeur, peu importe si une bibliothèque est "open source" ou "source disponible". Je préfère ne pas apporter de modifications locales à une bibliothèque externe, car cela signifie une charge de maintenance supplémentaire. Non seulement lorsque des bogues sont détectés dans mes modifications locales, mais également lors de l'intégration de ces modifications encore et encore lorsqu'une nouvelle version de la bibliothèque sort.

Les seules situations où, à mon humble avis, "open source" bat la licence "source disponible" décrite dans la question est quand

• la licence de notre produit nécessite également la divulgation des sources des bibliothèques contenues
• nous sommes en train de produire une version améliorée / étendue de la bibliothèque

C'est pourquoi la Free Software Foundation utilise les termes «gratuit» ou «non libre» pour décrire les logiciels. Ils ne font pas référence au prix, mais aux restrictions qui sont placées sur l'utilisation ou la distribution du logiciel.

Il semble que vous ayez rencontré l'un des rares cas de coin où vous avez un accès complet au code source de quelque chose, mais le logiciel n'est pas "Open Source" selon la définition OSI .

L'un ou l'autre terme a la capacité de devenir un terme impropre. J'ai payé 50 $ pour ma première copie d'emacs (sur bande QIC), mais emacs est un logiciel gratuit . J'ai le code source de certaines applications propriétaires que mon entreprise utilise en interne, mais elles ne sont pas open source.

La chose qui soulève le plus gros drapeau rouge (du moins pour moi) n'est pas la garantie d'accéder au code source des futures versions. Si vous dépendez fortement de pouvoir modifier cet outil, je serais prudent. Même si vous avez un accord verbal avec le fournisseur que vous aurez toujours le code, sauf s'il est sous forme de contrat .. cet accord n'a jamais eu lieu.

En tant que CTO, je fais de mon mieux pour m'assurer que nous ne dépendons pas de logiciels non libres. J'ai été à plusieurs reprises dans le mauvais sens du blocage des fournisseurs dans le passé, une erreur que j'aime éviter. Bien que nous utilisions des éléments exclusifs, notre entreprise ne subirait pas de difficultés excessives si, soudainement, nous ne pouvions plus les utiliser.

Il me semble que vous construisez des trucs autour de ce logiciel et de l'accès au code, donc je recommanderais d'obtenir quelque chose par écrit qui dit que vous aurez toujours accès. Que se passe-t-il si le vendeur est acheté?

Cela importe beaucoup. Principaux problèmes avec l'approche "source disponible" que vous avez décrite:

• Vous ne contrôlez pas votre destin technologique si vous n'avez pas la liberté de modifier la source. Souvent, le piratage direct de la source peut être préférable à une solution de contournement compliquée.
• Vous n'avez aucune garantie que le logiciel continuera à être maintenu, et vous n'avez pas la possibilité de le faire vous-même que vous obtenez avec une véritable source ouverte.
• Comme cela ressemble à une licence personnalisée, vous avez probablement un plus grand risque juridique par rapport à l'utilisation de quelque chose de bien connu et prouvé comme les licences GPL ou BSD.
• S'il ne s'agit pas d'une véritable source ouverte, vous n'obtiendrez pas le même niveau de communauté utile autour d'elle, ce qui est un avantage majeur pour de nombreux projets open source

Ma suggestion: essayez de persuader le créateur de publier le logiciel sous une licence open source. Cela devrait être un gagnant / gagnant pour tout le monde - vous parce que vous obtenez le logiciel que vous voulez sous licence open source, le créateur parce que rendre le projet open source est susceptible de rendre le logiciel beaucoup plus efficace à long terme.