sabato 15 dicembre 2007

Libbertà



Quanno m’accorsi d’esse prigioniero
Cor laccio ar piede in mano a un regazzino
Non c’ebbi che n’pensiero, de rivolà in giardino
[Er grillo zoppo - Trilussa]


Una volta, purtroppo, era più facile definire cosa fosse la libertà.
Forse perchè, quando si ha un piede straniero sopra il cuore, il peso si sente anche senza stare a pensarci.
Poi la situazione è migliorata e si è potuto distinguere tra la libertà da (beneficiario un popolo) e la libertà di (beneficiario il singolo).

Ci sta una libertà anche un po' più egoistica, un po' meno quando si usa lo stesso termine per scopi marketing, o per gridare il diritto di poter fotografare la privacy altrui, o per difendere la libertà di opprimere.

Tra gli estremi si posiziona, a mio modo di vedere, il software libero.

Il che ci riconduce (con un salto triplo degno del peggior telegiornalista che cerca di passare da un crudo fatto di cronaca nera alla rubrica settimanale di gastronomia) alla fine del post precedente, in cui accennavo al modello di business di un software libero come Daz Studio.

Ricordate che vi avevo minacciati di parlare di licenze Open Source e modelli di business?
Ricordate il finale di Hotel California, You can check out any time you like, but you can never leave? Fino a che punto siete veramente liberi di non cliccare sul link Leggi Tutto?

Credete che io possa riuscire mai ad annichilire ulteriormente la mia già scarsa immagine di scrittore, continuando con queste penosissime introduzioni?


Ricorderete certamente (non metto il link al post precedente perchè dovreste vergognarvi anche al solo pensiero di scherzare sulla possibilità di non averlo ancora letto) che il modello di business di Daz Studio e compagnia bella si basa sulla rivendita di modelli grafici 3D pre-realizzati (più o meno come qualche altro migliaio di siti di grafica, con la differenza che, essendosi creati loro il programma sono in vantaggio, perchè posseggono un forte catalizzatore e una forte leva marketing).

Diventa interessante, confrontarlo, molto brevissimamente, con altri modelli di business basati sull'Open Source (free as freedom, not price, ci rammentano fin da piccoli dalla Free Software Foundation (FSF)):
  • pubblicità/marketing (personale e per terzi - sempre basato sui grandi numeri)
  • consulenza/servizi/corsi sui propri ed altri prodotti (cross-selling, tenendo presente che, con l'Open Source si abilitano alcuni mercati - es.: le linee strategiche per l'e-government prevedono, al punto 6, un incremento la diffusione e la utilizzazione di soluzioni Open Source e da tempo esiste un osservatorio Open Source; per certi versi è come se l'Open Source venga a costituire una sorta di certificazione, simile a quelle della qualità - su quest'onda nasce il marchietto dell'OSI, che si propone internazionalmente per censire le varie licenze open source). Tra i vari modi di far pagare i servizi trovo interessante la proposta di proporre un supporto a contributo volontario, che potrebbe anche portare ad uno sviluppo Open Source ben più orientato e goal-driven (variante come minimo da indagare, direi - l'ho vista usare, almeno, da ATutor, un sistema per l'e-learning basato su GPL) [Consulting e Subscription Strategy]
  • dual licencing: per scopi commerciali, una licenza commerciale affianca quella open (così si 'vende' anche il prodotto e non solo i servizi collegati, da un lato risparmiando in marketing e sulla rete commerciale, rispetto ad un prodotto 'classico') [Dual Licence Strategy]
  • vendita di estensioni, moduli o, comunque, feature a valore aggiunto non presenti nella parte Open Source del prodotto (up-selling); facilitato dalla natura elettronico/informatica (non fisica) del prodotto
  • vendita di accessori o prodotti correlati: non solo libri, manuali e CD sull'argomento, ma anche magliette, tazze ed altri accessori di questo tipo
  • supporto volontario al servizio (particolarmente efficace per servizi di altissimo livello e con grandissimo seguito come quelli forniti da Sourceforge o dalla Wikipedia)

Casomai dovesse interessarvi approfondire questo primo riassunto, sopra, tra parentesi quadre ho indicato nomi di strategie utilizzati in un bellissimo (anche se un po' datato) articolo di IT Manager's Journal, che aggiunge anche le strategie di Optimization, Patronage, Hosted ed Embedded, decisamente più adatte (soprattutto la seconda) ad aziende di una certa dimensione e brand. Se vi avanza tempo, potrebbe interessarvi anche la presentazione di Tim O'Reilly relativa ai design pattern nei business model Open Source (non così fondamentale come altri testi dello stesso autore, peraltro).

Di fatto, il modello di business utilizzato da Daz si configura quasi come una vendita di estensioni: solo, mentre i moduli aggiuntivi di un prodotto si venderanno a pochi clienti selezionati, con costi relativamente elevati, le estensioni di questo tipo avranno come target la massa e potranno mantenere un prezzo basso.

Da notare che una variante interessante (non facilissima da applicare a prodotti impalpabili come quelli informatici e, in particolare ai modelli grafici, almeno in prima istanza) può essere quella di far leva sulla mania di collezionismo: si comprano pacchetti chiusi e si trovano, con diversa probabilità, oggetti 'confezionati' randomicamente (per chi avesse giocato a Magic the Gatheringo simili dovrebbe essere molto chiaro). Non ho esempi a questo proposito, non ne ho trovati, se ne conoscente segnalatemeli.

Con un modello di business basato sulla vendita di gadget o librerie, si evita pure il problema che mi sta capitando nel cercare di trovare un modo di affibbiare ad un mio sistema una licenza Open Source GPL v3 (la GPL è la licenza che più di tutte permette di supportare il dual licencing affiancando una licenza commerciale ad una Open Source e la versione 3 è particolarmente interessante per la compatibilità con altre licenze libere, Apache 2.0 in particolare e per la protezione nei confronti di chi volesse tentare di imporre eventuali brevetti su quanto è stato realizzato).

Forse vi sto per dire una banalità e vi annoierete (ma spero, invece, che vi cada la mascella per lo stupore come è capitato a me), ma mi è recentemente capitato di notare con disappunto che, sotto certe condizioni e pur utilizzando parti di software libero, è più facile rilasciare un prodotto software con una licenza commerciale che con la GPL.

Infatti le licenze, anche quelle libere, in quanto oggetti legali possono essere incompatibili tra loro, come ci ricordano i tipi della GNU (abbastanza ovviamente il link precedente è un approfondimento GPL-centrico: sarebbe interessante avere una sorta di matrice, tra le licenze più diffuse, ma non l'ho trovata).

Lo stupore cresce quando vi accorgete che le licenze di SUN non sono compatibili con la GPL.

Lo ridico in un altro modo: Java (di SUN - spiego dopo questa apparentemente curiosa precisazione) e GPL (fino al 13/11/2007) non potevano convivere.

Lo ridico ancora: Stallman si è espresso almeno due volte a proposito di quella che lui chiama Java Trap, tra il 2004 ed il 2006, evidenziando come programmi basati su Java (di SUN) non possano essere legalmente anche licenziati con la GPL.

Perchè la precisazione di prima (Java di SUN)? ne esistono altre? Certo, Java come specifica non pone vincoli, li pone la licenza con cui viene rilasciata l'implementazione. E la licenza di SUN, per quanto riconosciuta dalla fsf come libera, non è compatibile con GPL.

Le implementazioni alternative sono almeno 2: GNU Classpath, suggerito da Stallman ed il più recente Apache Harmony. Essendo implementazioni basate su licenze Open Source compatibili con la GPL, se riuscite a compilare il vostro sistema usando le loro librerie e compilatori, ok, siete salvi, potete rilasciare il vostro programma Java sotto GPL.

Purtroppo, allo stato attuale, sono implementazioni ancora parziali (per fare un esempio, il mio sistema non è ancora compilabile con questi due pacchetti - sto verificando come sostituire i metodi non implementati con altri, ma devo ancora capire bene se il gioco valga la candela).

Una breve parentesi: GNU Classpath si ferma alle specifiche della JDK 1.4, mentre Apache Harmony parte dalla compatibilità con la 1.5. Vedete voi cosa più vi serve (spero per voi che sia la 1.5 o la 1.6, ovviamente).
Inoltre con Apache Harmony potete farci sostanzialmente ciò che vi pare (licenza Apache 2.0), compreso commercializzare il vostro prodotto; con GNU Classpath, invece, non ne sono sicurissimo (il testo è ambiguo, la spiegazione sembra più possibilista - se riuscite a capirlo voi, con un ragionevole livello di certezza, fatemi un fischio): si basa su GPL (quindi, tutto ciò che tocca dovrebbe diventare GPL), ma con una eccezione che permette di linkare altri moduli, senza farli diventare GPL.

Certamente, lo so, l'ho detto prima, è inutile che continuiate a bisbigliare: esiste un'altra possibilità, dal 13/11/2007 Java è stato annunciato con licenza GPL (qualche commento di Goslin a questo proposito). Ne hanno parlato tutti, ci mancherebbe altro che fosse sfuggito un particolare così importante.

Purtroppo, almeno per i miei scopi, non va mica tanto bene. La scelta di SUN riguarda la licenza GPL v2, non la GPL v3. Ci sono, almeno, le seguenti controindicazioni:
- GPL v2 e GPL v3 sono incompatibili tra loro: quindi, tutta la parte relativa ai brevetti non sarebbe applicabile
- molto peggio, GPL V2 e licenza Apache non sono compatibili tra loro (mentre GPL v3 e Apache, sì): quindi non potrei utilizzare, nel mio sistema, tutte quelle belle librerie che uso
- ancora peggio: usando Java licenziato GPL v2 il vostro sistema diventerebbe GPL v2 anche lui e non sarebbe applicabile il dual licencing con licenza commerciale, non essendo il primo della cordata

Acc.... ma scusate, non ci sono programmi Java licenziati sotto GPL?
E come fanno? Ricevono lettere di cause dalla FSF in continuazione?
O so basano su zone grigie di interpretazione (tipo quella per cui, secondo l'Apache Foundation già la GPLv2 era compatibile con la licenza Apache 2.0, mentre secondo la FSF no)?

Vi devo chiedere di smetterla di deviare continuamente in parentesi inutili, e di cercare di concentrarvi sul punto fondamentale: come faccio a risolvere il mio problema?

Con lincenze BSD o MPL? No, troppo libere, io sono uno di quelli che 'non sopportano l'idea che altri possano vendere il mio sistema': anche un commerciale normodotato (cosa che io non sono, io sono la versione seria del signor Spock di Star Trek) potrebbe piazzare nel tempo libero il mio sistema e questo non mi potrebbe mai andare giù, dopo i miei inutili tentativi.
Prendendo spunto dalla GPL e aggiungendo varianti che permettano l'uso di librerie free? No, potrebbe essere complesso, non sono un legale, diventa un casino, ci vuole un attimo a sbagliarsi e a renderla troppo o troppo poco flessibile (pensate solo a quanto tempo e risorse ci hanno messo a variare la GPLv2 per farla diventare GPLv3).

Queste cose le dico per voi, per evitare che vi troviate con un bellissimo sistema (il più bello di tutti, ovviamente), basato su librerie Open Source, senza poter sfruttare la distribuzione free, perchè potreste rischiare di infrangere una o più delle licenze.
Non voglio che rischiate di dover rivedere le librerie di base del vostro sistema e di dover adattare parti del codice con ulteriore effort, a fronte di nessuna aggiunta in funzionalità (ulteriori costi, per voi), solo perchè non siete stati abbastanza lungimiranti all'inizio del progetto.
Non voglio rischiare io di rompermi le balle a leggere un lamento lungo un post sul vostro blog, scritto per sfogare il vostro disappunto e per chiedere inutilmente a Stallman e compagni se non sia il caso di ripensare un po' i vincoli della libertà, come già suggerito diverso tempo fa dallo stesso poeta con cui abbiamo iniziato questo post:

La libbertà [...]
se c'è chi la guida e la riduce
e l'incanala verso l'officina,
appena arriva smove la turbina,
diventa forza e se trasforma in luce.
[...]
Ma quanno l'acqua ha smosso ner cammino
una centrale elettrica o un mulino,
se canta o se barbotta, nun è male
lassaje un pò de sfogo naturale!
[La libbertà - Trilussa]

Bye
    Depa
P.S.: le mie scuse a Trilussa, per la leggera forzatura ed anacronismo dell'ultima citazione. Non credo di averne invertito o travisato completamente il senso, ma sono conscio di averlo allontantato un po' dall'originale intenzione.
P.P.S.: a Stallman e compagni: tranquilli, non sentitevi in obbligo di affrettarvi con un commento a questo post, la risposta la capisco da solo e comprendo la posizione, anche se la condivido solo parzialmente.
P.P.P.S.: prometto che smetto, ma non potevo non ricordare anche questa strofa, perchè su questo argomento non può che farmi bene anche un po' di autocritica:
La libertà non è star sopra un albero,
non è neanche il volo di un moscone,
la libertà non è uno spazio libero,
libertà è partecipazione
[La libertà - Gaber]


6 commenti:

Ugo ha detto...

Percepisco una certa confusione:

"Stallman si è espresso almeno due volte a proposito di quella che lui chiama Java Trap, tra il 2004 ed il 2006, evidenziando come programmi basati su Java (di SUN) non possano essere legalmente anche licenziati con la GPL."

Assolutamente no. Stallman non ha mai sostenuto una cosa del genere, semplicemente perchè non è vera. Quello che Stallman dice è che se usate features di Java che esistono solo nella implementazione di Sun, il vostro programma potrebbe non girare su una piattaforma interamente free. Ciò non implica nulla, tantomento "legalmente", a proposito della licenza del vostro codice.

"usando Java licenziato GPL v2 il vostro sistema diventerebbe GPL v2 anche lui e non sarebbe applicabile il dual licencing con licenza commerciale, non essendo il primo della cordata"

Ancora no. Puoi scrivere codice Java e licenziarlo sotto _qualunque_ licenza, free, non-free, open o closed, non importa. Quello che _non_ puoi fare è rilasciare una versione modificata di OpenJDK sotto una licenza non free. Il tuo programma scritto in Java lo puoi rilasciare come ti pare.

"Acc.... ma scusate, non ci sono programmi Java licenziati sotto GPL?
E come fanno? Ricevono lettere di cause dalla FSF in continuazione?
O so basano su zone grigie di interpretazione (tipo quella per cui, secondo l'Apache Foundation già la GPLv2 era compatibile con la licenza Apache 2.0, mentre secondo la FSF no)?"

Per l'appunto. Lo fanno perchè possono farlo, non violano nessuna licenza. Un programma scritto in Java non è un "derived work" del JDK di Sun, di GNU Classpath o di alcuna altra implementazione di Java, a meno che non duplichi parti di codice sotto copyright Sun, FSF o di altrii. Infatti esistono programmi Java distribuiti sotto GPL, CDDL, MPL, EPL, AL, qualunque licenza OSI-approved o sotto licenze commerciali. E nessuno si stupisce di questo o si attende di ricevere la lettera di un legale.

Dirò di più: puoi rilasciare il tuo programma sotto GPL v2 o v3 includendo codice rilasciato sotto AL e nessuno si scandalizzerà. Non puoi invece rilasciare sotto AL o comunque una licenza BSD-like un sw derivato da codice GPL v2.

Ugo

P.S.: quando la pianti con Blogger? Sta merda di sistema adesso pretende che posti un commento usando il mio Blogger account (maledetto il giorno che mi sono registrato) o come anonimo.

Depa ha detto...

Ugo,
inizio dal fondo: non cambierò questo blog di piattaforma (almeno non a breve), anche se sto valutandone altre (Wordpress, in particolare) per altri, sempre miei, blog (che non ho ancora il tempo di aprire, ma spero di riuscire a farlo all'inizio dell'anno prossimo). Comunque, Blogger non pretende che tu usi il tuo Blogger account, ma ti lascia scegliere una identità o utilizzare un account diverso (c'è un link apposito, sotto al box per i commenti). Io lo uso per postare commenti su altri blog, in modo che non risulti il posting nè come anonimo, nè come Blogger account, ma con i classici 3 campetti di nick, mail e url.

Veniamo al resto.
Vorrei veramente aver fatto confusione e spero che tu possa chiarirmi un po' di cose, che non mi convincono ancora dal tuo commento.

E' vero che in nessuno dei due articoli Stallman dice chiaramente ed esplicitamente che usare Java di SUN con licenza GPL è illegale. Ma è anche vero che dice (prendo dal primo link):
- Sun's implementation of Java is non-free. The standard Java libraries are non-free also.

Se segui l'altro link da me proposto 3 paragrafi prima, quello che ti porta sulla compatibilità delle licenze secondo GNU (e compatibilità, in quel contesto è intesa come compatibilità legale), questo concetto viene espresso più chiaramente:
le licenze SUN sono tutte considerate free, ma non compatibili, quindi non usabili legalmente insieme alla GPL.
La matrice di compatibilità riporta una posizione già più morbida di quella degli articoli che ho citato prima, perchè Stallman dice chiaramente, come riportavo sopra, che l'implementazione di SUN è non-free: se prosegui nel verificare cosa dice ufficialmente la FSF a proposito delle compatibilità, trovi questa frase (è nella prima riga sotto l'heading "Non-Free Software Licences"):
A non-free license is automatically incompatible with the GNU GPL

Quindi, anche se ci gira attorno, in quei due articoli Stallman sta veramente dicendo, per quanto io capisco, che le licenze SUN sono incompatibili con GPL (ai tempi v2). Sarei ben contento se tu riuscissi a spiegarmi come interpretare differentemente queste righe.

Ancora, dalle FAQ:
You have a GPL'ed program that I'd like to link with my code to build a proprietary program. Does the fact that I link with your program mean I have to GPL my program?
Yes.

e, altra FAQ (l'enfasi è mia):
In an object-oriented language such as Java [Nota mia: proprio l'esempio che ci serve!], if I use a class that is GPL'ed without modifying, and subclass it, in what way does the GPL affect the larger program?
Subclassing is creating a derivative work. Therefore, the terms of the GPL affect the whole program where you create a subclass of a GPL'ed class.


Quindi, quando dici:
"Puoi scrivere codice Java e licenziarlo sotto _qualunque_ licenza, free, non-free, open o closed, non importa. Quello che _non_ puoi fare è rilasciare una versione modificata di OpenJDK sotto una licenza non free. Il tuo programma scritto in Java lo puoi rilasciare come ti pare."
non riesco a capire su cosa ti basi per sostenerlo: se il mio programma usa classi che posso trovare sotto altre implementazioni sono d'accordo con te (ed è il contenuto del mio post), ma per le FAQ riportate sopra, se esiste solo nell'implementazione di SUN (che poi è quanto dico nel resto del post), o uso licenza SUN e NON posso rilasciarlo (piuttosto esplicitamente, da quanto leggo) sotto GPL perchè incompatibili, come precedentemente mostrato, o uso la licenza GPLv2 e
devo rilasciare il tutto sotto licenza GPLv2 (ma senza possibilità di dual licencing, perchè non sei il primo della cordata), come da ultima FAQ riportata (quindi non _qualunque_ licenza: per es., non GPLv3, che compatibile non è - sempre stesso link di compatibilità fornito da FSF - non Apache, qualunque versione - la GPLv2 NON era compatibile con quelle licenze, quindi non rilasciabile legalmente sotto quelle licenze e uno dei risultati più importanti della v3 è stato proprio quello di poter essere compatibile con Apache 2.0, - etc. etc.).

In particolare, come scrivevo, non potrei applicare dual licencing con licenza commerciale.

In particolare, quando dici: Lo fanno perchè possono farlo, non violano nessuna licenza. Un programma scritto in Java non è un "derived work" del JDK di SUN sei sull'interpretazione limite: chiaramente le FAQ riportate dicono che è un "derivative work" di una libreria Java, resta da capire quale.

Il che ci porta ancora alla mia precedente interpretazione: se riesci a farlo girare anche sotto uno solo dei Java con licenza compatibile con GPL (GNU Classpath o Apache Harmony) ok, facendo sempre attenzione alle compatibilità, altrimenti funzioni solo con SUN, cadi nella trappola di Stallman, non sei più free, non sei più GPL compatibile. Legalmente.

Io spero (e non mi interessa verificarlo) che tutti i programmi Java-GPL in giro rispettino queste condizioni un po' contorte, ma avendo visto l'elenco delle classi e metodi finora implementati nelle implementazioni Apache e GNU, è un bel lavoro di fino, starci dentro.

Alternativamente, spero di aver capito male qualche passaggio e spero che tu - o altri, beninteso, Stallman compreso - riesca a darmi una interpretazione che riesca a spiegarmi come, nonostante tutti i testi riportati, si possa fare un sistema GPL in Java, senza dover fare uno slalom tra i metodi.

Ugo ha detto...

"Quindi, anche se ci gira attorno, in quei due articoli Stallman sta veramente dicendo, per quanto io capisco, che le licenze SUN sono incompatibili con GPL (ai tempi v2). Sarei ben contento se tu riuscissi a spiegarmi come interpretare differentemente queste righe."

Certo che le licenze Sun (JDK BCL http://java.sun.com/j2se/1.5.0/source_license.html in questo specifico caso) sono incompatibili con GPL. Non puoi _combinare_ codice BCL e GPL in un unico programma e distribuirlo sotto BCL o GPL.

Ma se leggi bene la BCL, in nessun punto dice che il codice che tu scrivi usando il JDK debba per forza essere distribuito a sua volta sotto BCL. La licenza non è "virale".

"Subclassing is creating a derivative work. Therefore, the terms of the GPL affect the whole program where you create a subclass of a GPL'ed class. "

Ma in questo caso non fai subclassing di una classe GPL, bensì di una classe BCL, e la BCL non parla di derivative work e non dice che un eventuale derivative work debba essere distribuito sotto particolari condizioni. Se così fosse non sarebbe nemmeno possibile scrivere sw proprietario in Java.

Derivando invece da codice GPL, le cose sono completamente diverse, perchè l'intento della GPL è esplicitamente quello di evitare che codice GPL possa essere esteso per scrivere codice non-free. Ma non è il tuo caso.

Le FAQ che tu citi si applicano a codice derivato da codice GPL, non dal codice contenuto nel JDK, che non è distribuito sotto GPL. Quindi le tue paure sono completamente infondate.

Spero che ora la questione ti sia un po' più chiara.

Depa ha detto...

Ugo,
mi piacerebbe che la fosse, ma temo che mi manchi ancora un pezzo.
Provo a riassumere il tuo ragionamento.

1. se io scrivo codice Java, sto producendo un derivative work della BCL, che mi permette di usare la licenza che io preferisco (GPL compresa) per il mio codice. Fin qui ok, nessun vincolo lato Java, mai avuto dubbi in proposito
2. Quindi io posso rilasciare il mio codice sotto GPL (qui un po' meno d'accordo, il quindi non dipende solo da BCL, ma anche da GPL, ci torno tra un po')
3. A questo punto, casomai qualcuno estendesse il mio codice, sarei tranquillo, il suo diventa GPL, perchè dal punto 2 in avanti, tutto è GPL. Anche su questo punto mi trovi perfettamente d'accordo.

L'intera seconda parte del mio post si basa sul dubbio che sollevo relativamente al punto 2 del tuo commento.

Da cosa deriva questo dubbio (che sarei ben lieto di eliminare)?

Estratto dalla sezione di definizioni della GPLv3 (ammetto che in GPLv2 sembra non essere così forte, ma solo perchè non era definito bene il concetto di source code come in GPLv3 - al solito l'enfasi è mia):
The "Complete Corresponding Source Code" for a work in object code form means all the source code needed to understand, adapt, modify, compile, link, install, and run the work, excluding general-purpose tools used in performing those activities but which are not part of the work. [...]For example, this includes any scripts used to control those activities, and any shared libraries and dynamically linked subprograms that the work is designed to require

Quindi, GPL tra i suoi prerequisiti sembra (almeno a me, spero sempre di sbagliarmi) che stia richiedendo, nel caso specifico di Java, di rilasciare i sorgenti anche delle librerie Java che linko (da java.lang.Object in giù).

Ovvero: BCL mi permette di rendere GPL il mio codice, ma GPL me lo nega come prerequisito, se io linko librerie BCL.

C'è una FAQ esplicita anche su questo (enfasi mia):
What legal issues come up if I use GPL-incompatible libraries with GPL software?
If the libraries that you link with fall within the following exception in the GPL:
However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

then you don't have to do anything special to use them; the requirement to distribute source code for the whole program does not include those libraries, even if you distribute a linked executable containing them. Thus, if the libraries you need come with major parts of a proprietary operating system, the GPL says people can link your program with them without any conditions.


Ora, purtroppo, le librerie di Java non rientrano (in una interpretazione stretta, forse, ma non sono un legale e non me la sentirei di rischiare un tentativo in questo senso) nella casistica qui indicata. Tieni presente che ho pure inviato una domanda esplicita alla FSF per interpretare il tutto e per capire bene i limiti, ma mi è solo arrivata mail dall'autoresponder che dice che loro ne hanno fin troppe da seguire e, se lo trovo sulle FAQ non risponderanno mai).

Vero è (e ti ringrazio, perchè senza gli approfondimenti richiesti per rispondere a questi commenti non me ne sarei accorto,l'ho visto ora) che la stessa risposta continua:
If you want your program to link against a library not covered by that exception, you need to add your own exception, wholly outside of the GPL.
Segue esempio, ma mi ci vorranno 2 giorni per capirlo, a senso.

Ovvero: sembra che si possa fare fare, ma con una modifica, non con il testo base/standard della licenza (non era, quindi, così scontato!)

Sembra una sorta di FLOSS Exception di MySQL, ma sulle librerie __già__ linkate dal programma, non su quelle linkabili, anche se non vedo ancora bene dove stia la differenza, nel testo.

Resta la domanda provocatoria: i vari GPL Java-based già esistenti riportano una simile eccezione che cita le librerie di Java?

Attendo comunque un tuo commento, per capire se ti torna o se pensi che io abbia capito male e si possa fare anche senza questa special exception.

Ugo ha detto...

Non so dove ti abbia trovato quel testo. La versione definitiva è leggermente (http://www.gnu.org/licenses/gpl-faq.html) differente. Per esempio dice solo "Corresponding Source Code" e non anche "Complete". E dice esplicitamente che questo Corresponding Source Code "does not include the work's System Libraries".

Nella FAQ inoltre c'è un punto (la domanda è relativa a Windows ma si applica tranquillamente anche a Java) che dice:

"The GPL permits this because that run-time library normally accompanies the compiler or interpreter you are using. So it falls under the exception in GPL section 3."

Quindi la run-time library di Java, che accompagna normalmente l'interprete (e infatti è distribuita sempre unitamente a JRE e JDK) fa eccezione alla definizione del Complete Source Code.

Dice anche "That doesn't mean it is a good idea to write the program so that it only runs on Windows. Doing so results in a program that is free software but “trapped” (in this case, trapped by Windows instead of by Java, but the effect is the same)."

Quindi è legalmente permesso, ma non è una buona idea per i motivi discussi nell'articolo di Stallman sulla "Java trap".

A me sembra chiarissimo, così come è chiarissimo alle migliaia di persone che distribuiscono codice Java sotto GPL.

Ugo

Depa ha detto...

C'è voluto un po' ma ora ti rispondo. E' che ho dovuto riprendermi. Non per la risposta che mi hai dato, ma perchè avevo già finito la mia, inviata e... errore di connessione, testo non inviato e da rifare.

Ok, vero, hai ragione (lo dico sospeso a metà tra l'essere contento per la risposta che mi hai dato e l'essere indispettito per doverti scrivere che hai ragione ;) ).

Il testo di cui ho fatto cut&paste era, evidentemente, una versione draft che avevo in locale (ma convinto di averla aggiornata ed aiutato in questo dalle FAQ, che non sono aggiornatissime, come ho potuto verificare).
Ho erroneamente riguardato quella in locale, al posto di quella corretta, pur linkata nel post.

La versione definitiva dice anche qualcosa di meglio, rispetto a quello che fai notare: infatti esclude dal work anche:
generally available free programs which are used unmodified in performing those activities but which are not part of the work.
Molto meglio, perchè le System Libraries, sopra definite, sono quelle del Sistema Operativo o quelle di runtime rilasciate con compilatori ed interpreti e ci saremmo giocati comunque JavaMail e tutte le altre librerie di Java EE (servlet, JSP, SOAP, Autenticazione, accesso ad LDAP, Messaging, etc. etc.), più tutte quelle librerie standard di Java, pur dotate di stessa licenza, ma non rilasciate insieme alla VM.

Sarebbe perfetto, ma ci hanno messo, subito dopo, un esempio, che sembra andare in direzione contraria:
Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require.

Possiamo intendere: le librerie che restano, dopo aver tolto quelle di Sistema e i programmi free inalterati?

A te ed al resto del mondo sembrerà chiarissimo, ma a me sembra, perlomeno, contradditorio (forse ho fatto bene a non far giurisprudenza...). Soprattutto anche alla luce del draft errato che avevo erroneamente inserito nel commento. Sembra lo abbiano messo a posto, ma non del tutto: perchè?

Le stessa FAQ che citi ha un problema (simile, peraltro, ad una citata nel mio scorso commento e di cui mi sono accorto quando sono andato a verificare il testo definitivo e quello draft): citano una sezione 3 che non esiste più.
Era, infatti, parte della GPLv2, ripresa in modo più letterale della versione attuale dal draft. E, nella sua versione precedente aveva il difetto di non sembrare applicabile direttamente a tutte le librerie Java (al più a quelle del JRE), come già dicevo nel precedente commento.

Riguardo al "free software, but trapped", è vero che nella riga precedente parla di compatibilità con GPL, ma è anche vero che quando quelli della FSF parlano di free software e di GPL lo fanno, solitamente, con particolare attenzione alla distinzione tra i due concetti, distinzione che proprio loro evidenziano continuamente, quindi ci presterei attenzione.

Ciò detto, vorrei fare alcune precisazioni su questo mio intervento:
- quanto ho appena scritto serve più che altro a spiegare perchè per me il tutto continua a rimanere tutt'altro che chiaro, anche se, alla luce del testo definitivo, come dicevo, propenderei a darti ragione
- tanto più che si tratta, come sottolinei giustamente, di un problema che evidenzio solo io, mentre ci sono parecchi programmi GPL in Java: qualsiasi testo di carattere legale è interpretabile, probabilmente stavo fornendo una interpretazione troppo stretta (sono ben contento che non sia così)
- cercherò comunque di contattare ancora la FSF per capire se c'è modo di avere una interpretazione esplicita e non automatica, per maggior sicurezza
- per quanto riguarda le librerie standard non parte del JRE, potrebbe non fare male aggiungere comunque, nell'incertezza, quella eccezione di cui parlano le FAQ (perchè dovrebbero parlarne, se fosse tutto così lineare?) e che citavo nel precedente commento: al più diventerebbe ridondante.

Intanto, grazie per le spiegazioni: a me sono state utili, spero che l'intero dialogo lo sia anche per altri (giusto per non sentirmi davvero il solo ad interpretare malamente la licenza)