Ciao a tutti
Qualcuno sa qualcosa in merito a questo tipo di licenza? (http://www.osor.eu/eupl/european-union-public-licence-eupl-v.1.1) Pur seguendo con assiduità questa mailing-list (flame compresi :-) ) non mi ci ero ancora imbattutto ne avevo sentito citarla da alcuno: siete a conoscenza di qualche progetto che abbia seguito esplicitamente questa licenza? Grazie a presto Francesco Massa Università di Genova - Dip.Te.Ris. Il giorno 16 aprile 2011 12:00, <[hidden email]> ha scritto: Invia le richieste di iscrizione alla lista Gfoss all'indirizzo _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
2011/4/18 Francesco Massa <[hidden email]>:
> Ciao a tutti > Qualcuno sa qualcosa in merito a questo tipo di licenza? > (http://www.osor.eu/eupl/european-union-public-licence-eupl-v.1.1) > > Pur seguendo con assiduità questa mailing-list (flame compresi :-) ) non mi > ci ero ancora imbattutto ne avevo sentito citarla da alcuno: siete a > conoscenza di qualche progetto che abbia seguito esplicitamente questa > licenza? EUPL e' la licenza designata dalla Commissione Europea per tutte le sue iniziative Open Source. Qualsiasi progetto afferente alla sua orbita deve aderivi. Il problema e' che trattasi di una licenza virale, pertanto incompatibile con altre licenze virali quali GPL, LGPL, Apache, Mozilla. Questo se il progetto che deve essere rilasciato ha una finalita' pubblica. Per meglio capire, un esempio GIS: QGIS e' rilasciato in GPL, pertanto la viralita' di tale licenza obbliga che tutti i plugin scritti per QGIS devono essere rilasciati con una licenza GPL. Ovvero: non e' possibile rilasciare un plugin QGIS con una licenza EUPL (cosi' come con qualsiasi altra licenza). Questo non vieta la Commissione Europea di sviluppare plugin per QGIS a suo uso interno, pero' potete bene immaginare quale ricaduta negativa va a presentare siffatta situazione: il codice scritto all'interno della Commissione non puo' essere riusato. La ricaduta negativa va vista anche da un altro punto di vista (oltre a quello che rendera' impossibile pubblicare alcuni progetti che gia' usano da anni librerie con altre licenze virali): tale licenza scoraggia l'uso di componenti GPL (e LGPL e Apace ecc ecc) esistenti che dominano l'attuale panorama open source, obbligando gli sviluppatori a risviluppare nuovamente librerie di base gia' disponibili con licenza virale differente. Il tutto ovviamente con grosso dispendio di risorse pubbliche che potrebbero essere diversamente impiegate. In teoria tutti i progetti incubati su osor [0] devono seguire questa licenza, li puoi trovare qualche esempio. ciao P [0] http://www.osor.eu/ -- Paolo Corti Geospatial software developer web: http://www.paolocorti.net twitter: @capooti _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
On Mon, Apr 18, 2011 at 03:40:31PM +0200, Paolo Corti wrote:
> > Per meglio capire, un esempio GIS: QGIS e' rilasciato in GPL, pertanto > la viralita' di tale licenza obbliga che tutti i plugin scritti per > QGIS devono essere rilasciati con una licenza GPL. La licenza GPL influisce sulle modifiche che fai al codice GPL. Quindi versioni modificate di QGIS o di plugin con licenza GPL devono essere rilasciate a loro volta con la GPL. Ma se scrivi ex-novo un plugin esterno (di quelli in Python per intendersi), non essendo né derivato né linkato a codice GPL puoi rilasciarlo con la licenza che vuoi. Al limite anche non libera. So di aggiungere confusione, ma credo che stia proprio così. -- Niccolo Rigacci Firenze - Italy _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
In reply to this post by Paolo Corti
On 04/18/2011 03:40 PM, Paolo Corti wrote:
> Il problema e' che trattasi di una licenza virale, pertanto incompatibile con > altre licenze virali quali GPL, LGPL, Apache, Mozilla. Questo se il progetto > che deve essere rilasciato ha una finalita' pubblica. Asp... nelle "Guidelines for Users and Developers" di EUPL 1.1 c'è scritto: <<The EUPL foresees an important exception to the above rule: it is the case where the use of a compatible copyleft licence is compulsory.>> .. <<From the EUPL point of view, there are compatible copyleft licences listed as follows (1 st February 2009): • the GNU General Public Licence (GPLv.2) • the Open Software Licence (OSL) v. 2.1 and/or v. 3.0 • the Common Public Licence v. 1.0 • the Eclipse Public Licence v 1.0 • The CeCILL v. 2.0 What does this mean? Imagine that you have merged together two pieces of software code: • the first piece of code was licensed to you under the EUPL; • the second piece of code was licensed to you under one of the above compatible copyleft licences (for example the GPLv2). If you decide to re-distribute the derivative work, you will re-distribute this work under the provision of the GPLv2. This is an obligation resulting from the GPLv2, which is “copyleft”. The EUPL solves the “conflict of licences” by authorising you to comply with such an obligation>> Da quel che capisco, questo vuol dire che, se sviluppi una libreria con EUPL ed una con GPL e vuoi poi eseguire un merge di queste due, puoi benissimo ripubblicare il tutto solo con GPL. Non te ne avere a male Paolo... ma io ritengo che LGPL e ASL (Apache) NON siano delle licenze "virali", in quanto il prodotto può benissimo essere rilasciato con un'altra licenza. In ASF avevamo discusso la cosa qualche anno fa, ed era venuto fuori che la licenza Apache permetteva anche il fork di un progetto open source per farlo divenire proprietario ! In effetti la cosa è successa ad un progetto Apache di cui sono committer (Apache Cocoon) e non abbiamo potuto fare niente per impedirlo... tranne ridere di quei *furbacchioni* che sono rimasti inesorabilmente indietro nell'aggiunta di feature e soluzione di bachi rispetto all'implementazione open source. In ultimo, sono d'accordo con Niccolò riguardo ai plugin: se scrivi ex-novo un plugin non sei soggetto al rilascio in GPL in quanto non si tratta di un prodotto "derivato", ma di uno che si "interfaccia" al codice protetto da GPL. Ciao, Luca Morandini http://www.lucamorandini.it _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
In reply to this post by Niccolo Rigacci
Il giorno lun, 18/04/2011 alle 16.20 +0200, Niccolo Rigacci ha scritto:
> Ma se scrivi ex-novo un plugin esterno (di quelli in Python per > intendersi), non essendo né derivato né linkato a codice GPL puoi > rilasciarlo con la licenza che vuoi. Al limite anche non libera. A quello che so io l'import di una libreria in py equivale ad un linking dinamico, per cui anche i plugin devono sottostare alla stessa licenza. Realata refero, queste son cose da avvocati, comunque. Saluti. -- Paolo Cavallini: http://www.faunalia.it/pc _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
On Mon, Apr 18, 2011 at 05:03:27PM +0200, Paolo Cavallini wrote:
> > A quello che so io l'import di una libreria in py equivale ad un linking > dinamico, per cui anche i plugin devono sottostare alla stessa licenza. Ho approfondito un attimo la cosa: Un plugin QGIS in Python esegue "from qgis.core import *", quindi linka dinamicamente il codice di QGIS [1]. Chi ha scritto la GPL sostiene che linkare una libreria GPL - anche dinamicamente - costituisce lavoro derivato e quindi richiede di rilasciare con la stessa licenza. C'è invece chi sostiene che ci siano margini per ritenere l'opera non derivata [2]. Quindi mi correggo: se fate un plugin Python per QGIS rilasciatelo sotto GPL, altrimenti ci potrebbero essere problemi! [1] http://www.qgis.org/wiki/Writing_Python_Plugins [2] http://en.wikipedia.org/wiki/GNU_General_Public_License#Point_of_view:_dynamically_and_static-linking_violates_GPL -- Niccolo Rigacci Firenze - Italy _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
In reply to this post by Paolo Corti
Il 18/04/2011 15:40, Paolo Corti ha scritto:
> 2011/4/18 Francesco Massa<[hidden email]>: >> Ciao a tutti >> Qualcuno sa qualcosa in merito a questo tipo di licenza? >> (http://www.osor.eu/eupl/european-union-public-licence-eupl-v.1.1) >> >> Pur seguendo con assiduità questa mailing-list (flame compresi :-) ) non mi >> ci ero ancora imbattutto ne avevo sentito citarla da alcuno: siete a >> conoscenza di qualche progetto che abbia seguito esplicitamente questa >> licenza? > > EUPL e' la licenza designata dalla Commissione Europea per tutte le > sue iniziative Open Source. Qualsiasi progetto afferente alla sua > orbita deve aderivi. > Il problema e' che trattasi di una licenza virale, pertanto > incompatibile con altre licenze virali quali GPL, LGPL, Apache, > Mozilla. L'unica cosa che ha la EUPL è che scrive chiaramente di essere compatibile con diverse licenze fra cui la GPL e LGPL _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
In reply to this post by Francesco Massa
Il 18/04/2011 15:15, Francesco Massa ha scritto:
> Ciao a tutti > Qualcuno sa qualcosa in merito a questo tipo di licenza? > (http://www.osor.eu/eupl/european-union-public-licence-eupl-v.1.1) > > Pur seguendo con assiduità questa mailing-list (flame compresi :-) ) non > mi ci ero ancora imbattutto ne avevo sentito citarla da alcuno: siete a > conoscenza di qualche progetto che abbia seguito esplicitamente questa > licenza? Mi sto occupando di un problema di rilascio di software libero da parte della P.A. ed una delle soluzioni proposte è la EUPL. Dopo essermi confrontato con Carlo Piana nutro dei dubbi in merito. Le EUPL nasce in particolare per venire incontro alle "paure" della p.a. Di fatto è una sorta di GPL riscritta in tutte e lingue riconosciute dall'unione europea e, al suo interno, dichiara quali sono le licenze con cui questo testo è compatibile. Detta così subito un sacco di gente batte la mani dicendo "WOW! Finalmente qualcosa scritta seconda il sistema giuridico di dove vivo! WOW! Finalmente una licenza che mi dica chiaramente su cosa questa è compatibile" Ragionando però a mente fredda: - perché devo avere un testo scritto in diverse lingue? Se vado in tribunale con quale testo ci vado? Alla fine la GPL non ha mai perso una causa - dichiarare la licenza con cui è compatibile può essere interessante ma se poi ... cambiano i testi di riferimento? C'è un caso di una piattaforma ad uso della protezione civile della basilicata che alla fine ha dovuto fare il dual licensing come EUPL e GPL3 La domanda è: ma perché non rilasciare direttamente tutto in GPL3? Qualcuno dice che la EUPL è uscita mentre scrivevano la GPL3 e quindi non ha avuto tempo di riadattarsi e bla bla bla ... Allora nuovamente: perché usare una licenza che deve rincorrere dietro a tutte le altre con il rischio di rimanere sempre vecchia? Qualcuno la mette sulla "inter compatibilità fra le licenze"... ed anche questa non mi torna: se un testo (= una licenza) dichiara precisamente delle cose, come posso poi pensare di infilarlo in un calderone che mi permette poi di trasformarlo in altro modo? No grazie. In sintesi l'EUPL mi sembra una idea malsana che serve solo a qualche burocrate della p.a. per farsi levare un pò di FUD* dal cranio Alla fine i modelli delle licenze sono 3: - liberale (es. MIT, Apache ... ) - debole (es. LGPL, MPL ... ) - forte (es. GPL, aGPL ... ) ne scegli uno, e ti scegli la licenza che ha più successo su questo fronte (e la GPL non ha MAI perso una causa) e lasci perdere tutto il resto. Infine non capisco perché, al mondo di internet, si cerchi di calare tutte queste licenze sui propri confini ... e se a violare la licenza sono di altre nazioni? Rispondendo a Francesco (sperando che mi abbia letto fino a qui) per dei progetti che usano la EUPL, a parte consultare il sito osor.eu, consiglio di guardare il sito http://www.eupl.it Dove, alla voce "software", si trovano due progetti italiani: http://www.creativu.it/ http://www.piattaformaexperience.it/ * http://it.wikipedia.org/wiki/Fear,_uncertainty_and_doubt _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
> La domanda e': ma perche' non rilasciare direttamente tutto in GPL3? +1 --strk; () Free GIS & Flash consultant/developer /\ http://strk.keybit.net/services.html _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
In reply to this post by Maurizio Napolitano-2
On 04/18/2011 05:51 PM, Maurizio Napolitano wrote:
> > Ragionando però a mente fredda: > - perché devo avere un testo scritto in diverse lingue? Perché ti viene utile in caso di controversia internazionale. > Se vado in tribunale con quale testo ci vado? In quello del foro di competenza direi: e poi sono equivalenti, garante la EU. > Alla fine la GPL non ha mai perso una causa > - dichiarare la licenza con cui è compatibile può essere interessante ma se poi > ... cambiano i testi di riferimento? Beh, oltre alla licenza viene specificato anche il numero di versione, per cui il testo è fissato. > C'è un caso di una piattaforma ad uso della protezione civile della basilicata che > alla fine ha dovuto fare il dual licensing come EUPL e GPL3 Credo che questo sia dovuto al fatto che EUPL 1.1 è compatibile con GPL 2, non con GPL 3. > La domanda è: ma perché non rilasciare direttamente tutto in GPL3? Questa è una buona domanda... io però preferirei evitare la "viralità" e rilasciare sotto ASL. > Qualcuno dice che la EUPL è uscita mentre scrivevano la GPL3 e quindi non ha avuto > tempo di riadattarsi e bla bla bla ... Possibilissimo, visto i tempi della EU. > In sintesi l'EUPL mi sembra una idea malsana che serve solo a qualche burocrate > della p.a. per farsi levare un pò di FUD* dal cranio Possible, ma proprio per questo può essere molto utile: "Non si preoccupi Assessore, la licenza è garantita dall'Unione Europea !" ;) > Infine non capisco perché, al mondo di internet, si cerchi di calare tutte queste > licenze sui propri confini ... e se a violare la licenza sono di altre nazioni? Appunto, deve essere una licenza plurinazionale. Saluti, Luca Morandini http://www.lucamorandini.it -- Regards, Luca Morandini http://www.lucamorandini.it _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
Il 18/04/2011 18:40, Luca Morandini ha scritto:
> On 04/18/2011 05:51 PM, Maurizio Napolitano wrote: >> >> Ragionando però a mente fredda: >> - perché devo avere un testo scritto in diverse lingue? > > Perché ti viene utile in caso di controversia internazionale. Ok, non sono un giurista, ma in tribunale ci vado con un riferimento unico, non con versioni diverse anche se di lingue diverse. Ripeto: la GPL non ha mai perso una causa a livello internazionale > >> Se vado in tribunale con quale testo ci vado? > > In quello del foro di competenza direi: e poi sono equivalenti, garante > la EU. Quindi dici che se uso il testo in italiano e la violazione avviene da un qualsiasi altro stato europeo si va a discutere sul testo in italiano? >> Alla fine la GPL non ha mai perso una causa >> - dichiarare la licenza con cui è compatibile può essere interessante >> ma se poi >> ... cambiano i testi di riferimento? > > Beh, oltre alla licenza viene specificato anche il numero di versione, > per cui il testo è fissato. motivo per cui si perde la compatibilità con le licenze più' usate nel mondo e ti tocca fare il dual lincesing ... aumentando cosi' la confusione >> C'è un caso di una piattaforma ad uso della protezione civile della >> basilicata che >> alla fine ha dovuto fare il dual licensing come EUPL e GPL3 > > Credo che questo sia dovuto al fatto che EUPL 1.1 è compatibile con GPL > 2, non con GPL 3. Come gia' detto: ma allora perche' non usare direttamente la GPL3? >> La domanda è: ma perché non rilasciare direttamente tutto in GPL3? > > Questa è una buona domanda... io però preferirei evitare la "viralità" e > rilasciare sotto ASL. allora non sostieni nemmeno la EUPL, giusto? >> Qualcuno dice che la EUPL è uscita mentre scrivevano la GPL3 e quindi >> non ha avuto >> tempo di riadattarsi e bla bla bla ... > > Possibilissimo, visto i tempi della EU. IMHO: ha dimostrato di essere debole in partenza, no? >> In sintesi l'EUPL mi sembra una idea malsana che serve solo a qualche >> burocrate >> della p.a. per farsi levare un pò di FUD* dal cranio > > Possible, ma proprio per questo può essere molto utile: "Non si > preoccupi Assessore, la licenza è garantita dall'Unione Europea !" ;) Certo, ma posso anche dire "Non si preoccupi assessore, la licenza GPL esiste da 20 anni e nessuno ha mai perso una casa. Le fornisco un elenco anche su casi europei" >> Infine non capisco perché, al mondo di internet, si cerchi di calare >> tutte queste >> licenze sui propri confini ... e se a violare la licenza sono di altre >> nazioni? > > Appunto, deve essere una licenza plurinazionale. non mi convinci. Prometto che se mi rispondi blocco il flame. temo che non ne usciamo :) In ogni caso, sul progetto su cui sto lavorando, a breve avremo una discussione sul tema software libero e codice di amministrazione digitale, dove, sicuramente, il tema EUPL verrà fuori (tra l'altro ho messo i riferimenti anche nel documento di progetto) Se rimarranno dubbi (come credo) pensavo di organizzare un incontro sul tema specifico EUPL. Una delle questioni che sono nel cantiere e' il fatto che abbiamo anche delle personalizzazione di software proprietario di cui pero' la proprieta' del codice sviluppato per l'adattamento e' della p.a. Li dovremmo decidere se usare qualcosa come lgpl, o mpl, o asl o ... free as beer. _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
In reply to this post by Luca Morandini
Ciao Luca, ben ritrovato ;)
2011/4/18 Luca Morandini <[hidden email]>: > Da quel che capisco, questo vuol dire che, se sviluppi una libreria con EUPL > ed una con GPL e vuoi poi eseguire un merge di queste due, puoi benissimo > ripubblicare il tutto solo con GPL. certo, è così. Il problema è che se sviluppi per conto della Comunità Europea sei però costretto da loro indicazioni a rilasciare in EUPL (mi riferisco a questo [0] recente documento, di dominio pubblico) e quindi non puoi usare componenti con GPL v3 (sempre se è nelle intenzioni rilasciare pubblicamente il software). Dal documento indicato risulterebbe anche l'impossibilità ad incorporare componenti a GPL v2. > Non te ne avere a male Paolo... ma io ritengo che LGPL e ASL (Apache) NON > siano delle licenze "virali", in quanto il prodotto può benissimo essere > rilasciato con un'altra licenza. Ma figurati se me la prendo, e anzi fai bene a sottolineare la mia inesattezza ;) In realtà sempre guardando lo stesso documento, anche LGPL e ASL sono considerate non utilizzabili ai fini del rilascio in EUPL (pg. 14 del documento), pertanto, non conoscendole bene, le avevo considerate (erroneamente) tali. Sarebbe a questo punto utile capire perchè secondo tale documento queste non possono essere utilizzate. > In ultimo, sono d'accordo con Niccolò riguardo ai plugin: se scrivi ex-novo > un plugin non sei soggetto al rilascio in GPL in quanto non si tratta di un > prodotto "derivato", ma di uno che si "interfaccia" al codice protetto da > GPL. A mio avviso la FAQ in merito della FSF [1] non si presta a diverse interpretazioni: nel caso dei plugin per QGIS, il link è chiaramente dinamico (importi le librerie di QGIS) e pertanto si suggerisce "caldamente" di rispettare (l'eventuale) viralità della licenza dell' application host. Il discorso è complesso, e come ha detto Paolo Cavallini, è più materia di avvocati. Ma io nel dubbio non mi avventurerei ciao Paolo [0] http://www.osor.eu/news/misc/OSS-guidelines-v-DIGIT-2.pdf/view [1] http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins -- Paolo Corti Geospatial software developer web: http://www.paolocorti.net twitter: @capooti _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
On 04/18/2011 11:03 PM, Paolo Corti wrote:
> > 2011/4/18 Luca Morandini<[hidden email]>: >> Da quel che capisco, questo vuol dire che, se sviluppi una libreria con EUPL >> ed una con GPL e vuoi poi eseguire un merge di queste due, puoi benissimo >> ripubblicare il tutto solo con GPL. > > certo, è così. Il problema è che se sviluppi per conto della Comunità > Europea sei però costretto da loro indicazioni a rilasciare in EUPL > (mi riferisco a questo [0] recente documento, di dominio pubblico) e > quindi non puoi usare componenti con GPL v3 (sempre se è nelle > intenzioni rilasciare pubblicamente il software). Dal documento > indicato risulterebbe anche l'impossibilità ad incorporare componenti > a GPL v2. La mia lettura del testo [0] è diversa: puoi incorporare componenti GPL 2 ma non puoi rilasciarli sotto EUPL, cosa che però è permessa da EUPL. Insomma, la EUPL permette di rilasciare le modifiche ad un software GPL 2 sotto GPL 2 (visto che è compatibile con EUPL), essa però non permette di farlo con un componente ASL (licenza che non è compatibile con EUPL). >> Non te ne avere a male Paolo... ma io ritengo che LGPL e ASL (Apache) NON >> siano delle licenze "virali", in quanto il prodotto può benissimo essere >> rilasciato con un'altra licenza. > > Ma figurati se me la prendo, e anzi fai bene a sottolineare la mia > inesattezza ;) > In realtà sempre guardando lo stesso documento, anche LGPL e ASL sono > considerate non utilizzabili ai fini del rilascio in EUPL (pg. 14 del > documento), pertanto, non conoscendole bene, le avevo considerate > (erroneamente) tali. Sarebbe a questo punto utile capire perchè > secondo tale documento queste non possono essere utilizzate. Appunto perché non sono virali come la EUPL (o la GPL). >> In ultimo, sono d'accordo con Niccolò riguardo ai plugin: se scrivi ex-novo >> un plugin non sei soggetto al rilascio in GPL in quanto non si tratta di un >> prodotto "derivato", ma di uno che si "interfaccia" al codice protetto da >> GPL. > > A mio avviso la FAQ in merito della FSF [1] non si presta a diverse > interpretazioni: nel caso dei plugin per QGIS, il link è chiaramente > dinamico (importi le librerie di QGIS) e pertanto si suggerisce > "caldamente" di rispettare (l'eventuale) viralità della licenza dell' > application host. > Il discorso è complesso, e come ha detto Paolo Cavallini, è più > materia di avvocati. Ma io nel dubbio non mi avventurerei Non credo che possiamo astenerci dal farlo... è un po' come con la legge Stanca: dobbiamo diventare tutti un po' avvocati :| Ciao, Luca Morandini http://www.lucamorandini.it _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
In reply to this post by Maurizio Napolitano-2
On 04/18/2011 10:37 PM, Maurizio Napolitano wrote:
> Il 18/04/2011 18:40, Luca Morandini ha scritto: >> On 04/18/2011 05:51 PM, Maurizio Napolitano wrote: >> >>> Se vado in tribunale con quale testo ci vado? >> >> In quello del foro di competenza direi: e poi sono equivalenti, garante >> la EU. > > Quindi dici che se uso il testo in italiano e la violazione avviene da un > qualsiasi altro stato europeo si va a discutere sul testo in italiano? Dipende dal foro di competenza, se è quello di Atene vai a discutere il testo in Greco. >>> - dichiarare la licenza con cui è compatibile può essere interessante >>> ma se poi >>> ... cambiano i testi di riferimento? >> >> Beh, oltre alla licenza viene specificato anche il numero di versione, >> per cui il testo è fissato. > > motivo per cui si perde la compatibilità con le licenze più' usate nel mondo e ti > tocca fare il dual lincesing ... aumentando cosi' la confusione Basta che la EUPL venga aggiornata ogni tanto, non mi sembra uno sforzo impossibile. >>> La domanda è: ma perché non rilasciare direttamente tutto in GPL3? >> >> Questa è una buona domanda... io però preferirei evitare la "viralità" e >> rilasciare sotto ASL. > > allora non sostieni nemmeno la EUPL, giusto? Diciamo che mi sembra un tentativo utile di fornire una protezione giuridica europea al software OSS... però preferirei che come riferimento si prendesse la "liberale" ASL. >>> Qualcuno dice che la EUPL è uscita mentre scrivevano la GPL3 e quindi >>> non ha avuto >>> tempo di riadattarsi e bla bla bla ... >> >> Possibilissimo, visto i tempi della EU. > > IMHO: ha dimostrato di essere debole in partenza, no? Non è che le licenze cambiano con le stagioni: basta aggiornare la EUPL, come scrivevo sopra. >>> In sintesi l'EUPL mi sembra una idea malsana che serve solo a qualche >>> burocrate >>> della p.a. per farsi levare un pò di FUD* dal cranio >> >> Possible, ma proprio per questo può essere molto utile: "Non si >> preoccupi Assessore, la licenza è garantita dall'Unione Europea !" ;) > > Certo, ma posso anche dire > "Non si preoccupi assessore, la licenza GPL esiste da 20 anni e nessuno ha mai > perso una casa. Le fornisco un elenco anche su casi europei" Per carità, anche questo va bene. > Una delle questioni che sono nel cantiere e' il fatto che abbiamo anche delle > personalizzazione di software proprietario di cui pero' la proprieta' del codice > sviluppato per l'adattamento e' della p.a. > Li dovremmo decidere se usare qualcosa come lgpl, o mpl, o asl o ... free as beer. Io con il Poligrafico dello Stato (che però è una SpA) ho spuntato, quasi 10 anni fa, una ASL, licenza che è stato un buon investimento per loro quando hanno avuto, gratis, dei miglioramenti di performance che un altro committer ha apportato al codice originale :) Saluti, Luca Morandini http://www.lucamorandini.it -- Regards, Luca Morandini http://www.lucamorandini.it _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
In reply to this post by Francesco Massa
On 04/18/2011 11:59 PM, Paolo Corti wrote:
> >> La mia lettura del testo [0] è diversa: puoi incorporare componenti GPL 2 ma >> non puoi rilasciarli sotto EUPL, cosa che però è permessa da EUPL. > > non ho capito. Se non posso rilasciare il mio software come EUPL > perchè sto usando componenti GPL2, allora è come dire che GPL2 è > virale. Lo è, quella che NON è virale è LGPL. >> Appunto perché non sono virali come la EUPL (o la GPL). > > scusa: ma se non sono virali, allora perchè non posso incorporare un > componente GPL e rilasciare come EUPL? dal documento sembra che questo > non è fattibile Allora: 1) GPL è virale per cui impone che si rilascino i derivati come GPL 2) EUPL è virale per ma non impone se stessa nei prodotti derivati, basta che la licenza scelta per i derviati sia compatibile con essa (cioè virale) 3) ASL non è virale, per cui non è compatibile con EUPL... ma, , per quanto ne so, la ASL non ti vieta di rilasciare derivati da ASL come GPL, per cui non so rispondere alla tua domanda. Saluti, Luca Morandini http://www.lucamorandini.it _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
On 04/19/2011 07:51 AM, Luca Morandini wrote:
> 3) ASL non è virale, per cui non è compatibile con EUPL... ma, , per quanto ne so, > la ASL non ti vieta di rilasciare derivati da ASL come GPL, per cui non so > rispondere alla tua domanda. ...magari la EU non ha voluto fare uno sgarbo ad Apache: anche se la cosa era fattibile giuridicamente, sarebbe risultato in una gpl-zzazione forzata del software Apache, mossa non molto educata. Saluti, Luca Morandini http://www.lucamorandini.it _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
In reply to this post by Francesco Massa
Vista la passione profusa ho l'impressione di aver toccato un argomento piuttosto complesso e attuale. Grazie mille: tutti questi interventi mi hanno certamente aiutato a capire meglio la situazione. Auspico che presto possa uscire una EUPL v2.0 che possa dirimere la questione: anche a me piace l'idea che la licenza sia esplicitamente riconosciuta dalla CE ed esista un foro competente per le questioni giuridiche. Francesco Massa Il giorno 19 aprile 2011 07:46, <[hidden email]> ha scritto: Invia le richieste di iscrizione alla lista Gfoss all'indirizzo _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
In reply to this post by Luca Morandini
>> Quindi dici che se uso il testo in italiano e la violazione avviene da un >> qualsiasi altro stato europeo si va a discutere sul testo in italiano? > > Dipende dal foro di competenza, se è quello di Atene vai a discutere il > testo in Greco. non ne sono totalmente convinto. Meglio avere un testo unico di riferimento e basta. E' vero che la EU mi dovrebbe dare delle garanzie. E se a violarla sono in Cina? >> motivo per cui si perde la compatibilità con le licenze più' usate nel >> mondo e ti >> tocca fare il dual lincesing ... aumentando cosi' la confusione > > Basta che la EUPL venga aggiornata ogni tanto, non mi sembra uno sforzo > impossibile. Certo ... la data di uscita della 1.1 e' stata nel 2007, stesso anno dell'uscita della GPL3. Visto che la GPL non e' una licenza usata da 4 gatti, e sono passati quasi 4 anni ... >> allora non sostieni nemmeno la EUPL, giusto? > > Diciamo che mi sembra un tentativo utile di fornire una protezione > giuridica europea al software OSS... quindi mi confermi che e' una licenza nata per evitare un po' di FUD nella P.A. >> IMHO: ha dimostrato di essere debole in partenza, no? > > Non è che le licenze cambiano con le stagioni: basta aggiornare la EUPL, > come scrivevo sopra. ... e come scrivevo sopra sono passati quasi 4 anni ... Ok! I tempi della EU sono lenti. Non sono un giurista, ma credo che lo sforzo di aggiornare verso la GPL3 non porti via 4 anni di tempo. >> "Non si preoccupi assessore, la licenza GPL esiste da 20 anni e >> nessuno ha mai >> perso una casa. Le fornisco un elenco anche su casi europei" > > Per carità, anche questo va bene. andrebbe bene se invece che "casa" avessi scritto "causa" :) /me lamer :) Mi fa piacere che sei d'accordo, quindi nuovamente mi chiedo "perche' usare la EUPL?" Ma non voglio continuare il flame :) >> Una delle questioni che sono nel cantiere e' il fatto che abbiamo >> anche delle >> personalizzazione di software proprietario di cui pero' la proprieta' >> del codice >> sviluppato per l'adattamento e' della p.a. >> Li dovremmo decidere se usare qualcosa come lgpl, o mpl, o asl o ... >> free as beer. > > Io con il Poligrafico dello Stato (che però è una SpA) ho spuntato, > quasi 10 anni fa, una ASL, licenza che è stato un buon investimento per > loro quando hanno avuto, gratis, dei miglioramenti di performance che un > altro committer ha apportato al codice originale :) In questo caso si tratta di personalizzazioni di software proprietario. Non ho ancora investigato, ma c'e' il rischio che lo sforzo per fare in modo che questi componenti siano ridistribuibili in maniera indolore (intendo dire far diventare queste personalizzazioni come plugin) temo abbia dei costi. Grazie comunque del suggerimento. ASL e' una licenza che si porta dietro un caso d'uso con pochi paragoni [1]. In conclusione: non porto avanti il flame, prima mi leggo per bene la EUPL, e se ci riesco pure in diverse lingue ... cosi' vedo se sclero :) [1] di recente sono stato affascinato dalla lettura di "surplus cognitivo. creatività e generosità nell'era digitale" di Clay Shirky Fra gli esempi di successo riportati si parla proprio di apache. Per chi vuole farsi una idea di cosa parla Shirky nel libro segnalo questa presentazione al TED http://www.ted.com/talks/clay_shirky_how_cognitive_surplus_will_change_the_world.html (dove pero' non parla di ASL) _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
On 04/19/2011 10:03 AM, Maurizio Napolitano wrote:
> >>> Quindi dici che se uso il testo in italiano e la violazione avviene da un >>> qualsiasi altro stato europeo si va a discutere sul testo in italiano? >> >> Dipende dal foro di competenza, se è quello di Atene vai a discutere il >> testo in Greco. > > non ne sono totalmente convinto. > Meglio avere un testo unico di riferimento e basta. Beh, in questo caso dovrai farti fare la traduzione, certificata, a tue spese. > E' vero che la EU mi dovrebbe dare delle garanzie. > E se a violarla sono in Cina? Traduzione certificata. >> Diciamo che mi sembra un tentativo utile di fornire una protezione >> giuridica europea al software OSS... > > quindi mi confermi che e' una licenza nata per evitare un po' di FUD nella P.A. Beh, la genesi della EUPL non la conosco, ma mi sembra un'inferenza ragionevole. >> Non è che le licenze cambiano con le stagioni: basta aggiornare la EUPL, >> come scrivevo sopra. > > ... e come scrivevo sopra sono passati quasi 4 anni ... > Ok! I tempi della EU sono lenti. Non sono un giurista, ma credo che lo sforzo di > aggiornare verso la GPL3 non porti via 4 anni di tempo. In effetti gli Eurocrati potrebbero darsi una mossa. > ASL e' una licenza che si porta dietro un caso d'uso con pochi paragoni [1]. Intendi HTTP Server ? Sì, in effetti la sua diffusione è con pochi paragoni. Va anche citata, di passaggio, la differente filosfia tra ASF e FSF (e quindi tra le loro licenze): in ASF si tende a dare importanza più al processo che al prodotto, più alla comunità che al codice; mentre in FSF ci si focalizza sulla protezione del codice, cioè del prodotto. Saluti, Luca Morandini http://www.lucamorandini.it -- Regards, Luca Morandini http://www.lucamorandini.it _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
In reply to this post by Luca Morandini
Ciao Luca
allora per punti: > 1) GPL è virale per cui impone che si rilascino i derivati come GPL sono d'accordo, anche se a dire il vero sarebbe meglio parlare di copyleft ;) > 2) EUPL è virale per ma non impone se stessa nei prodotti derivati, basta > che la > licenza scelta per i derviati sia compatibile con essa (cioè virale) Supponendo di voler utilizzare librerie open source in un software EUPL: sono compatibili con EUPL tutte le librerie con licenze che ti consentono di continuare a rilasciare il tuo lavoro come EUPL, quindi in teoria anche la maggior parte delle licenze non virali (direi le stesse che sono utilizzabili anche da GPL). Viceversa NON si possono usare licenze copyleft a meno delle seguenti eccezioni: * GPLv.2 * OSL v. 2.1 and/or v. 3.0 * CPL v. 1.0 * EPL v 1.0 * CeCILL v. 2.0 Queste sono 5 licenze copyleft, che pero' sono compatibili con EUPL. Nel caso uno sviluppatore usi una di queste con EUPL, la prima prende il sopravvento e si dovra' rilasciare il software con tale licenza. Credo sia utile sintetizzare con degli esempi: * se sviluppo un software usando GDAL, essendo X/MIT (non virale, debole), posso rilasciare il mio software come EUPL senza problemi (e ovviamente usare anche componenti EUPL al suo interno) * se sviluppo un plugin per QGIS, essendo quest'ultimo GPL v 3.0, non posso ne rilasciare diversamente da GPL v 3.0 ne usare componenti EUPL all'interno del plugin * se infine sviluppo un software usando un componente GPL v 2.0, sono costretto a rilasciare come GPL v 2.0, ma posso usare componenti EUPL nel codice > 3) ASL non è virale, per cui non è compatibile con EUPL... ma, , per quanto > ne so, > la ASL non ti vieta di rilasciare derivati da ASL come GPL, per cui non so > rispondere alla tua domanda. Come detto in precedenza, la maggior parte delle licenze non virali sono compatibili con EUPL perche' consentono di rispettare il copyleft di EUPL. Il motivo per cui non si possa rilasciare in EUPL un software che include componenti ASL (secondo il documento indicato in precedenza) e' a questo punto da ricercare all'interno del testo della licenza ASL: evidentemente c'e' qualcosa che la rende incompatibile. > ...magari la EU non ha voluto fare uno sgarbo ad Apache: anche se la cosa > era fattibile giuridicamente, sarebbe risultato in una gpl-zzazione forzata > del software Apache, mossa non molto educata. Lo sgarbo lo fa proprio dicendo, in un suo documento ufficiale, che EUPL con e' compatibile con ASL, pur potendo (in linea di principio) esserlo. Uno sviluppatore che deve rilasciare EUPL non potra' mai usare ASL nel suo codice (penalizzando quindi i progetti Apache), sempre secondo quel documento. ciao P -- Paolo Corti Geospatial software developer web: http://www.paolocorti.net twitter: @capooti _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
Free forum by Nabble | Edit this page |