Java con licenza Open Source? Sun dice no

Non vorrei scatenare flame, anche perchè non ne so abbastanza al riguardo, ma il buon KDE ha tra le sue caratteristiche il fatto di non essere retrocompatibile, cioè una applicazione scritta per KDE 1.x non gira su KDE 2 o KDE 3 e nessuna applicazione scritta per KDE 2.x gira sul 3.
Non so se sia colpa della licenza LGPL, di sicuro non è una bella cosa.
Il tanto mazziato Windows se non altro permette che una applicazione scritta per il 95 giri senza troppi problemi su XP.
Questo è un caso di cosiddetta "autoincompatibilità", cioè un software è incompatibile con sè stesso. Ripeto, non sono competente, non vorrei sbagliare, ma mi sembra che i casi più gravi siano proprio nel software GPL.
Per "frammentazione" si può anche intendere questo caso particolare.

x bizzu

Non sto dicendo che la java virtual machine
e' marcia di per se, ma per il modo in cui
SUN la distribuisce, tenendola chiusa e distribuendo
solo lei i sorgenti (a parte blackdown)
fa si che risulti "marcia" per molte degli
applicativi non appena cambia qualcosa in qualche libreria o nel kernel.

Tanto per citare il vecchio plugin libjavaplugin_oji.so
compilato con il vecchio egcs 1.1.2 che non andava
su tutte gli applicativi compilati con gcc 3.2.X.

Per cui alla fine ciascuna applicazione ha bisogno
della sua specifica JVM e non sempre le
JVM vecchie funzionano su sistemi con librerie
nuove.

Se dipende da me (la flame) no problem...



Si ma...
1) il KDE non ha subito io fork di cui tanto si ha paura...
2) AFAIK l'incompatibilita` deriva principalmente dal cambio QT2->QT3, che sta alla base di KDE. (Inciso: e chi produce QT? Esatto, un'azienda commerciale... OK che e` sotto GPL, ma teniamo comunque a mente la TrollTech Inc.)




E come potrebbe essere colpa della LGPL?



...Le ricordo solo io i vari casi di incompatibilita` pre XP/Post XP? si eh?

[quote]
ma mi sembra che i casi piu gravi siano proprio nel software GPL.
[/quoOTE]

A me sembra di no. Vogliamo fare qualche altro nome?

veramente IBM gia' realizza una JVM (oltre che un JDK) sua , cosi' come la faceva Microsoft (che non aggiorna piu' dal giurassico) o come la fanno altri (vedi BEA).

Non per altro esiste un comitato che definisce le funzionalita' di Java, chiaramente Sun sara' il membro + importante, ma ci sono anche altri...

Allora non mi è chiaro come fa KDE ad essere sotto LGPL se le librerie su cui si basa non lo sono! Soprattutto non capisco perchè buttare al vento fior di software (tipo Kisocd, per esempio) per un cambio di librerie....ma non è il solo esempio....insomma, come si spiega la bestiale autoincompatibilità di Linux? e perchè FreeBSD non presenta questo difetto? è colpa delle licenze diverse o è un caso?
Per quello che riguarda il pre o post XP, io non ho mai avuto problemi a mettere software vecchio sotto XP, tranne nel caso di accesso diretto all'hardware, e mi è capitato solo una volta con un programma di pilotaggio di PLC (Siemens Step7)....qualcuno mi illumina?

AFAIK le QT sono GPL non LGPL. Ma non seguo molto bene il mondo della kappa per cui puo` darsi benissimo che sia poco aggiornato.



Major release, API change. Ci sta, voglio dire, non e` fuori dal mondo.



Una certa tendenza (irritante in certi casi) a reinventare la ruota e a rivoluzionare piu` che evolvere, e questa c'e`.
Ma da qui alla "bestiale incompatibilita`" mancano ancora qualche ampia serie di altri esempi, perche` io in vari anni di Linux 'sta incompatibilita` mostruosa mica l'ho vista, sara` stata solo fortuna che devo dirti.



Che io sappia il passaggio 4.x -> 5.x non e` proprio painless.
Inciso: la licenza non c'entra nulla IMHO, e` un problema di modalita` di sviluppo. In linux, come detto, c'e` questa tendenza a rivoluzionare, in BSD molto meno (d'altronde, la storia parla in modo molto eloquente).



Io si. Risolvibile, per carita`. E` bastato aspettare un poco, per carita`. Non ho ammattito quasi nulla, per carita`. Ma c'e` stato. E non si e` risolto in una reingegnerizzazione del SW (forse del SW che andava su KDE2 e non e` stato portato su KDE3 non era proprio ottimo ottimo), ma, a quanto mi risulta, a colpi di pezze dentro windows. Questo e` tollerabile in un'entita` commerciale. Alla Linux. Inc. non vogliono conquistare la borsa, vogliono solo fare un lavoro tecnicamente migliore possibile, quindi quando serve l'API change, si fa l'API change. Qualcuno patchera` i sorgenti o produrra` nuovo SW per le nuove API.

Sì, il passaggio da FreeBSD 4.x al 5.x non è indolore, però le applicazioni nate per la versione 5 generalmente possono funzionare senza troppi problemi anche sul 4, e questo perchè nel caso di BSD, la versione 5 non è una evoluzione della 4, ma sono due branche separate di sviluppo, una considerata "stable" non nel senso di "esente da crash", ma nel senso "sviluppo senza stravolgimenti" e l'altra nominata "current" per indicare "sviluppo continuativo". Dalla current periodicamente viene estratta una distribuzione vera e propria detta "release"
Per Linux io invece mi sono scornato diverse volte su cose del tipo "questo pacchetto richiede il pacchetto XYZ 0.1.2_rc4, versione attualmente installata 0.1.2_rc5" oppure "il pacchetto Pincopallo 0.3.4 beta2 è in conflitto con il pacchetto Pincopallo 0.3.4 beta2 bis" o ancora "il modulo è compilato con gcc versione 2.x mentre il kernel è compilato con gcc versione 3.x. Non funzionerà"
E vai di installazione di gcc 2.x....
Insomma, nel caso di Java, già così ci sono un tot di problemi, ma non vorrei trovarmi con un Java a GPL con decine di versioni sparse in giro, nominate PippoJava 0.0.2 beta4_rc3 o JavaToni 20050402 alpha87_1 e discussioni del tipo "il mio Java è migliore del tuo"...."non è vero, il tuo fa schifo" e diventare deficienti ogni volta che un applet salta fuori con la scritta "questo programma richiede JavaPincoPallo e non funziona con JavaCelentano che hai installato"



...scusa, mi sono lasciato trasportare...

Secondo me hai ragione...è per questo che sarebbe adatta una licenza OpenSource, ma non GPL Una licenza che non consenta fork del progetto esterni...

E` capitato anche a me, questo.
RPM fatti a bestia probabilmente, nel qual caso il legame con GPL, Linux od OSS e` quantomeno discutibile



Questo e` un'altro dei grossi nomi di cui parlavo e di cui volevo un'esempio, e questo in effetti e` fastidioso. GCC3 e` stato molto discusso per questo ed altri motivi.



Si, ma tornando al punto originale, sono emersi sinora vari problemi e problemini dell'OSS e di Linux, ma manco un caso di progetto grosso e famoso con una caterva di fork a giro che creano problemi di incompatibilita`
Se vuoi io ti cito un paio di questi casi:
- egcs vs gcc: durato qualche mese, poi egcs e` stato riassorbito da gcc
- samba fork: qualche mese indipendentemente poi i due progetti, AFAIK, si sono riuniti
- mplayer VS mplayexp: mplayerxp e` praticamente morto
- caso del kernel: ci sono N tree a giro, ma uno ed uno solo e` ufficiale, e c'e` comunque forte scambio di codice tra i tree.
(e comunque in questi casi c'e` comunque una compatibilita` piu` o meno vasta, e provata sol campo, tra i vari progetti)

Morale: a me pare che si faccia di tutta l'erba un gran fascio, specialmente quando si parla di problemi e controindicazioni dell'OSS.

per tutti quelli che parlano di rischi di avere 16 jvm sotto GPL incompatibili... ma non c'e' gia' il Java Community Process che standardizza e poi gli altri (Sun, Bea, Ibm etc..) implementano?