Gli Schemi a Doppia Licenza

alcuni progetti tentano di fondare se stessi usando uno schema a doppia licenza, nel quale i lavori derivati proprietari possono pagare il detentore del copyright per i diritti di usare il codice, ma il codice rimane ancora libero per l'uso da parte dei progetti open source. Ciò tende a finanziare bene sia per le librerie di codice sia per applicazioni per computer indipendenti dalla rete, naturalmente. I termini esatti differiscono da caso a caso. Spesso la licenza per i lato libero è la GNU GPL, poiché essa impedisce ad altri di incorporare il codice coperto nobel loro prodotto proprietario senza il permesso del detentore del copyright, ma a volte essa è una licenza personalizzata che ha lo steso effetto. Un esempio della prima è la licenza MySQL, descritta a http://www.mysql.com/company/legal/licensing/; un esempio della seconda è la strategia di licenza della Sleepycat Software, descritta a http://www.sleepycat.com/download/licensinginfo.shtml.

Potreste starvi domandando: come può un detentore del copyright offrire una concessione di licenza proprietaria per un costo aggiuntivo se i termini della GNU GPL stabiliscono che il codice deve essere disponibile sotto termini meno restrittivi? La risposta è che i termini della GPL sono qualcosa che il detentore del copyright impone a ogni altro; il proprietario è quindi libero di decidere di non applicare quei termini a se stesso. Un buon modo di pensare a ciò è immaginare che che il possessore proprietario abbia un numero infinito di copie ammucchiate in un secchio. Ogni volta che lui prende una copia dal secchio per inviarle nel mondo, può decider quale licenza mietervi dentro: GPL, proprietaria o qualche altra. Il suo diritto di fare ciò non è intaccato dalla GPL o da qualche altra licenza open source; è semplicemente un potere garantito dalla legge sul copyright.

L'attrattiva della licenza doppia sta nel fatto che, al meglio delle sue possibilità, fornisce a un progetto di software libero un modo per ottenere una fonte di profitto sicuro. Sfortunatamente ciò può anche interferire con le dinamiche normali di un progetto open source. Il problema è che ogni volontario che dà un contributo sta collaborando con due distinte entità: la versione libera del codice e quella proprietaria. Mentre il collaboratore sarà soddisfatto di collaborare alla versione free, dacché quella è la norma nei progetti open source, egli può sentirsi buffo nel collaborare al flusso di entrata semi proprietario dei qualche altro. L'imbarazzo è esacerbato dal fatto che che nelle licenze doppie, il detentore del copyright ha veramente bisogno di raccogliere copyright formali sottoscritti da tutti i collaboratori, per potersi proteggere da un collaboratore scontento che in un secondo momento reclami una percentuale dei diritti d'autore dalle entrate proprietarie. Il processo di raccolte di queste assegnazioni con un pezzo si carta significa che i collaboratori si confrontano duramente col fatto che essi stanno facendo un lavoro che crea soldi per qualcun altro.

Non tutti i volontari saranno seccati da ciò; dopotutto il loro contributo va all'edizione open source, e in ciò può essere che stia il loro interesse. Tuttavia la licenza doppia è una richiesta da parte del detentore del copyright di assegnare a se stesso uno speciale diritto che gli altri non hanno. Ed è così che spinge al sorgere di tensioni a un certo punto, almeno fra alcuni volontari.

Ciò che sembra avvenire nella pratica è che le compagnie che si basano sul software a licenza doppia non hanno comunità di sviluppo veramente egualitario. Esse conseguono una correzione dei bugs su piccola scala e patch di ripulita da fonti esterne, ma finiscono col fare una gran parte di duro lavoro con le risorse interne. Per esempio, Zack Urlocker, vice presidente del marketing alla MySQL, mi disse che la compagnia finisce col prendere in affitto i più attivi volontari comunque. Così, anche se il prorotto di per se stesso è open source, sotto licenza GPL, il suo sviluppo è più o meno controllato dalla compagnia, sebbene con la (estremamente improbabile) possibilità che qualcuno veramente insoddisfatto dell' uso del software da parte della compagnia potrebbe fare una diramazione dal progetto. In quale grado questo minacci in modo preëstimolante le politiche della compagnia non so, ma ad ogni modo, MySQL non sembra avere problemi di consenso sia nel mondo dell'open source sia oltre.