Motivi per NON aprire codice non profit di origine? [chiuso]

Devi tenere in considerazione che l'open sourcing del tuo codice potrebbe richiedere uno sforzo ulteriore.

Ad esempio, in questo post sul blog, l'ingegnere Sun / Oracle descrive gli sforzi che hanno dovuto intraprendere aprendo il loro codice: Apri Fonte o lavanderia sporca?

As we get ready to dive into the open source world, one of the many activities that's occurring is the preparation of the code for being open sourced. There are some obvious things that need to be done. For instance, our source code includes a mixture of code that we've written and code that we've licensed from others. We'll need to separate out the latter and open source only the appropriate pieces of code.

Another preparation activity is "scrubbing" the code of proprietary information, mentions of particular customers, developers, technologies etc. This is a little less obvious, but consider the following example:

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

While all of the above might be true, we probably have a relationship of some sort with Intertrode Tech and having comments like this in the code could hurt our business somehow and so it should be removed. Arguably it shouldn't have been there in the first place, but now's the time to take it out.

Another part of the "scrubbing" activity is to remove profanity and other "undesirable" words...

Nota tutte le modifiche precedenti dovevano essere apportate al codice che è stato considerato perfettamente OK come closed source - che lo rende puro extra effort per così dire.

Sicurezza.

Ad esempio, supponi di creare un framework web e tu stesso lo usi.

Essendo un progetto non profit, non hai avuto il tempo di dedicarti a ispezionare ogni bit di codice per la vulnerabilità a un attacco o un altro:

• CSRF
• XSS
• Iniezione SQL
• Correzione della sessione
• Uso di buggy librerie di terze parti o persino di lingue

Ora, avendo aperto il progetto, permetti agli amici di contribuire, ma permetti anche agli occhi maligni di avere una visione completa del tuo lavoro e, se trovano un server che sta eseguendo il tuo codice, hai eliminato la tua abilità per nascondere le tue 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 trovato nel paio dei livelli che ho ottenuto nella Stripe acquisisci il flag game , conoscere il codice è uno dei modi più semplici per trovare le vulnerabilità (e talvolta può essere l'unico modo).

Un buon motivo per non aprire l'open source è che parte della tua fonte potrebbe essere protetta da copyright. Con quale frequenza non cerchi sul Web una soluzione rapida a un problema e prendi semplicemente il frammento di codice che trovi?

Bene, quelli potrebbero essere protetti da copyright e non so se l'autore vorrebbe che il suo codice venga rilasciato da una licenza diversa.

Devi stare attento a come scegli la tua licenza per evitare potenziali problemi di responsabilità.

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

Avviso: Non sono un avvocato .

Bene, se è un no-profit e la sua proprietà intellettuale è strongmente legata al codice del software, allora alcuni potrebbero voler proteggerlo dal riutilizzo commerciale, o anche abusivamente sfruttato per creare copie di carbonio del tuo software.

Alcune altre ragioni - che sono probabilmente radicate nel primo, in realtà - sono che nel tuo caso molte ricerche di alto livello avvengono con finanziamenti privati, e di solito gli investitori vogliono vedere il ROI. E fino ad ora, non tutti gli attori dell'industria del software (o dei nuovi arrivati) sono stati pienamente convinti della validità del modello open source (molto probabilmente per mancanza di conoscenza e comprensione delle licenze, o semplicemente per paura che la licenza non prevenga i malintenzionati usi e copie).

Inoltre, queste aziende non vogliono essere citate in giudizio da coloro che hanno tentato di ottenere un profitto sulle loro spalle, e anche le licenze sono considerate una salvaguardia in questo senso, a ragione o no.

Potrebbe non sembrare così, ma forse le organizzazioni non profit sono redditizie per i loro fondatori o investitori. I benefici non sono diretti. Quindi hanno un grande interesse per i NFP che vanno strong e non vengono battuti dai concorrenti (anche se non si pensa spesso a "concorrenti" nel mercato no-profit), e vogliono preservarli IP, anche se è a costo di non ottenere più occhiatti liberi per rivedere il loro codice per trovare problemi e migliorarlo presto.

Nota anche che le leggi sul copyright differiscono da paese a paese. Molti paesi europei considerano le leggi sul copyright degli Stati Uniti e il sistema dei brevetti degli Stati Uniti di essere piuttosto stupefatti, ad esempio, quindi c'è un background culturale e un peso che è difficile da scrollare di dosso.

Jut my 2 cents sull'argomento.

(Ho lavorato molto con le università, e recentemente ho fatto bioinformatica e assistenza sanitaria ... È una domanda ricorrente per me e i miei colleghi :))

Ci sono almeno due diversi tipi di open source.

Se il tuo atteggiamento è "ecco qualcosa di utile, ho finito con quello" (e questo risulta essere accurato) quindi c'è un piccolo svantaggio.

D'altro canto, se il tuo atteggiamento è "Sono davvero eccitato e voglio che alcuni utenti reali aiutino a guidare lo sviluppo futuro", quindi pensa molto attentamente. Dovrai trascorrere del tempo a supportare gli utenti, molti dei quali sono incapaci. Dovrai considerare richieste in conflitto per funzionalità e miglioramenti. Troverai sempre più difficile apportare modifiche, per preservare la compatibilità con le versioni precedenti.