On 09/11/2010 19:58, Davide Prina wrote: > On 09/11/2010 10:58, Federico Di Gregorio wrote: >> On 09/11/2010 10:38, Paolo Sala wrote: > >>> Ti affidi ad un loro strumento e poi la versione successiva.. cucù! >> >> E quindi? E` come dire che non usi software libero perché il detentore >> del copyright può sempre cambiare licenza in una versione succesiva. Ti >> sembra sensato? > > ma facciamo un esempio concreto per capire se il tuo controesempio è > valido o meno. I casi possono essere visti come assurdi, ma servono solo > per esaminare la risposta ricevuta e vedere se è coerente o meno al > discorso. > > Oracle ha acquisito Sun e sembra non si comporta molto bene per alcuni > ex progetti Sun che erano o sono ancora rilasciati con licenza libera. > > 1) Mettiamo il caso che da domani rilasci OpenOffice.org solo con > licenza proprietaria e non più con licenza LGPL 3.0. > > Io (certamente non io, ma una qualsiasi persona o gruppo di persone) > posso prendere i sorgenti dell'ultima versione LGPL 3.0 e continuare lo > sviluppo rispettando tale licenza, o, a mia scelta, aggiornarla ad una > licenza superiore, come permesso dalla LGPL. > > Posso avere un danno perché chi produceva OpenOffice.org non mi permette > più di averlo con una licenza LGPL, ma devo acquistarlo come prodotto > proprietario o, molto meglio, contribuire per continuare ad avere un > prodotto libero. > > Lo stesso si può dire nel caso in cui Oracle cessi l'implementazione e > la distribuzione del prodotto.
Esatto. > 2) Facciamo invece un altro caso, prendendo sempre in esame Oracle. > Da domani Oracle decide che non emetterà più nessuna nuova versione dei > suoi database relazionali, che non fornirà più patch o assistenza; > semplicemente si dedicherà ad altro, magari ancora principalmente > database, ma non più relazionali e non più di quel tipo (è successo un > bel po' di anni fa con alcuni prodotti proprio di Oracle). > > Cosa succede se io sono un utente Oracle e uso in produzione i suoi > ex-database relazionali? > a) o passo alla nuova tipologia di database che Oracle mi offre o passo > alla concorrenza... però questo potrebbe essere per me troppo costoso o > semplicemente non auspicabile (es: mette a disposizione solo database > sui suoi server esterni, ma io non voglio metterci i miei dati) > b) mi tengo la versione attuale... però se c'è un bug di sicurezza dovrò > rischiare i miei dati, se c'è un bug dovrò cercare di aggirarlo in > qualche modo (non potrò in ogni caso correggerlo), se questo database > non funziona su versioni nuove dei futuri sistemi operativi (chi mi > assicura che funzionerà? senza certezze forse conviene restare su > versioni arcaiche), sarò costretto a tenermi versioni vetuste con tutti > i problemi che ne comportano (magari non funziona su hardware recente, > magari ci sono bug, ...) Sempre esatto. > A mio parere il controesempio fatto non calza, perché nel caso del > software libero puoi subentrare al precedente detentore del copyright > continuando lo sviluppo e la distribuzione; mentre nel caso di un > prodotto proprietario... sei su un binario morto! Non puoi fare proprio > nulla. Sempre esatto e, ovviamente, sono d'accordo. Però non vedo come questo c'entri col mio discorso. Io non sto parlando di usare prodotti proprietari M$ (cosa che *non* faccio tranne casi eccezionali di lavoro e anche li con la puzza sotto il naso) bensì di usare software libero basato su specifiche pubbliche (di M$) con la garanzia che quelle specifiche *non* contengono brevetti che verranno utilizzati per limitarmi. Io dico: 1) Mono è software libero e M$ ha promesso che non farà mai valere i suoi brevetti. 2) F# è rilasciato da M$ sotto licenza Apache 2 (che oltre a tutto il resto protegge dai brevetti). Ora, non dvrei usare questo software libero solo perché in qualche modo (specifiche in un caso (1), copyright nell'altro (2)) c'è sopra il bollino M$? federico -- Federico Di Gregorio [email protected] Bhoe, bhe, bhe. Sono brutto e cattivo. Brutto lama! -- Cuzco -- Per REVOCARE l'iscrizione alla lista, inviare un email a [email protected] con oggetto "unsubscribe". Per problemi inviare un email in INGLESE a [email protected] To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
