Consigli ed esperienze su quale licenza scegliere per il software?

Gli sviluppatori di software hanno la scelta di scegliere una licenza appropriata in base agli obiettivi del lavoro.

Qualcuno può dare alcuni consigli / esperienze su quale licenza scegliere per il software?

Quali sono i pro / contro di "regalare" tutto il lavoro in codice come codici open source?

Come trattare con attori industriali che vorrebbero beneficiare del codice di ricerca?

Qualcuno può dare alcuni consigli / esperienze su quale licenza scegliere per il software?

La licenza che scegli dipenderà da quanto vuoi che sia libero il tuo codice, ma libero significa cose diverse per persone diverse.

• Per i sostenitori delle licenze permissive , significa gratuitamente consentire alle persone di utilizzare il software come vogliono in questo momento , senza preoccuparsi di quanto siano libere le future derivazioni.
• Per i sostenitori delle licenze di copyleft , libero significa garantire che il software e ogni sua derivazione rimangano liberi , preparandosi a sacrificare alcune libertà immediate per garantirlo.

Più una licenza è permissiva, più persone saranno in grado di usarla, ma meno controllo avrai su di essa. Quanto più restrittivo è, tanto più è probabile che tu abbia scoraggiato le persone utilizzando il tuo software in primo luogo.

Esistono numerose licenze gratuite e open source, tra cui GPL <= 2, GPL 3 , LGPL , BSD , Eclipse e così via. Ci sono pro e contro per ciascuno, quindi leggi quali restrizioni pongono sul codice e decidi chi vuoi essere in grado di usarlo. Attenzione , qualunque cosa tu scelga qualcuno si lamenterà - questo è il territorio della guerra santa .

Nel complesso è un sottile bilanciamento e dipende molto dal pubblico di destinazione del tuo software.

• Una grande risorsa per determinare quale licenza è la licenza giusta per te è il differenziatore di licenza interattivo molto completo , da Oxford University OSS Watch .

A mio avviso, entrambe le licenze permissive e copyleft sono appropriate per il codice scientifico - l'importante è che il codice sia in primo luogo open source. Credo che la scienza dovrebbe essere aperta, e così dovrebbe essere usato il codice per supportare tale scienza.

Quali sono i pro / contro di "regalare" tutto il lavoro in codice come codici open source?

L'idea di regalare il tuo software è che se gli altri lo trovano utile lo useranno.

Se lo usano, troveranno, segnaleranno e spesso correggeranno i bug, risparmiando lo sforzo di fare lo stesso.

Se gli piace e il tuo software fa quasi quello che vogliono, potrebbero migliorare il tuo software e contribuire con quei miglioramenti.

Questo è un sacco di se però.

Come trattare con attori industriali che vorrebbero beneficiare del codice di ricerca?

In primo luogo, se si desidera vietare l'uso commerciale del proprio codice, è possibile selezionare una licenza con una clausola di non riutilizzo commerciale.

In secondo luogo, se pensi che qualcuno potrebbe utilizzare il tuo software per alimentare un servizio, senza mai effettivamente distribuire il codice a nessun altro, allora potresti prendere in considerazione la GPL Affero che collega quella particolare scappatoia copyleft.

In terzo luogo, puoi fare quanto sopra e offrire una doppia licenza. Offrire licenze GPL o AGPL per il download pubblico e licenze commerciali a pagamento ti offre il meglio di entrambi i mondi e significa che potresti persino essere in grado di generare entrate dalle vendite commerciali del tuo software che possono aiutarti a supportare le tue attività scientifiche.

Nota, se hai intenzione di farlo, offrilo fin dall'inizio - è probabile che causi meno attrito dai tuoi collaboratori open source rispetto a iniziare a offrire licenze commerciali in seguito. Se la tua comunità diventa popolare, non vuoi che le persone ti accusino di svendersi se non avessi la possibilità di sfruttamento commerciale in seguito. Idealmente, dovresti impostare un Accordo di licenza per collaboratori (CLA) adatto prima di iniziare ad accettare contributi di terze parti nel tuo codebase.

Questa risposta a questa domanda fornisce anche alcune buone informazioni su questa opzione.

PETSc utilizza questa licenza , che è una forma meno restrittiva di BSD . La differenza cruciale rispetto a GPL, è che il software può essere utilizzato commercialmente. Molte persone hanno un'obiezione di principio al software chiuso, tuttavia nella mia esperienza nessuna azienda si avvicinerà al tuo codice se ha una licenza GPL. Inoltre, gli utenti industriali di PETSc sono stati incredibilmente preziosi. Tendono a presentare problemi piuttosto complessi, che la maggior parte degli accademici troverebbe più difficile di quanto giustificato per una pubblicazione. Hanno anche fornito molto codice a PETSc, in modo che entrasse nella normale catena di supporto. Vorrei sconsigliare qualsiasi licenza senza potenziale uso commerciale, e difenderei la licenza meno restrittiva possibile (potresti sicuramente masterizzare PETSc su un CD e provare a venderlo sul credulone).

Uso GPL, principalmente a causa del sentimento verso il movimento open source originale (e quindi spero che possa aiutarlo a diffondersi). Inoltre, questo è paradossalmente il modo migliore per proteggere i tuoi possibili guadagni dai capitalisti immorali: come autore, puoi sempre distribuire il codice su una diversa licenza in parallelo e quindi mantenere la versione proprietaria per un uso commerciale in white label.
Tuttavia, potrebbe trattarsi anche di una contro - fonte di finanziamento potrebbe essere esonerato dal fatto che tutto il tuo lavoro dovrebbe diventare di dominio pubblico, cosa che va oltre questa licenza.

Ad ogni modo, la cosa più importante in questo argomento è che qualsiasi licenza è migliore di nessuna, che sfortunatamente è abbastanza spesso nel mondo dello sviluppo scientifico - e odio tutti quei / * rubati dal programma di John Smith che non ha mai pubblicizzato * / o CI penso di averlo visto nel post di Jane Smith su un gruppo nel 1995 ... o forse nel 1993?

In primo luogo, i pro / contro di andare open source:

Pro: più persone useranno il tuo codice, forniranno feedback, correzioni, miglioramenti, ecc. Finirai per avere un codice migliore e più persone che si fidano di esso.

Contro: se mai vuoi basare un'azienda nel tuo codice, hai meno opzioni (ma ce ne sono ancora alcune, come vendere servizi di consulenza)

Per quanto riguarda la scelta di una licenza, procederei nel seguente ordine:

1. Il tuo datore di lavoro / agenzia di sovvenzione impone qualcosa? Quindi non hai scelta. Controlla questo per tutti i partecipanti al codice.
2. Riutilizzi il codice che ha una licenza particolare che limita la tua scelta? Quindi anche le tue scelte sono limitate. In pratica, l'integrazione di parti di codice con licenza GPL è la fonte più frequente di tali limitazioni.
3. Decidi cosa apprezzi di più: la filosofia di tutto il codice che dovrebbe essere aperta dietro GPL e licenze simili, o la filosofia di incoraggiamento il più ampio possibile dietro la licenza BSD.
4. All'interno di ciascuna delle due grandi famiglie di licenze Open Source, scegli in base a ciò che è più comune / accettato nella tua comunità.

Gran parte della mia ricerca è finanziata da fondi pubblici e quindi sento l'obbligo di utilizzare la licenza meno restrittiva possibile. Se altre persone nel mio paese stanno aiutando a pagare per questa ricerca, ho davvero il diritto di dire loro che non possono integrare il mio codice in una distribuzione chiusa di software e / o commerciale? Mi aspetto che la maggior parte delle persone che usano il mio codice siano scienziati accademici, ma non ho problemi filosofici con le aziende che migliorano il mio software integrandolo con altri software (possibilmente commerciali), inserendo una GUI, ecc., Per consegnare un prodotto questo li aiuta a realizzare un profitto.

Detto questo, provo a utilizzare licenze che richiedono un'attribuzione adeguata. Per esempio, se una società non piega il mio codice in un prodotto commerciale più grande, voglio che mettere in chiaro che il mio codice può essere ottenuto liberamente da me. Ma a parte questo, voglio porre il minor numero di requisiti possibile agli utenti del mio codice.

Per lo sviluppo di software che non è finanziato dai dollari dei contribuenti, sono consapevole che altre licenze potrebbero essere più appropriate.

Nessuno lo ha spiegato chiaramente, quindi penso che valga la pena dirlo:

Alcune delle licenze open source (in particolare: la GPL) sono "virali", nel senso che ogni volta che il codice viene utilizzato in un nuovo progetto, il nuovo progetto deve essere concesso in licenza allo stesso modo. Inoltre, il codice non può essere collegato a (in certi modi) codice con licenza diversa.

Una conseguenza pratica è:

• Se implementi un nuovo metodo numerico in C, la licenza non consentirà di chiamarlo da un software così comune come MATLAB o Mathematica

• Se implementate un nuovo algoritmo di elaborazione delle immagini, la licenza non consentirà di crearne un plug-in Photoshop

• e così via ...

Questo non solo impedirà il riutilizzo commerciale, ma anche un comodo riutilizzo da parte di altri accademici (se usano software chiuso) e se qualcuno si basa sul codice, impedirà loro di dare il loro lavoro in un "do "che cosa vuoi".

Questo è qualcosa che devi considerare prima di completare la formulazione della licenza.

L'ho messo in questo modo perché ho incontrato persone (non molto familiari con le licenze open source) che non ne erano a conoscenza o non l'hanno considerato da questo punto di vista.

^{(Questa è solo un'opinione personale, ma credo che applicare tali restrizioni al lavoro che provengono dal mondo accademico (finanziato con fondi pubblici) non sia appropriato. Quindi o mantengo il codice o lo do via.)}

Indipendentemente dalla licenza con cui scegli di andare, ricorda di controllare attentamente tutti i tuoi accordi di finanziamento per assicurarti che non vi siano clausole che dettino o limitino il modo in cui potresti procedere con la licenza del tuo software.

So che nel mio caso molti dei miei progetti sono costituiti da diversi livelli di finanziamento, un po 'qui e un po' lì, e tenendo traccia di come sono autorizzato a concedere in licenza le mie cose dalle persone che tengono le luci accese e le macchine in esecuzione sono piuttosto complesse.

Per grandi quantità di codice vado per una delle licenze descritte nelle altre risposte, e di solito LGPL. Tuttavia, sebbene di solito non sia raccomandato per il software , per piccoli script autonomi che potrei inviare a un collega del settore, spesso scelgo una licenza Creative Commons . Questo perché tendono ad essere più chiari per l'individuo a cui invio il codice, il che blocca qualsiasi potenziale problema di incomprensione. Questo ha funzionato bene per me in passato.

A differenza della maggior parte delle persone che rispondono qui (che lavorano in organizzazioni accademiche e / o pubbliche), sto lavorando in ambito commerciale.

Per i miei prodotti, il codice è chiuso e continuano a esserci grandi vantaggi commerciali nel fare questo. Ma ci sono ovviamente altri modi per farlo (ad esempio, come dimostrato da MySQL tra gli altri). Vedo spesso l'approccio della licenza commerciale LGPL + per le biblioteche. Devo ancora usare una simile biblioteca in un sistema commerciale, ma non lo escluderei (finora ho usato solo tali biblioteche, ad esempio ALGLIB, a livello di ricerca e sviluppo). Ciò contrasta con un prodotto GPL - che potrei usare internamente ma non userei mai in un prodotto, principalmente a causa della natura virale.

Quando rilascio il codice sorgente (esempi di istruzioni, programmi gratuiti, ecc.), Di solito utilizzo la licenza Berkeley. Questo sembra essere molto più nello spirito del codice "libero", con attribuzione ma senza le stringhe e la politica della GPL. Forse è per questo che (o licenze simili come la licenza MIT) sono così popolari tra università e organizzazioni pubbliche. Il codice sorgente viene dato nel vero significato di "libero" (ecco un po 'di codice, fai quello che vuoi con esso) ma l'autore ottiene ancora credito / attribuzione.

Questa è una vecchia domanda, ma penso che la Licenza pubblica Mozilla meriti di essere menzionata come una via di mezzo tra licenze permissive (BSD, MIT) e licenze copyleft forti (GPL). Il codice MPL può essere utilizzato e ridistribuito, ma il codice MPL e le eventuali modifiche devono essere resi disponibili. Ad esempio, un'azienda può prendere del codice MPL, apportare i propri miglioramenti e distribuirlo in un pacchetto software proprietario di origine chiusa, a condizione che rendano disponibile la versione modificata del codice MPL originale. Non sono obbligati a rilasciare tutto il proprio codice sorgente, come farebbero con GPL.

Con la licenza BSD, c'è la paura che una società possa prendere il tuo codice e migliorarlo senza restituire questi contributi a te o alla comunità in generale, secondo la logica che i miglioramenti apportati ad essa conferiscono un vantaggio competitivo. (La risposta di Matt Knepley suggerisce che non tutti agiscono in questo modo). D'altra parte, molte persone potrebbero evitare del tutto il codice GPL. L'MPL evita entrambe queste potenziali insidie, almeno in linea di principio.