Raisons pour ne pas ouvrir le code source à but non lucratif? [fermé]

Je suis un grand fan de code source ouvert. Je pense que je comprends la plupart des avantages de l'open source. Je suis un chercheur étudiant en sciences et je dois travailler avec une quantité assez surprenante de logiciels et de codes qui ne sont pas open source (qu'ils soient propriétaires ou non publics). Je ne vois pas vraiment de bonne raison à cela, et je peux voir que le code et les personnes qui l'utilisent gagneraient certainement à être plus public (sinon rien, en science, il est essentiel que vos résultats puissent être reproduits si nécessaire, et c'est beaucoup plus difficile si les autres n'ont pas accès à votre code).

Avant de commencer à faire du prosélytisme, je veux savoir: existe-t-il de bons arguments pour ne pas publier le code sans but lucratif avec une licence conforme à l'OSI?

(Je me rends compte qu'il y a quelques questions similaires , mais la plupart se concentrent sur des situations dans lesquelles le code est principalement utilisé pour gagner de l'argent, et je ne pouvais pas avoir beaucoup de pertinence dans les réponses.)

Précision: par "sans but lucratif", j'intègre les motivations de profit en aval, telles que la reconnaissance de la marque par la société mère et les attentes des investisseurs en matière de profit. En d'autres termes, la question ne concerne que les logiciels pour lesquels il n'y a AUCUN motif de profit lié au logiciel.

Vous devez prendre en compte le fait que l’approvisionnement en source ouverte de votre code peut nécessiter des efforts supplémentaires.

Par exemple, dans cette entrée de blog, l’ingénieur Sun / Oracle décrit les efforts qu’ils ont dû déployer lorsqu’ils utilisaient un code source ouvert : Open Source ou Dirty Laundry?

Alors que nous nous apprêtons à plonger dans le monde du logiciel libre, l’une des nombreuses activités en cours est la préparation du code pour l’utilisation libre. Il y a des choses évidentes à faire. Par exemple, notre code source comprend un mélange de code que nous avons écrit et de codes que nous avons autorisés par d'autres. Nous devrons séparer ces derniers et ouvrir le code source uniquement les éléments de code appropriés.

Une autre activité de préparation consiste à "nettoyer" le code des informations exclusives, à mentionner des clients particuliers, des développeurs, des technologies, etc. Ceci est un peu moins évident, mais considérons l'exemple suivant:

/\*
 \* HACK - insert a time delay here because the stupid Intertrode
 \* Technologies framebuffer driver will hang the system if we
 \* don't. Those guys over there must really be idiots.
 \*/

Bien que tout ce qui précède puisse être vrai, nous entretenons probablement une relation avec Intertrode Tech. Des commentaires de ce type dans le code pourraient nuire à notre activité et il faudrait donc la supprimer. On pourrait soutenir que cela n'aurait pas dû être là en premier lieu, mais le moment est venu de le supprimer.

Une autre partie de l'activité de "nettoyage" consiste à éliminer les blasphèmes et autres mots "indésirables" ...

Notez que toutes les modifications ci-dessus ont dû être apportées au code considéré comme parfaitement correct comme source fermée - ce qui en fait un effort supplémentaire pour ainsi dire.

Sécurité.

Par exemple, imaginons que vous construisiez un framework Web et que vous l'utilisiez vous-même.

En tant que projet à but non lucratif, vous n'avez pas eu le temps de consacrer le temps nécessaire à l'inspection de chaque bit de code pour vérifier sa vulnérabilité à une attaque ou à une autre:

• CSRF
• XSS
• Injection SQL
• Fixation de session
• Utilisation de bibliothèques tierces boguées ou même de langages

Maintenant que vous avez ouvert le projet en mode source ouverte, vous permettez à des utilisateurs sympathiques de contribuer, mais vous permettez également à des utilisateurs malveillants de bénéficier d’une visibilité complète sur votre travail. Si un serveur qui exécute votre code est trouvé, vous ne pouvez plus masquer votre imperfections dans l'obscurité.

Bien entendu, cela peut ne pas s'appliquer au type de logiciel sur lequel vous travaillez; et comme toujours, l' obscurité n'est pas une excuse pour la paresse en sécurité.

Cependant, tout comme je l’ai trouvé dans quelques-uns des niveaux que j’ai obtenus dans Stripe , c’est le code qui est le moyen le plus facile de trouver des vulnérabilités (et parfois même le seul moyen).

Une bonne raison de ne pas ouvrir le code source est que certaines de vos sources peuvent être protégées par des droits d'auteur. À quelle fréquence ne cherchez-vous pas sur le Web une solution rapide à un problème et ne prenez-vous que l'extrait de code que vous trouvez?

Eh bien, ceux-ci peuvent être protégés par le droit d'auteur et je ne sais pas si l'auteur souhaite que son code soit redéfini sous une licence différente.

Vous devez faire attention à la manière dont vous choisissez votre licence pour éviter tout problème de responsabilité.

Un avocat peut être une meilleure personne pour parler de cela, mais l'idée générale est de savoir ce qui se passe si quelqu'un utilise (ou abuse) la demande et qu'elle cause un préjudice? Êtes-vous responsable? Évidemment, cela dépend du type de logiciel que vous écrivez, mais vous devez toujours faire attention à ce que votre licence dit à propos de votre responsabilité. Cela peut être une tâche délicate à résoudre, il est donc plus facile de ne pas publier le code source.

Avertissement: je ne suis pas un avocat .

Eh bien, s'il s'agit d'un organisme à but non lucratif et que sa propriété intellectuelle est étroitement liée au code du logiciel, certains voudront peut-être le protéger pour qu'il ne soit pas réutilisé commercialement ou même exploité de manière abusive pour créer des copies conformes de votre logiciel.

Parmi les autres raisons - qui sont probablement profondément ancrées dans la première, en fait -, il y a dans votre cas une grande partie de la recherche haut de gamme réalisée avec un financement privé et les investisseurs veulent généralement un retour sur investissement. Et jusqu'à présent, tous les acteurs de l'industrie du logiciel (ou les nouveaux venus) n'ont pas été totalement convaincus de la viabilité du modèle open source (probablement par manque de connaissance et de compréhension de la gestion des licences, ou par la simple crainte que la licence ne prévienne les logiciels malveillants). utilisations et copies).

En outre, ces entreprises ne veulent pas être poursuivies en justice par ceux qui ont tenté de réaliser un profit sur leur dos, et la licence est considérée comme une garantie à cet égard également, avec raison ou non.

Cela peut ne pas sembler être le cas, mais peut-être que les organisations à but non lucratif SONT rentables pour leurs fondateurs ou leurs investisseurs. Les avantages ne sont tout simplement pas directs. Ils ont donc tout intérêt à ce que les NFP se développent et ne se fassent pas imposer par des concurrents (même si vous ne penseriez pas non plus à des "concurrents" sur le marché des organismes à but non lucratif), et ils souhaitent préserver leur La propriété intellectuelle, même si cela ne vous coûte pas plus cher, examinez leur code pour trouver les problèmes et l’améliorer rapidement.

Notez également que les lois sur le droit d'auteur diffèrent d'un pays à l'autre. De nombreux pays européens considèrent par exemple que les lois américaines sur le droit d'auteur et le système américain des brevets sont plutôt sidérés, de sorte qu'il existe un contexte culturel et un poids qu'il est difficile de faire disparaître.

Jut mes 2 cents sur le sujet.

(J'ai beaucoup travaillé avec des universités et récemment en bioinformatique et en santé ... C'est une question récurrente pour moi et mes collègues :))

Il existe au moins deux types d'open source différents.

Si votre attitude est "voici quelque chose d'utile, j'en ai fini" (et cela s'avère être exact), alors il y a peu d'inconvénients.

D'autre part, si votre attitude est "je suis vraiment excité et je veux que de vrais utilisateurs aident à conduire le développement futur", alors réfléchissez très attentivement. Vous devrez passer du temps à aider les utilisateurs, dont beaucoup n’ont aucune idée de ce qu’ils sont. Vous devrez prendre en compte les demandes conflictuelles concernant des fonctionnalités et des améliorations. Vous constaterez qu'il est de plus en plus difficile d'apporter des modifications afin de préserver la compatibilité ascendante.