Scegli la tua licenza
Se il tuo codice è stato closed source fino ad ora, la prima cosa che dovresti fare è decidere quale licenza open source ( GPL < = 2, GPL 3 , LGPL , BSD , Eclipse ecc.) che vuoi da usare.
Ci sono pro e contro a ciascuno, quindi leggi le restrizioni che inseriscono nel codice e decidi chi vuoi essere in grado di usarlo. Avviso , a seconda di quale sceglierai, qualcuno si lamenterà - questo è guerra santa e oltre lo scopo di questa domanda.
Sanitizza il tuo repository
Se il codice nel tuo repository non ha già applicato la tua licenza scelta, passerò attraverso l'intera cronologia delle revisioni finora e applicandolo retroattivamente (questo potrebbe richiedere una ricollocazione in ogni punto in cui una nuova fonte il file è stato introdotto). Ciò, tuttavia, produrrà un bel repository pulito che, quando viene rilasciato al pubblico, non ha revisioni in cui la licenza scelta non è in vigore.
Un'altra opzione è avviare il tuo repository pubblico nel punto della tua prima versione, con una cronologia minima o nulla fino a quel momento.
Questo ha lo svantaggio che le persone non possono tornare indietro nella cronologia e capire come sei arrivato dove sei oggi, ma ha il vantaggio che le persone non puoi tornare indietro nella tua storia e capire come sei arrivato dove sei oggi. * 8' )
Quando la società per cui lavoro ha realizzato il software su cui lavoro su open source, abbiamo iniziato producendo solo istantanee della directory di lavoro nei punti di rilascio. Quando ci siamo spostati su repository github pubblici, abbiamo iniziato ogni% repo% co_de al punto in cui un plug-in era (o un insieme di plug-in erano) spostato da git , raramente includendo qualsiasi storia.
Considera una doppia licenza
Se ritieni che ci possa essere un interesse commerciale nell'utilizzo del tuo software, ma hai una preferenza ideologica per una licenza di riutilizzo restrittiva come GPL 3, prendi in considerazione l'idea di offrire una doppia licenza. Offrire licenze GPL 3 per il download pubblico e licenze commerciali a pagamento ti offre il meglio di entrambi i mondi.
Fare questo fin dall'inizio potrebbe causare meno attrito rispetto all'avvio di offrire licenze commerciali in seguito. Se la tua comunità diventa popolare, le persone potrebbero accusarti di vendere se non avessi avuto la possibilità di sfruttamento commerciale in seguito.
Considera un accordo di collaborazione
Se hai intenzione di licenzare due volte, o semplicemente vuoi mantenere il tuo codebase tuo, dovrai o reimplementare te stesso le correzioni apportate dai contributi o ottenere contributori per assegnare i diritti sui loro contributi a te. Altrimenti scoprirai che i loro contributi ti impediscono di rilasciare il tuo codebase sotto altre licenze.
La risposta Mason Wheeler alla domanda La licenza open source del mio codice mi limita più tardi? fornisce alcune buone informazioni su questo e come è stato utilizzato il progetto libsdl per risolvere questo problema.
Tieni presente che, proprio come la tua scelta di licenza può limitare le persone e le organizzazioni che useranno e contribuiranno al tuo progetto, così sceglierai se avere un accordo con il contributore. Alcune persone non saranno felici di contribuire a un progetto che richiede loro di firmare un accordo di contributore.
Accordi di Collaboratore a doppia licenza
Il accordo con i fornitori di Oracle (i collegamenti sono difficili da vedere in quella pagina) è un buon modello per un accordo di contributore. È anche concesso in licenza (CC) in modo da poterlo modificare e riutilizzarlo.