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 Fabio Boneschi pubblicata il 14 Aprile 2004, alle 16:07 nel canale ProgrammiIBM










Forza Horizon 6 Recensione: si vola in Giappone!
HONOR CHOICE AI Note, il registratore IA che si ricarica dallo smartphone
Insta360 GO 3S Pack Retrò: l'azione incontra lo stile delle macchine a pellicola
Torna l'e-bike Engwe più venduta: P275 SE con sconto folle di 600 euro, più secondo sconto
Netflix vuole realizzare i film d'animazione con l'IA generativa? Un annuncio di lavoro sembra confermarlo
Bitwarden cancella "Always free" dal sito: cosa sta succedendo al password manager open source?
Volkswagen ID. Polo GTI: debutta la prima GTI elettrica da 226 CV, 0-100 in 6,8 secondi
Leapmotor è pronta a lanciare un secondo marchio di gamma medio alta
Honda lavora a un cambio virtuale per le moto elettriche, con tanto di vibrazioni 'da cambiata'
70mai A410 a 90,99€: la dashcam doppia a 2.5K con GPS che registra anche quando l'auto è parcheggiata
Garmin Instinct 3 Tactical in promo a 384,49€: lo smartwatch rugged con GPS in versione 50mm, senza rivali nel prezzo
ASUS ROG Edition 20: i primi moduli DDR5 a marchio ROG arrivano in kit da 48 GB con profili XMP ed EXPO
Polio, HPV e malaria: Anthropic e Gates Foundation vogliono distribuire l'IA dove non arriva
Stellantis sceglie la via di Wuhan: Peugeot e Jeep elettriche "Made in China" per l’export globale
ASUS ROG Crosshair 2006: tutto quello che devi sapere sulla motherboard che celebra i 20 anni della linea ROG
SpaceX ha intenzione di costruire più siti di lancio per il razzo spaziale Starship, negli USA e all'estero









63 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - infoBeh 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...
sì ma n faranno beneficienza ocn quei soldi
ma HP Compaq e altri non hanno mai sviluppato soluzioni integralmente loro...
Ma scherzi ? PA-RISC e Alpha dove li metti
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.
Ma scherzi ? PA-RISC e Alpha dove li metti
uhm...ops
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?
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.
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".
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.
OK. Ma la storia del KDE, che non è un progetto di poco conto, mi sembra dimostri che un approccio diverso sarebbe stato migliore...
Dipende dal progetto, chiaramente. Ma se ci sono riusciti quelli di Gnome, che è un OSS...
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).
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?
Guarda, non ne sono cosi` sicuro. Solitamente i progetti buoni alla fine convergono, e la selezione fa il suo corso.
Anche, ma e` difficile pretenderlo da degli hobbysti (anche nel senso nobile del termine).
Non seguo la faccenda KDE, non saprei darti info piu` precise.
Credo che ci sia qualcosa di sottile sotto, comunque.
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).
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.
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.
Un progetto che parte già col piede giusto non sarebbe ancora meglio? Oltre al fatto che, ripeto, lo spreco di risorse viene decisamente ridotto.
Beh, non è che il gruppo debba essere composto da una sola persona, e se "muore" (grat, grat
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.
Non ne ero a conoscenza.
Perché manca gente esperiente, generalmente.
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.
Non lo conosco. Ho citato AmigaOS perché è un esempio eloquente, in quanto si tratta di un intero s.o...
A questo punto si potrebbe limitare anche il riutilizzo del codice, se necessario. Lo so, è una proposta indecente.
No, non e` indecente: semplicemente non e` piu` OSS, e` un'altra cosa
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
Si certo. E` lo stesso discorso che si fa per la retrocompatibilita`, in certi casi.
Io non conosco questo, per cui non mi pronunzio.
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.
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
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
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".