Newsgroup: it.comp.os.dibattiti
Titolo: [OT] ma non troppo: Java is now OPEN!

Annunciato or ora in modo ufficiale: Java è stato rilasciato con
licenza GPL V2!
https://openjdk.dev.java.net/servlets/ProjectSource
Raffaele



ecco. sto guardando ora che le librerie di mono sono sotto licenza mit x11.
spero che anche le classi di java abbiano una licenza più libera della gpl
(almeno lgpl) o siamo rovinati...
traduzione: vuoi rilasciare un progetto in java che usi le classi del jre ?
ok, ma solo sotto gpl... ARGH!
-- 
NoWhereMan
-- NoWhereBlog: 
www.nowhereland.it
-- FlatPress: 
http://flatpress.nowhereland.it
 blog flat-file powered,
xhtml1.1strict compliant
-- deviantArt: 
http://nowhereland.deviantart.com

 ok, ma solo sotto gpl... ARGH!
Personalmente, meglio che GPL poteva solo essere Apache, la licenza...
Prevedo comunque un grosso boost per il progetto Harmony, comunque.
Sarebbe un colpaccio avere due implementazioni di Java in
concorrenza/collaborazione tra loro, una GPL ed una Apache...
Raffaele

 jre ? ok, ma solo sotto gpl... ARGH!
Q:
Will Sun continue distributing its commercial implementation of the JDK?
A:
Yes. For people who want the benefits of commercial support, and 
predictability, they may choose to use Sun's commercial distribution of the 
JDK or JRE. The free commercial implementation of the JDK may be found at 
http://java.sun.com/javase/downloads/index.jsp
. Similarly, Sun's free JRE 
may be downloaded from 
http://java.com
. To learn more about development and 
deployment support options, visit 
http://sun.com/javasupport
.
Q:
Will Sun's commercial JDK releases be built from the open-source code?
A:
Yes, for the most part. Since there's some encumbered code in the JDK, Sun 
will continue to use that code in commercial releases until it's replaced by 
fully-functional open-source alternatives.
Basta solo stare attenti  e Stallmann/Sun  non si papperanno tutto il 
lavoro.
Me vede già un grosso nome a cui verrà recapitata una lettera per violazione 
della GNU/GPL :-)
Saluti
. 

 Personalmente, meglio che GPL poteva solo essere Apache, la licenza...
apache ha la clausola pubblicitaria, se non erro. non compatibile gpl,
buuuh!
ciao :)


 
https://openjdk.dev.java.net/servlets/ProjectSource
Stavo per dirlo io... magari e' la volta buona che esce qualcosa di
decente.
-- 
RiK0

Enrico 'Mc Osten' Franchi ha scritto:

Beh, cos'ha di "indecente", ora come ora, java? (senza andare troppo
per le lunghe, và...)
Raffaele

 decente.
Se anche la libreria standard e` rilasciata sotto GPL, allora e` gia`
uscito qualcosa di poco decente. Passi se fosse un normale applicativo, ma
per un intero ambiente come Java la cosa personalmente la vedo piu`
deleteria che mai (hint: perche` Python, Perl o Ruby non sono rilasciati
sotto GPL?)
Enrico



quoto in toto. è esattamente quello che intendevo io


 sotto GPL?)
Sun vuole evitare che qualcuno prenda pezzi del suo codice senza dare 
nulla in cambio.  Come biasimarla?


leggiti la licenza di java. e chiediti come mai in molti progetti sia
stato evitato l'uso di java. Un esempio su tutti, le build di openoffice
in italiano riducono di molto le sue funzionalità per problemi di licenza.
Da come l'hanno raccontata a me, ci sono delle clausole che scaricano la
responsabilità di sun sullo sviluppatore.

 sotto GPL?)
Perchè dovrebbero, dico io... Chi ha sviluppato quei linguaggi ha
deciso di usare la tal licenza. Cosa ci sarebbe di deleterio
nell'impedire che qualcuno si appropri del lavoro di sun prima, e della
community ora? hint: perchè linux è rilasciato sotto GPL?
In ogni caso, una piccola nota:
chiunque potrà modificare il codice, e rilasciare versioni modificate
dello stesso, ma solo le versioni certificate (ovvero, che rispettano
le specifiche definite da sun) potranno fregiarsi del nome "JAVA", che
resta trademark della Sun. Per il resto, GPL.
Raffaele

 ok, ma solo sotto gpl... ARGH!
Non è cosi, ma fa niente.
-- 
Lawrence - 
http://www.oluyede.org/blog
http://www.neropercaso.it
"Nothing is more dangerous than an idea
if it's the only one you have" - E. A. Chartier

 responsabilità di sun sullo sviluppatore.
Credo che ce ne siano ben poche, di software house tipo Sun, che si
accollino la responsabilità di ciò che scrivono. Se non funziona
windows, la colpa non è di Microsoft. Se non funziona Java, la colpa
non è di Sun.
Ma del resto, se non funziona linux la colpa non è di Linus, così
come se non funziona Tomcat la colpa non è di Apache. Se non funziona
Python/Ruby/Perl/PHP la colpa ricade forse su chi li ha sviluppati? Non
credo proprio, sai...
Raffaele

 responsabilità di sun sullo sviluppatore.
Credo che ce ne siano ben poche, di software house tipo Sun, che si


 credo proprio, sai...
infatti. E allora basta rompere i maroni sulla storia che il free
software non dà garanzie. Non lo dà nessun software. :-)

 software non dà garanzie. Non lo dà nessun software. :-)
L'hai tirato fuori tu il discorso della "clausola che scarica la
responsabilità sullo sviluppatore"...
Raffaele

 Non è cosi, ma fa niente.
dì pure ;)
non puoi linkarti con codice non gpl a librerie gpl, o sbaglio?
ciao!


 licenza GPL V2!
In questo modo si riduce la forza di .NET che evidentemente preoccupa Sun, e
si dà la spallata definitiva a Novell che non ha più il vantaggio di Mono.
-- 
Per rispondermi, togli il nome del poeta

 si dà la spallata definitiva a Novell che non ha più il vantaggio di Mono.
"vantaggio"? :D


 ciao!
Non puoi lincarti staticamente. Puoi lincarti dinamicamente.
E con java che io sappia non esiste il concetto di "link statico",
quindi il problema non si pone, se lo usi solo per sviluppare.
Se invece vuoi modificarlo e ridistribuirlo, beh, son fatti tuoi...
Raffaele

 non puoi linkarti con codice non gpl a librerie gpl, o sbaglio?
Ti limiti a implemementare interfaccie, chiamare metodi e linkarti
dinamicamente.


 quindi il problema non si pone, se lo usi solo per sviluppare.
ah ok 
io mi rifacevo a questo (e punti seguenti)
http://www.fsf.org/licensing/licenses/gpl-faq.html#LinkingWithGPL
non si cita linking statico e dinamico :/
più avanti:
"If the modules are included in the same executable file, they are
definitely combined in one program. If modules are designed to run linked
together in a shared address space, that almost surely means combining them
into one program."
comunque se è proprio come dici, va bene così :)


 dinamicamente.
ok devo aver frainteso in qualche modo... ho risposto in dettaglio a
raffaele.
io a suo tempo ho affrontato il problema con codice php, quindi parlare di
linking è un po' difficile. non trovando risposte sufficienti ho
semplicemente deciso di usare solo codice gpl (perché già ne dovevo usare
per requisiti miei) o compatibile


 into one program."
Link dinamico
:)
Raffaele

 :)
eh, ma appunto!   :(
lì c'è scritto "that almost surely means combining them into one program".  
:(


 :(
E dove sta il problema?
Che io abbia notizia, non c'è mai stata la necessità di compilare
staticamente un programma java... persino con JNI ti limiti ad
implementare un'interfaccia...
IMHO è un non-problema.
Raffaele

 community ora?
Il discorso e` differente. Se la libreria standard viene rilasciata sotto
GPL, allora tutte le applicazioni che la useranno dovranno essere
rilasciate con la stessa licenza (ti lascio immaginare le conseguenze
riguardanti i progetti commerciali che girano attorno a Java). Il discorso
comunque dovrebbe decadere in quanto, da quello che ho letto, Sun
rilascera` Java in _doppia_ licenza (GPL e commerciale) che,
ipoteticamente, le permetterebbe di crearsi un mercato tipo quello di
MySQL
Enrico
P.S. ma a questo punto, le GNU ClassPath spariranno?

 GPL + Classpath Exception
Se non ho capito male, nonostante la licenza sia GPL, e` possibile
utilizzare Classpath per creare delle applicazioni commerciali chiuse,
giusto? Se sara` cosi`, allora ritiro tutto
Enrico

 software non dà garanzie. Non lo dà nessun software.
Oh, ma il problema oramai non e` dare garanzie o meno, il problema e` che
il software commerciale ti mette a disposizione una figura (il produttore)
che nel software free il piu` delle volte non esiste
Enrico


ok, ma se non dà garanzie a cosa serve?
E comunque il produttore esiste comunque, l'opensource non nasce per
generazione spontanea! :-)

:

Io non lo so, ma se dicono che la versione GPL _sostituira'_ le altre mi pare
ovvio che non adotteranno le doppie licenze ...
Quindi o si sono fottuti il cervello o e' possibile scrivere applicazioni
chiuse con la versione GPL.
E' Sun pero', magari si sono fottuti il cervello.
  ngw

 P.S. ma a questo punto, le GNU ClassPath spariranno?
Non credo proprio. A mio avviso nel prossimo futuro avremo almeno 3
scelte:
- openjdk (sun java)
- GCJ+GNUClasspath
- Apache Harmony
Con Apache Harmony in grado di utilizzare, in virtù della sua
struttura modulare, le altre alternative in fatto di VM e classpath.
Raffaele

 giusto?
Ripeto quello che è nelle FAQ:
GPL + Classpath Exception è usata da FSF nel suo Classpath per 
permettere alle applicazioni proprietarie di usarlo.
Sun ha adottato la stessa strategia, GPL + Classpath Exception.
Questa "Classpath Exception" è una clusola in fondo alla licenza GPL, 
tanto per intenderci. Immagino che la si possa mettere solo se si è 
detentori del (C), ma questa è un'altra storia.
Per cui:
"It allows you to link an application available under any license to a 
library that is part of software licensed under GPL v2, without that 
application being subject to the GPL's requirement to be itself offered 
to the public under the GPL."
Insomma, ha lo stesso risultato di una LGPL ma dato che Sun ha scelto la
GPL ha dovuto aggiungere l'eccezione.

 On Mon, 13 Nov 2006 15:25:59 -0800, Ottavio Campana wrote:

Il software commerciale mette a disposizione, per lo più,
l'_assistenza_.
Raffaele

 per le lunghe, và...)
In breve, piu' o meno tutto il linguaggio. La libreria mi piace, la
macchina virtuale pure abbastanza. Quello che e' abbstanza penoso e'
proprio il linguaggio. Manca di flessibilita' e invece che aiutare il
programmatore gli mette i bastoni fra le ruote.  In dettaglio ho
scritto diverse volte cosa non mi piace di Java(lang) in giro per Usenet.
Non saprei se e' il caso di aprire la discussione qui.
-- 
RiK0



non ci capiamo. lì sembra che , sia il link dinamico o statico, *comunque*
si considera "combining them into one program", ergo il problema sussiste.
Comunque, dato che, leggo qui, c'è questa "classpath exception" credo che
non ci siano a questo punto problemi. Meglio così (se adottavano la LGPL
facevano prima, comunque...)


 facevano prima, comunque...)
No, dice "quasi sicuramente". C'è un grosso, grasso "quasi" di
differenza.
E comunque, come già detto, c'è la classpath exception, che salva
capra e cavoli.
Raffaele

 capra e cavoli.
sìsì. bene per l'exception :)


 sìsì. bene per l'exception :)
No, dico...persino Stallman, gran visir di tutti i GNUisti, bin laden
della FreeSoftwareFundation, si è congratulato con la Sun per questa
mossa! Non so se mi spiego! :D
http://www.javalobby.org/java/forums/t84265.html
Raffaele

 La libreria mi piace
Anche l'API di quella libreria? Poi c'è da considerare il fatto che la
libreria è un riflesso del linguaggio, nel senso che molte cose magari
con un altro tipo di linguaggio (e sai a che mi riferisco) non
servirebbe proprio.


 IMHO č un non-problema.
Beh, l'esempio che ho sempre fatto e` quello del tool CLI, e 
redirezione dell'output, la gui non gpl il resto si.
Contravviene alla GPL: devi rilasciare ANCHE la gui sotto gnu. La cosa 
puo` estendersi anche alle VM, la GPL e` troppo vaga in questo senso.
-- 
Sensei <senseiwa@Apple's mail>
Research (n.): a discovery already published by a chinese guy one month
               before you, copying a russian who did it in the 60s.

 
http://www.javalobby.org/java/forums/t84256.html
Qui è spiegato un pò tutto per bene:
http://www.artima.com/forums/flat.jsp?forum=276&thread=184783



non capisco perché non possa esistere anche per l'opensource.


non capisco perché non possa esistere anche per l'opensource.

 non capisco perché non possa esistere anche per l'opensource.
ESISTE, per l'open source. Ma nessuno è obbligato a fornirla,
quest'assistenza.
Quando invece paghi profumatamente un contratto d'assistenza con
qualcuno, questo qualcuno è _obbligato_ a fornirti assistenza secondo
quanto pattuito.
Per dirla breve, se ho un contratto con Red Hat che dice che loro
devono darmi assistenza completa, non possono rispondermi RTFM...
Raffaele


Senti, mi sembra che la possibilità di avere un contratto di assistenza
non dipenda dalla licenza del software. Non credo che nessun software,
libero o proprietario,obblighi il venditore a fornire un contratto di
assistenza.....
Vogliamo parlare di windows? :-)

 Vogliamo parlare di windows? :-)
Ma anche no! Bleah!
Raffaele, che vuole sto dannato linux sul suo portatile aziendale...

 Raffaele, che vuole sto dannato linux sul suo portatile aziendale...
e che problemi hai? :-)

 e che problemi hai? :-)
Che devo intortarmi un pò sistemisti e superiori. Purtroppo lo
standard per le workstation è windows xp e/o 2000.
Raffaele

 standard per le workstation è windows xp e/o 2000.
una ubuntu che gira live dal cd di installazione? ;-)

 una ubuntu che gira live dal cd di installazione? ;-)
mmmm...dovrei mettermi su un ambiente di sviluppo Oracle in una distro
live...che per carità, dovrebbe girare tutto, ma sai che
sbattimento...
Però l'idea non è proprio da buttare...ora che mi hai messo la pulce
nell'orecchio...
Raffaele

 puo` estendersi anche alle VM, la GPL e` troppo vaga in questo senso.
Io direi che hai sempre fatto un esempio clamorosamente sbagliato. Se
cosi` fosse, anche l'output di GCC dovrebbe essere rilasciato sempre e
solo sotto GPL (e cosi` non e`)
Enrico

 generazione spontanea!
Il produttore esiste, ovvio. Il problema e` che molte volte e` composto da
n+1 persone sparse per il mondo, e che nessuno di loro ha il tempo o la
voglia di fare supporto (prendi ad esempio Firebird, il cui supporto e`
delegato a IBPhoenix). Tieni presente che molti progetti open source
validi e funzionanti sono tenuti in piedi da persone che lo fanno solo
perche` gli piace, e non perche` pensano di guadagnarci qualcosa
Enrico

 cesso...ma le Forms fan venire l'orticaria...), per dirne una.
Non per fare il solito puntiglioso, ma Oracle in determinati ambiti e`
ancora imbattibile. Per quanto riguarda Oracle Forms[1], beh, penso che
oramai Oracle debba tenerlo in piedi solo per supporto alle aziende che lo
usano ancora (a noi una volta ce lo hanno chiesto espressamente)
Enrico
[1] Per chi e` curioso, fatevi un favore, _NON_ cercate informazioni su
questo prodotto

 perche` gli piace, e non perche` pensano di guadagnarci qualcosa
bah, io vedo postgresql e il supporto che viene erogato nelle mailing list.

 Contravviene alla GPL: devi rilasciare ANCHE la gui sotto gnu.
ti prego, qualunque cosa tu stia fumando: tagliala con del tabacco.
poi, quando avrai smaltito, scopri la differenza tra input/output di un
programma e derivative work.
ciao,
 Emmanuele.

 bah, io vedo postgresql e il supporto che viene erogato nelle mailing list.
Il supporto erogato e` un supporto _amatoriale_ e non professionale. Dire
ad una azienda "sottoscrivi la mailing list" significa essere derisi fino
alla fine dei giorni
Enrico


Nel caso di PostgreSQL il supporto derivante dalle mailing list è 
tutt'altro che amatoriale...
E' così buono che una azienda ha dovuto rinunciare al business della sua 
offerta di supporto:  
http://lwn.net/Articles/193740

 offerta di supporto:  
http://lwn.net/Articles/193740
Volendo puň anche pagare per il supporto:
http://www.postgresql.org/support/
trovando digitando "postgresql support" su google. Primo risultato.


 servirebbe proprio.
Vero anche questo. Come in effetti alcune parti (tipo quelle che
riguardano la programmazione generica, parecchio penosa), non mi
piacciono.
Ma complessivamente, al di la di certe over-ingegnerizzazioni, le cose
non sono malaccio. In confronto al linguaggio, un paradiso.
-- 
RiK0

 solo sotto GPL (e cosi` non e`)
No, non e` cosi`. Riprendi un poco i post sul discorso... La questione 
e` che nella GPL c'e` scritto che i pezzi "sufficientemente" collegati 
sono da rilasciare GPL. Cazzarola mica e` la prima volta che lo faccio 
notare! :)
``These requirements apply to the modified work as a whole. If 
identifiable sections of that work are not derived from the Program, 
and can be reasonably considered independent and separate works in 
themselves, then this License, and its terms, do not apply to those 
sections when you distribute them as separate works. But when you 
distribute the same sections as part of a whole which is a work based 
on the Program, the distribution of the whole must be on the terms of 
this License, whose permissions for other licensees extend to the 
entire whole, and thus to each and every part regardless of who wrote 
it.''
Mi spieghi il ``reasonably considered independent and separate works in 
themselves''?
Ovvero l'esempio mio GUI-CLI con stdio e` reasonably considered 
independent, oppure no? E chi lo stabilisce? E in base a che criterio?
Ho detto che c'e` una vaghezza della definizione, e mi pare di non sbagliare.




Se non sei un troll, prendi la risposta ad Emmanuele.


 Se non sei un troll, prendi la risposta ad Emmanuele.
forse volevi dire enrico :D


 Ho detto che c'e` una vaghezza della definizione, e mi pare di non sbagliare.
la vaghezza ce l'hai infilata tu a forza, ignorando una parola e, quel
che è peggio, il contesto.
se modifichi le premesse per avere ragione allora ti sarà davvero
difficile non avere ragione.
ciao,
 Emmanuele.

 forse volevi dire enrico :D
Mi si nomina in vano?
-- 
RiK0

 difficile non avere ragione.
L'esempio sopra fatto e` abbastanza per capire quanto sia vago. Cosa fa 
la mia GUI un prodotto derivato?
C'e` la parolina *ANY* per i derivati (any derivative work):
The "Program", below, refers to any such program or work, and a "work 
based on the Program" means either the Program or any derivative work 
under copyright law: that is to say, a work containing the Program or a 
portion of it, either verbatim or with modifications and/or translated 
into another language.
Leggi sull'output cosa dice:
[...] The act of running the Program is not restricted, and the output 
from the Program is covered only if its contents constitute a work 
based on the Program (independent of having been made by running the 
Program). Whether that is true depends on what the Program does.
A me non pare chiaro come il sole se una GUI closed source per un 
programma GPL e` possibile o e` in violazione della liceza. Le librerie 
e` chiaro a tutti. Ma per l'output?
Qualcuno mi da una spiegazione facile, con i passaggi della GPL in cui 
si dice che io non infrango la legge e la FSF mi denuncia come 
manipolatore del popolo?


 manipolatore del popolo?
non c'è "spiegazione semplice": c'è la spiegazione legale.  è stato
chiesto (in mia presenza) ed è stato risposto che l'output e l'input di
un programma GPL non sono per magilla GPL.
se vuoi essere sicuro, però, non chiedi qui su ICOD perché non c'è
nessuno che ti può dare un parere legale: chiedi a eben moglen.  questo
si applica, ovviamente, anche a tutti i thread sulle licenze che sono
passati di qui negli anni, in cui geek si davano battaglia su testi che
non sono stati scritti da geek per geek.
ciao,
 Emmanuele.

 Mi si nomina in vano?
Non direi, copione di nomi :)
Enrico

 fa il front-end - per la stessa definizione di front-end.
Do per assodato quindi che una GUI di per se non puo` essere 
considerato un derivative work. O almeno, spero tu abbia ragione...


 considerato un derivative work. O almeno, spero tu abbia ragione...
Si parlava di frontend a un tool. La GUI può essere derivative work,
dipende da cosa "derivi"


 considerato un derivative work.
non ho mai detto questo.
un *front-end* non può essere considerato un derivative work del tool di
cui fa il front-end - a meno che uno dei due non contenga del codice
dell'altro; questo caso non avviene se entrambi sono stati sviluppati in
una clean room.
ciao,
 Emmanuele.

 independent, oppure no? E chi lo stabilisce? E in base a che criterio?
E` considerato indipendente in quanto la GUI che fa da frontend al CLI
utilizza l'output di quest'ultimo per funzionare. Se seguissimo il tuo
ragionamento, allora anche un'immagine creata con GIMP dovrebbe essere
rilasciata sotto licenza GPL
Enrico

 offerta di supporto:  
http://lwn.net/Articles/193740
Ok, PostgreSQL ha una mailing list a livello professionale[1], quanti altri
progetti open source possono dire la stessa cosa?
Enrico
[1] fino ad un certo punto. Tieni presente sempre che le aziende una
mailing list non la percepiscono come supporto professionale ad un software

 progetti open source possono dire la stessa cosa?
Non lo so, io ti ho solo fatto notare che nel caso di PostgreSQL non si 
può dire che abbia un supporto amatoriale.

 non capisco perché non possa esistere anche per l'opensource.
Perchè per esempio per l'opensource non c'è nessuno che paga un omino
per partire e venire fino da te a risolvere un problema software. Con
Oracle, IBM, et similia, puoi fare contratti d'assistenza che prevedono
tale evenienza.
Con l'open source puoi trovare magari una mailing list, o simile.
Ma per avere una persona esperta che venga da te a risolverti i
problemi, o trovi un freelance, oppure ti rivolgi ad un'azienda che si
accolli la responsabilità di fornire tale assistenza.
e sia chiaro, io supporto l'open source, ma quel che l'è, l'è:
l'assistenza operativa, per l'open source, è difficilissima da
trovare, anche pagando, mentre per prodotti commerciali closed è
molto, ma molto più facile da ottenere (pagando...).
E sottolineo OPERATIVA.
Raffaele

 tale evenienza.
Se e' per quello puoi farli anche con RedHat o SuSE, per dirne due.
-- 
RiK0

 una clean room.
Mmh... ok. L'importante quindi e` non linkare in modo alcuno i 2 
progetti se non con stdio, giusto?


 dipende da cosa "derivi"
Semplice stdio. L'output di un comando, una gui per tar ad esempio.


 rilasciata sotto licenza GPL
Beh la mia e` piuttosto paura, visto che l'interpretazione di 
derivative work puo` variare nel tempo ed in base agli avvocati. Anche 
l'idea di offesa varia, e quindi metto le mani avanti nel piu` strano 
dei casi.


 Se e' per quello puoi farli anche con RedHat o SuSE, per dirne due.
Comprai SuSE per 2 distribuzioni (9.2 e 9.3) e devo dire che sono stati 
peggio di MS per il supporto. Purtroppo.


 Semplice stdio. L'output di un comando, una gui per tar ad esempio.
Direi di no.


 Se e' per quello puoi farli anche con RedHat o SuSE, per dirne due.
Mosche bianche. Ed è comunque un fenomeno che sta iniziando ad avere
un senso solo ora, quanto a qualità dell'offerta.
Raffaele

 progetti se non con stdio, giusto?
se esistono librerie in comune tra i due si applicano le licenze delle
librerie in comune.
ma, e ripeto un'ultima volta: se vuoi essere *sicuro* chiedi a un
legale, non su ICOD.
ciao,
 Emmanuele.

 Semplice stdio. L'output di un comando, una gui per tar ad esempio.
   Credo proprio di no: la GPL non impedisce ad un programma non GPL di
chiamarne uno GPL, anzi mi pare sia l'unica interoperatibilità
"concessa"...
-- 
                          |
\|/ ____ \|/   \ ||_|     |   Ogni viaggio, anche il piu` lungo
"@'/ ,. \`@"    \|| |     |   inizia con il primo passo...
/_| \__/ |_\ Vax Headroom |
   \__U_/                 |