Se, e solo se, il progetto ha una doppia licenza, allora puoi scegliere la tua licenza e il tuo fork preferiti da lì. Ma devi assicurarti che gli tutti aspetti del codice che hai bisogno siano concessi in licenza nella tua licenza preferita. Tu sei hai il permesso di separare un progetto da "selezionare in modo semplice" solo gli aspetti di cui hai bisogno o sono compatibili con la tua licenza preferita.
Pensa al dual-licensing come linee di assetto su un'automobile. Supponendo che puoi permetterti un solo veicolo, scegli una linea di assetto e la guidi fuori dal lotto. (Aka, hai biforcato il progetto.) Il veicolo funziona ancora; va tutto bene; hai una licenza unica ora.
È probabile che la linea di ritaglio A
abbia alcune caratteristiche che vuoi veramente, ma puoi solo "permetterti" di tagliare la linea B
. Questo è il momento in cui ti affidi al mercato post-vendita e ad altri meccanismi per installare le funzionalità che desideri da A
ma non puoi permetterti. E se sei un vero fai-da-te a portata di mano, puoi apportare queste modifiche da solo. Quelle nuove funzionalità che hai costruito / pagato ora fanno parte della linea di ritaglio B
o ma tu decidi di rilasciarle / licenziarle (è qui che l'analogia automatica cade a pezzi).
Alcuni avvertimenti rapidi -
1) Uso il termine "afford" per far funzionare l'analogia dell'automobile. È una metafora, tutto qui.
2) La licenza scelta potrebbe influenzare il modo in cui è possibile rilasciare nuove funzionalità. Ad esempio, l'uso di GPL forzerebbe le nuove funzionalità a essere GPL.