Java con licenza Open Source? Sun dice no

Java con licenza Open Source? Sun dice no

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

di pubblicata il , alle 16:07 nel canale Programmi
IBM
 
I migliori sconti su Amazon oggi

Amazfit Bip 5, 46 mm, Smartwatch, Schermo grande, chiamate Bluetooth, Alexa, GPS, durata della batteria di 10 giorni, fitness tracker con frequenza cardiaca, monitoraggio dell'ossigeno nel sangue

Compra ora

AMAZFIT Active 2 Smart Watch 44mm, AI, Controllo Vocale, GPS e Mappe incluse, Batteria da 10 Giorni, 160+ Modalità Sportive, Resistente allAcqua 5 ATM per Android e iPhone, Nero

Compra ora
63 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
Ecio17 Aprile 2004, 09:33 #31
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_Claw17 Aprile 2004, 10:00 #32
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_Claw17 Aprile 2004, 10:01 #33
Originariamente inviato da Ecio
Oddio non mi pare che i progetti di Apache siano poi cosi' tanto "hobbystici"...


[code]
[...]Nel caso in cui in un progetto girino anche $$$ le cose cambiano,[...]
[/code]
Ecio17 Aprile 2004, 10:03 #34
Originariamente inviato da Ikitt_Claw
[code]
[...]Nel caso in cui in un progetto girino anche $$$ le cose cambiano,[...]
[/code]



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_Claw17 Aprile 2004, 10:25 #35
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)
Ecio17 Aprile 2004, 10:44 #36
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_Claw17 Aprile 2004, 11:42 #37
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.
cdimauro17 Aprile 2004, 23:03 #38
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.
Ecio18 Aprile 2004, 10:07 #39
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...
Ikitt_Claw18 Aprile 2004, 11:16 #40
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...
« Pagina Precedente     Pagina Successiva »

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^