menu di navigazione del network

Rai Open Source

Essendo la Rai una pubblica amministrazione non dovrebbe rilasciare tutto il codice in suo possesso? Compreso il sito web raiplay.it

1 Mi Piace

Sono abbastanza certo che la RAI non sia una Pubblica Amministrazione.

1 Mi Piace

Parlando delle PA in generale, ma da quello che ho visto penso che valga anche per molte societĂ  miste pubblico privato, ed anche delle regioni, comuni, ecc.
Se lo sviluppa internamente si dovrebbe, e parlo anche delle App.
Se se lo fa sviluppare da una qualche ditta esterna, come accade assai spesso per tutta la PA, dovrebbe lo stesso, ma se non l’ha messa come clausola nel contratto di sviluppo, cosa che assai spesso succede, allora la ditta di sviluppo può rifiutarsi di rilasciare il codice.
Quasi sempre neanche la PA a diritto ad avere il codice sorgente dei software, app, web, che ha pagato.
Spesso il fatto che quella clausola sul codice non venga messa non è affatto una dimenticanza.
Non so se esita una qualche legge, direttiva, ecc dello stato italiano comunitaria che imponga in automatico il rilascio del codice sorgente per tutti i software sviluppati per conto della PA.
Tempo fa lessi che alcuni paesi Europei hanno leggi simili, ma non ne so altro.

Mi ha evidentemente tratto in inganno questo link

Peccato. A rigor di logica mi sarebbe piaciuto che la RAI rilasciasse il proprio codice, pazienza

Be visto che oltre al canone da comunque da un servizio pubblico, sarebbe anche il caso.
Non so se altre al canone sia finanziata in parte ancora dallo stato.

Comunque negli ultimi 10 anni a reso disponibile buona parte del suo enorme archivio via web, per non parlare di tutte le trasmissioni dei canali di Radio Rai disponibili in podcast.

Comunque il problema del rilascio del codice sorgente per tutti quei programmi pagati dalle PA rimane ancora un problema, soprattutto nel caso che quella PA abbia bisogno del codice sorgente dei software che ha pagato per passare da uno sviluppatore ad un altro

2 Mi Piace

Il problema della proprietà d’ingegno delle opere della PA è abbastanza datato.
Il problema è legato all’identificazione della proprietà dei diritti sull’opera intellettuale.

Quando viene commissionato lo sviluppo di un software l’opera d’ingegno è frutto della mente che ne definisce nei dettagli funzionalità, caratteristiche e comportamento.
Ciò significa che non è sufficiente fare un appalto chiedendo ‘la realizzazione di una app di nome Io che consenta alla PA di comunicare con il cittadino’ per detenerne i diritti sull’opera.

Se il capitolato contiene informazioni sufficientemente precise da indicare quali modalità, quali caratteristiche, prestazioni, modalità di deployment, organizzazione dei menu, modalità di interazione con l’utente, etc. etc. etc. allora la titolarità è in capo a chi ha prodotto l’analisi e le specifiche, ed il fornitore è un mero implementatore.
Naturalmente è importante che la PA chiarisca in modo formale con chi realizza le specifiche che l’opera derivante dall’incarico fornito sarà della PA (e sarebbe appropriato che a PA ufficializzasse a priori quale sarà la licenza con cui verrà rilasciato il codice).

Nella PA vi sono una miriade di persone di buona volontĂ  che si rimboccano le maniche e scrivono programmi, database, fogli elettronici particolarmente complessi con il fine di migliorare il funzionamento del proprio Ufficio.
In questi casi la titolarità dell’opera d’ingegno resta loro, e possono revocare il diritto all’utilizzo della propria opera in qualsiasi momento.

Sarebbe pertanto appropriato che la PA si dotasse di regole chiare per la produzione ed il licensing del software, proprio per evitare il problema del lock-in con i fornitori, che poi diventano di fatto monopolisti ed in grado di ricattare la PA sulle funzioni da realizzare, sui costi e sulla qualitĂ  del prodotto che il cliente si trova costretto ad accettare.

Per farlo occorrerebbe inoltre che la PA si dotasse delle competenze necessarie sia per la progettazione del software (analisi e specifiche da inserire nei capitolati) sia di tutti i meccanismi necessari per assicurare la qualitĂ  del software nel corso della sua vita.
Aggiungo inoltre che la PA dispone di un’infinità di shadow software (quell’insieme di programmi, fogli elettronici, database, etc.) che di fatto assicurano efficienza alla burocrazia senza saperlo: sarebbe fondamentale che la PA avviasse un processo di assessment per l’identificazione di tutti questi software, di omogeneizzazione di tutte le versioni diverse ma omologhe, messa sotto controllo di qualità, pubblicazione nel portale del software open source della PA e di documentazione e diffusione sul territorio.

1 Mi Piace

Per esserci venuto a contatto direttamente sia nella PA che ne privato, posso dire che la cosa non è affatto facile,
Ne contratto di appalto TUTTUO deve essere espressamente specificato, ad esempio:
1 - Che il committente ha diritto di ricevere il codice sorgente del programma e di tutti gli update futuri nella forma che permetta la compilazione diretta senza alcun intervento o modifica, si mi sono imbattuto in un caso in cui al committente era stato fornito un codice sorgente che semplicemente non si compilava, ed era stato dato volutamente cosĂŹ per continuare a tenere legato il committente allo sviluppatore.
2 - Che ha pieno diritto di utilizzare il codice sorgente in qualsiasi forma egli ritenga opportuno, anche cedendolo a terzi, senza doverne dare comunicazione alla società che l’ha realizzato e senza dovere pagare alcun diritto d’autore, anche in questo caso mi sono trovato di fronte a casi in cui il committente veniva poi bloccato da assurde richiesto di pagamento di diritti d’autore, e permessi di ogni tipo.

Sopratutto la parte dei diritti d’autore è importante, perché se non ben specificato chi ha realizzato materialmente il software ti può comunque bloccare.
Detta in parole povere bisogna far firmare un contratto con chi realizza il software che dica io ti pago, tu fai il software e poi il software sia in forma di codice che compilato è mio per farne quello che voglio, senza che io ti debba piÚ alcun compenso di alcun tipo, tutti i diritti sul software di qualsiasi tipo passano a me committente.
Stessa cosa quando si tratta di far realizzare qualche tipo di database, dove bisogna specificare sia riguardo alla parte di programmazione, si riguardo hai dati che verranno poi caricati nel database.

Stai quindi dicendo che le linee guida su approvvigionamento e riuso del software nella p.a. non hanno basi giuridiche?

Comunque, non vorrei sbagliare, i diritti di utilizzo e di sfruttamento anche economico sono ben cedibili, quelo che non è disponibile (cioè vendibile, trasferibile ecc.) è il diritto a essere riconosciuto autore dell’opera (software o altro).

Non è esattamente così. Nel caso di un programmatore che sviluppa un software, il diritto d’autore, se il programmatore è assunto, passa automaticamente al datore di lavoro, non al committente. Spesso il software viene sviluppato in modo agile, ossia senza un’analisi iniziale completa. Il datore di lavoro ha solo passato l’incarico dal committente allo sviluppatore.

A proposito, c’è qualche indicazione sul fatto che il software sviluppato per la digitalizzazione in ambito PNRR sia licenziato con EUPL?

Qualsiasi PA, per poter rilasciare con licenza libera qualsiasi opera deve in primis possederne la titolaritĂ .
E credo che non esista nella PA un censimento delle sue proprietĂ  e dei relativi diritti di utilizzo.

Oltre a ciò occorre andare a verificare quali parti delle opere siano rilasciate con licenza libera, e quali invece siano state integrate ma siano soggette a licenza proprietaria.
Da ultimo, occorre verificare quale parte abbia avuto la PA nella realizzazione dell’opera, se semplicemente come indicatrice delle sommarie esigenze da soddisfare, o come partecipe attivo nella definizione dell’analisi e delle specifiche.

Un ottimo riepilogo delle norme inerenti la proprietà d’ingegno può essere trovato qui: Contratto di sviluppo software - Contratti - Notizie Giuridiche - Brocardi.it
Gli ultimi due paragrafi sono un’ottima sintesi generale.

Qui (https://www.agid.gov.it/sites/default/files/repository_files/lg-acquisizione-e-riuso-software-per-pa-docs_pubblicata.pdf) le linee guida dell’AgID per l’acquisizione ed il riuso del software per le PA.

Fondamentale è l’art. 3.7.2: *<<Come già discusso in Titolarità (pagina 3), l’amministrazione deve assicurarsi la piena titolarità del software *
realizzato ex novo. Si rimanda al citato paragrafo per ulteriori informazioni.>>

Un utile elenco di domande e risposte sul tema può essere consultato qui: Domande Frequenti

2 Mi Piace