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

34

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.

rien101
la source
+1 car je trouve cette question intéressante moi-même. Mais je me demande si c'est le bon endroit pour poser cette question. Peut-être auriez-vous des perspectives différentes des autres sites SE, comme le site PM.SE. Juste une suggestion.
Hayem
@haylem, je n'avais pas vu PM.SE, mais il semble que ce soit davantage pour les aspects techniques de la gestion de projet?
naught101
Entretenez-vous activement le projet par la suite ou s'agit-il d'un cimetière de code? En d'autres termes, quel est l'avenir du projet?
@ ThorbjørnRavnAndersen: oui, j'assume la maintenance, le développement et l'utilisation actifs du code.
naught101

Réponses:

28

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.

moucheron
la source
2
Eh bien, cela s'applique aux grandes entreprises avec une base de code existante, encore moins au code écrit pour être Open Source à partir de zéro.
Konrad Rudolph
1
@KonradRudolph OP a mentionné que je dois travailler avec ... du code qui n'est pas open source (que ce soit propriétaire ou non public), ce qui signifie qu'il n'a pas été là à partir de rien
gnat
Est-ce que la même chose n’est pas arrivée avec DOOM 3? Un numéro de brevet
retarde la
11

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

Nicole
la source
7
Ce débat dure depuis des siècles, et j’avais l’impression que l’open source était préférable pour la sécurité, mais seulement si le projet était assez populaire (du moins chez les développeurs). Il est étrange que les arguments ne soient pas vraiment clairs sur le net (que je peux trouver de toute façon).
naught101
1
En combinaison avec naught101s, ce commentaire a beaucoup de sens. Si moins de gens se soucient de votre source et que vous utilisez dans la production, il y a de bonnes chances que quelqu'un de "mauvais" l'inspecte et l'utilise contre vous (éventuellement)
schlingel
1
La sécurité à travers l'obscurité?
Danubian Sailor
3
@lechlukasz Avez-vous même lu le post en entier?
Nicole
1
@Oleksi Merci, mais je le sais. J'ai dit "l'obscurité n'est pas une excuse pour la paresse en sécurité." Cette question ne concerne pas l'ouverture / fermeture, mais l' ouverture d' un système précédemment fermé. Je suis tout à fait d’accord avec le lien que vous avez posté, mais les développeurs ne sont pas parfaits et lorsque vous ouvrez un système source, il ya une chance que les premiers yeux qui découvrent un bogue l’exploiteront au lieu de le réparer pour vous.
Nicole
10

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.

Pieter B
la source
1
+1 pour les droits d'auteur. Je voulais juste ajouter des brevets aussi. Vous découvrirez peut-être que votre projet open-source empiète sur des milliers de brevets logiciels hébergés par les "corps". Streaming vidéo? Breveté. Annonces payées au clic? Breveté. Juste quelques exemples. Cependant, il est peu probable que les "corps" se moquent - à moins que vous ne soyez un concurrent.
Amadeus Hein
1
Héhé. Ce n'est pas vraiment un argument contre l'open source, mais contre le piratage. Mais vous avez raison, je parie que c'est un problème dans beaucoup de gros codes privés.
naught101
1
@ naught101 D'accord. L'open source expose uniquement le problème. Dans ce cas, la propriété fermée est une question de ne pas se faire prendre;)
Andres F.
Vous dites donc qu’une des raisons de garder le code source fermé est de vous permettre de cacher les violations occasionnelles du droit d’auteur? Ne pensez-vous pas que c'est une raison plutôt contraire à l'éthique?
Mark Booth
1
Non éthique .... peut-être, une très très bonne raison de ne pas ouvrir la source, certainement.
Pieter B
6

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.

Oleksi
la source
1
Oui, c'est un bon point, et la plupart des licences de système d'exploitation contiennent généralement un texte couvrant le cul quelque part. Je suppose que je supposais une licence de type "sans responsabilité acceptée".
naught101
4

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

haylem
la source
Hrm .. J'étais gentil de considérer le code et l'IP ensemble dans ma question. J'aurais peut-être dû préciser cela. Je pense à un retour sur investissement et des considérations d' image de marque des motifs de profit ... (je me rends compte que la « science » était un peu vague, et que beaucoup de la science est rentable - mon domaine (sciences du système de terre est certainement pas bien).
naught101
Clarifié la question. Désolé pour le tracas.
naught101
Je considère que votre domaine est rentable. Le marché n'est peut-être pas très vaste, mais cela ne veut pas dire que ce n'est pas rentable. En fait, je considérerais que cela implique assez d’argent. Pourquoi vous sentez-vous autrement?
haylem
Je suis en modélisation climatique. Personne ne paie pour les modèles climatiques. Personne ne paie pour utiliser des modèles climatiques. L'utilisation du logiciel ne génère aucun profit. Les gens sont payés pour faire de la recherche en utilisant ces modèles (et cela inclut souvent l'écriture des modèles), et le temps de calcul est parfois payé, mais cela signifie que le partage de code rendrait les choses moins chères (plus de temps à consacrer à la recherche au lieu de l'écrire) , moins de temps perdu sur les installations HPC). Je ne vois pas vraiment comment le logiciel est lié à une quelconque rentabilité.
naught101
1
@ psr: Je pense que ce n'est pas le problème101: les résultats des utilisations du modèle ont des résultats rentables, mais pas nécessairement beaucoup d'argent est dépensé dans la vente de logiciels mettant en œuvre le modèle. Me surprend aussi, mais pourrait très bien être.
Hayem
1

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.

Ddyer
la source
3
Je ne vois pas vraiment comment la publication de code oblige quiconque à fournir de l'assistance. Et du moins en science, la plupart des utilisateurs sont bien informés, du moins sur le processus, sinon sur le code lui-même.
naught101
1
@ naught101: Oblige non, mais si quelqu'un utilise votre code, vous allez obtenir des e-mails, des questions, des suggestions ... qui va prendre un certain effort pour que , à moins que vous choisissez simplement de les ignorer. En dehors de la science, de nombreux utilisateurs ne sont pas trop informés, vous pouvez donc peut-être aider des personnes aux prises avec des problèmes d'installation élémentaire, etc. simplement parce que vous avez publié du code. J'ai vécu ça au moins. Même les clauses de non-responsabilité de type BSD "fournies en l'état" etc. n'empêchent pas - et ne devraient pas - empêcher les gens de demander de l'aide.
Joonas Pulakka
1
Upvote parce que cette réponse n'est pas vraiment moins applicable que beaucoup d'autres. @JoonasPulakka: bien sûr, cela ne devrait pas empêcher les gens de demander de l'aide. Mais cela devrait les empêcher d’attendre une réponse. De plus, si vous avez le logiciel réel en public, alors vous avez probablement la même responsabilité envers les utilisateurs, que votre code soit public ou non (selon le CLUF, peut-être). Vous devez peut-être attendre plus de requêtes de la part des développeurs si vous publiez le code, mais il serait bon de penser que la plupart d'entre eux auront un indice, et pourraient rembourser quelques conseils sous forme de correctif ou deux ..
naught101