Salve a tutti, provo a fornire qualche elemento di risposta a karlessi più sotto. Visto che questo è il mio primo post sulla lista, alla quale mi sono iscritto su (ottimo!) consiglio di Juan Carlos, ne approfitto prima per una breve presentazione. Sono Zack, ricercatore e prof. di informatica all'università Paris Diderot e all'Inria, e attivista software libero da quasi 20 anni. Sono stato a capo di Debian per qualche anno, e collaboro ora --- sempre come volontario --- sia con la Open Source Initiative (come membro del board of directors) che con la Free Software Foundation (nel comitato High Priority Projects). Ho co-fondato in Giugno scorso il progetto Software Heritage <https://www.softwareheritage.org>, di cui vi parlerò prossimamente su questa lista :-) Lurko da un paio di settimane in lista, e ne approfitto per farvi i complimenti per le interessanti segnalazioni e discussioni! On Wed, Nov 23, 2016 at 11:32:28AM +0000, karlessi wrote:

siamo alla ricerca di una licenza per il software che rilasceremo, una piattaforma collaborativa per il bilancio partecipativo.

si pensava a una AGPL (Affero GPL) v3.

Come si accederà alla piattaforma? Principalmente via web, o comunque remotamente over the net? Se si AGPL per il software è effettivamente un'ottima scelta, praticamente l'unica che vi garantisce che chiunque metta in piedi un servizio basato su versioni modificate della piattaforma debba pubblicare le modifiche al software. (Che non è il caso per la GPL standard, nel caso di servizi software fruiti over the net.) La AGPL non viete però di utilizzare il software per motivi commerciali. Più in generale, *nessuna* licenza Free/Open Source Software ha, ne può avere, restrizioni di questo tipo. L'uso "commerciale" rientra tra le libertà garantite dal software libero. Ed è una feature, non un bug :-)

Però, per i contenuti, la licenza che i partner hanno trovato adatta è la CC by-nc-sa 4.0

il che è contradditorio. oppure no?

Lo è certamente da un punto di vista "culturale", visto che mi aspetterei che vogliate fornire libertà analoghe tra il software ed i dati che fornirete. Con AGPL da una parte e BY-NC-SA dall'altra questa analogia si rompe, e secondo me non per buoni motivi (leggi sotto). Inoltre, potrebbero down the line sorgere problemi di incompatibilità di licenze. La barriera tra dati e codice sorgente tende a diventare sempre più labile; pensa ad esempio a documentazione generata da codice o vice versa, oppure a codice generato automaticamente a partire dai dati forniti dagli utenti (e.g., learning matrices per machine learning), etc. È quindi una buona idea pensare ad una licenza per i dati che sia (implicitamente o esplicitamente) compatibile con la licenza del software che li tratta. Nell'ambito delle licenze Creative Commons la scelta è quindi presto fatta: CC BY-SA 4.0, che è stata dichiarata esplicitamente compatibile con GPL (e quindi con AGPL per transitività) un annetto fa https://creativecommons.org/share-your-work/licensing-considerations/compati... Oppure ovviamente una licenza ancora più liberale, tipo CC0.

Uno degli impegni presi con l'Unione Europea è che i risultati del progetto dovranno essere "non appropriabili", che rimangano patrimonio comune.

Come avrai probabilmente già dedotto dal miei commenti finora, personalmente mi trovo invece concorde con la definizione di Free Culture. E trovo che offrire l'opzione "non commercial" introdotta da Creative Commons sia stato un errore storico, per altro di difficile implementabilità all'atto pratico, come dimostrano gli anni di dibattiti legali su cosa effettivamente è considerato "commerciale" o no secondo le licenze CC e secondo i sistemi giuridici in giro per il mondo. Ovviamente non cercherò qui di convincerti, perché siamo chiaramente in disaccordo :) Ma ci tengo a mettere in evidenza che l'uso commerciale dei dati è assolutamente compatibile con la "non appropriabilità" degli stessi e con il giustissimo policy goal di farli restare patrimonio comune (come parte dell'"open data commons" in questo caso). Se qualcuno "fa soldi" con open data, non sta *togliendo* quei dati dal commons, perché i dati restano disponibili per altri usi. Sta "solo" facendo soldi, che può darti fastidio o meno, ma non c'è un danno per gli altri, che continuano a potere usare i dati originali. Separatamente, ci si può chiedere quali licenze implementino al meglio il policy goal di incoraggiare la creazione di *nuovi* open data, derivati dai precedenti. E anche qui la risposta è abbastanza chiara: si tratta, nell'ambito delle licenze CC, di tutte le varianti SA. Quindi, anche se ci arrivo qua da un percorso logico diverso, il mio consiglio è ancora una volta di optare per la licenza CC BY-SA 4.0 per i dati. Hope this helps, -- Stefano Zacchiroli . zack@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader . OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »

ciao Karlessi! non ti rispondo nel merito della licenza, ho solo un dubbio sulla ragione di fondo... 2016-11-23 9:32 GMT-02:00 karlessi <karlessi@ippolita.net>:

In questo caso, stiamo parlando di software creato con denaro dell'Unione Europea. Se usiamo una licenza come AGPL v. 3, i cittadini europei pagano per far sviluppare un software che poi può essere riutilizzato da chiunque per business (per esempio, sarebbe questo il caso, da una società con sede negli USA).

Se avenisse quel che dici, sarebbe un'opportunità fortunata. In una dinamica di rete, se qualcuno inizia a fare business sopra ad una tecnologia simile, ha interesse a partecipare al mantenimento del software, la localizzazione, traduzioni, customizzazioni, e tutte altre attività che i creatori possono delegare (o rifarsi, se non gli piace quel che hanno fatto) Per la questione geografica: UE ha messo soldi per far sviluppare qualcosa che i cittadini UE possono beneficiarne. fine. se poi un giapponese o una brasiliana lo usano, perchè dovrebbe essere un problema? Nessuno fa del business su del codice che non padroneggia, ed affidarsi ad una soluzione FLOSS esistente richiede sempre degli accordi con il team di sviluppo. Non vuoi che il tuo corpo di sviluppo impari qualcosa che poi viene dismesso, o che cambia direzione, o che cambia licenza. Non ci si prende questo rischio, per cui gli accordi che ne derivano finiscono per beneficiare, anche solo per minima parte, entrambi.