[relug] thread su licenze
- From: Daniele Torelli <torelizer@xxxxxxxxxxx>
- To: RELug <relug@xxxxxxxxxxxxx>
- Date: Wed, 26 Mar 2003 21:51:39 +0100
come promesso vi fwdo l'interminabile thread su GPL, BSD e chi più ne ha più ne
metta che ha imperversato sulla ML di Python per lungo tempo, ho riportato solo
l'antefatto e gli interventi più "filosofici" (vedi scontro AM vs FDG) perchè
quelli tecnici (almeno altrettanti) erano su casi abbastanza specifici e poi già
ci vuole del fegato e del tempo a leggersi tutta questa roba. Ho sostituito gli
autori delle mail con le iniziali, giusto per identificare i "personaggi" di
questa contesa... auguri al lettore ;-)
- MM
> Credo di aver letto tempo fa su questa ml che la licenza Python è più
> 'permissiva' della licenza GPL. Ricordo bene?
>
> A grandi linee in cosa differiscono le due licenze?
>
Il punto fondamentale (secondo me) della GPL e' che essa e' pensata per
garantire che tutti gli utenti ricevano gli stessi permessi della
licenza originaria (il copyleft, da "permesso d'autore") e che tali
permessi vengano trasmessi nei lavori derivati. Classico esempio, per
garantire le liberta' fondamentali deve essere disponibile il codice
sorgente.
Altre licenze, come quella di Python, o anche BSD, non impongono nulla,
lasciano solo totale liberta'. Questo significa pero' anche che lavori
derivati possono non avere gli stessi "permessi" che c'erano in origine.
Il "vantaggio" e' ad esempio che si puo' distribuire un "eseguibile"
senza il relativo sorgente.
Esiste anche una versione apposita della licenza GNU, la LGPL, per
potersi collegare a lavori non GPL, comunque.
> Ho letto entrambe le licenze ma, tra lingua inglese e termini legali,
> non sono riuscito a cogliere dove stia una differenza sostanziale. Dove
> posso leggere qualcosa di specifico su queste differenze?
Io ho trovato "illuminante":
http://www.gnu.org/licenses/licenses.html
Certo il discorso non e' cosi' semplice e banale come l'ho esposto qui,
ma mi sembrava di poter enfatizzare la caratterizzazione piu' evidente
nei due contesti.
- F
> Esiste anche una versione apposita della licenza GNU, la LGPL, per
> potersi collegare a lavori non GPL, comunque.
Esattamente, tutto giusto, per la LGPL diciamo che c'è stato un
compromesso proprio per permettere di distribuire librerie con una
licenza che potesse essere impiegata anche in ambiti "proprietari",
altrimenti con la GPL ci sarebbero stati problemi.
Banalmente ... la licenza di Python è _più_ permissiva della GPL, non
migliore, diversa, a seconda delle _tue_ esigenze ne adotti una o
l'altra (o le altre centinaia che ci sono in giro).
- AG
> Banalmente ... la licenza di Python è _più_ permissiva della GPL, non
> migliore, diversa, a seconda delle _tue_ esigenze ne adotti una o
> l'altra (o le altre centinaia che ci sono in giro).
Attenzione, che in realta` non puoi adottare la licenza di python cosi`
com'e` per tue applicazioni. ovviamente IANAL, ma questo e` abbastanza
chiaro:
http://groups.google.com/groups?hl=it&lr=&ie=UTF-8&selm=m3vg3br5sg.fsf%40mira.informatik.hu-berlin.de
- AM
> Credo di aver letto tempo fa su questa ml che la licenza Python è più
> 'permissiva' della licenza GPL. Ricordo bene?
Si`.
> A grandi linee in cosa differiscono le due licenze?
Qualsiasi lavoro derivato da programmi coperti da GPL deve usare
egualmente la licenza GPL. Con la licenza Python, come con quasi
tutte le altre licenze Open Source (www.opensource.org) diverse da
GPL e LGPL, puoi invece anche scegliere di mantenere closed-
source i tuoi programmi derivati da Python. Ad esempio potresti
scegliere di modificare Python e trarne un tuo prodotto "Sython"
da vendere commercialmente, closed-source.
> Ho letto entrambe le licenze ma, tra lingua inglese e termini legali,
> non sono riuscito a cogliere dove stia una differenza sostanziale. Dove
> posso leggere qualcosa di specifico su queste differenze?
Oltre che su opensource.org, trovi un breve riassunto su
http://www.linux4smallbiz.com/guide/licenses e su vari altri
siti. Come sempre, google aiuta molto in questo.
Raramente troverai menzionata specificamente la licenza di
Python su questi trattati generali sull'open-source, ma non e`
un problema, poiche` essa non e` molto differente da quelle
BSD o X11.
- FN
un domanda: cercando un po' ho visto che la licenza di Python e' un po'
cambiata nel tempo e tra le versioni, pur rimanendo sempre nei limiti di
licenza di un Software Libero. Ora, visto che ogni volta che si parla di
SL si ha come pietra di paragone la GPL (non che sia verbo divino, per
carita', ma senz'altro una pietra di paragone), mi chiedo come mai per
Python non si sia scelto di applicare la GPL.
- AM
Forse perche` il patito di Python e` Eric Raymond (colui che ha coniato
il termine "open source" ed e` il paladino delle licenze OS non-GPL) e
non RMS?-)
In breve: le motivazioni per la licenza di Python sono sostanzialmente
le stesse che per ogni altra applicazione OS con licenza non-GPL, come
tutte le versioni di BSD gratuiti, VIM, Perl con la sua Artistic License,
Mozilla, e via elencando: NON impedire l'uso del codice cosi` coperto a
chi, per qualsiasi ragione, vuole o deve "chiudere" i sorgenti di una parte
o del tutto di un prodotto derivato da detto codice -- questo "impedire" e`
invece appunto lo scopo del GPL, che appunto usa il termine "free
software" e NON quello "open source". E` un po' una guerra di religione,
naturalmente. Entrambi i campi hanno come scopo strategico quello di
massimizzare la quantita` di software aperto in uso; il campo GPL ha una
posizione piu` moralistica e di principio, quello OS una piu` pragmatica, e
ciascuno dei due e` convinto che la sua posizione serva meglio gli scopi
strategici. Non a caso Raymond e RMS si detestano cordialmente;-).
- FDG
mah, questa mi pare abbastanza buffa. Eric Raymond non c'entra niente
con la licenza di Python, che e` cambiata nel tempo a seconda del datore
di lavoro del suo autore principale (GVR) ed anche per divenire alla
fine GPL compatibile.
> In breve: le motivazioni per la licenza di Python sono sostanzialmente
> le stesse che per ogni altra applicazione OS con licenza non-GPL, come
> tutte le versioni di BSD gratuiti, VIM, Perl con la sua Artistic License,
> Mozilla, e via elencando: NON impedire l'uso del codice cosi` coperto a
> chi, per qualsiasi ragione, vuole o deve "chiudere" i sorgenti di una parte
vuole. il "deve" non esiste.
> E` un po' una guerra di religione,
> naturalmente. Entrambi i campi hanno come scopo strategico quello di
> massimizzare la quantita` di software aperto in uso; il campo GPL ha una
> posizione piu` moralistica e di principio, quello OS una piu` pragmatica, e
piu`o meno. ovvero, detto cosi` e`giusto ma forse chi non ne sa molto
rimane un po'confuso. non e` una guerra di religione, se proprio
vogliamo e` uno scontro di culture.
posso consigliare la lettura di:
http://www.gnu.org/philosophy/categories.html
ed articoli affini.
- AM
> di lavoro del suo autore principale (GVR) ed anche per divenire alla
> fine GPL compatibile.
Si`, con quattro avvocati su cinque che sostenevano che lo era gia` e
quello favorito di RMS che invece si impuntava che non lo era. Alla
fine cambiando tre o quattro parole e punteggiatura ha smesso di
rompere anche quel quinto. Non ti dico i soldi e il tempo sprecati...
> vuole. il "deve" non esiste.
Balle spaziali. Mai sentito parlare di forze armate, servizi segreti, e
simili? Ci sono FIOR di leggi che impongono a simii corpi, in vari paesi,
di imporre certe limitazioni ad alcuni tipi di software che essi sviluppano --
limitazioni che non sono compatibili con la licenza GPL.
Hai mai sentito ER e RMS discuterne di persona? Non ti restera` alcun
dubbio sul livello religioso dello scontro...
- FDG
scarsa conoscenza della GPL (senza offesa, afferrarne tutte le
implicazioni non e` banale). la GPL scatta quando *distribuisci* del
codice, per cui, se sei l'esercito degli stati uniti (tanto per citarne
uno che presto vedremo tristemente in azione) puoi tenere segrete
*tutte* le modifiche al software, purche' tu non lo distribuisca al di
fuori dell'esercito. questo perche':
1/ all'interno dell'esercito i sorgenti girano senza problemi (come
succederebbe per il software proprietario);
2/ se non lo distribuisci all'esterno non hai alcun obbligo di
divulgare le modifiche da te apportate.
ovviamente se gli stati uniti vogliono vendere all'arabia saudita un
carro armato automatico con dentro un software GPL devono dargli i
sorgenti, ma quella e` una loro scelta. non *obbligo*, scelta, perche'
possono decidere di *non vendere* il carro armato (e fanno bene, imo).
> > piu`o meno. ovvero, detto cosi` e`giusto ma forse chi non ne sa molto
> > rimane un po'confuso. non e` una guerra di religione, se proprio
> > vogliamo e` uno scontro di culture.
>
> Hai mai sentito ER e RMS discuterne di persona? Non ti restera` alcun
> dubbio sul livello religioso dello scontro...
lo scontro fra loro due si. lo scontro d'idee fra FS e OSS no.
- AM
> codice, per cui, se sei l'esercito degli stati uniti (tanto per citarne
> uno che presto vedremo tristemente in azione) puoi tenere segrete
> *tutte* le modifiche al software, purche' tu non lo distribuisca al di
> fuori dell'esercito. questo perche':
No: puoi tenerlo segreto solo purche` tu non lo distribuisca *per nulla*.
Se lo distribuisci _entro_ l'esercito, devi esibire i sorgenti a tutti coloro
cui lo distribuisci. "L'esercito" non e` una persona, ma un ampio
insieme di persone, alcune delle quali (secondo leggi che non ha
stabilito l'esercito stesso, bensi` il Parlamento) hanno la "security
clearance" necessaria per vedere i sorgenti dei programmi che usano,
mentre altre (la maggioranza) no.
Dal punto di vista dell'esercito, le leggi del paese *DEVONO* essere
rispettate. Dunque, non ha senso dire, neppure di un organismo di
milioni di persone come un intero esercito, che *vuole*, ma bensi` ha
senso solo dire che *deve*, conservare la possibilita` di mantenere
riservati i sorgenti di alcuni programmi che sviluppa e distribuisce
(_deve_ distribuire, per rispettare le leggi che ne regolano le azioni).
> 1/ all'interno dell'esercito i sorgenti girano senza problemi (come
> succederebbe per il software proprietario);
Chiaramente non sai di cosa stai parlando. I sorgenti di moltissimi
programmi di uso militare non possono "girare senza restrizioni" ne`
piu` ne` meno di quanto non lo possano tante altre informazioni.
> 2/ se non lo distribuisci all'esterno non hai alcun obbligo di
> divulgare le modifiche da te apportate.
Se il compito (sancito dalla legge) di un laboratorio militare, o di
un'azienda che lavora per i militari, e` di sviluppare ad esempio il
software per il controllo di un aereo o simili, non a scopi strettamente
sperimentali ma operativi, la "distribuzione" del software stesso (ad
altri reparti / aziende sotto contratto militare) e` inevitabile.
> ovviamente se gli stati uniti vogliono vendere all'arabia saudita un
> carro armato automatico con dentro un software GPL devono dargli i
> sorgenti, ma quella e` una loro scelta. non *obbligo*, scelta, perche'
> possono decidere di *non vendere* il carro armato (e fanno bene, imo).
Stai confondendo i soggetti. La decisione se vendere o meno un certo
sistema d'arma viene presa (dal Governo, dal Parlamento, ecc, *NON*
dall'esercito, tanto meno dal laboratorio o azienda che sviluppa detto
sistema d'arma ed in particolare il suo software) molto tempo dopo che
il software e` stato sviluppato. Per conservare la propria futura liberta`
di scelta, parlamenti, governi ecc impongono limiti legali (quindi il "deve")
agli sviluppatori. L'ingegnere che ha scelto, anni fa, di arruolarsi nel
corpo tecnico dell'esercito, si e` impegnato a rispettare le leggi del suo
paese e in particolare ad obbedire agli ordini conformi alle leggi: e dunque
*deve* rispettare questi limiti. Nell'imporre l'uso di questo verbo
concordano il buon senso, le leggi ed i regolamenti di tutti i paesi,
e l'uso comune e abituale di tutti i linguaggi umani.
Di conseguenza, e` perfettamente corretto parlare di chi "vuole o
_deve_ chiudere i sorgenti" del software che sviluppa. Il soggetto non
e` un'intera nazione (o addirittura un grande complesso di nazioni
nel caso di alleanze e accordi internazionali per sviluppare sistemi
d'arma): chi sviluppa e` un individuo, un gruppo di individui, un dato
reparto o laboratorio, un'azienda, un gruppo di aziende -- le leggi che
ne regolano le azioni e ne vincolano alcune decisioni non le scelgono
loro, ma il parlamento (o un insieme di parlamenti).
Il tuo rifiuto di accettare questi fatti evidenti mi sembra che sia un
buon indicatore della natura di "guerra di religione" della crociata dei
paladini del GPL. Apparentemente pensando che ammettere l'ovvio
fatto che alcuni sviluppatori *non possono* rilasciare i sorgenti del
software che distribuiscono, poiche` le leggi glielo impediscono,
potrebbe in qualche modo indebolire la vosta crociata, la soluzione
e` semplice: negare l'evidenza dei fatti, tentare di confondere i
soggetti del discorso, magari, perche` no, provare anche a giocare
sull'attuale diffusissimo senso di rigetto contro atteggiamenti ed
azioni del governo USA. Se la realta` dei fatti si trova in contrasto
con la vostra ideologia, negare i fatti: piu` "religione" di cosi`...!
- FDG
> Se lo distribuisci _entro_ l'esercito, devi esibire i sorgenti a tutti coloro
> cui lo distribuisci. "L'esercito" non e` una persona, ma un ampio
e io cosa ho detto scusa?
> insieme di persone, alcune delle quali (secondo leggi che non ha
> stabilito l'esercito stesso, bensi` il Parlamento) hanno la "security
> clearance" necessaria per vedere i sorgenti dei programmi che usano,
> mentre altre (la maggioranza) no.
ok, su questo ti do ragione. ma..
> Se il compito (sancito dalla legge) di un laboratorio militare, o di
> un'azienda che lavora per i militari, e` di sviluppare ad esempio il
> software per il controllo di un aereo o simili, non a scopi strettamente
> sperimentali ma operativi, la "distribuzione" del software stesso (ad
> altri reparti / aziende sotto contratto militare) e` inevitabile.
si, ma i reparti possono non avvalersi del diritto ai sorgenti. essendo
tutto all'interno di un "organismo" molto rigido sarebbe banale farlo.
ovvero, sei soldato? se si, se non sei uun super-mastro-capo non ti e`
permesso leggere i sorgenti marcati come "Livello di Sicurezza
Ultravioletto". oh, si, puoi farteli dare, ma se li leggi vai sotto
corte marziale.
> Stai confondendo i soggetti. La decisione se vendere o meno un certo
> sistema d'arma viene presa (dal Governo, dal Parlamento, ecc, *NON*
> dall'esercito, tanto meno dal laboratorio o azienda che sviluppa detto
> sistema d'arma ed in particolare il suo software) molto tempo dopo che
> il software e` stato sviluppato. Per conservare la propria futura liberta`
> di scelta, parlamenti, governi ecc impongono limiti legali (quindi il "deve")
> agli sviluppatori. L'ingegnere che ha scelto, anni fa, di arruolarsi nel
> corpo tecnico dell'esercito, si e` impegnato a rispettare le leggi del suo
> paese e in particolare ad obbedire agli ordini conformi alle leggi: e dunque
> *deve* rispettare questi limiti. Nell'imporre l'uso di questo verbo
> concordano il buon senso, le leggi ed i regolamenti di tutti i paesi,
> e l'uso comune e abituale di tutti i linguaggi umani.
questo e` vero ma e` una *scelta* di quella persona quando va a lavorare
li. se voglio fare software GPL, rifiuto ogni offerta di lavoro della
microsoft, ovviamente.
cosi` come e` una scelta del governo chiudere i sorgenti per garantirsi
quello che tu hai descritto qui` sopra.
il *devo* e` rarissimo e troppo spesso usato per giustificare *scelte*
che non si giustificano in altro modo. ma questa e` filosofia ed andiamo
OT.
> Di conseguenza, e` perfettamente corretto parlare di chi "vuole o
> _deve_ chiudere i sorgenti" del software che sviluppa. Il soggetto non
> e` un'intera nazione (o addirittura un grande complesso di nazioni
> nel caso di alleanze e accordi internazionali per sviluppare sistemi
> d'arma): chi sviluppa e` un individuo, un gruppo di individui, un dato
> reparto o laboratorio, un'azienda, un gruppo di aziende -- le leggi che
> ne regolano le azioni e ne vincolano alcune decisioni non le scelgono
> loro, ma il parlamento (o un insieme di parlamenti).
ma quella persona ha scelto di mettersi in quella situazione.
> Il tuo rifiuto di accettare questi fatti evidenti mi sembra che sia un
> buon indicatore della natura di "guerra di religione" della crociata dei
> paladini del GPL. Apparentemente pensando che ammettere l'ovvio
no, e` solo un'indicazione di parecchio tempo passato a meditare sul
significato dei termini "dovere" e "scelta" ed una notevole voglia di
difendere l'autodeterminazione di ogni persona. c'entrano poco la GPL o
le guerre di religione.
> fatto che alcuni sviluppatori *non possono* rilasciare i sorgenti del
> software che distribuiscono, poiche` le leggi glielo impediscono,
per fortuna ancora non esistono leggi in questo senso (in europa). anche
se l'EUCD va in questo senso.. purtroppo :(
- AM
> e io cosa ho detto scusa?
Hai detto "distribuisca *al di fuori* dell'esercito". Lo lascio citato sopra
per riferimento.
> > insieme di persone, alcune delle quali (secondo leggi che non ha
> > stabilito l'esercito stesso, bensi` il Parlamento) hanno la "security
> > clearance" necessaria per vedere i sorgenti dei programmi che usano,
> > mentre altre (la maggioranza) no.
>
> ok, su questo ti do ragione. ma..
Oh bene. Dunque il "deve" si applica e ritiri le tue osservazioni in
contrario?-)
> > Se il compito (sancito dalla legge) di un laboratorio militare, o di
> > un'azienda che lavora per i militari, e` di sviluppare ad esempio il
> > software per il controllo di un aereo o simili, non a scopi strettamente
> > sperimentali ma operativi, la "distribuzione" del software stesso (ad
> > altri reparti / aziende sotto contratto militare) e` inevitabile.
>
> si, ma i reparti possono non avvalersi del diritto ai sorgenti. essendo
> tutto all'interno di un "organismo" molto rigido sarebbe banale farlo.
> ovvero, sei soldato? se si, se non sei uun super-mastro-capo non ti e`
> permesso leggere i sorgenti marcati come "Livello di Sicurezza
> Ultravioletto". oh, si, puoi farteli dare, ma se li leggi vai sotto
> corte marziale.
Con GPL, non puoi imporre ai soggetti cui distribuisci il programma
ulteriori condizioni restrittive. L'articolo 7 della licenza e` chiarissimo
in merito: se non puoi distribuire in modo da soddisfare simultaneamente
i tuoi obblighi secondo questa licenza, e altri obblighi su di te imposti
(per sentenze di tribunale o per qualsiasi altra ragione non limitata a
questioni di brevetto), allora non puoi distribuire per nulla.
> > Stai confondendo i soggetti. La decisione se vendere o meno un certo
> > sistema d'arma viene presa (dal Governo, dal Parlamento, ecc, *NON*
> > dall'esercito, tanto meno dal laboratorio o azienda che sviluppa detto
> > sistema d'arma ed in particolare il suo software) molto tempo dopo che
> > il software e` stato sviluppato. Per conservare la propria futura
> > liberta` di scelta, parlamenti, governi ecc impongono limiti legali
> > (quindi il "deve") agli sviluppatori. L'ingegnere che ha scelto, anni
> > fa, di arruolarsi nel corpo tecnico dell'esercito, si e` impegnato a
> > rispettare le leggi del suo paese e in particolare ad obbedire agli
> > ordini conformi alle leggi: e dunque *deve* rispettare questi limiti.
> > Nell'imporre l'uso di questo verbo concordano il buon senso, le leggi ed
> > i regolamenti di tutti i paesi, e l'uso comune e abituale di tutti i
> > linguaggi umani.
>
> questo e` vero ma e` una *scelta* di quella persona quando va a lavorare
> li. se voglio fare software GPL, rifiuto ogni offerta di lavoro della
> microsoft, ovviamente.
Prestare servizio militare e` una libera scelta in alcuni paesi (ad esempio,
negli USA, al momento, lo e`) ma non in altri; non tutte le legislazioni
nazionali riconoscono neppure il diritto all'obiezione di coscienza, ovvero,
ove lo riconoscono, possono spesso imporre specifiche condizioni
relative a quali "obiezioni" possano giustificare il rifiuto di prestare il
servizio militare.
Ad esempio, in Italia, puoi dichiararti obiettore di coscienza solo se
ti opponi allâuso delle armi in ogni circostanza per motivi religiosi,
filosofici o per convinzioni morali (o almeno, cosi` recitava la legge
al tempo in cui dovevo interessarmene: i motivi politici erano invece
esplicitamente esclusi). Se non ti opponi all'uso delle armi in OGNI
circostanza, ma solo in ALCUNE, non puoi essere obiettore; neppure
puoi se le tue obiezioni non sono all'uso delle armi bensi` ad altre
caratteristiche del servizio militare di leva (ad esempio, all'indossare
la divisa, a salutare la bandiera italiana, ovvero allo scrivere programmi
i cui sorgenti non sono poi liberamente distribuibili).
Per continuare la tua arrampicata sugli specchi, ti suggerisco di
arzigogolare che tutto sommato questo dipende dalla "scelta" di
nascere maschio (nella maggior parte dei paesi le donne non sono
soggette a servizio militare obbligatorio), ovvero di non avere tentato
la diserzione, mentito spudoratamente sui propri moventi, ovvero
affrontato (a seconda delle circostanze) il plotone d'esecuzione...
A mio vedere, se una legge dello Stato impone al soggetto Y l'azione
X, e` molto piu` ragionevole e sensato dire che "Y _deve_ fare X",
piuttosto che non sostenere che l'uso del verbo "dovere" e` errato
in quanto Y potrebbe "scegliere" la galera, la fuga, la pena capitale,
o qualsiasi altra punizione imposta dalla legge per i violatori. Penso
che solo un fanatico religioso potrebbe opporsi, con i piu` capziosi
argomenti, a questo normalissimo uso del verbo "dovere".
> cosi` come e` una scelta del governo chiudere i sorgenti per garantirsi
> quello che tu hai descritto qui` sopra.
I governi ed i parlamenti fanno le loro scelte, ma il risultato per i
cittadini (particolarmente quelli che prestano servizio militare) puo`
essere meglio inquadrato come "dovere" che non come "scelta".
> il *devo* e` rarissimo e troppo spesso usato per giustificare *scelte*
> che non si giustificano in altro modo. ma questa e` filosofia ed andiamo
> OT.
Il verbo "dovere" e` usato comunemente nel linguaggio Italiano per
indicare, ad esempio, la situazione di un soldato relativamente ai
legittimi ordini dei superiori.
La "filosofia" (guerra di religione) l'hai iniziata tu attaccando il mio
uso (perfettamente corretto) di "deve".
> > Di conseguenza, e` perfettamente corretto parlare di chi "vuole o
> > _deve_ chiudere i sorgenti" del software che sviluppa. Il soggetto non
> > e` un'intera nazione (o addirittura un grande complesso di nazioni
> > nel caso di alleanze e accordi internazionali per sviluppare sistemi
> > d'arma): chi sviluppa e` un individuo, un gruppo di individui, un dato
> > reparto o laboratorio, un'azienda, un gruppo di aziende -- le leggi che
> > ne regolano le azioni e ne vincolano alcune decisioni non le scelgono
> > loro, ma il parlamento (o un insieme di parlamenti).
>
> ma quella persona ha scelto di mettersi in quella situazione.
Non necessariamente, vedi sopra, a meno che la tua religione non ti
imponga di sostenere che (ad esempio) nascere maschio e cittadino
di certi Stati e` "una scelta" della persona.
Ma il tuo argomento e` totalmente capzioso anche senza dovere
ricorrere a questi controesempi. Riguarda per benino l'articolo 7
del GPL. Esso riconosce che possono venire IMPOSTE (non usa,
nota bene, il termine SCELTE) condizioni su di un soggetto, ad
esempio da una sentenza di una corte (nota dunque che PERFINO
il GPL e` meno capzioso di te -- senza dubbio perche` se no non
avrebbe nessuna speranza di sopravvivere in qualsiasi tribunale! --
e riconosce come OBBLIGO, NON come scelta, quello di rispettare
le sentenze giudiziarie); se questi doveri contrastano con le varie
condizioni del GPL, l'unica possibilita` e` evitare *interamente* la
distribuzione del programma.
Se dunque tu firmi un qualsiasi contratto dove ti IMPEGNI a
distribuire un programma, o a collaborare alla scrittura di un
programma da distribuirsi; allora se SCEGLI di fare del tuo codice
un derivato di un programma coperto da GPL, puoi trovarti in una
situazione insolubile -- dove un tribunale sancisce che devi imporre
certe condizioni, il tuo contratto sancisce che devi distribuire, e
GPL dice che non puoi distribuire per incompatibilita` di condizioni.
Se *DEVI* distribuire un programma con condizioni che non sono
compatibili con GPL, allora devi fare altre SCELTE relative a come
sviluppare il tuo programma. Enfatizzo deliberatamente che quale
sia una scelta e quale un dovere puo` benissimo essere in questo
verso, non necessariamente al contrario.
Spero che questo intero scambio risponda esaurientemente alla
domanda che ha iniziato il thread: scegliendo condizioni di licenza
open-source meno restrittive del GPL, programmi come Python,
VIM, FreeBSD, X11, e via elencando, ti permettono di _scegliere_
assai piu` liberamente come sviluppare il tuo codice, in tutte quelle
situazioni in cui *DEVI o VUOI* imporre condizioni restrittive ad
alcuni di coloro cui distribuirai quel codice.
Se _scegli_ di derivare il tuo programma da programmi coperti da
GPL, puoi (a seconda delle obbligazioni legali e contrattuali) anche
trovarti in situazioni in cui ti e` impossibile adempiere a tutti i tuoi
obblighi. Se sviluppi codice originale e _scegli_ di coprirlo con GPL
invece che con una delle altre licenze open-source, porrai in questa
stessa situazione tutti coloro che potrebbero considerare l'opzione
di derivare i propri programmi dal tuo.
> > Il tuo rifiuto di accettare questi fatti evidenti mi sembra che sia un
> > buon indicatore della natura di "guerra di religione" della crociata dei
> > paladini del GPL. Apparentemente pensando che ammettere l'ovvio
>
> no, e` solo un'indicazione di parecchio tempo passato a meditare sul
> significato dei termini "dovere" e "scelta" ed una notevole voglia di
> difendere l'autodeterminazione di ogni persona. c'entrano poco la GPL o
> le guerre di religione.
"Yeah, right".
> > fatto che alcuni sviluppatori *non possono* rilasciare i sorgenti del
> > software che distribuiscono, poiche` le leggi glielo impediscono,
>
> per fortuna ancora non esistono leggi in questo senso (in europa). anche
> se l'EUCD va in questo senso.. purtroppo :(
Esistono gia` (come minimo in ambito militare). Non sono interessato
a discutere dell'EUCD, anche se potremmo essere d'accordo nel
deprecarlo, come minimo sino a quando non ho la certezza che il mio
interlocutore non s'inerpichera` sugli specchi per cercare di condannare
il mio uso perfettamente legittimo e valido di parole come "deve".
- FDG
taglio tutto, per vari motivi, che spiego prima di dare qualche
risposta. una discussione che e` partita piuttosto generica (devo vs
voglio) e` passata al fare le pulci alla gpl e quindi all'obiezione
civile.
credo che alcune di queste cose non interessino tutti (in effetti siamo
solo "noi" due a discutere) quindi daro` un'ultima risposta divisa in
tre parti (questione "filosofica", gpl, obiezione) e poi passerei in
privato *dopo* la prossima mail di alex (che sara` sicuramene pubblica,
mi pare giusto).
questione filosofica
--------------------
ti do ragione su di una cosa: a volte (imo molte poche) devi usare una
licenza che non sia la GPL. il tuo esempio sul povero milite di leva in
un paese ove non puo` esercitare l'obiezione senza essere fucilato che
*deve* attenersi ad un certo comportamento ha un senso.
ripeto che questi casi sono (sempre imo) molto pochi e che la maggior
parte che si sente usare il termine dovere in realta` c'e` stata a monte
una scelta perche' i casi in cui veniamo privati della scelta sono oggi
pochissimi (essenzialmente quando entrano in gioco le leggi dello stato
in cui viviamo, comegiustamente hai fatto notare).
probabilmente se io avessi posto in questi termini la questione da
subito questa mini-flame non sarebbe partita. vabbe`..
senza stare a contare i punti... facciamo pari e patta?
questione gpl
-------------
> Con GPL, non puoi imporre ai soggetti cui distribuisci il programma
> ulteriori condizioni restrittive. L'articolo 7 della licenza e` chiarissimo
> in merito: se non puoi distribuire in modo da soddisfare simultaneamente
> i tuoi obblighi secondo questa licenza, e altri obblighi su di te imposti
> (per sentenze di tribunale o per qualsiasi altra ragione non limitata a
> questioni di brevetto), allora non puoi distribuire per nulla.
hai espresso perfettamente il senso dell'articolo 7, ma non si applica
al mio esempio. chi distribuisce il codice deve poter soddisfare
contemporaneamente la licenza (quindi distribuire i sorgenti) ed
eventuali altri obblighi (altrimenti non puo` usare la GPL).
ma *non e` responsabile* degli obblighi aggiuntivi di chi *riceve* il
codice. se la setta dei buzzuriani ha una regola che impedisce loro di
copiare un programma se questo contiene il termine "linux" io posso
comunque dargli un cd di linux con sorgenti e la gpl e` rispettata. che
poi loro non possano copiare quel cd e` ridistribuirlo sono cavoli loro
ma le loro (stupide) regole non posso influire su come io distribuisco
in modo perfettamente lecito sotto gpl.
idem se un soldato e` sottoposto ad una regola che dice che "tutto il
codice letto all'interno della caserma xxx non puo` essere divulgato
pena la morte".
comunque se vogliamo massacrarci sulla GPL c'e` sempre la questione dei
moduli python scritti in C e rilasciati sotto GPL utilizzati da codice
python proprietario magari linkato a moduli proprietari... :)
fine della dissertazione sulla gpl.
dissertazione sull'obiezione di coscienza
-----------------------------------------
>Prestare servizio militare e` una libera scelta in alcuni paesi (ad
> esempio,
> negli USA, al momento, lo e`) ma non in altri; non tutte le legislazioni
> nazionali riconoscono neppure il diritto all'obiezione di coscienza, ovvero,
> ove lo riconoscono, possono spesso imporre specifiche condizioni
> relative a quali "obiezioni" possano giustificare il rifiuto di prestare il
> servizio militare.
>
> Ad esempio, in Italia, puoi dichiararti obiettore di coscienza solo se
> ti opponi allÿuso delle armi in ogni circostanza per motivi religiosi,
> filosofici o per convinzioni morali (o almeno, cosi` recitava la legge
>
> al tempo in cui dovevo interessarmene: i motivi politici erano invece
> esplicitamente esclusi). Se non ti opponi all'uso delle armi in OGNI
> circostanza, ma solo in ALCUNE, non puoi essere obiettore; neppure
> puoi se le tue obiezioni non sono all'uso delle armi bensi` ad altre
> caratteristiche del servizio militare di leva (ad esempio, all'indossare
> la divisa, a salutare la bandiera italiana, ovvero allo scrivere programmi
> i cui sorgenti non sono poi liberamente distribuibili).
mm.. non e` vero. la mia richiesta recitava "...dato il mio iter
accademico e la mia preparazione specifica [...] credo di poter essere
maggiormente utile in ambiente civile che non militare..." ed e` stata
accettata. (mi han pure mandato ove avevo richiesto e senza calci in
culo).
nella domanda non ho mai nominato armi, filosofie o bandiere.
- EO
> taglio tutto, per vari motivi, che spiego prima di dare qualche
> risposta. una discussione che e` partita piuttosto generica (devo vs
> voglio) e` passata al fare le pulci alla gpl e quindi all'obiezione
> civile.
OK, lancio anche io i miei due cent.
Ricordatevi che esiste la multilicenza. La GPL e' quanto di meglio
ci puo' essere (secondo me e molti altri evidentemente), ma in questo
modo imperfetto :-> puo' ancora esserci l'esigenza di dare il
proprio software a chi vuole sfornare un prodotto chiuso.
Ricevendo un adeguato compenso per il gesto, si possono dare versioni
con licenze differenti (qualunque) a chiunque in modo che tutti
siano contenti. MySQL AB e varie altre aziende lo hanno dimostrato.
Per cui (purtroppo) gli stati uniti potrebbero vendere tank oltre
forntiera e non doversi sentir chiedere i sorgenti.
- AM
> La filosofia Open Source ha sicuramente contribuito, e sta contribuendo,
> alla diffusione del software libero e quindi al perfezionamento dei
> sistemi operativi e degli strumenti di sviluppo software ma chi mi
> garantisce che potrò contare su tutto ciò anche in futuro?
Non vi e` nessuna garanzia in merito! Questo vale anche per qualsiasi
software *proprietario*, anzi, la situazione in questo caso potrebbe anche
essere peggiore - se il proprietario del SW che usi fallisce o semplicemente
decide di non supportare ulteriormente quel dato prodotto non hai, anche
in questo caso, nessuna garanzia che lo sviluppo del prodotto continui.
> Da ciò che ho appreso mi pare che una licenza meno restrittiva della
> GPL, come la PSF, consentirebbe di proseguire lo sviluppo di un software
> libero in forma proprietaria. Potrei quindi ritrovarmi con un sistema
> operativo libero ma obsoleto?
Certamente, ma mi sembra che tu pensi che vi siano sostanziali
differenze fra cio` che potrebbe succedere a un programma coperto
da GPL rispetto a uno coperto dalla licenza BSD o simili. In un caso
come nell'altro non hai nessuna garanzia che lo sviluppo continui --
continuera` se e solo se abbastanza gente capace e` interessata a
farlo, se no, no. In entrambi i casi e` comunque possibile che qualcuno
inizi una track divergente di sviluppo proprietario: nel caso del sw
coperto da GPL questo qualcuno potrebbe essere solo colui che ne
detiene il copyright, nel caso del sw coperto da BSD o simili non vi
sono tali restrizioni.
Prendiamo ad esempio due motori di DB relazionali open source.
SAP-DB e` coperto da GPL: quindi, tu non puoi derivare da esso
programmi da distribuire con licenze diverse da GPL. Interbase di
Borland per un certo periodo fu coperto da "Interbase Public
License" (una versione Borland della "Mozilla Public License", una
licenza open-source non-GPL).
In entrambi i casi il produttore originale puo` se e quando vuole
decidere di riportare i suoi futuri sviluppi del software a sue licenze
proprietarie. SAP sinora non l'ha fatto. Borland invece si`. Ma
anche in quest'ultimo caso, e` semplicemente emerso un gruppo
di appassionati che ha preso gli ultimi sorgenti aperti di Interbase
e ora li sviluppa come "Firebird": il fatto che un'azienda (Borland)
da quella base di SW sviluppi in modo proprietario ovviamente non
impedisce a nessun ALTRO gruppo di continuare invece lo sviluppo
secondo una licenza open-source!
> E, per mantenerlo aggiornato, sarei
> costretto a dover acquistare le nuove release, tornando a subire tutte
> le imposizioni da cui mi sono appena liberato?
Se vuoi gli aggiornamenti di Interbase *da Borland* li compri. Se
vuoi quelli di Firebird, invece, li scarichi gratuitamente. Esattamente
la stessa situazione si avrebbe se, che so, Trolltech decidesse di non
fare piu` rilasci GPL (ne` altri open-source) delle sue librerie Qt: il
fatto di avere posto sotto GPL una data versione e release di Qt non
vincola Trolltech, proprietaria del copyright, a porvi nessun altro prodotto
(ad es. la versione Windows di Qt *non* e` sotto GPL -- lo e` solo
quella per X11, anche ora).
In ogni caso, indipendentemente che la data versione libera sia sotto
GPL, ovvero Mozilla PL o simili, nulla impedisce al proprietario del
copyright di fare nuove o parallele versioni non-GPL *e* nessuno
impedisce a te o ad altri appassionati di partire dall'ultima versione
open-source per qualsivoglia ulteriore sviluppo open-source.
- FDG
> In ogni caso, indipendentemente che la data versione libera sia sotto
> GPL, ovvero Mozilla PL o simili, nulla impedisce al proprietario del
> copyright di fare nuove o parallele versioni non-GPL *e* nessuno
> impedisce a te o ad altri appassionati di partire dall'ultima versione
> open-source per qualsivoglia ulteriore sviluppo
tutto vero, ma c'e` una differenza fondamentale fra licenze copyleft
(come la GPL, quelle che non permettono a terzi di derivare prodotti
proprietari) e le licenze del gruppo BSD, che invece permettono di
"proprietarizzare" il codice.
a parte le ovvie cosiderazioni etiche (non trovo giusto che qualcuno
possa rendere proprietario del codice non suo) c'e` un pericolo: ovvero
che una grossa azienda con ingenti fondi posso prendere del codice BSD
(o licenza equivalente) cambiarne l'1% in modo da renderlo lievemente
incompatibile col software originario e poi spingerlo sul mercato molto
piu` dell'originale, fino a (ri)creare un monopolio. questo e` molto
facile se hai un sacco di soldi e costi di sviluppo bassissimi grazie al
fatto che hai trovato il 99% del lavoro gia` fatto.
- AM
> a parte le ovvie cosiderazioni etiche (non trovo giusto che qualcuno
> possa rendere proprietario del codice non suo) c'e` un pericolo: ovvero
Questa spiegamela meglio. Se io deliberatamente scelgo di scrivere
un nuovo programma e distribuirlo con licenza BSD invece che GPL,
naturalmente *allo specifico scopo di permettere ad altri di renderlo
proprietario se vogliono* (se invece che permetterlo volessi vietarlo,
userei un'altra licenza, non necessariamente GPL ma anche ad es.
Mozilla), sarebbe a tuo vedere _NON GIUSTO_ che qualcuno possa
usare il mio programma *secondo le mie specifiche intenzioni*?! O
intendi che non e` giusto che io distribuisca il frutto del MIO ingegno
come [espletivo rimosso per decenza] preferisco?!
L'una e l'altra interpretazione -- che sia ingiusto che io possa decidere
a mio piacere delle condizioni di ridistribuibilita` di codice totalmente
frutto del mio ingegno, e/o che sia ingiusto che qualcuno usi il mio
codice in modo totalmente coerente con le mie intenzioni -- sono
talmente assurde e ridicole che non riesco assolutamente a capire
cosa [espletivo rimosso] tu possa intendere, quindi, pls, chiarisci!
> che una grossa azienda con ingenti fondi posso prendere del codice BSD
> (o licenza equivalente) cambiarne l'1% in modo da renderlo lievemente
> incompatibile col software originario e poi spingerlo sul mercato molto
> piu` dell'originale, fino a (ri)creare un monopolio. questo e` molto
> facile se hai un sacco di soldi e costi di sviluppo bassissimi grazie al
> fatto che hai trovato il 99% del lavoro gia` fatto.
Gia`, talmente facile che non l'ha mai fatto nessuna "grossa azienda con
ingenti fondi", nonostante l'enorme disponibiltia` di software coperto da
licenze "BSD-like" e l'indiscutibile avidita` di tante grosse aziende. O non
sara` che ti sfuggono alcuni dettagli (totalmente ovvi) come il fatto che
la gente NON e` cosi` imbecille come pensano generalmente tutti quelli
che vogliono imporre (appunto alla gente) l'uno o l'altro comportamento
"per il loro bene"? Tipo il fatto che la "lieve incompatibilita`", se
accettata pubblicamente, sarebbe banalmente facile da riprodurre (se e`
solo l'1%, che ci vuole?!) cosi` da potere poi proporre al pubblico una
versione totalmente gratuita ed equivalente del "prodotto" della grossa
azienda -- magari con altri 100 vantaggi perche` la produttivita` dello
sviluppo open source e` imbattibile, e "pubblicita` gratis" dal marketing
budget della "grossa azienda"...? Che sogno sarebbe per l'open-source...!
Facciamo un esempio specifico. Microsoft oggi controlla il grosso del
mercato per i linguaggi di alto livello ed agevole uso grazie al suo monopolio
di Visual Basic, nelle varie versioni piu` o meno professionali o enterprise
ovvero incorporate in popolari applicazioni come Office. Non poche aziende
che amerebbero molto smettere di pagare le onerose licenze MS, passando
a sistemi operativi tipo Linux e applicazioni tipo OpenOffice, non possono,
perche` sono dipendenti da programmi, estensioni, sistemi di macro, ecc ecc,
in Visual Basic, e i vari tentativi di clonare quest'ultimo da zero non
producono facilita` e tranquillita` di porting per tutti questi programmi
ecc.
Partiamo da questa situazione, dunque, e spiegaci un poco quali enormi
vantaggi MS trarrebbe dallo smantellare il proprio lucroso monopolio di
VB approfittando invece dei tanti vantaggi tecnici di Python nonche` della
sua licenza non-GPL. Tieni presente che MS sarebbe sempre tenuta a
riconoscere la paternita` Pythonica del suo nuovo ipotetico linguaggio,
visto che le licenze di tipo BSD, compresa quella di Python, impongono
comunque questo riconoscimento. La quantita` di pubblicita` gratis che
pioverebbe cosi` su Python, la quasi certezza che tutte le "migliorie" (ha!)
MS sarebbero immediatamente riprodotte anche sulle versioni di Python
gratuite e/o per Linux/BSD/MacOsX/OpenOffice/ecc, ecc... che sogno...!!!
Un minimo di motivazione potrebbero averla aziende _concorrenti_ di MS,
tipo Sun, IBM, Oracle, SAP, Siebel, e cosi` via; in questo caso un attacco
diretto contro VB potrebbe avere dei vantaggi strategici, come per Sun
l'attacco contro MS Office costituito da StarOffice. Naturalmente se una
azienda del genere non e` formata da totali imbecilli, riconoscera` subito
il vantaggio dell'open-source in un attacco contro posizioni fortissime ed
arroccate e *aprira`* i sorgenti, ben lungi dal chiuderli, del tutto a parte
qualsiasi _obbligo_ alla apertura imposto da licenze esistenti -- cosi` ha
fatto Sun accostando OpenOffice a StarOffice, cosi` AOL Time Warner
accostando Mozilla a Netscape, cosi` SAP aprendo i sorgenti di Adabas
quando l'acquisto` e ne cambio` il nome a SAP/DB, ecc, ecc. L'_obbligo_
di mantenere aperti i sorgenti puo` solo _inibire_ l'adozione di una certa
base di codice da parte di un'azienda che stia considerando un simile
attacco strategico, restringendone i margini operativi (ad esempio, AOL/TW
mantiene Netscape vero e proprio "chiuso", anche se al 99% coincidente
con Mozilla che e` invece "aperto" con apposita licenza, cosi` da potere
incorporare in Netscape anche componenti di terze parti che NON sono
disposte a trasformare la propria licenza in GPL o simili -- analoga` e` la
situazione di StarOffice vs OpenOffice)...
- FDG
> Mozilla), sarebbe a tuo vedere _NON GIUSTO_ che qualcuno possa
> usare il mio programma *secondo le mie specifiche intenzioni*?!
no. parlavo per me, ovviamente. nel caso che dici tu non ho proprio
niente da criticare. la liberta` innnanzi tutto, anche quella di darsi
un martello sulle oo se si vuole. :)
> azienda -- magari con altri 100 vantaggi perche` la produttivita` dello
> sviluppo open source e` imbattibile, e "pubblicita` gratis" dal marketing
il discorso "non e` mai stato fatto" non e` accettabile. potrebbe essere
fatto ed e` notorio che la microsoft modifica sempre lievemente i
protocolli standard (per aggiungere features dice lei) in modo da
"fidelizzare" il cliente.
inoltre quell'incompatibilita` potrebbe essere molto difficile da
replicare, soprattutto negli stati uniti dove il reverse enginering e`
ormai in molti casi vietato dal DMCA.
nota bene: io non c'e` l'ho con microsoft priori ma credo che un
quasi-monopolio sostenuto in maniera scorretta sia un male (in senso
economico, non nel senso del Male) di per se.
> Partiamo da questa situazione, dunque, e spiegaci un poco quali enormi
> vantaggi MS trarrebbe dallo smantellare il proprio lucroso monopolio di
> VB approfittando invece dei tanti vantaggi tecnici di Python nonche` della
> sua licenza non-GPL. Tieni presente che MS sarebbe sempre tenuta a
nessuno. hai ovviamente scelto un esempio per il quale hai ragione. ma
vai un po' a vedere come la microsoft ha lievemente modificato
l'autenticazione kerberos in LDAP per creare il suo ActiveDirectory
rendendo di fatto lungo e macchinoso integrare unix e windows. non
impossibile, solo noioso quel tanto che quando invece colleghi un client
windows e tutto semplicemente funziona ti trovi a pensare che il
prodotti microsoft siano migliori.
taglio il resto del discorso perche', sebbene interessante, non c'entra
con questa discussione.
- AM
> il discorso "non e` mai stato fatto" non e` accettabile. potrebbe essere
Non sara` accettabile, ma e` vero sino ad ora.
> fatto ed e` notorio che la microsoft modifica sempre lievemente i
> protocolli standard (per aggiungere features dice lei) in modo da
> "fidelizzare" il cliente.
Certamente, proprio come tutti i motori di DB relazionali (compresi
quelli open-source e GPL in particolare) introducono sempre piccole
incompatibilita` con gli standard SQL (per aggiungere features,
dicono gli autori), con il risultato che lo sviluppatore che "ci casca"
e usa le features extra (senza rivestirle accuratamente in uno strato
per futura portabilita`) resta praticamente prigioniero (ti hanno mai
chiesto di portare da PostgreSQL a, che so, MySQL, o SAP/DB con
tutta la sua potenza e il suo GPL, codice scritto usando anche solo
una _frazione_ delle dannate estensioni PostgreSQL...?).
Il fatto che SQL sia coperto da standard ANSI (e ISO) e i vari
motori che lo implementano siano coperti, chi da GPL, chi da altre
licenze proprietarie o open-source, non impedisce certo ad ogni
implementazione di motori di DB relazionali (MS SQL Server
pienamente incluso, non differente in questo da tanti altri) di
aggiungere le sue millanta incompatibilita`/estensioncelle "per
fidelizzare il cliente". E` dunque assurdo usare questa diffusa (e
dannata) prassi di estendere/modificare gli standard, allo scopo di
difendere o attaccare una qualsiasi tipologia di licenza: contro
detta prassi, neanche gli Dei possono nulla (come Schiller diceva
della stupidita`, mi pare) -- non c'e` licenza, ne` scopo commerciale
o non-commerciale, che tenga.
> inoltre quell'incompatibilita` potrebbe essere molto difficile da
> replicare, soprattutto negli stati uniti dove il reverse enginering e`
> ormai in molti casi vietato dal DMCA.
*BUM*. Hai parlato specificamente di una modifica dell'1% del
codice. Trattandosi di un linguaggio di programmazione, bisognera`
naturalmente che le sue feature siano documentate, se no non le
usera` in pratica nessun programmatore e quindi l'introduzione di
incompatibilita` non avra` nessun peso ne` interesse. E dunque
dalla documentazione stessa sara` banale reimplementare queste
minuscole modifiche alla base del codice, che per tua stessa ipotesi
toccano un paio di migliaia di righe di codice C o giu` di li`. Nessun
reverse engineering necessario.
La situazione puo` essere diversa nel caso di un protocollo di
comunicazione per cui l'ipotetico fornitore malvagio fornisca
implementazioni di _entrambi_ gli estremi, diciamo sia del cliente
sia del servente (e magari di proxy o che altro possa starvi in
mezzo); in questo caso, possono introdursi incompatibilita`
*non documentate* rispetto al protocollo standard che rendono
difficile implementare clienti alternativi da usare con lo stesso
servente, o viceversa, o proxy furbi, e cosi` via, senza reverse
engineering. In questo caso, si puo` fare il reverse engineering
in un laboratorio a Bangalore (uno dei centri piu` attivi ed in
rapida crescita nel mondo dello sviluppo software) o simili...
> nota bene: io non c'e` l'ho con microsoft priori ma credo che un
> quasi-monopolio sostenuto in maniera scorretta sia un male (in senso
> economico, non nel senso del Male) di per se.
Io ce l'ho si` con Microsoft, sia a priori sia a posteriori, nonche` anche
con i monopoli anche piu` morbidi e corretti (se ne esistono): si tratta
comunque di iatture economiche, e generalmente, anche su altri piani
non strettamente economici, gli effetti dei monopoli sono deleteri, sia
che i monopoli siano in gestione privata oppure pubblica.
Sarebbe, a mio parere, una tragedia, se, chiamato per una consulenza
da un'azienda che sviluppa software e vuole scegliere le tecnologie (in
particolare i linguaggi) da usare, io potessi proporre solo Microsoft _o_
alternative che obbligassero l'azienda che mi ha chiamato a distribuire
anche tutti i sorgenti dei propri prodotti; so bene che, in questi casi, tali
aziende sceglierebbero di _rischiare_ i futuri ricatti MS piuttosto che non
scegliere la _certezza_ di non potere decidere autonomamente quali
politiche di apertura totale o parziale dei loro sorgenti serviranno meglio
i propri interessi. Fortunatamente posso proporre invece alternative
che liberano subito l'azienda dai rischi dei ricatti MS (e dalla certezza
dei _costi_ connessi ai prodotti MS) *senza* pregiudicare minimamente
la liberta` strategica di scelta dell'azienda stessa -- entrare intanto con
software open-source, e *separatamente* operare per convincere poi
l'azienda che e` nel *suo interesse* aprire i sorgenti della *maggior parte*
dei suoi prodotti. Se l'unica alternativa fosse, o MS o GPL, penso che
mi dovrei ripassare subito le varie robe di .NET e simili...:-(.
> > budget della "grossa azienda"...? Che sogno sarebbe per
> > l'open-source...!
> >
> > Facciamo un esempio specifico. Microsoft oggi controlla il grosso del
> > mercato per i linguaggi di alto livello ed agevole uso grazie al suo
> > monopolio di Visual Basic, nelle varie versioni piu` o meno professionali
> > o enterprise ovvero incorporate in popolari applicazioni come Office.
> > Non poche aziende che amerebbero molto smettere di pagare le onerose
> > licenze MS, passando a sistemi operativi tipo Linux e applicazioni tipo
> > OpenOffice, non possono, perche` sono dipendenti da programmi,
> > estensioni, sistemi di macro, ecc ecc, in Visual Basic, e i vari
> > tentativi di clonare quest'ultimo da zero non producono facilita` e
> > tranquillita` di porting per tutti questi programmi ecc.
> >
> > Partiamo da questa situazione, dunque, e spiegaci un poco quali enormi
> > vantaggi MS trarrebbe dallo smantellare il proprio lucroso monopolio di
> > VB approfittando invece dei tanti vantaggi tecnici di Python nonche`
> > della sua licenza non-GPL. Tieni presente che MS sarebbe sempre tenuta a
>
> nessuno. hai ovviamente scelto un esempio per il quale hai ragione. ma
Ah ma guarda. Ho scelto un esempio direttamente connesso al tema
di questa mailing list, denominata "python@xxxxxxxxxxxxxxx". La domanda
che ha dato inizio a questa discussione e` perche` Python sia coperto da
una licenza open-source particolarmente liberale, _non_ da GPL o simili...
> vai un po' a vedere come la microsoft ha lievemente modificato
> l'autenticazione kerberos in LDAP per creare il suo ActiveDirectory
> rendendo di fatto lungo e macchinoso integrare unix e windows. non
> impossibile, solo noioso quel tanto che quando invece colleghi un client
> windows e tutto semplicemente funziona ti trovi a pensare che il
> prodotti microsoft siano migliori.
Non ho lavorato con ActiveDirectory quindi non conosco di persona
la situazione, ma non mi stupisce. Ma il punto relativo al valore delle
licenze e` un altro. I sorgenti di kerberos possono essere distribuiti
solo in USA e Canada (o almeno cosi` era la situazione non troppo
tempo fa) quindi e` ovvio che sarebbe stato illegale per gli autori usare
una licenza incompatibile con questa restrizione, come lo e` GPL, no?
E in ogni caso: o Kerberos e` coperto da brevetto (non mi pare che
lo sia), nel qual caso la licenza dei suoi sorgenti e` irrilevante; oppure
non lo e` -- e` un PROTOCOLLO pubblicato e reimplementabile da
chiunque lo voglia, semplicemente riscrivendone da capo i sorgenti
sulla base della pubblicazione (magari il risultato avra` bug e falle di
sicurezza, ma che i prodotti MS siano PIENI di bug e falle non sarebbe
certo una novita`, ne` purtroppo sembra che sinora cio` ne abbia
sostanzialmente impedito la diffusione).
- NW e conclusione
Oh, non sarà la prima volta che parlo a sproposito e scateno un magico
'tutti contro Nicholas' risolutore (:D), ma Alex non ti sembra di essere
un po' troppo incazzoso ? Mi sembra che Federico stia discutendo
normalmente...
La discussione è interessante ma magari evita di usare un tono puramente
da flame war...
E' da qualche post che noto quest'atteggiamento, e probabilmente è solo
una mia impressione, ma mantenete toni pacati, tanto ognuno ha le sue
idee e si comporta come meglio crede, UNO Stalman e UN Raymonds sono più
che sufficienti :)))
e da allora nessuno postò...
--
------------------------------------------------------------------
Free Electronic Music -> http://stage.vitaminic.it/daniele_torelli
------------------------------------------------------------------
Other related posts:
- » [relug] thread su licenze