Trovo tutta questa messe di mail sull'argomento licenze molto
interessante, perchè da modo anche a quelli che come me non si occupano
di sviluppo, ma sono solo end-user, di capire le varie filosofie e
anche qualche retroscena.
Ora sto usando sia OpenOffice che LibreOffice e mi pare di notare -
anche se è un po' prematuro per me dirlo - che quest'ultimo non ha i
problemi di stabilità del primo quando si maneggia BASE, almeno sulla
mia macchina (Win XP).
Ciao.
Aldo
Il 07/01/2012 16.16, Italo Vignoli ha scritto:
On 1/6/12 8:56 PM, Renato Ferrari wrote:
Sul sito di Apache, ma forse ho cercato male, ho letto la licenza versione 2.0
(2004), data per corrente, che sembra gpl3.
Apache License non è compatibile con GPL e LGPL, per cui il codice
rilasciato da Apache Software Foundation non può contenere componenti
rilasciati con queste due licenze. In questo momento, la maggior parte
dell'attività dei pochi(ssimi) sviluppatori di Apache Openoffice (Ohloh
fornisce un eccellente confronto tra Apache OpenOffice e LibreOffice, a
questo indirizzo
https://www.ohloh.net/p/compare?project_0=LibreOffice&project_1=Apache+OpenOffice)
è concentrata sulla rimozione di tutti i componenti copyleft, e solo nel
caso del filtro di importazione SVG quest'attività si è tradotta in uno
sviluppo utile.
Apache License è un'ottima licenza, quando viene utilizzata per gli
scopi per cui è nata, ovvero per sviluppare software (sistemi operativi
e programmi) indirizzato a chi lo riutilizza per farne un prodotto per
gli utenti finali.
Cerco di spiegare meglio con due esempi reali: Apache Server viene
utilizzato per sviluppare soluzioni, ma non viene fornito da solo se non
a chi sa come utilizzarlo (quindi, non è un prodotto end user); il
sistema operativo Android viene utilizzato dai produttori di telefoni
per creare la propria soluzione end user (quindi, diventa end user solo
con l'aggiunta di sviluppi quasi sempre proprietari).
Se Apache License è un'ottima licenza, perché - nel caso di OpenOffice -
diventa una pessima (opinione personale) licenza?
Facciamo un po' di storia del rapporto tra OpenOffice e IBM. La prima
versione di OOo aveva due licenze: LGPL (copyleft) e SISSL (permissiva o
copyfree). IBM ha sfruttato la licenza permissiva per sviluppare
Symphony, e quando OOo ha abbandonato la licenza SISSL (perché, a parte
IBM, nessuna azienda l'aveva adottata, per cui non aveva senso tenerla
in vita) con la versione 2.0, ha preferito continuare a usare il codice
sorgente di OOo 1.1 (che era un'antologia di bug) piuttosto che essere
obbligata dalla LGPL a contribuire i propri sviluppi alla comunità.
Nel 2008, IBM ha firmato un accordo con Sun che le consentiva di usare
il codice sorgente di OOo 3.0 per sviluppare un prodotto proprietario,
senza contribuire gli sviluppi alla comunità. Sun deteneva tutto il
copyright sul codice, per cui poteva fare questo accordo.
Nel 2008 alla conferenza di Pechino IBM ha ammesso di essere un cattivo
membro della comunità. Nel 2011 alla PlugFest di Berlino IBM ha ammesso
di essere un cattivo membro della comunità. In entrambi i casi ha detto
che avrebbe contribuito i propri sviluppi, ma non si è ancora visto
nulla (e secondo me non si vedrà mai nulla).
IBM ha "guidato" Oracle verso la donazione di OOo ad Apache Software
Foundation (IBM ha salutato l'annuncio con un comunicato stampa e tre
post - Rob Weir, Sam Ruby e Bob Sutor - nel giro di 30 minuti dal
comunicato di ASF, e siccome IBM impiega da due a tre settimane per la
semplice approvazione di un comunicato stampa, che il tutto non sia
stato concertato lo possono raccontare a tutti ma non al sottoscritto,
che fa il comunicatore aziendale da trent'anni ed è stato consulente
della stessa IBM) perché la Apache License le avrebbe permesso di
perpetuare nel tempo l'uso del codice sorgente di OOo senza contributo
alla comunità.
Il problema sono gli effetti collaterali della Apache License, ovvero la
necessità di rimuovere il codice con licenza GPL e LGPL che non era di
proprietà Sun/Oracle (che non era stato utilizzato per caso), e il fatto
che le licenze permissive tendono a tenere alla larga gli sviluppatori
volontari dal progetto (per cui senza i 5 sviluppatori IBM e i
pochissimi sviluppatori volontari che aderiscono al progetto o per una
propria crociata contro le licenze copyleft o per ostilità verso TDF gli
sviluppatori tenderebbero a zero).
Ovviamente, tutti i giudizi sono assolutamente di parte.
