Parliamo qui di uno dei temi più ricorrenti nel mondo del software libero: libero, ok, ma io come ci campo?
Capita sovente che clienti si rivolgano a me per consigli su come scegliere una licenza piuttosto che un’altra, ma in realtà quello che chiedono riguarda la strategia “di business”. Le prime volte dicevo “ditemi la vostra strategia di business, io vi dirò che licenze sono disponibili date le componenti che volete utilizzare”. Ma mi sono reso conto molto presto che si tratta di un classico problema uovo-gallina.
Viene prima l’uovo o la gallina?
La scelta di un modello di business deriva dalla licenza che si intende adottare, o la licenza che si intende adottare dipende dal modello di business che si è scelto?
Sovente, nessuna delle due opzioni. O tutte e due. Come in un puzzle, conviene iniziare dai pochi punti noti. Quasi mai si inizia da una situazione del tutto vergine. Quasi sempre si ha già un minimo di progetto abbozzato, se non un prototipo. A volte si ha addirittura non un vero e proprio prodotto sul mercato che si vuole rendere “open source”. Allora la scelta dipende in larga misura da costrizioni esterne; oppure dalla voglia di disfare ciò che si è già fatto, se le costrizioni esterne non consentono di seguire la strada che si vorrebbe prendere.
Nel gergo si parla di “inbound” (in ingresso) per definire il software già esistente e le relative licenze, software che inseriremo nel nostro lavoro, e “outbound” (in uscita) per il software che distribuiamo e la licenza che utilizzeremo per tale distribuzione.
Qualcosa di nuovo, qualcosa di vecchio, qualcosa di prestato, qualcosa di rosso
Le condizioni di licenza inbound possono richiedere che il software derivato sia sotto una determinata licenza o categoria di licenze (outbound), oppure possono addirittura escludere la licenziabilità del software sotto una o più licenze incompatibili. Dunque una qualsiasi decisione deve per forza partire da una ricognizione di quello che c’è già, per vedere di chi è, se va buttato e se va buttato cosa se ne deve andare con esso.
Se il software è interamente sviluppato dal nostro imprenditore, non c’è problema. O c’è? In teoria può accadere che qualcuno (uno stagista, un ambiente di sviluppo, una libreria che faceva comodo e di cui ci si è dimenticati) non abbia inserito nel codice qualcosa di altri, che viene sotto una licenza, le cui condizioni siano incompatibili con la licenza outbound. A seconda delle dimensioni del progetto e della sua anzianità, o del fatto che è stato acquistato da terzi (magari dopo l’acquisizione della società che l’aveva creato), queste informazioni possono non essere direttamente reperibili. Nel qual caso esistono strumenti di analisi del codice sorgente, tra i quali Black Duck è il più famoso e completo, a pagamento, e altri gratuiti. Questi strumenti restituiscono un rapporto più o meno accurato che costituisce una buona base di partenza.
Per dirla in termini tecnici, occorre sempre fare un minimo di attività di controllo, che sovente viene chiamata “due diligence tecnica”, per scoprire prima quello che se si scopre dopo si piangono lacrime amare.
Scegliamo la licenza, no, il modello di business, no, cosa?
I modelli più gettonati sono: dual licensing, open core (freemium), subscription+personalizzazioni e (scusate l’abuso di inglese), “io speriamo che me la cavo”. Dell’ultimo non parleremo.
Dual licensing
Il modello “dual licensing” è andato molto di moda in passato, faceva piuttosto gola agli investitori esterni (venture capitalist) perché sembrava l’uovo di Colombo. Avere i benefici del software libero e consentiva di monetizzare come se fosse software proprietario. Tombola!
Aggiungiamo che nel boom delle aziende tecnologiche c’era almeno un esempio vincente: MySQL AB, che con l’omonimo database campione di vendite nel boom delle dotcom, era stata comprata da Sun Microsystems per due miliardi di dollari. L’idea che il trucco potesse essere ripetuto ha fatto gola a molti.
Il funzionamento è semplice: stesso software, due licenze. La prima è una licenza di software libero. Invado il mercato, distribuisco a costo zero, creo un nome, creo effetti di rete, la gente sviluppa sul mio prodotto, lo faccio diventare appetibile. E lo distribuisco anche sotto licenza proprietaria. Perché uno dovrebbe pagare per qualcosa che già è disponibile gratuitamente? Per avere l’assistenza? Garanzie? Aggiornamenti? No, quello è il modello “subscription” (vedi sotto). Qui stiamo parlando di una licenza proprietaria.
Per far funzionare questo modello, la licenza di software libero deve essere una licenza copyleft. Più forte è il copyleft, più è difficile utilizzarla per un prodotto proprietario. Per cui chi vuole usare il prodotto con una licenza outbound proprietaria deve per forza ottenere un permesso ulteriore, un’eccezione al copyleft.
Il modello ha due debolezze: per quanto forte sia il copyleft, i suoi effetti si dispiegano su ciò che può essere considerato “prodotto derivato”. Dunque occorre che il software incorporante sia inseparabile da quello incorporato, o che sia inefficiente disaccoppiare i due sistemi per renderli indipendenti.
La seconda debolezza è che per avere la possibilità di concedere eccezioni al copyleft, occorre il permesso di tutti i titolari. In uno sviluppo distribuito, è difficile ottenere tale permesso in capo a un solo soggetto, perché difficilmente un terzo investe in un prodotto che altri sfrutteranno. Ma anche così, occorre che chi contribuisce sottoscriva un accordo speciale, di assegnazione (“Contribution Assignment Agreement”) in cui si cede il copyright sui contributi, ricevendo in cambio una licenza illimitata. Non una cosa molto appetibile per i più. Per cui si finisce per tornare a un modello di sviluppo “a silos” in cui tutto il lavoro è comunque sulle spalle di uno solo.
Un esempio del fallimento di tale modello, che ha portato a un “forking” (divisione) del progetto è OpenOffice.org, sempre di Sun Microsystem. Alcuni sviluppatori hanno creato la Document Foundation per un nuovo progetto: Libre Office. Il quale ora ha un numero enorme di sviluppatori indipendenti che contribuiscono regolarmente. OpenOffice.org ne riceve molti, molti meno. Ne parlano altri su queste colonne, non approfondisco.
Open Core
Il modello “open core” si basa sul concetto di creare un nucleo (“core”) aperto, a cui possibilmente molti partecipanti contribuiscano in modo sostanziale.
In questo modo, si garantisce che almeno per quanto riguarda l’infrastruttura centrale si possano ricevere vari contributi, visto che molti potranno comunque giovarsi. Per poi realizzare soluzioni a valore aggiunto nella parte “esterna”, che può anche essere molto piccola, ma specializzata. Ad esempio, creare un motore di database, per poi realizzare database di livello industriale (es: PostgreSQL), oppure un’infrastruttura di gestione dei flussi multimediali, utilizzabile da chi volesse costruirci sopra applicazioni multimediali di ogni tipo (esempio: GStreamer).
Qui, al contrario del dual licensing, i prodotti proprietari e liberi sono distinti (spesso l’uno contiene l’altro) e la licenza solitamente è non copyleft, copyleft debole o copyleft forte con eccezioni. Cioò proprio perché il “core” è destinato a essere compreso in un prodotto che potrà essere proprietario, e ci potrebbero essere incompatibilità.
Spesso questa è la strada scelta da progetti completamente liberi, in cui si inizia con un modello di licenza completamente libera. Poi nell’evoluzione si valuta che il modello iniziale non è sostenibile, perché da progetto semi-hobby è diventato qualcosa di serio e non è più gestibile, oppure perché per finanziare lo sviluppo necessita un introito derivante dalla messa a reddito.
Subscription/personalizzazioni ibridi
Il modello che monetizza mediante l’offerta di “subscription” e personalizzazioni è quello più tipico del software libero.
Non è incompatibile con un modello dual licensing, anzi, i progetti dual licensing che conosco essere più di successo in realtà combinano un modello duale, un open core e un modello subscription. Ad esempio, Zimbra, Alfresco, OpenBravo, Zarafa non puntano tanto ad essere inclusi in progetti più ampi, quanto ad avere un canale “comunitario”, nel quale la comunità è più di utilizzatori e di integratori che di sviluppatori, e offrire un servizio “premium” a chi necessità di livelli di supporto garantiti, includendo magari porzioni proprietarie di software per scopi precisi, non disponibili nella versione comunitaria.
Questo tipo di strategia ha alcuni vantaggi, ad esempio costituisce una garanzia di indipendenza per il cliente, che al massimo dovrà migrare verso una versione “comunitaria” tutto sommato simile, e rimpiazzare le parti proprietarie o con le versioni sviluppate dalla comunità, oppure da imprenditori concorrenti (nel caso di Zimbra, ad esempio, Zextras), oppure create ad hoc da ditte specializzate sulla tecnologia. Inoltre si segmenta il mercato, offrendo una soluzione premium a chi è interessato a livelli di servizio e prestazioni più elevate, mentre non si rinuncia all’effetto di rete dato dall’utilizzo di gran parte della base di codice per chi non ha risorse o necessità per giustificare il livello premium.
Modelli di subscription “puri”
In realtà, il modello più aderente alla filosofia del software libero è quello “puro” di servizi.
Qui ci sono spesso fraintendimenti. Può accadere che da un punto di vista esteriore, la forma giuridica del rapporto tra l’operatore economico e il cliente sia, in modo un po’ sorprendente di vendita di “licenze”.
“Ma come”, i più attenti avranno già pensato “comperare software libero non si può”. Ni. L’acquisto di una copia del software conclude comunque un contratto di vendita in entrambi i casi. Nel contratto di acquisto di software proprietario si acquista, oltre alla copia in sé (il software, sia che venga consegnato su un supporto o da una risorsa online) anche un diritto d’uso di una o più copie, oltre a una serie di prestazioni accessorie. Acquistando invece una copia di software libero, non si acquista il diritto d’uso, perché quello è già garantito dalla licenza originale, e tale licenza viene concessa per effetto stesso della distribuzione.
Il distributore non può subordinare al pagamento di una somma di denaro o all’approvazione di clausole aggiuntive i diritti già concessi dalla licenza, in questo dunque la sorpresa del lettore è legittima. Ma nessuna licenza impone di distribuire il software libero che si detiene, anche quello che si è modificato. Per cui legittimamente il detentore di quella versione del software può pretendere un compenso per consegnarne una copia. Il destinatario poi potrà in perpetuo comunque esercitare tutti i diritti assegnatigli, compreso quello di distribuire altre copie o, nel caso di software copyleft, di ottenere il completo corrispondente codice sorgente della copia che ha ricevuto.
Indipendentemente dalla modalità di acquisizione, il rapporto tra le parti in un modello di subscription può anche avere caratteristiche per certi versi simili a quello proprietario. Ad esempio è facile osservare un limite massimo di copie installabili oppure l’obbligo di installare il software su tutte le macchine di una certa categoria (Red Hat). Anche qui, la limitazione non deriva dalla licenza, ma dal contratto ed è una condizione per poter fruire delle altre prestazioni contrattuali. Ancora, può capitare di rinvenire nelle condizioni un divieto di modifica del software o di caricare versioni compilate da sé. Anche qui, si tratta di una condizione contrattuale, non di una condizione della licenza. La differenza principale è che in caso di violazione, la sanzione sarà di natura contrattuale, ad esempio l’inoperatività della garanzia, l’inesigibilità dell’obbligo di assistenza, la risoluzione contrattuale. Giammai la perdita del diritto di usare il software, o la perdita della licenza.
Al termine del contratto, anche in caso di risoluzione contrattuale, il cliente sa che potrà conservare le versioni installate del software, modificarle, installarle su altre macchine. Insomma, sarà garantito contro il lock-in perché, venuto meno il contratto, il software rimarrà pur sempre software libero.
Il cliente potrà cedere copie a terzi? In base alla licenza, sicuramente. In base al contratto, probabilmente sì (altrimenti ci potrebbe essere un vincolo inconciliabile con la licenza). Tuttavia c’è da considerare un elemento di cui ancora non abbiamo parlato, e che conclude la nostra trattazione.
Il marchio
Il marchio, in un modello di business legato al software libero, è forse il diritto di privativa più importante nel controllare e garantire sufficienti ritorni. E forse è anche l’unico che non ha grandi incompatibilità (se non in casi difficilmente concepibili) con nessuna licenza di software libero. Ed è per questo che non mi stancherò di ripetere che in qualsiasi progetto o attività legate al software libero un investimento sostanziale sui marchi è da considerare quanto più presto possibile.
Per quanto riguarda la monetizzazione dell’attività, il marchio ha ovviamente la funzione di incrementare il valore del fornitore, rendendolo riconoscibile e consentendo di riconnettere, nella visione degli utenti, i valori positivi del prodotto al suo produttore (anche quelli negativi, ma è un’altra storia) e viceversa. Con una politica accorta del marchio (“trademark policy”), si potrà distinguere il proprio prodotto e il proprio servizio da quello di concorrenti, anche nel caso in cui si tratta di software tutto sommato simile. E anche nel caso in cui il software sia proprio lo stesso, bit per bit. Un esempio chiarirà meglio: Red Hat realizza una delle distribuzioni di Linux più conosciute, soprattutto appetibile in installazioni di livello industriale. Oracle ha potuto prendere l’intera distribuzione di Red Hat e offrirla ai propri clienti (quasi) tale-quale. L’unica differenza è che non ha potuto “venderlo” con il marchio Red Hat. In questo caso è ovviamente difficile stabilire se valga di più il marchio Red Hat o quello di Oracle, quello che importa è che i prodotti abbiano un marchio diverso così ognuno “vale” per quanto sono i meriti della propria attività, e non ci si appropria di quella altrui.
Resta il fatto che il nome del prodotto da cui il prodotto rimarchiato deriva potrà essere comunque presente, ma in funzione descrittiva, per designarne l’origine, dunque in buona fede, in modo non apparente come il marchio del secondo operatore, in modo da non causare confusione quanto all’origine del prodotto e l’identità del produttore. Tale uso è lecito e non richiede il permesso del titolare.
Allo stesso modo, nel caso di un operatore che realizza software open core, in dual licensing o ibrido, con un marchio riconosciuto, un concorrente potrà affermare di supportare la versione community della propria controparte, usando per offrire i propri prodotti e servizi il marchio del produttore originale, in versione descrittiva, ovvero senza dare l’impressione di essere “ufficiale” o “autorizzato” (pena, oltre alla contraffazione del marchio, una possibile censura per concorrenza sleale)
Sarà possibile anche per il concorrente distribuire la versione community della propria controparte? La risposta è tendenzialmente negativa.
Il principio di esaurimento prevede che il marchio (ma anche il copyright) non possa essere utilizzato per controllare l’ulteriore diffusione di un prodotto da parte di chi ne abbia acquistato una copia. Una volta acquistata tale copia, essa può dunque essere rivenduta (vedi la sentenza UsedSoft per il copyright) senza chiedere il permesso.
È piuttosto evidente però nel caso di una licenza di software libero, chi acquisisce la copia non abbia solo il diritto di usare quella copia, ma abbia molti diritti ulteriori. Facendo circolare copie del prodotto originale, non sta “rivendendo” la propria copia, non sta dunque ri-distribuendo un singolo individuo della specie, ma sta facendo un’attività di creazione e distribuzione di prodotti “nuovi” (le virgolette sono d’obbligo), attività che deve essere autorizzata dal titolare del marchio.
Conclusioni
Abbiamo solo scalfito la superficie, i modelli di business ottenibili dal software libero sono molteplici e le combinazioni infinite. Non abbiamo trattato dei modelli che usano il software per vendere hardware, o per popolare la propria offerta in cloud, non trattandosi di modelli in cui il software distribuito è la pietanza principale. Ma è un modello che non può essere sottaciuto, in un mondo in cui alcune delle più grandi società del mondo si basano quasi esclusivamente su software libero utilizzato per il cloud, da Amazon a Facebook, da eBay a Google.
Termina qui, dunque, la nostra breve disamina dell’open declinato sul mondo del software.
Facebook Comments