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
3 Mi Piace
Salve,
stavo investigando proprio su questo argomento (open source nella P.A.) e non si trova molto, infatti sono arrivato a questo post.
Sarebbe interessante anche per i fornitori terzi, come lâazienda a cui sono legato (DXC, che è presente in diversi contratti di servizi IT per la P.A.), capire come effettivamente aiutare i clienti della P.A. nella gestione di questa tematica. In generale lâiniziativa è ovviamente a carico delle entitĂ della P.A. che commissionano la realizzazione di soluzione e usano servizi al riguardo ma molto spesso ciò non accade; inoltre anche nei capitolati dâoneri degli appalti non câè alcuna accezione sul tema per cui considero il punto 1 della FAQ, giĂ menzionata, come indicazione primaria. Câè un aspetto ulteriore: quando un fornitore include nelle soluzioni, sviluppate per una P.A., software open source e in particolare se questo software open source usa una licenza possa creare dei vincoli non contemplati preventivamente. Spesso le entitĂ della P.A. non hanno la competenza di entrare nel merito di questi aspetti.
Mi chiedo se ci siano novitĂ di rilievo in merito in questi ultimi sei mesiâŚ
Grazie.
Franco Fiorese (DXC)
franco.fiorese@dxc.com