Java con licenza Open Source? Sun dice no

[Ecio]

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?

[qweasdzxc]

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.

[cionci]

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

[qweasdzxc]

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

[cionci]

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

Infatti...

[dragunov]

Quanta sapienza

[cdimauro]

Totalmente d'accordo con cionci (che tra l'altro in questo periodo ha un'insolita vena "artistica" ), 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...

[cionci]

Originariamente inviato da dragunov
Quanta sapienza

Qualcosa di + costruttivo

[Ikitt_Claw]

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.

[Ikitt_Claw]

Originariamente inviato da dragunov
Quanta sapienza

Quanta profondita`...

[cionci]

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

[Ecio]

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

[Ikitt_Claw]

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

[Ikitt_Claw]

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,[...]

[Ecio]

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

[Ikitt_Claw]

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)

[Ecio]

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

[Ikitt_Claw]

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.

[cdimauro]

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.

[Ecio]

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