Link alla notizia: http://news.hwupgrade.it/12225.html

IBM ha chiesto un incontro a Sun per verificare la possibilità di rilasciare Java con licenza Open Source, ma Jonathan Schwartz alza gli scudi!

Click sul link per visualizzare la notizia.

Secondo me per la situazione precaria in cui si trova Sun rendere una tecnologia opensource l'aiuterebbe soltanto a scavare la fossa che gli si sta aprendo sotto.
Byezz ;)

in effetti non posso dare torto a Schwartz.
Se Java fosse Open Source vi sarebbero i pro ed i contro (come in tutte le cose):

pro: forse gli open developper potrebbero dare una mano nella manutenzione delle classi base che, è opinione di tutti i maggiori esperti di java, sono il maggior freno nelle prestazioni di un programma java. Infatti l'agognato 1:1,5 (rapporto tra applicazioni c++ e applicazioni java) con il Java HotSpot è stato solo avvicinato ma è ancora lontano da essere raggiunto.
contro: una frammentazione senza controllo di versioni diverse del java runtime environment.

Conoscendo i motivi che portano alla nascita di Java, i contro superano di molto i vantaggi.

IMHO

Sono d'accordo in pieno con Schwartz. E poi a cosa servirebbe Java opensource? Forse a permettere a IBM di fare una sua versione?
Se non ti piace una classe, la ridefinisci! (visto in modo molto semplicistico :D )

Potrebbe benissimo essere OpenSource, ma non GPL...la licenza GPL è troppo limitativo...ovviamente IMHO...

Onestamente le affermazioni sulla compatibilita'
sono ridicole; soprattutto perche' ci sono
cosi' tante macchine virtuali Java rilasciate
da SUN, IBM, etc., che nemmeno loro sanno piu' starci dietro, per non parlare di tutte le incompatibilita
che sorgono usando le macchine virtuali di
SUN compilate con compilatori vecchi su distro
preistoriche, su kernel 2.6...
Altro che write once run everywhere: write
once, run nowhere e' la situazione attuale...

Credo che alla fin fine ci sono piu' release
di macchine virtuali SUN che applicazioni Java...

Anche io sono d'accordo con Schwartz. Concordo nel pensare che la GPL sia un'ottima cosa per certi tipi di software, ma questo non è il caso di Java. Piuttosto, esistono licenze open che comunque limitano la frammentazione selvaggia, forse si potrebbe vedere su una cosa del genere...

concordo con cionci, la gpl pone troppi obblighi per un progetto come java

Originariamente inviato da Kralizek
contro: una frammentazione senza controllo di versioni diverse del java runtime environment.


Mi fai un nome di un progetto OSS di una certa rilevanza dove questo accade?

vogliamo parlare delle implementazioni Java per Athlon
64 disponibili grazie alla licenza di SUN?

Ci sono migliaia di progetti failure proof in GPL,
basti pensare al perl, al python, al PHP e
quindi spaventarsi di frammentazioni (laddove
di solito quando avvengono frammentazioni si
cambia anche il nome) mi sembra eccessivo, tanto
gia' la situazione attuale e' pessima (causa
macchine virtuali marce) e vede gia' Java inusabile
in applicazioni di una certa importanza...

Originariamente inviato da joe4th
vogliamo parlare delle implementazioni Java per Athlon
64 disponibili grazie alla licenza di SUN?

Ci sono migliaia di progetti failure proof in GPL,
basti pensare al perl, al python, al PHP e
quindi spaventarsi di frammentazioni (laddove
di solito quando avvengono frammentazioni si
cambia anche il nome) mi sembra eccessivo, tanto
gia' la situazione attuale e' pessima (causa
macchine virtuali marce) e vede gia' Java inusabile
in applicazioni di una certa importanza...

Dalle tue affermazioni si deduce che non hai proprio idea di come sia fatta una virtual machine... :rolleyes:
Java viene compilato in bytecode che NON è un linguaggio macchina, ha quindi bisogno di un interprete che porti le istruzioni JVM a quelle della macchina. Questo vuol dire che ci deve essere una JVM per ogni architettura.
Aggiungi poi le chiamate alle funzioni del sistema operativo per le GUI o altro, e avrai una JVM per (quasi) ogni SO.
Quindi mi sembra lampante che ci debbano essere molte JVM diverse per avere compatibilità.
La JVM non è assolutamente marcia come dici tu, ha invece tecniche molto avanzate che migliorano di release in release (è un po' impossibile fare un software universale in una sola versione che vada bene con tutto...).
Java è interpretato: è logico che non vada bene per tutti i tipi di applicazioni... se vuoi prestazioni usa il C++.

Originariamente inviato da Ikitt_Claw
Mi fai un nome di un progetto OSS di una certa rilevanza dove questo accade?

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.

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.

Originariamente inviato da krokus
Non vorrei scatenare flame, anche perche non ne so abbastanza al riguardo,

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

ma il buon KDE ha tra le sue caratteristiche il fatto di non essere retrocompatibile, cioe 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.

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.)



Non so se sia colpa della licenza LGPL, di sicuro non e una bella cosa.

E come potrebbe essere colpa della LGPL?


Il tanto mazziato Windows se non altro permette che una applicazione scritta per il 95 giri senza troppi problemi su XP.

...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?

Originariamente inviato da bizzu
Sono d'accordo in pieno con Schwartz. E poi a cosa servirebbe Java opensource? Forse a permettere a IBM di fare una sua versione?


veramente IBM gia' realizza una JVM (oltre che un JDK) sua (http://www-106.ibm.com/developerworks/java/jdk/) , 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?

Originariamente inviato da krokus
Allora non mi è chiaro come fa KDE ad essere sotto LGPL se le librerie su cui si basa non lo sono!

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.


Soprattutto non capisco perchè buttare al vento fior di software (tipo Kisocd, per esempio) per un cambio di librerie....ma non è il solo esempio....

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


insomma, come si spiega la bestiale autoincompatibilità di Linux?

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.


e perchè FreeBSD non presenta questo difetto? è colpa delle licenze diverse o è un caso?

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).


Per quello che riguarda il pre o post XP, io non ho mai avuto problemi a mettere software vecchio sotto XP,

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"

:bsod:

...scusa, mi sono lasciato trasportare...
:D

Originariamente inviato da krokus
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"
Secondo me hai ragione...è per questo che sarebbe adatta una licenza OpenSource, ma non GPL ;) Una licenza che non consenta fork del progetto esterni...

Originariamente inviato da krokus
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"

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


o ancora "il modulo è compilato con gcc versione 2.x mentre il kernel è compilato con gcc versione 3.x. Non funzionerà"

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.


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

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 (http://www.jcp.org/) che standardizza e poi gli altri (Sun, Bea, Ibm etc..) implementano?

Originariamente inviato da cionci
Secondo me hai ragione...è per questo che sarebbe adatta una licenza OpenSource, ma non GPL ;)
e visto che la gpl e' una delle licenze opensource piu restrittive in assoluto, quale proponi?
Una licenza che non consenta fork del progetto esterni...
e quindi una licenza che per definizione non puo essere opensource?
ti esprimi male o proprio non sai cosa vuol dire opensource?
fai un giretto qua:
http://www.opensource.org/docs/definition.php


3. Derived Works

The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.

Rationale: The mere ability to read source isn't enough to support independent peer review and rapid evolutionary selection. For rapid evolution to happen, people need to be able to experiment with and redistribute modifications.

Originariamente inviato da qweasdzxc
e visto che la gpl e' una delle licenze opensource piu restrittive in assoluto, quale proponi?
Sinceramente non sono un espertone di licenze...ma andrebbe bene una creata ad hoc...
Originariamente inviato da qweasdzxc
e quindi una licenza che per definizione non puo essere opensource?

Io intendevo OpenSource nel senso stretto del termine...a sorgente aperto...
Un licenza che permetta lo sviluppo da parte di una comunità in cui tutti possono mettere mano al codice, ma sia espressamente vietata la possibilità di far usare il codice sorgente al di fuori del progetto principale...
In poche parole sviluppo aperto, ma codice non riutilizzabile in altri contesti...a molti patiti dell'OpenSource questa cosa farà rabbrividire, ma secondo me sarebbe una soluzione valida per molti software e sistemi operativi... Una gestione centrale "privata" del codice sorgente, ma chiunque può contribuire... E solo il gruppo di gestione può decidere quali modifiche andranno effettivamente a far parte dei sorgenti "ufficiali" e solo la compilazione di quei sorgenti sarà ammessa ;)

PS: non sono contro l'OpenSource, anzi le applicazioni io le metterei tutto sotto BSD ;) Comunque per situazioni del genere preferirei quanto sopra...

ma non e' questo che si sta chiedendo a sun.

Originariamente inviato da qweasdzxc
ma non e' questo che si sta chiedendo a sun.
Infatti...

Quanta sapienza

Totalmente d'accordo con cionci (che tra l'altro in questo periodo ha un'insolita vena "artistica" :D ), e vorrei citare un caso: quello dell'AmigaOS. Nato nel 1985 con la versione 1.0, si è evoluto nell'arco di una dozzina di anni fino alla versione 3.9, subendo anche notevoli cambiamenti (come il passaggio dalla 1.3 alla 2.0/2.1, e dalla 2.0 alla 3.0, ad esempio).

Ebbene, il software che ha seguito pedissequamente le direttive Commodore ha sempre funzionato su qualunque hardware e qualunque versione del s.o. >= a quella per cui era stato sviluppato all'epoca. Questo, ripeto, nonostante siano intervenute anche pesanti modifiche alle API, che hanno anche RIVOLUZIONATO il modo di scrivere applicazioni.

Molti "amighisti" ricorderanno le incompatibilità dei programmi e giochi dovute al passaggio a un nuovo hardware e/o s.o., ma pochi sanno che la causa di tutto ciò è da imputare esclusivamente alla mancata applicazione delle suddette regole. Chi ha sviluppato applicazioni e/o giochi e conosce i famosi ROM Kernel Manual, può confermare ciò che dico.

Riallacciandomi al discorso portato fin qui avanti, quel che manca, quindi, è un gruppo che diriga UNA versione del software, che si evolve sì con lo sforzo di tante persone, ma che conservi UNA linea ben precisa. Un software che, possibilmente, mantenga una completa compatibilità col passato e con tutte le applicazioni che su esso si basino. Non si tratta di un'utopia, visto che è già stato fatto in passato, e non ha portato a problemi di sorta.

Non vedo difficoltà nel fatto che ciò possa venir applicato al mondo open source: sorgente libero a modifiche di tanti e presente in un'unica versione non sono certo concetti mutuamente esclusivi. IMHO è una nuova strada che può portare a benefici non indifferenti nel mondo open source...

Originariamente inviato da dragunov
Quanta sapienza
:rolleyes: Qualcosa di + costruttivo ;)

Originariamente inviato da cdimauro
Riallacciandomi al discorso portato fin qui avanti, quel che manca, quindi, è un gruppo che diriga UNA versione del software, che si evolve sì con lo sforzo di tante persone, ma che conservi UNA linea ben precisa. Un software che, possibilmente, mantenga una completa compatibilità col passato e con tutte le applicazioni che su esso si basino. Non si tratta di un'utopia, visto che è già stato fatto in passato, e non ha portato a problemi di sorta.

Si, sarebbe carino.
L'OSS, pero`, ha un "problema": e` ancora principalmente portato avanti da gente che programma per necessita` (sua) o che programma quel che ha voglia quando ne ha voglia. Un appropccio "hobbystico" se vogliamo. In questi casi, i mantainer cosine come stabilita` delle API tra major release, retrocompatibilita` e cose del genere tendono a non vederle come priorita` assolute.

Nel caso in cui in un progetto girino anche $$$ le cose cambiano, vedasi kernel (per certe cose) o GNOME/GTK, dove in tutta la serie 2.x e` garantita retrocompatibilita` sorgente e binaria per le librerie.

Originariamente inviato da dragunov
Quanta sapienza

Quanta profondita`...

Originariamente inviato da Ikitt_Claw
Nel caso in cui in un progetto girino anche $$$ le cose cambiano, vedasi kernel (per certe cose) o GNOME/GTK, dove in tutta la serie 2.x e` garantita retrocompatibilita` sorgente e binaria per le librerie.
Certo...ma intorno a Java i soldi ci girano...e tanti ;) Quindi sarebbe la soluzione migliore ;)

Originariamente inviato da Ikitt_Claw
L'OSS, pero`, ha un "problema": e` ancora principalmente portato avanti da gente che programma per necessita` (sua) o che programma quel che ha voglia quando ne ha voglia. Un appropccio "hobbystico" se vogliamo.

Oddio non mi pare che i progetti di Apache siano poi cosi' tanto "hobbystici"...

Originariamente inviato da cionci
Certo...ma intorno a Java i soldi ci girano...e tanti ;) Quindi sarebbe la soluzione migliore ;)

Si, infatti e` da mo che si va dicendo che java anche OSS sarebbe interessante ;)

Originariamente inviato da Ecio
Oddio non mi pare che i progetti di Apache siano poi cosi' tanto "hobbystici"...


[...]Nel caso in cui in un progetto girino anche $$$ le cose cambiano,[...]

Originariamente inviato da Ikitt_Claw

[...]Nel caso in cui in un progetto girino anche $$$ le cose cambiano,[...]



appunto come gia' detto li' di soldi ne girerebbero, non stiamo mica parlando del progettino simil php-nuke scritto dall'universitario nei ritagli di tempo e rilasciato come opensource su sourceforge :p

Originariamente inviato da Ecio
appunto come gia' detto li' di soldi ne girerebbero,

Allora stiamo dicendo la stessa cosa.
Io sostengo la tesi secondo cui la JVM OSS [b]non[/]b porterebbe la tanto temuta frammentazione dell'offerta creando N+1 JVM incompatibili tra loro.

D'altrocanto, ci siamo messi a parlare anche di casi di incompatibilita` tra versioni successive di software OSS, del perche` succede, di come porvi rimedio...
In quest'ultimo ambito ho espresso il mio pensiero riguardo all'hobbysmo (in cui, per inciso, non vedo assolutamente nulla di male e non lo ritengo affatto inferiore, a priori, alle potenzialita` del SW commerciale)

Originariamente inviato da Ikitt_Claw
Allora stiamo dicendo la stessa cosa.
Io sostengo la tesi secondo cui la JVM OSS [b]non[/]b porterebbe la tanto temuta frammentazione dell'offerta creando N+1 JVM incompatibili tra loro.

scusa, leggere i msg di prima mattina fa un brutto effetto e non c'ho capito una fava :)

io non sono certo di cosa potrebbe succedere con una JVM OSS, ma anchio non penso che ci sia cosi' tanto rischio di versioni incompatibili, anche xche' come dicevo dovrebbe essere un comitato (JCP) x decidere le feature da aggiungere e gia' esistono JVM realizzate da entita' diverse rispetto a Sun.



D'altrocanto, ci siamo messi a parlare anche di casi di incompatibilita` tra versioni successive di software OSS, del perche` succede, di come porvi rimedio...
In quest'ultimo ambito ho espresso il mio pensiero riguardo all'hobbysmo (in cui, per inciso, non vedo assolutamente nulla di male e non lo ritengo affatto inferiore, a priori, alle potenzialita` del SW commerciale)

beh ci sono casi di incompatibilita' anche su software non OSS...
per quanto riguarda l'hobbysmo, e' certamente una cosa utile, anche se chiaramente con discorsi di questo tipo c'e' sempre il rischio di non avere assistenza/il sw non viene piu' sviluppato etc...

chiaramente con un minimo di oculatezza nella scelta dei prodotti e con un po' di "rischio calcolato" non vedo xche' non scegliere quelle vie...

Originariamente inviato da Ecio
scusa, leggere i msg di prima mattina fa un brutto effetto e non c'ho capito una fava :)

Anch'io non mi sono espresso benissimo. In sintes: una JVM OSS sarebbe interessante da vedere; a priori e ad analizzando la storia non ci sono -o non sono cosi` tragici- i rischi che alcuni paventano. In una parola, secondo me dietro alla scelta di SUN non ci sono (solo) motivazioni tecniche ma piu` che altro di marketing/accordi commerciali.


chiaramente con un minimo di oculatezza nella scelta dei prodotti e con un po' di "rischio calcolato" non vedo xche' non scegliere quelle vie...

Esattamente.

Originariamente inviato da Ikitt_Claw
Si, sarebbe carino.
L'OSS, pero`, ha un "problema": e` ancora principalmente portato avanti da gente che programma per necessita` (sua) o che programma quel che ha voglia quando ne ha voglia. Un appropccio "hobbystico" se vogliamo. In questi casi, i mantainer cosine come stabilita` delle API tra major release, retrocompatibilita` e cose del genere tendono a non vederle come priorita` assolute.
Proprio per questo motivo vedrei bene un nuovo tipo di licenza open source, che impedisse i fork del progetto e tenesse una linea guida ben precisa.
In questo modo un gruppo direttivo si occuperebbe di portare avanti le specifiche e di definire l'architettura, e quindi le API, e di controllare e risolvere i problemi relativi alla retrocompatibilità: dovrebbero essere delle persone capaci, con notevole esperienza nel campo della programmazione e/o di ingegneria del software, e che si metterebbero a disposizione seriamente, non una volta ogni morte di papa o quando più gli aggrada.
Il resto della comunità, chiunque volesse collaborare "a tempo perso", lo potrebbe fare, ma all'interno di regole ben definite.
In questo modo tutte le energie verrebbero convogliate in una direzione e il progetto non potrebbe che giovarne.
Nel caso in cui in un progetto girino anche $$$ le cose cambiano, vedasi kernel (per certe cose) o GNOME/GTK, dove in tutta la serie 2.x e` garantita retrocompatibilita` sorgente e binaria per le librerie.
E' cosa buona e giusta. ;)
Comunque penso che il discorso potrebbe essere applicabile a prescindere dalla presenza o meno di $: sarebbe un atto di buona volontà e volto al bene dell'OSS.

Originariamente inviato da cdimauro
Proprio per questo motivo vedrei bene un nuovo tipo di licenza open source, che impedisse i fork del progetto e tenesse una linea guida ben precisa.
In questo modo un gruppo direttivo si occuperebbe di portare avanti le specifiche e di definire l'architettura, e quindi le API, e di controllare e risolvere i problemi relativi alla retrocompatibilità: dovrebbero essere delle persone capaci, con notevole esperienza nel campo della programmazione e/o di ingegneria del software, e che si metterebbero a disposizione seriamente, non una volta ogni morte di papa o quando più gli aggrada.
Il resto della comunità, chiunque volesse collaborare "a tempo perso", lo potrebbe fare, ma all'interno di regole ben definite.
In questo modo tutte le energie verrebbero convogliate in una direzione e il progetto non potrebbe che giovarne.


Mi sembrano un po' i discorsi che si leggevano su linux 10 anni fa... se non erro per sviluppo di sistemi "core" come il kernel l'approccio e' quello, la gente sviluppa, <qualcuno> (non so chi sia) decide se includere la tal modifica/sviluppo nel kernel altrimenti si puo' rilasciare il proprio codice come patch e chi vuole lo utilizza. Potrebbero benissimo fare cosi', con il JCP come il comitato che decide cosa mettere e cosa no e se qualcuno vuole fare patch/fork che non seguono l'andamento ufficiale puo' farlo ma se nessuno (o pochi) lo seguono, il suo fork non ha molto valore...

Originariamente inviato da cdimauro
Proprio per questo motivo vedrei bene un nuovo tipo di licenza open source, che impedisse i fork del progetto e tenesse una linea guida ben precisa.

Questo, come gia` detto, collide un po` troppo con l'idea di Open Source perche` sia attuato.
La caoticita` e l'assenza di controllo forte dello sviluppo, o meglio, anzi, i rischi che questi eventi si verifichino, sono parte del modello di sviluppo.

[...]
ingegneria del software, e che si metterebbero a disposizione seriamente, non una volta ogni morte di papa o quando più gli aggrada.

Per questo ci vuole $$$. Ma allora si va a delineare un modello che inizia ad essere fantascientifico piu` che concreto (perche` l'OSS, bene o male -anzi, piu` bene che male- funziona eccome). Ci vorrebbero le ditte che pagano dei professionisti -o comunque gente a tempo pieno- MA che pero` rendono libero l'accesso al codice... Sa di utopia.


In questo modo tutte le energie verrebbero convogliate in una direzione e il progetto non potrebbe che giovarne.

secondo me si tratta semplicemente di qualita` del progetto. I team piu` accorti (e, casualmente, i progetti di maggior successo) si preoccupano comunque di queste problematiche pur mantenendo un'approccio OSS puro.


Comunque penso che il discorso potrebbe essere applicabile a prescindere dalla presenza o meno di $: sarebbe un atto di buona volontà e volto al bene dell'OSS.

Sulla compatibilita` binaria ho qualche dubbio, del resto stiamo parlando di OSS. Su quella sorgente, ci sono casi in cui non e` possibile o non e` conveniente tecnicamente, e si ritorna al punto di cui sopra...

Originariamente inviato da Ikitt_Claw
Per questo ci vuole $$$. Ma allora si va a delineare un modello che inizia ad essere fantascientifico piu` che concreto (perche` l'OSS, bene o male -anzi, piu` bene che male- funziona eccome). Ci vorrebbero le ditte che pagano dei professionisti -o comunque gente a tempo pieno- MA che pero` rendono libero l'accesso al codice... Sa di utopia.
Ma qui rientra il ruolo di Sun ed IBM che investono soldi in Java e quindi va nel loro interesse mettere sviluppatori a tempo pieno che fanno queste cose...già ci sono e quindi non cambierebbe niente...

Originariamente inviato da cionci
Ma qui rientra il ruolo di Sun ed IBM che investono soldi in Java e quindi va nel loro interesse mettere sviluppatori a tempo pieno che fanno queste cose...già ci sono e quindi non cambierebbe niente...

Allora nulla vieta di fare direttamente come per il kernel, o apache, o gcc, che funzionano bene, hanno un numero di fork scars(issim)o o nullo, e sono GPL o OSS puri.
Per cui, dov'e` il problema? :)

Il problema è che a Sun non va bene (per i $$$) ;)

Allora...ti faccio un esempio la NASA vuole mettere una VM su un robot per andare su Marte... Il codice è GPL...allora la Sun non ci becca niente...
Se non sono permesse fork e non è permesso riutilizzare il codice all'esterno delle VM "ufficiali"...allora Sun ci prende tanti $$$...
Credo che la differenza sia sicuramente qui...

Se il problema di Sun sono le possibili fork (o anche il riutilizzo del codice in altri progetti) allora sarebbe meglio studiare una licenza che non le permetta...

Originariamente inviato da cionci
Il problema è che a Sun non va bene (per i $$$) ;)

Allora...ti faccio un esempio la NASA vuole mettere una VM su un robot per andare su Marte... Il codice è GPL...allora la Sun non ci becca niente...
Se non sono permesse fork e non è permesso riutilizzare il codice all'esterno delle VM "ufficiali"...allora Sun ci prende tanti $$$...
Credo che la differenza sia sicuramente qui...

Se il problema di Sun sono le possibili fork (o anche il riutilizzo del codice in altri progetti) allora sarebbe meglio studiare una licenza che non le permetta...


uhm ma come dicevo c'e' la VM sia di Sun che di IBM che di BEA etc...
non penso che tutti i soldi vadano a Sun, o no ?
o forse ci sara' qche porcata tipo che devono pagare il JCP e quindi danno tanti soldi e tanti soldi gli tornano?

Originariamente inviato da Ecio
non penso che tutti i soldi vadano a Sun, o no ?
Ma concordi che rilasciando la VM sotto GPL qualche $$$ ce lo perde ?

Originariamente inviato da cionci
Il problema è che a Sun non va bene (per i $$$) ;)


Si ma allora siamo d'accordo: problema commerciale/manageriale, non tecnico.

Originariamente inviato da Ikitt_Claw
Si ma allora siamo d'accordo: problema commerciale/manageriale, non tecnico.
Certo...ma allora ci potremmo accontentare di quella licenza di cui si parlava prima... Andrebbe solo proposta ;) :D

Originariamente inviato da cionci
Ma concordi che rilasciando la VM sotto GPL qualche $$$ ce lo perde ?


mah non saprei, alla fine i soldi Sun ce li fa sui server e sui servizi penso, a maggior ragione la VM la rilascia gia' free.... mah boooh :confused:

Originariamente inviato da Ecio
mah non saprei, alla fine i soldi Sun ce li fa sui server e sui servizi penso, a maggior ragione la VM la rilascia gia' free.... mah boooh :confused:

eh sui server mica tanti...di quote ne hanno perse parecchio ultimamente, tant'è che hanno intrapreso la scelta di supportare gli Opteron quindi i guadagnis aranno + che altro sul prodotto finito non sul cuore che pulsa all'interno delle macchine...

Trovandosi nei panni dei dirigenti Sun credo faremmo per il bene dell'azienda + o - tutti questa scelta...certo dal pdv del normale utente farebbe + piacere l'open src...ma dato che i soldi non sn i nostri...

Originariamente inviato da DioBrando
eh sui server mica tanti...di quote ne hanno perse parecchio ultimamente, tant'è che hanno intrapreso la scelta di supportare gli Opteron quindi i guadagnis aranno + che altro sul prodotto finito non sul cuore che pulsa all'interno delle macchine...


Beh faranno come HP e simili che vendono server + soluzioni chiavi in mano pur usando processori Intel "normalissimi"


Trovandosi nei panni dei dirigenti Sun credo faremmo per il bene dell'azienda + o - tutti questa scelta...certo dal pdv del normale utente farebbe + piacere l'open src...ma dato che i soldi non sn i nostri...

Beh hanno i soldi che hanno ricevuto dalla Microsoft per fermare le cause legali :D

Originariamente inviato da Ecio
Beh faranno come HP e simili che vendono server + soluzioni chiavi in mano pur usando processori Intel "normalissimi"


ma HP Compaq e altri non hanno mai sviluppato soluzioni integralmente loro...per Sun è un netto cambio di direzione che a loro è costato un mare di soldi...e di incazzature da parte di coloro si sn affidati alle UltraSparc&co...


Beh hanno i soldi che hanno ricevuto dalla Microsoft per fermare le cause legali :D

sì ma n faranno beneficienza ocn quei soldi :D:D:D

Originariamente inviato da DioBrando
ma HP Compaq e altri non hanno mai sviluppato soluzioni integralmente loro...
Ma scherzi ? PA-RISC e Alpha dove li metti ;)

Originariamente inviato da Ecio
Mi sembrano un po' i discorsi che si leggevano su linux 10 anni fa... se non erro per sviluppo di sistemi "core" come il kernel l'approccio e' quello, la gente sviluppa, <qualcuno> (non so chi sia) decide se includere la tal modifica/sviluppo nel kernel altrimenti si puo' rilasciare il proprio codice come patch e chi vuole lo utilizza. Potrebbero benissimo fare cosi', con il JCP come il comitato che decide cosa mettere e cosa no e se qualcuno vuole fare patch/fork che non seguono l'andamento ufficiale puo' farlo ma se nessuno (o pochi) lo seguono, il suo fork non ha molto valore...
Ciò non impedisce comunque di avere diversi progetti che poi, comunque, si biforcano. Meglio un progetto che ha un obiettivo ben preciso, e su cui non è possibile effettuare il fork.
In questo modo la gente che ha voglia di contribuire seriamente, proporrà e/o lavorerà direttamente su quel progetto, e lo svilupperà secondo le esigenze che sono state evidenziate dal gruppo direttivo.

Originariamente inviato da cionci
Ma scherzi ? PA-RISC e Alpha dove li metti ;)

uhm...ops :oink: :D

cmq diciamo che tutto sommato si sn adattati molto prima a soluzioni ibride, Sun nel suo caso rispetto ai tempi è stato quasi un unicum.
Mentre Intel e AMD sviluppavano soluzioni molto performanti e tutto sommato a basso costo rispetto al marasma proprietario, loro sn andati avanti fornendo e hw e sw...però o sei un colosso in grossa salute o prima o poi il mercato ti stritola se non riesci a stare al passo dei concorrenti.

Nn è detto che lo sviluppo hw si blocchi di colpo, però non potranno + proseguire in un dualismo così paritario...o + investimenti e sforzi nel sw o nell'hw...credo sia palese abbiano scelto la prima...

concordi? :D

Originariamente inviato da Ikitt_Claw
Questo, come gia` detto, collide un po` troppo con l'idea di Open Source perche` sia attuato.
Non collide: l'open source è una cosa, impedire il fork è un'altra cosa. Diciamo che, per come viene visto in questo momento l'OSS, è fuori dalla logica attuale.
La caoticita` e l'assenza di controllo forte dello sviluppo, o meglio, anzi, i rischi che questi eventi si verifichino, sono parte del modello di sviluppo.
L'approccio "caotico", però, può comportare un notevole spreco di risorse: è molto meglio partire da soluzioni (o presunte tali) e farle crescere, piuttosto che andare a tentoni sperando di trovare quella "buona".
Per questo ci vuole $$$. Ma allora si va a delineare un modello che inizia ad essere fantascientifico piu` che concreto (perche` l'OSS, bene o male -anzi, piu` bene che male- funziona eccome). Ci vorrebbero le ditte che pagano dei professionisti -o comunque gente a tempo pieno- MA che pero` rendono libero l'accesso al codice... Sa di utopia.
No, basta trovare gente disposta a impegnarsi seriamente in qualche progetto. E' chiaro che una società che abbia a disposizione dei $$$, potrà permettersi di pagare gente per farlo. Per tutti gli altri progetti "squattrinati", qualcuno disposto a seguire il progetto lo si trova. Lo si è fatto finora, appunto, e non vedo quali difficoltà potrebbero sorgere per dei progetti che differiscano soltanto per una licenza un po' più restrittiva.
secondo me si tratta semplicemente di qualita` del progetto. I team piu` accorti (e, casualmente, i progetti di maggior successo) si preoccupano comunque di queste problematiche pur mantenendo un'approccio OSS puro.
OK. Ma la storia del KDE, che non è un progetto di poco conto, mi sembra dimostri che un approccio diverso sarebbe stato migliore...
Sulla compatibilita` binaria ho qualche dubbio, del resto stiamo parlando di OSS.
Dipende dal progetto, chiaramente. Ma se ci sono riusciti quelli di Gnome, che è un OSS...
Su quella sorgente, ci sono casi in cui non e` possibile o non e` conveniente tecnicamente, e si ritorna al punto di cui sopra...
D'accordo. Ma quanto meno, anche se a volte si effettuano delle reigegnerizzazioni del software che portano a delle modifiche consistenti a livello di sorgente, che sia mantenuta la più completa compatibilità a livello binario e di API: e questa non è certo una cosa dell'altro mondo. AmigaOS, come ho citato prima, insegna. E stiamo parlando di un intero s.o., con annessi e connessi (decine e decine di librerie che spaziano dal kernel all'interfaccia grafica).

Originariamente inviato da cdimauro
Non collide: l'open source è una cosa, impedire il fork è un'altra cosa. Diciamo che, per come viene visto in questo momento l'OSS, è fuori dalla logica attuale.

No, non e` solo questo. OSS vuol dire liberta` di usare il codice in un'altro progetto OSS (sto semplificando, spero che gli assunti siano chiari).
Togliere la liberta` di fork() (che peraltro, la storia insegna, e` un'evento raro e abbastanza grave, non certo all'ordine del giorno) inizia a penalizzare pesantemente questo concetto, perche` pone delle domande scomode:
quand'e` fork e quand'e` semplcie riutilizzo del codice? Che si mette la soglia al 50%+1 delle righe di codice?


L'approccio "caotico", però, può comportare un notevole spreco di risorse: è molto meglio partire da soluzioni (o presunte tali) e farle crescere, piuttosto che andare a tentoni sperando di trovare quella "buona".

Guarda, non ne sono cosi` sicuro. Solitamente i progetti buoni alla fine convergono, e la selezione fa il suo corso.


No, basta trovare gente disposta a impegnarsi seriamente in qualche progetto.


Anche, ma e` difficile pretenderlo da degli hobbysti (anche nel senso nobile del termine).


OK. Ma la storia del KDE, che non è un progetto di poco conto, mi sembra dimostri che un approccio diverso sarebbe stato migliore...

Non seguo la faccenda KDE, non saprei darti info piu` precise.
Credo che ci sia qualcosa di sottile sotto, comunque.


Dipende dal progetto, chiaramente. Ma se ci sono riusciti quelli di Gnome, che è un OSS...


Si, ma li` c'e` SUN che ci mette $$$ e impegno. GNOME 1.x usciva "quand'era pronto" infatti (ok, era anche peggio, ma questa e` un'altra storia).


D'accordo. Ma quanto meno, anche se a volte si effettuano delle reigegnerizzazioni del software che portano a delle modifiche consistenti a livello di sorgente, che sia mantenuta la più completa compatibilità a livello binario e di API:

Questo richiede un solido progetto a monte. In alcuni casi questo manca, o la rifattorizzazione non avviene in tempo.
Mi viene in mente transcode: mi chiedo come faranno ad aggiornarlo e generalizzarlo senza spezzare completamente la retrocompatibilita` a livello di codice, se lo faranno.

Originariamente inviato da Ikitt_Claw
No, non e` solo questo. OSS vuol dire liberta` di usare il codice in un'altro progetto OSS (sto semplificando, spero che gli assunti siano chiari).
Togliere la liberta` di fork() (che peraltro, la storia insegna, e` un'evento raro e abbastanza grave, non certo all'ordine del giorno) inizia a penalizzare pesantemente questo concetto, perche` pone delle domande scomode:
quand'e` fork e quand'e` semplcie riutilizzo del codice? Che si mette la soglia al 50%+1 delle righe di codice?
A questo punto si potrebbe limitare anche il riutilizzo del codice, se necessario. Lo so, è una proposta indecente. :mad: Ammazzatemi pure per la bestemmia che ho detto.
Guarda, non ne sono cosi` sicuro. Solitamente i progetti buoni alla fine convergono, e la selezione fa il suo corso.
Un progetto che parte già col piede giusto non sarebbe ancora meglio? Oltre al fatto che, ripeto, lo spreco di risorse viene decisamente ridotto.
Anche, ma e` difficile pretenderlo da degli hobbysti (anche nel senso nobile del termine).
Beh, non è che il gruppo debba essere composto da una sola persona, e se "muore" (grat, grat ;)) quella tutto va a farsi benedire. I progetti di un certo spesso sono portati avanti da un gruppo consistente.
Non seguo la faccenda KDE, non saprei darti info piu` precise.
Credo che ci sia qualcosa di sottile sotto, comunque.
Per me vale la stessa cosa: ho soltato citato un fatto riportato qui sul forum, tutto qui.
Si, ma li` c'e` SUN che ci mette $$$ e impegno. GNOME 1.x usciva "quand'era pronto" infatti (ok, era anche peggio, ma questa e` un'altra storia).
Non ne ero a conoscenza. :) Comunque non cambia il fine ultimo del discorso.
Questo richiede un solido progetto a monte. In alcuni casi questo manca,
Perché manca gente esperiente, generalmente.
o la rifattorizzazione non avviene in tempo.
A volte bisogna avere il coraggio di fermarsi e ricominciare. A volte anche di abbandonare. L'ho fatto con un grosso progetto (commerciale), quando mi sono reso conto che più avanti di così non poteva andare.
Mi viene in mente transcode: mi chiedo come faranno ad aggiornarlo e generalizzarlo senza spezzare completamente la retrocompatibilita` a livello di codice, se lo faranno.
Non lo conosco. Ho citato AmigaOS perché è un esempio eloquente, in quanto si tratta di un intero s.o... ;)

Originariamente inviato da cdimauro
A questo punto si potrebbe limitare anche il riutilizzo del codice, se necessario. Lo so, è una proposta indecente. :mad: Ammazzatemi pure per la bestemmia che ho detto.

No, non e` indecente: semplicemente non e` piu` OSS, e` un'altra cosa :)


Un progetto che parte già col piede giusto non sarebbe ancora meglio? Oltre al fatto che, ripeto, lo spreco di risorse viene decisamente ridotto.


Tante cose sarebbero meglio, ma molto spesso non sono decidibili a priori.
Troppe variabili in gioco, troppe personalita` da conciliare, troppe esigenze da accumunare, troppo. Se e` cosi` un motivo c'e`, non ti preoccupare ;)


A volte bisogna avere il coraggio di fermarsi e ricominciare. A volte anche di abbandonare. L'ho fatto con un grosso progetto (commerciale), quando mi sono reso conto che più avanti di così non poteva andare.


Si certo. E` lo stesso discorso che si fa per la retrocompatibilita`, in certi casi.


Non lo conosco. Ho citato AmigaOS perché è un esempio eloquente, in quanto si tratta di un intero s.o... ;)

Io non conosco questo, per cui non mi pronunzio.

Forse bisognerebbe mettersi d'accordo sul significato del termine "open source", per districare la matassa.Indichiamo il semplice fatto che i sorgenti siano disponibili e visionabili/modificabili da tutti (quindi nell'accezzione letterale del termine), o altro?
Io vedo le licenze (GPL, LGPL, ecc.) come delle cose a sé stanti (tant'è che limitano in maniera diversa la fruizione dei sorgenti), per cui quel che ipotizzavo si andava a configurare semplicemente come una nuova tipologia di licenza.

Originariamente inviato da cdimauro
Forse bisognerebbe mettersi d'accordo sul significato del termine "open source", per districare la matassa.Indichiamo il semplice fatto che i sorgenti siano disponibili e visionabili/modificabili da tutti (quindi nell'accezzione letterale del termine), o altro?[/b]

Opensource: qualsiasi software accompagnato da licenza che soddisfi i requisiti indicati in http://www.opensource.org/docs/definition.php


Io vedo le licenze (GPL, LGPL, ecc.) come delle cose a sé stanti (tant'è che limitano in maniera diversa la fruizione dei sorgenti), per cui quel che ipotizzavo si andava a configurare semplicemente come una nuova tipologia di licenza.

Benissimo, ma e` altamente probabile (specie se e` vietata o parzialmente vietato il riuso del codice o i fork) che quello non sia piu` software opensource, ma un'altra cosa. Nulla di male, per carita`, basta solo che sia chiaro.

Perche`, per dire, col piffero che il sottoscritto (ma anche il resto del mondo pare essere rimasto freddino ;) ) contribuirebbe ad un software coperto dalla commercialissima licenza MS shared source, allo stato attuale delle cose.

Originariamente inviato da Ikitt_Claw
Opensource: qualsiasi software accompagnato da licenza che soddisfi i requisiti indicati in http://www.opensource.org/docs/definition.php
Interessante. Anche quello che dice alla fine: <<Origins: Bruce Perens wrote the first draft of this document as "The Debian Free Software Guidelines", and refined it using the comments of the Debian developers in a month-long e-mail conference in June, 1997. He removed the Debian-specific references from the document to create the "Open Source Definition.">>

e nel frame a sinistra: <<We think the Open Source Definition captures what the great majority of the software community originally meant, and still mean, by the term "Open Source". However, the term has become widely used and its meaning has lost some precision. The OSI Certified mark is OSI's way of certifying that the license under which the software is distributed conforms to the OSD; the generic term "Open Source" cannot provide that assurance, but we still encourage use of the term "Open Source" to mean conformance to the OSD.>>

Da premettere che l'utilizzo del termine "open source" nell'accezzione letterale del termine risale a ben prima di ciò.
Benissimo, ma e` altamente probabile (specie se e` vietata o parzialmente vietato il riuso del codice o i fork) che quello non sia piu` software opensource, ma un'altra cosa. Nulla di male, per carita`, basta solo che sia chiaro.
A mio avviso lo è: non mi sembra cozzare con i 10 "criteri" espressi nel link che hai postato.
Perche`, per dire, col piffero che il sottoscritto (ma anche il resto del mondo pare essere rimasto freddino ;) ) contribuirebbe ad un software coperto dalla commercialissima licenza MS shared source, allo stato attuale delle cose.
Penso che la licenza ipotizzata abbia ben poco a che spartire con lo shared source di MS, poiché non esiste il concetto di proprietà. ;)

Originariamente inviato da cdimauro

Da premettere che l'utilizzo del termine "open source" nell'accezzione letterale del termine risale a ben prima di ciò.


:eek:

però eran pur sempre le 6 :D

No, è un errore che ho commesso due volte. Semplicemente ricordavo male la parola. :p

Grazie per la correzione. :)