Java con licenza Open Source? Sun dice no

[Ikitt_Claw]

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

[cionci]

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

[Ikitt_Claw]

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?

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

[Ecio]

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?

[cionci]

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 ?

[Ikitt_Claw]

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.

[cionci]

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

[Ecio]

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

[DioBrando]

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

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

[Ecio]

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

[DioBrando]

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

sì ma n faranno beneficienza ocn quei soldi

[cionci]

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

[cdimauro]

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.

[DioBrando]

Originariamente inviato da cionci
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?

[cdimauro]

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

[Ikitt_Claw]

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.

[cdimauro]

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

[Ikitt_Claw]

Originariamente inviato da cdimauro
A questo punto si potrebbe limitare anche il riutilizzo del codice, se necessario. Lo so, è una proposta indecente. 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.

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