Ragioni per NON open source codice no profit? [chiuso]

Sono un grande fan del codice open source. Penso di aver compreso la maggior parte dei vantaggi dell'andare all'open source. Sono un ricercatore di studenti di scienze e devo lavorare con una quantità piuttosto sorprendente di software e codice che non è open source (o è proprietario o non è pubblico). Non riesco davvero a vedere una buona ragione per questo, e posso vedere che il codice e le persone che lo usano trarrebbero sicuramente beneficio dall'essere più pubblico (se non altro, nella scienza è vitale che i tuoi risultati possano essere replicati se necessario, e questo è molto più difficile se gli altri non hanno accesso al tuo codice).

Prima di uscire e iniziare il proselitismo, voglio sapere: ci sono buoni argomenti per non rilasciare pubblicamente il codice no profit e con una licenza conforme a OSI?

(Mi rendo conto che ci sono alcune domande simili in giro, ma la maggior parte si concentra su situazioni in cui il codice viene utilizzato principalmente per fare soldi, e non potrei essere molto pertinente nelle risposte.)

Chiarimento: per "no profit", includo motivi di profitto a valle, come il riconoscimento del marchio della società madre e le aspettative di profitto degli investitori. In altre parole, la domanda riguarda solo i software per i quali NON esiste alcun motivo di profitto legato al software.

È necessario tenere conto del fatto che l'apertura del codice potrebbe richiedere uno sforzo aggiuntivo.

Ad esempio, in questo post di blog l'ingegnere Sun / Oracle descrive gli sforzi che hanno dovuto intraprendere per l'approvvigionamento del codice: Open Source o Dirty Laundry?

Mentre ci prepariamo ad immergerci nel mondo open source, una delle tante attività che si svolgono è la preparazione del codice per essere open source. Ci sono alcune cose ovvie che devono essere fatte. Ad esempio, il nostro codice sorgente include una combinazione di codice che abbiamo scritto e codice che abbiamo concesso in licenza da altri. Dovremo separare quest'ultimo e l'open source solo le parti di codice appropriate.

Un'altra attività di preparazione è "scrubbing" del codice di informazioni proprietarie, menzioni di particolari clienti, sviluppatori, tecnologie ecc. Questo è un po 'meno ovvio, ma si consideri il seguente esempio:

/\*
 \* 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.
 \*/

Mentre tutto quanto sopra potrebbe essere vero, probabilmente abbiamo una relazione di qualche tipo con Intertrode Tech e avere commenti come questo nel codice potrebbe danneggiare la nostra attività in qualche modo e quindi dovrebbe essere rimosso. Probabilmente non avrebbe dovuto essere lì in primo luogo, ma ora è il momento di tirarlo fuori.

Un'altra parte dell'attività "scrubbing" è quella di rimuovere volgarità e altre parole "indesiderabili" ...

Si noti che tutte le modifiche di cui sopra hanno dovuto essere apportate al codice che è stato considerato perfettamente OK come sorgente chiusa, il che lo rende un ulteriore sforzo per così dire.

Sicurezza.

Ad esempio, supponi di creare un framework Web e di utilizzarlo tu stesso.

Come progetto senza fini di lucro, non hai avuto il tempo di dedicare all'ispezione di ogni bit di codice per la vulnerabilità a un attacco o a un altro:

• CSRF
• XSS
• SQL Injection
• Fissazione della sessione
• Utilizzo di librerie di terze parti difettose o addirittura di lingue

Ora, avendo aperto il progetto, permetti agli occhi amichevoli di contribuire, ma permetti anche agli occhi maliziosi una visione completa del tuo lavoro e, se trovano un server che esegue il tuo codice, hai eliminato la tua capacità di nascondere il tuo imperfezioni nell'oscurità.

Naturalmente, questo potrebbe non essere applicabile al tipo di software su cui stai lavorando; e come sempre l' oscurità non è una scusa per la pigrizia nella sicurezza.

Tuttavia, proprio come ho riscontrato nei due livelli che ho superato in Stripe, cattura il gioco della bandiera , sapendo che il codice è il modo più semplice per trovare le vulnerabilità (e talvolta può essere l'unico modo).

Un buon motivo per non open source è che parte della tua fonte potrebbe essere protetta da copyright. Quante volte non cerchi nel web una soluzione rapida a un problema e prendi semplicemente lo snippet di codice che trovi?

Bene, quelli potrebbero essere protetti da copyright e non so se l'autore vorrebbe trovare il suo codice in licenza con una licenza diversa.

È necessario prestare attenzione a come si sceglie la licenza per evitare potenziali problemi di responsabilità.

Un avvocato può essere una persona migliore con cui parlare di questo, ma l'idea generale è cosa succede se qualcuno usa (o abusa) l'applicazione e causa qualche danno? Sei responsabile? Ovviamente questo dipenderà dal tipo di software che stai scrivendo, ma devi sempre fare attenzione a ciò che la tua licenza dice sulla tua responsabilità. Questa può essere una cosa difficile da ottenere, quindi potrebbe essere più semplice non rilasciare il codice sorgente.

Attenzione: non sono un avvocato .

Bene, se non ha scopo di lucro e la sua proprietà intellettuale è fortemente legata al codice del software, alcuni potrebbero voler proteggerlo dal riutilizzo commerciale o addirittura sfruttato in modo abusivo per creare copie carbone del proprio software.

Alcuni altri motivi - che sono probabilmente profondamente radicati nel primo, in realtà - sono che nel tuo caso gran parte della ricerca di alto livello avviene con finanziamenti privati ​​e di solito gli investitori vogliono vedere il ROI. E finora, nessuno degli attori dell'industria del software (o dei nuovi arrivati) è stato completamente persuaso della fattibilità del modello open source (molto probabilmente per mancanza di conoscenza e comprensione delle licenze, o semplicemente per paura che le licenze non impediscano i malware usi e copie).

Inoltre, queste aziende non vogliono essere citate in giudizio da coloro che hanno tentato di ottenere profitti sulle loro spalle e le licenze sono viste come una protezione anche a questo proposito, con buone ragioni o no.

Potrebbe non sembrare così, ma forse le organizzazioni senza fini di lucro SONO redditizie per i loro fondatori o investitori. I vantaggi non sono diretti. Quindi hanno un grande interesse nel fatto che gli NFP stiano andando forte e non siano battuti al limite dai concorrenti (anche se spesso non penseresti spesso ai "concorrenti" nel mercato no profit) e vogliono preservare il loro IP, anche se è a costo di non ottenere più bulbi oculari gratuiti per rivedere il loro codice per trovare problemi e migliorarlo in anticipo.

Si noti inoltre che le leggi sul copyright differiscono da paese a paese. Molti paesi europei considerano le leggi statunitensi sul copyright e il sistema dei brevetti statunitensi piuttosto confusi, per esempio, quindi c'è un background culturale e un peso che è difficile scrollarsi di dosso.

Jut i miei 2 centesimi sull'argomento.

(Ho lavorato molto con le università e recentemente in bioinformatica e sanità ... È una domanda ricorrente per me e i miei colleghi :))

Esistono almeno due diversi tipi di open source.

Se il tuo atteggiamento è "ecco qualcosa di utile, ho finito con esso" (e questo risulta essere accurato), allora c'è poco svantaggio.

D'altra parte, se il tuo atteggiamento è "Sono davvero entusiasta e voglio che alcuni utenti reali aiutino a guidare lo sviluppo futuro", pensa attentamente. Dovrai dedicare tempo a supportare gli utenti, molti dei quali sono all'oscuro. Dovrai prendere in considerazione richieste contrastanti per funzionalità e miglioramenti. Sarà sempre più difficile apportare modifiche per preservare la compatibilità con le versioni precedenti.