Trolltech adotterà la licenza GPL 3.0 per le librerie Qt

[Mercuri0]

Sbagliato, partendo dal presupposto che tu non scriva sempre partendo da 0 ma utilizzando librerie e sorgenti gia scritti da altri, la licenza che sei _obbligato_ ad utilizzare e' la piu' restrittiva tra quelle del vario codice che prendi in prestito. ( se non una addirittura peggiore xD )

Ripeto, se usi roba scritta da altri in un modo o nell'altro la paghi. Microsoft da le licenze quando compri l'ide. Perché qualcuno dovrebbe scrivere software gratis?
E' questo il punto che non capisco del vostro discorso.

In quell'articolo semplicemente spingono ad usare la GPL invece della LGPL, perche' la LGPL porterebbe vantaggio anche al di fuori della comunita' opensource. Di questo fatto uno sviluppatore ( n.b. io sono uno sviluppatore ) se ne puoi anche fregare, finche' la sua proprieta' intellettuale e' protetta.

Alura, stavamo commentando a proposito delle QT. L'articolo linkato non l'ho letto, e francamente non è che mi importi molto. Al solito l'ultima parola sulla licenza c'è l'ha il proprietario del copyright del codice, e su le maing-list dei programmatori che frequento si parla molto più dei problemi tecnici che non di licenze. Non è che Stallman sia il dio dell'OpenSource, eh.

Tornando in topic, per quanto riguarda il progetto KDE (che bazzico) tutte le librerie sono LGPL e i programmi GPL. La scelta GPL2/GPL3 si era posta solo per eventuali problemi di compatibilità con altri programmi (forse qualcosa di samba) e il fatto che le QT siano anche GPL3, permette anche a KDE di essere GPL 2 o 3 (a scelta del distributore), con qualche componente solo GPL3 nelle zone "grigie"... più libertà di così!

Ecco, su questo punto mi chiedo una cosa: se io linko le kdelibs ad un programma closed, cosa succede alle QT ? Di fatto le kdelibs si basano sulle QT che sono GPL.

Ecco i dettagli
http://developer.kde.org/documentation/books/kde-2.0-development/ch19.html
Per sviluppare con le kdelibs devi linkare anche le QT, con quel che ne consegue.
Però vedi che non sono gli sviluppatori OpenSource qui il problema :P

Io non contestavo tanto il fatto "la LGPL per gli sviluppatori esterni sarebbe meglio" (grazie al cavolo!) ma il fatto di pensare di poter imporre una licenza a chi il software l'ha scritto.
E di sicuro la TrollTech non puà dar via il suo core-business...

[Sajiuuk Kaar]

ot: ci mancavano solo i supertroll :'''D

[82screamy]

... Ad annunciarlo è stato Haavard Nord, CEO della compagnia norvegese ...

La trolltech è norvegese...a giudicare dal cognome lo è anche il suo A.D....certo che un norvegese che fa di cognome Nord...beh...

[cionci]

Originariamente inviato da Mercuri0

ma il fatto di pensare di poter imporre una licenza a chi il software l'ha scritto.

Che è quello che vogliono fare Stallman & Co. sconsigliando la LGPL per le librerie più importanti.
Tornando alla questione kdelibs. Se le QT sono GPL e le kdelibs sono LGPL e visto che per fare un programma per KDE bisogna linkare anche le QT, allora non potrà mai esistere un programma chiuso per KDE a meno di comprare una licenza QT ?
Ed è anche uno dei motivi per cui non uso KDE sperando che si diffonda di più gnome.

[weseven]

esattamente. ciònonostante esistono un bel po' di programmi chiusi che usano le qt, l'abominio di skype ad esempio su tutti.
quindi sarebbe meglio che si diffondesse più gnome, incoraggiando il software chiuso? :/
imho, la qualità del codice di applicazioni kde è indiscutibile. koffice, karbon, krita, kile,k3b, amarok, konqueror, kmess, kopete.. (ma quanto odiosa è la pratica di usare queste maledette k XD).
tutti ottimi programmi _aperti_ .
che ci siano altrettanto ottimi programmi chiusi ben venga, nessuno vieta di usarli su kde (ebbasta con sta storia qt vs gtk, con un tema tipo qtcurve le apps gtk son belle anche su kde). ma il favorirli è un po' un controsenso.

[xeal]

Ma è un controsenso anche volerli svantaggiare e osteggiare a tutti i costi, cosa che risulta decisamente esplicita nella pagina linkata sui motivi per preferire la gpl alla lgpl. In tutta la pagina emerge una visione del mondo open source come una casta (e come tale inevitabilmente chiusa: o sei con noi, o sei contro di noi) in guerra con il mondo closed source e commerciale, che bisogna surclassare ad ogni costo. Questo perchè alla base c'è una visione idealistica e utopica di un "mondo informatico" perfetto che IMHO poco o nulla ha a che vedere con la realtà dell'informatica. In informatica non possono esistere fedi, ma solo soluzioni perfettibili a problemi reali. I problemi sono reali perchè l'informatica è uno strumento utile nel "mondo reale", che è imperfetto e, quindi, pieno di problemi da risolvere. E le soluzioni saranno a loro volta imperfette, perchè l'imperfezione del mondo è tale che nulla può essere veramente perfetto, ciò non toglie che si debba tendere al meglio, ma per fare ciò è necessario consentire non solo l'esistenza, ma anche l'integrazione, la convivenza e l'interoperabilità (e intercambiabilità) tra soluzioni alternative. Ciò implica che sia fondamentalmente sbagliato osteggiare l'uno o l'altro modo di intendere l'informatica per partito preso.

Ma a parte questo, non vedo come la gpl possa realmente risolvere il problema alla radice. Questo perchè l'open source, inteso letteralmente come disponibilità dei sorgenti di un'applicazione, esisteva già agli albori dell'informatica (o poco dopo), per via delle notevoli differenze hardware tra le macchine che avrebbero dovuto eseguire quelle applicazioni, ed era comunque un "mondo" molto chiuso. Immaginiamo di imporre in qualche modo a tutti gli sviluppatori di rilasciare i sorgenti: alcuni (molti, pochi, non fa differenza) di questi sorgenti sarebbero praticamente illegibili, privi di commenti, con indentazione alla cactus di cane, con nomi privi di senso per variabili e funzioni (del tipo aa134_o85BBtY) e porzioni di codice inutili, messe li solo per confondere (tipo identità matematiche su alcune variabili prima dell'elaborazione vera, porzioni di codice mai chiamato, oppure funzioni su variabili fittizie e inutili chiamate in punti opportuni, senza pregiudicare le prestazioni). Molte di queste "sofisticazioni" potrebbero essere introdotte con delle routine automatizzate, che quindi non allungherebbero i tempi di sviluppo, nè pregiudicherebbero più di tanto la correttezza dei programmi, quindi si potrebbe procedere sviluppando i sorgenti "veri", creandone una copia modificata, compilando ed eseguendo i test di verifica sulla base della copia modificata, e rilasciando l'eseguibile compilato sulla base della versione definitiva dei sorgenti "modificati", che diventerebbero in questo modo i sorgenti "veri" da distribuire.

Non mi pare che la gpl (ma potrei sbagliare: non la conosco a memoria) imponga dei vincoli particolari sull'uso di nomi di fantasia per le variabili o sull'estro nell'implementazione degli algoritmi, o sulla presenza e qualità dei commenti, quindi ci ritroveremmo con un software open source solo in apparenza (e formalmente), ma in realtà non più leggibile, per un programmatore di non altissima esperienza, di quanto lo sia il dump in assembly di un software closed e offuscato. Meglio quindi consentire e facilitare l'esistenza e l'integrazione delle alternative, lasciando che gli sviluppatori decidano quale delle due filosofie abbracciare, magari passando dall'una all'altra in momenti e contesti e con scopi diversi, anche, entro certi limiti, all'interno dello stesso progetto, senza voler imbastire una competizione da vincere a tutti i costi per realizzare a tutti i costi un ideale dell'open source. E non ditemi che nessuno vuole fare questo, perchè FSF parla proprio di competizione da vincere: "By releasing libraries that are limited to free software only, we can help each other's free software packages outdo the proprietary alternatives. The whole free software movement will have more popularity, because free software as a whole will stack up better against the competition". Che succederebbe se l'open vincesse la competizione, nel senso che l'unica opzione possibile/conveniente per gli sviluppatori fosse l'open? Succederebbe che qualcuno abbraccerebbe l'open non perchè convinto dalla filosofia di base, ma per pura convenienza, per una scelta di comodo forzata, e cercherebbe degli espedienti per non rendere il proprio software facilmente intelligibile alla concorrenza (di cui continuerebbe a non fidarsi, o con la quale riterrebbe di non poter competere solo sui servizi e non anche sulla qualità e diversità del software). Le alternative devono poter coesistere, perchè nessuna sarà mai migliore in senso assoluto, e non ha senso pensare di cancellarne completamente una (o alcune), neanche alla fine di un lungo percorso, perchè a) si avrebbe un impoverimento delle possibili soluzioni a problemi reali, e b) l'alternativa non scomparirebbe del tutto, ma si ripresenterebbe sotto altre forme.

Non voglio certo dire che l'open non possa rivelarsi, col tempo, una scelta nettamente superiore, e che di conseguenza tutto il software possa sposarne la filosofia, ma non credo che sia corretto farne una questione di principio; credo invece che si debba ritenere altrettanto possibile l'ipotesi diametralmente opposta e accettare che il metodo migliore emerga da un confronto all'interno di una coesistenza armonizzata, senza cercare stratagemmi che facciano pendere forzatamente, in qualche modo, l'ago della bilancia da una parte o dall'altra, e accettando invece che il "vincitore" non possa essere la "soluzione definitiva", ma che, laddove surclassasse nettamente l'altro, potrebbe esserne a sua volta superato in un momento successivo, perchè nuovi problemi impongono soluzioni diverse.

Comunque, se non sbaglio, un software closed può "chiamare" un programma sotto gpl, ovvero un software closed può interagire con uno open attraverso il meccanismo delle pipeline, perchè questo non rappresenta un uso "diretto" (chiedo venia per la terminologia) del suo codice. Di conseguenza, l'adozione della gpl per le librerie non può implicare _sempre_e_comunque_ la creazione di _soli_ software open e coperti _interamente_ da gpl: si può realizzare una parte open che si appoggi alle librerie per renderne disponibili le funzionalità attraverso una pipeline a processi closed (capaci di comunicare tra di loro). Ma una pipeline si basa su un flusso di dati, quindi dovrebbe essere possibile per un solo processo open comunicare, mediante più stream, con più processi closed, e se questo è corretto, allora la comunicazione può diventare più complessa, assumere altre forme (scambio di messaggi, pacchetti, ecc.), e la componente open di un progetto complessivamente closed potrebbe assumere le sembianze di un servizio in un'architettura client-server, in parte vanificando, di fatto, il tentativo di sfruttare la gpl per creare degli svantaggi al software closed (o, ma è lo stesso, dei vantaggi per l'open di cui il mondo closed non possa godere). Certo, in molti casi potrebbe non essere un'opzione valida, perchè comunque richiede del lavoro extra (ma non paragonabile alla riscrittura di una o più librerie) e potrebbe avere delle ripercursioni sul piano delle prestazioni (l'interazione mediante pipeline o una struttura client-server introduce un certo overhead rispetto all'uso di thread e librerie linkate staticamente o dinamicamente, e per tornare in topic non credo che ne valga la pena per delle librerie grafiche, anche considerando che le stesse si appoggeranno su un server grafico). Ma in altri il gioco potrebbe valere la candela, e francamente non credo che si possa accusare chi seguisse questa strada di voler sfruttare indebitamente il lavoro della comunità, perchè comunque la componente open, che si occuperebbe dell'interazione con le librerie lato server, potrebbe tornare utile alla comunità come astrazione delle stesse librerie pronta per l'uso in altri contesti in cui l'interazione client-server sia una scelta valida (ad esempio, in scenari di calcolo distribuito). Si potrebbe obiettare, forse, che comunque in questo modo si "costringono" degli sviluppatori closed a "restituire il favore" alla comunità open source (creando inoltre qualcosa che potrebbe essere sfruttato anche dai diretti concorrenti nel mondo closed source), ma io rispondo subito che si tratta di un risultato ben diverso dal voler creare una spaccatura, o quanto meno una contrapposizione netta tra i due "metodi" di fare software, con l'intento di rendere meno vantaggiosa la produzione di programmi chiusi (ma di fatto riuscendoci solo su un ipotetico sistema "full open", che perderebbe un grosso bacino d'utenza) e più facile per gli sviluppatori open creare progetti di qualità almeno pari o superiore a quella di analoghi prodotti closed, riutilizzando blocchi creati da altri sviluppatori open ai quali gli sviluppatori closed non _devono_ poter accedere nei loro progetti. Ed è proprio questa visione dell'informatica per ranghi contrapposti di fazioni in lotta che non condivido, e anzi contesto.

P.S. a me kde piace, e magari diffondendosi adeguatamente potrebbe spingere Trolltech a ridurre il costo delle licenze commerciali (oltretutto, se non ho frainteso una parte degli ultimi framework sarà disponibile solo nella versione a pagamento), a vantaggio di una sana diversificazione e armonizzazione delle applicazioni che le usano.