Open source - Cronologia

656066: /* Four freedoms */

2025-07-06T09:14:39Z

Four freedoms

← Versione meno recente		Versione delle 09:14, 6 lug 2025
Riga 56:		Riga 56:
	== Caratteristiche principali ==		== Caratteristiche principali ==
	=== Four freedoms ===		=== Four freedoms ===
	L’espressione '''“four freedoms”''' si riferisce ai quattro principi fondamentali dell’open source, definiti da Richard Stallman.		L’espressione '''“four freedoms”''' si riferisce ai quattro principi fondamentali dell’open source, definiti da Richard Stallman.<ref name="oshistoryieee"></ref>
	*'''La libertà 0''' (cioè la libertà di eseguire il programma come si desidera) implica libertà per qualsiasi persona od organizzazione di utilizzare il programma open source su qualsiasi tipo di sistema informatico, per qualsiasi tipo di attività e senza dover successivamente comunicare con lo sviluppatore o con qualche altra entità specifica. Tale condizione favorisce lo scopo '''individuale''' dell’utente, che però non potrà imporre le proprie intenzioni iniziali a un eventuale utente a cui è stato ridistribuito. Un codice imperfetto, che comprometterebbe l’utilità di un programma, può essere ulteriormente modificato da altri utenti. La libertà di eseguire un programma include, per necessità di cose, la libertà di non eseguirlo.		*'''La libertà 0''' (cioè la libertà di eseguire il programma come si desidera) implica libertà per qualsiasi persona od organizzazione di utilizzare il programma open source su qualsiasi tipo di sistema informatico, per qualsiasi tipo di attività e senza dover successivamente comunicare con lo sviluppatore o con qualche altra entità specifica. Tale condizione favorisce lo scopo '''individuale''' dell’utente, che però non potrà imporre le proprie intenzioni iniziali a un eventuale utente a cui è stato ridistribuito. Un codice imperfetto, che comprometterebbe l’utilità di un programma, può essere ulteriormente modificato da altri utenti. La libertà di eseguire un programma include, per necessità di cose, la libertà di non eseguirlo.
	*'''La libertà 1''' (cioè la libertà di studiare il codice sorgente e di apportare modifiche), per essere in vigore, prevede che sia libero l’accesso al codice sorgente. Il programma deve quindi eseguire incondizionatamente le modifiche apportate da ciascun utente. Per rispettare la condizione posta, è necessario che si possano includere nel programma anche moduli già esistenti, anche se l’utente che apporta le modifiche non ne detiene il ''copyright''. Stabilire il valore delle modifiche in quanto migliori o peggiori contribuisce quindi a non rendere libero un programma, ma in accordo alla libertà 1 è prevista la possibilità di cancellare un programma.		*'''La libertà 1''' (cioè la libertà di studiare il codice sorgente e di apportare modifiche), per essere in vigore, prevede che sia libero l’accesso al codice sorgente. Il programma deve quindi eseguire incondizionatamente le modifiche apportate da ciascun utente. Per rispettare la condizione posta, è necessario che si possano includere nel programma anche moduli già esistenti, anche se l’utente che apporta le modifiche non ne detiene il ''copyright''. Stabilire il valore delle modifiche in quanto migliori o peggiori contribuisce quindi a non rendere libero un programma, ma in accordo alla libertà 1 è prevista la possibilità di cancellare un programma.
	*'''La libertà 2''' (cioè la libertà di ridistribuire copie da altri utenti), implica la libertà di distribuire gratuitamente o addebitando costi di distribuzione, senza chiedere o concedere alcun tipo di permesso, che dall’altra parte permette di conservare e utilizzare privatamente le proprie modifiche per qualsiasi scopo. La libertà di ridistribuire copie deve includere la possibilità di includere forme binarie o eseguibili del programma, che si tratti o no di versioni modificate, nel caso queste non vi siano ancora implementate.		*'''La libertà 2''' (cioè la libertà di ridistribuire copie da altri utenti), implica la libertà di distribuire gratuitamente o addebitando costi di distribuzione, senza chiedere o concedere alcun tipo di permesso, che dall’altra parte permette di conservare e utilizzare privatamente le proprie modifiche per qualsiasi scopo. La libertà di ridistribuire copie deve includere la possibilità di includere forme binarie o eseguibili del programma, che si tratti o no di versioni modificate, nel caso queste non vi siano ancora implementate.
	*'''La libertà 3''' (cioè la libertà di distribuire pubblicamente le proprie modifiche), comprende in sé condizioni analoghe a quanto stabilito per la libertà 2. Contiene però all’interno dei suoi principi il rilascio di una ''licenza libera'', da cui deriveranno naturalmente altre versioni libere arricchite da ulteriori modifiche. ~~<ref name="oshistoryieee"></ref>~~		*'''La libertà 3''' (cioè la libertà di distribuire pubblicamente le proprie modifiche), comprende in sé condizioni analoghe a quanto stabilito per la libertà 2. Contiene però all’interno dei suoi principi il rilascio di una ''licenza libera'', da cui deriveranno naturalmente altre versioni libere arricchite da ulteriori modifiche.

	=== Regola sulla produzione di pacchetti, sulla distribuzione e sull'esportazione ===		=== Regola sulla produzione di pacchetti, sulla distribuzione e sull'esportazione ===

656066: /* Four freedoms */

2025-07-06T09:14:20Z

Four freedoms

← Versione meno recente		Versione delle 09:14, 6 lug 2025
Riga 60:		Riga 60:
	*'''La libertà 1''' (cioè la libertà di studiare il codice sorgente e di apportare modifiche), per essere in vigore, prevede che sia libero l’accesso al codice sorgente. Il programma deve quindi eseguire incondizionatamente le modifiche apportate da ciascun utente. Per rispettare la condizione posta, è necessario che si possano includere nel programma anche moduli già esistenti, anche se l’utente che apporta le modifiche non ne detiene il ''copyright''. Stabilire il valore delle modifiche in quanto migliori o peggiori contribuisce quindi a non rendere libero un programma, ma in accordo alla libertà 1 è prevista la possibilità di cancellare un programma.		*'''La libertà 1''' (cioè la libertà di studiare il codice sorgente e di apportare modifiche), per essere in vigore, prevede che sia libero l’accesso al codice sorgente. Il programma deve quindi eseguire incondizionatamente le modifiche apportate da ciascun utente. Per rispettare la condizione posta, è necessario che si possano includere nel programma anche moduli già esistenti, anche se l’utente che apporta le modifiche non ne detiene il ''copyright''. Stabilire il valore delle modifiche in quanto migliori o peggiori contribuisce quindi a non rendere libero un programma, ma in accordo alla libertà 1 è prevista la possibilità di cancellare un programma.
	*'''La libertà 2''' (cioè la libertà di ridistribuire copie da altri utenti), implica la libertà di distribuire gratuitamente o addebitando costi di distribuzione, senza chiedere o concedere alcun tipo di permesso, che dall’altra parte permette di conservare e utilizzare privatamente le proprie modifiche per qualsiasi scopo. La libertà di ridistribuire copie deve includere la possibilità di includere forme binarie o eseguibili del programma, che si tratti o no di versioni modificate, nel caso queste non vi siano ancora implementate.		*'''La libertà 2''' (cioè la libertà di ridistribuire copie da altri utenti), implica la libertà di distribuire gratuitamente o addebitando costi di distribuzione, senza chiedere o concedere alcun tipo di permesso, che dall’altra parte permette di conservare e utilizzare privatamente le proprie modifiche per qualsiasi scopo. La libertà di ridistribuire copie deve includere la possibilità di includere forme binarie o eseguibili del programma, che si tratti o no di versioni modificate, nel caso queste non vi siano ancora implementate.
	*'''La libertà 3''' (cioè la libertà di distribuire pubblicamente le proprie modifiche), comprende in sé condizioni analoghe a quanto stabilito per la libertà 2. Contiene però all’interno dei suoi principi il rilascio di una ''licenza libera'', da cui deriveranno naturalmente altre versioni libere arricchite da ulteriori modifiche. <ref name=~~“oshistoryieee”~~></ref>		*'''La libertà 3''' (cioè la libertà di distribuire pubblicamente le proprie modifiche), comprende in sé condizioni analoghe a quanto stabilito per la libertà 2. Contiene però all’interno dei suoi principi il rilascio di una ''licenza libera'', da cui deriveranno naturalmente altre versioni libere arricchite da ulteriori modifiche. <ref name="oshistoryieee"></ref>

	=== Regola sulla produzione di pacchetti, sulla distribuzione e sull'esportazione ===		=== Regola sulla produzione di pacchetti, sulla distribuzione e sull'esportazione ===

656066 il 09:13, 6 lug 2025

2025-07-06T09:13:14Z

Mostra modifiche

656066: /* Esempi noti di software open source */

2025-06-26T17:16:00Z

Esempi noti di software open source

← Versione meno recente		Versione delle 17:16, 26 giu 2025
Riga 53:		Riga 53:

	Nonostante queste difficoltà, la diffusione degli ideali del free software ha inciso profondamente sulle modalità di produzione della conoscenza: ha ridefinito il '''ruolo''' dell’autore, rimesso in discussione le '''gerarchie del sapere''' e promosso modelli di cooperazione fondati su coordinazione tecnico-sociale. Questa ha portato alla nascita di ''pubblici ricorsivi'', ovvero '''comunità''' capaci di sviluppare software e licenze che garantiscano la propria stessa sopravvivenza. È proprio questa flessibilità, legata alla pianificazione condivisa e alla possibilità di proporre alternative operative, che permette ai progetti open source di adattarsi e prosperare.		Nonostante queste difficoltà, la diffusione degli ideali del free software ha inciso profondamente sulle modalità di produzione della conoscenza: ha ridefinito il '''ruolo''' dell’autore, rimesso in discussione le '''gerarchie del sapere''' e promosso modelli di cooperazione fondati su coordinazione tecnico-sociale. Questa ha portato alla nascita di ''pubblici ricorsivi'', ovvero '''comunità''' capaci di sviluppare software e licenze che garantiscano la propria stessa sopravvivenza. È proprio questa flessibilità, legata alla pianificazione condivisa e alla possibilità di proporre alternative operative, che permette ai progetti open source di adattarsi e prosperare.

			== Caratteristiche principali ==
			=== Four freedoms ===
			L’espressione '''“four freedoms”''' si riferisce ai quattro principi fondamentali dell’open source, definiti da Richard Stallman.
			*'''La libertà 0''' (cioè la libertà di eseguire il programma come si desidera) implica libertà per qualsiasi persona od organizzazione di utilizzare il programma open source su qualsiasi tipo di sistema informatico, per qualsiasi tipo di attività e senza dover successivamente comunicare con lo sviluppatore o con qualche altra entità specifica. Tale condizione favorisce lo scopo '''individuale''' dell’utente, che però non potrà imporre le proprie intenzioni iniziali a un eventuale utente a cui è stato ridistribuito. Un codice fallimentare, che comprometterebbe l’utilità di un programma, può essere ulteriormente modificato da altri utenti. La libertà di eseguire un programma include, per necessità di cose, la libertà di non eseguirlo.
			*'''La libertà 1''' (cioè la libertà di studiare il codice sorgente e di apportare modifiche), per essere in vigore, prevede che sia libero l’accesso al codice sorgente. Il programma deve quindi eseguire incondizionatamente le modifiche apportate da ciascun utente. Per rispettare la condizione posta, è necessario che si possano includere nel programma anche moduli già esistenti, anche se l’utente che apporta le modifiche non ne detiene il ''copyright''. Stabilire il valore delle modifiche in quanto migliori o peggiori contribuisce quindi a non rendere libero un programma, ma in accordo alla libertà 1 è prevista la possibilità di cancellare un programma.
			*'''La libertà 2''' (cioè la libertà di ridistribuire copie da altri utenti), implica la libertà di distribuire gratuitamente o addebitando costi di distribuzione, senza chiedere o concedere alcun tipo di permesso, che dall’altra parte permette di conservare e utilizzare privatamente le proprie modifiche per qualsiasi scopo. La libertà di ridistribuire copie deve includere la possibilità di includere forme binarie o eseguibili del programma, che si tratti o no di versioni modificate, nel caso queste non vi siano ancora implementate.
			*'''La libertà 3''' (cioè la libertà di distribuire pubblicamente le proprie modifiche), comprende in sé condizioni analoghe a quanto stabilito per la libertà 2. Contiene però all’interno dei suoi principi il rilascio di una ''licenza libera'', da cui deriveranno naturalmente altre versioni libere arricchite da ulteriori modifiche.

			=== Regola sulla produzione di pacchetti, sulla distribuzione e sull'esportazione ===
			Sono anche accettabili regole su come ''pacchettizzare'' una versione modificata, purché non limitino in modo determinante la libertà di distribuire versioni modificate o di produrre versioni modificate, aumentando quindi la complessità. Risulta più controverso un contesto in cui una licenza richiede di cambiare il nome con cui il programma sarà chiamato da altri programmi. Ciò impedisce il rilascio della versione modificata in modo che possa sostituire l'originale quando chiamata dagli altri programmi. Risulta possibile una conciliazione solo con lo scopo di ''aliasing'', cioè una funzionalità che permette di specificare il nome originario del programma come alias della versione modificata.

			=== Licenze e possibilità legali ===
			Se lo sviluppatore di un software ha il potere di revocare la licenza o di sostituirla con una più restrittiva, il programma non può essere considerato '''libero'''. Questo vale anche se la revoca avviene per una violazione da parte dell’utente.
			Inoltre, una licenza libera non può subordinare la sua validità al rispetto delle licenze di altri programmi non liberi. Se, ad esempio, una licenza imponesse all’utente di rispettare le condizioni di tutti i programmi che utilizza, e l’utente facesse uso anche di software non libero, allora sarebbe costretto a rispettare anche le licenze non libere.
			In questo caso, verrebbero meno le condizioni essenziali per definire quella licenza come '''libera''', poiché dipenderebbe dal rispetto di vincoli esterni alla licenza stessa.
			<br>
			È considerato accettabile che una licenza di software libero indichi quale giurisdizione legale si applica, o in quale sede territoriale si risolveranno eventuali controversie.
			Questo tipo di clausole non limita la '''libertà''' del software, ma serve solo a regolare aspetti legali pratici.
			La maggior parte delle licenze di software libero si fondano su principi giuridici che variano a seconda del contesto normativo: '''negli Stati Uniti prevalgono i meccanismi di tutela tramite brevetto''', mentre '''in Italia (e in generale in Europa) il software è protetto principalmente dal diritto d’autore'''.
			Questo comporta dei limiti: da un lato, il diritto d’autore impone restrizioni sull’uso e la distribuzione del software; dall’altro, la licenza libera interviene per neutralizzare o superare quei limiti, concedendo specifiche libertà all’utente.
			Tuttavia, proprio perché la licenza opera nel contesto del diritto d’autore o del brevetto, essa stessa è soggetta a certi vincoli legali. Se una licenza, pur basata sul diritto d’autore, rispetta le condizioni designate da Stallman nella sua teorizzazione delle ''four freedoms'', è improbabile, anche se non impossibile, che si possa incorrere in qualche problema di natura legale.
			Ciò nonostante, alcune licenze di software libero sono basate su '''contratti''', i quali possono imporre una maggiore quantità di restrizioni: vi sono quindi molti modi possibili di infrangere quanto stabilito dalle '''condizioni di libertà''' di una licenza, rendendo complesso il processo di stipulazione di un contratto.
			Se una licenza fondata su un contratto legale introduce restrizioni ai diritti dell’utente che non rispettano i criteri fondamentali del software libero, tali clausole rappresentano una violazione della '''libertà''' garantita dalla licenza.
			In altre parole, anche se il contratto è valido sul piano giuridico, non può limitare le '''libertà essenziali''' dell’utente, come l’uso, lo studio, la modifica o la ridistribuzione del software.<ref>Open Source Initiative (2025), Old Licenses Category, https://opensource.org/licenses-old/category</ref>

	== Esempi noti di software open source ==		== Esempi noti di software open source ==

656066: /* Caratteristiche principali */

2025-06-26T17:15:44Z

Caratteristiche principali

@@ Riga 82: / Riga 82: @@
 === Android ===
 Un esempio particolarmente rilevante di progetto open source su larga scala è Android, il sistema operativo per dispositivi mobili sviluppato inizialmente da '''Android Inc.''' e acquisito da '''Google''' nel 2005. Basato sul ''kernel Linux'' e rilasciato con licenza '''Apache 2.0''', Android ha reso possibile l'espansione di un intero ecosistema di applicazioni e dispositivi, promuovendo la diffusione del modello open source anche nel mercato ''consumer''. Sebbene Google mantenga un forte controllo sullo sviluppo delle versioni ufficiali tramite l’'''Android Open Source Project''' (AOSP), produttori hardware e comunità indipendenti hanno potuto personalizzare il sistema operativo secondo le proprie esigenze. Questa apertura ha favorito l’innovazione e la diversificazione, ma ha anche evidenziato alcune tensioni tra apertura e controllo centralizzato, soprattutto in merito alla presenza di servizi proprietari Google preinstallati su molti dispositivi. Android rappresenta quindi un caso emblematico di come l’open source possa funzionare come infrastruttura abilitante, pur dovendo confrontarsi con logiche commerciali e modelli di organizzazione dei processi decisionali, della partecipazione della comunità e della distribuzione delle responsabilità ibridi.
 == Contributi pubblici e privati su progetti open source ==

656066: /* Licenze e possibilità legali */

2025-06-26T17:15:04Z

Licenze e possibilità legali

← Versione meno recente		Versione delle 17:15, 26 giu 2025
Riga 100:		Riga 100:
	<br>		<br>
	È considerato accettabile che una licenza di software libero indichi quale giurisdizione legale si applica, o in quale sede territoriale si risolveranno eventuali controversie.		È considerato accettabile che una licenza di software libero indichi quale giurisdizione legale si applica, o in quale sede territoriale si risolveranno eventuali controversie.
	Questo tipo di clausole non ~~limitano~~ la '''libertà''' del software, ma ~~servono~~ solo a regolare aspetti legali pratici.		Questo tipo di clausole non limita la '''libertà''' del software, ma serve solo a regolare aspetti legali pratici.
	La maggior parte delle licenze di software libero si fondano su principi giuridici che variano a seconda del contesto normativo: '''negli Stati Uniti prevalgono i meccanismi di tutela tramite brevetto''', mentre '''in Italia (e in generale in Europa) il software è protetto principalmente dal diritto d’autore'''.		La maggior parte delle licenze di software libero si fondano su principi giuridici che variano a seconda del contesto normativo: '''negli Stati Uniti prevalgono i meccanismi di tutela tramite brevetto''', mentre '''in Italia (e in generale in Europa) il software è protetto principalmente dal diritto d’autore'''.
	Questo comporta dei limiti: da un lato, il diritto d’autore impone restrizioni sull’uso e la distribuzione del software; dall’altro, la licenza libera interviene per neutralizzare o superare quei limiti, concedendo specifiche libertà all’utente.		Questo comporta dei limiti: da un lato, il diritto d’autore impone restrizioni sull’uso e la distribuzione del software; dall’altro, la licenza libera interviene per neutralizzare o superare quei limiti, concedendo specifiche libertà all’utente.
	Tuttavia, proprio perché la licenza opera nel contesto del diritto d’autore o del brevetto, essa stessa è soggetta a certi vincoli legali. Se una licenza, pur basata sul diritto d’autore, rispetta le condizioni designate da Stallman nella sua teorizzazione delle ''four freedoms'', è improbabile, anche se non impossibile, che si possa incorrere in qualche problema di natura legale.		Tuttavia, proprio perché la licenza opera nel contesto del diritto d’autore o del brevetto, essa stessa è soggetta a certi vincoli legali. Se una licenza, pur basata sul diritto d’autore, rispetta le condizioni designate da Stallman nella sua teorizzazione delle ''four freedoms'', è improbabile, anche se non impossibile, che si possa incorrere in qualche problema di natura legale.
	Ciò nonostante, alcune licenze di software libero sono basate su '''contratti''', i quali possono imporre una maggiore quantità di restrizioni: vi sono quindi molti modi possibili di infrangere quanto stabilito dalle '''condizioni di libertà''' di una licenza, rendendo complesso il processo di stipulazione di un contratto.		Ciò nonostante, alcune licenze di software libero sono basate su '''contratti''', i quali possono imporre una maggiore quantità di restrizioni: vi sono quindi molti modi possibili di infrangere quanto stabilito dalle '''condizioni di libertà''' di una licenza, rendendo complesso il processo di stipulazione di un contratto.
	Se una licenza fondata su un contratto legale introduce restrizioni ai diritti dell’utente che non rispettano i criteri fondamentali del software libero, ~~allora~~ tali clausole rappresentano una violazione della '''libertà''' garantita dalla licenza.		Se una licenza fondata su un contratto legale introduce restrizioni ai diritti dell’utente che non rispettano i criteri fondamentali del software libero, tali clausole rappresentano una violazione della '''libertà''' garantita dalla licenza.
	In altre parole, anche se il contratto è valido sul piano giuridico, non può limitare le '''libertà essenziali''' dell’utente, come l’uso, lo studio, la modifica o la ridistribuzione del software.<ref>Open Source Initiative (2025), Old Licenses Category, https://opensource.org/licenses-old/category</ref>		In altre parole, anche se il contratto è valido sul piano giuridico, non può limitare le '''libertà essenziali''' dell’utente, come l’uso, lo studio, la modifica o la ridistribuzione del software.<ref>Open Source Initiative (2025), Old Licenses Category, https://opensource.org/licenses-old/category</ref>

656066 il 17:13, 26 giu 2025

2025-06-26T17:13:39Z

← Versione meno recente		Versione delle 17:13, 26 giu 2025
Riga 4:		Riga 4:
	#Poter ridistribuire copie del software		#Poter ridistribuire copie del software
	#Poter distribuire le proprie modifiche		#Poter distribuire le proprie modifiche
	L’approccio open source è basato sulla trasparenza e la collaborazione, dunque le libertà sopra elencate costituiscono una nuova visione della produzione di software, orientata alla cooperazione tra sviluppatori utenti e istituzioni.		L’approccio open source è basato sulla '''trasparenza''' e la '''collaborazione''', dunque le libertà sopra elencate costituiscono una nuova visione della produzione di software, orientata alla '''cooperazione''' tra sviluppatori, utenti e istituzioni.
	<ref name="oshistoryieee">J. M. Gonzalez-Barahona, ''A Brief History of Free, Open Source Software and Its Communitie'', Computer, vol. 54, no. 02, pp. 75-79, Feb. 2021, https://doi.ieeecomputersociety.org/10.1109/MC.2020.3041887</ref>		<ref name="oshistoryieee">J. M. Gonzalez-Barahona, ''A Brief History of Free, Open Source Software and Its Communitie'', Computer, vol. 54, no. 02, pp. 75-79, Feb. 2021, https://doi.ieeecomputersociety.org/10.1109/MC.2020.3041887</ref>

656066 il 17:13, 26 giu 2025

2025-06-26T17:13:10Z

← Versione meno recente		Versione delle 17:13, 26 giu 2025
Riga 4:		Riga 4:
	#Poter ridistribuire copie del software		#Poter ridistribuire copie del software
	#Poter distribuire le proprie modifiche		#Poter distribuire le proprie modifiche
	L’approccio open source è basato sulla ~~'''~~trasparenza~~'''~~ e la collaborazione, le libertà sopra elencate ~~hanno posto~~ una nuova visione della produzione software, orientata alla ~~'''~~cooperazione~~'''~~ tra sviluppatori utenti e istituzioni.		L’approccio open source è basato sulla trasparenza e la collaborazione, dunque le libertà sopra elencate costituiscono una nuova visione della produzione di software, orientata alla cooperazione tra sviluppatori utenti e istituzioni.
	<ref name="oshistoryieee">J. M. Gonzalez-Barahona, ''A Brief History of Free, Open Source Software and Its Communitie'', Computer, vol. 54, no. 02, pp. 75-79, Feb. 2021, https://doi.ieeecomputersociety.org/10.1109/MC.2020.3041887</ref>		<ref name="oshistoryieee">J. M. Gonzalez-Barahona, ''A Brief History of Free, Open Source Software and Its Communitie'', Computer, vol. 54, no. 02, pp. 75-79, Feb. 2021, https://doi.ieeecomputersociety.org/10.1109/MC.2020.3041887</ref>

656066: /* Licenze e possibilità legali */

2025-06-26T08:00:08Z

Licenze e possibilità legali

656066: /* Separazione hardware e software, l’inizio del copyright */

2025-06-25T15:34:18Z

Separazione hardware e software, l’inizio del copyright

← Versione meno recente		Versione delle 15:34, 25 giu 2025
Riga 16:		Riga 16:

	=== Separazione hardware e software, l’inizio del copyright ===		=== Separazione hardware e software, l’inizio del copyright ===
	Il modello di software proprietario nasce con la separazione tra hardware e software, nel 1969, quando '''IBM''' annuncia la separazione di alcuni software dal catalogo principale, vendendoli separatamente rispetto all’hardware. <br>		Il modello di software proprietario nasce con la separazione tra hardware e software, nel 1969, quando '''IBM''' annuncia la separazione di alcuni software dal catalogo principale, vendendoli separatamente rispetto all’hardware.
	Dalla concezione quindi di ''accessorio'' ~~del hardware~~, il software in quel momento ha assunto un proprio valore economico e commerciale. Questo cambiamento aprì la strada alla nascita ~~dell'~~'''industria del software indipendente''', in cui numerose aziende cominciarono a sviluppare e commercializzare programmi destinati a funzionare su hardware prodotto da terzi. Questa evoluzione rese necessaria la definizione di leggi specifiche sul '''copyright''' al fine di tutelare i diritti degli sviluppatori, facendo si che l’utilizzo di programmi informatici fosse soggetto a '''licenze''' e '''restrizioni d’uso'''.		<br>
			Dalla concezione quindi di ''accessorio'' dell’hardware, il software in quel momento ha assunto un proprio valore economico e commerciale. Questo cambiamento aprì la strada alla nascita dell’'''industria del software indipendente''', in cui numerose aziende cominciarono a sviluppare e commercializzare programmi destinati a funzionare su hardware prodotto da terzi.
			Questa evoluzione rese necessaria la definizione di leggi specifiche sul '''copyright''', al fine di tutelare i diritti degli sviluppatori, facendo sì che l’utilizzo di programmi informatici fosse soggetto a '''licenze''' e '''restrizioni d’uso'''.

			Nei primi anni, la protezione giuridica del software si basava quasi esclusivamente sul diritto d’autore, soprattutto nei paesi europei, come l’Italia, dove il software è tuttora considerato alla stregua di un'opera dell’ingegno, assimilabile ai testi o alle composizioni artistiche.
			Negli Stati Uniti, invece, a partire dagli anni ’80, si è assistito a un crescente uso del '''brevetto''' come strumento di tutela del software, in particolare per proteggere algoritmi, processi e funzionalità implementate nei programmi.
			Questa differenza ha avuto un impatto profondo sull’evoluzione del settore: mentre il '''copyright''' tutela ''l’espressione'' del codice (cioè la forma con cui è scritto), il '''brevetto''' si concentra su ''funzionalità tecniche'' o ''idee implementative'' originali, purché soddisfino criteri di novità e utilità industriale.
			In Italia, e più in generale in Europa, l’approccio rimane orientato al diritto d’autore, e i brevetti software sono ammessi solo in casi molto specifici e con maggiore cautela rispetto al contesto statunitense.

	=== Prima distribuzione di software “libero” (anni Ottanta) ===		=== Prima distribuzione di software “libero” (anni Ottanta) ===
	Nonostante la vendita di software proprietario fosse ormai una prassi già a metà degli anni Settanta, alcuni programmi, già agli albori degli anni Ottanta, vengono distribuiti in modo simile al concetto che oggi chiamiamo '''FOSS''' (Free Open Source Software). Tra questi i nomi che spiccano maggiormente sono:		Nonostante la vendita di software proprietario fosse ormai una prassi già a metà degli anni Settanta, alcuni programmi, già agli albori degli anni Ottanta, vengono distribuiti in modo simile al concetto che oggi chiamiamo '''FOSS''' (Free Open Source Software). Tra questi i nomi che spiccano maggiormente sono:

← Versione meno recente		Versione delle 08:00, 26 giu 2025
Riga 95:		Riga 95:

	=== Licenze e possibilità legali ===		=== Licenze e possibilità legali ===
	Se lo sviluppatore di un software ha il potere di revocare la licenza o di sostituirla con una più restrittiva, il programma non può essere considerato libero. Questo vale anche se la revoca avviene per una violazione da parte dell’utente.		Se lo sviluppatore di un software ha il potere di revocare la licenza o di sostituirla con una più restrittiva, il programma non può essere considerato '''libero'''. Questo vale anche se la revoca avviene per una violazione da parte dell’utente.
	Inoltre, una licenza libera non può subordinare la sua validità al rispetto delle licenze di altri programmi non liberi. Se, ad esempio, una licenza imponesse all’utente di rispettare le condizioni di tutti i programmi che utilizza, e l’utente facesse uso anche di software non libero, allora sarebbe costretto a rispettare anche le licenze non libere.		Inoltre, una licenza libera non può subordinare la sua validità al rispetto delle licenze di altri programmi non liberi. Se, ad esempio, una licenza imponesse all’utente di rispettare le condizioni di tutti i programmi che utilizza, e l’utente facesse uso anche di software non libero, allora sarebbe costretto a rispettare anche le licenze non libere.
	In questo caso, verrebbero meno le condizioni essenziali per definire quella licenza come libera, poiché dipenderebbe dal rispetto di vincoli esterni alla licenza stessa.		In questo caso, verrebbero meno le condizioni essenziali per definire quella licenza come '''libera''', poiché dipenderebbe dal rispetto di vincoli esterni alla licenza stessa.
	<br>		<br>
	È considerato accettabile che una licenza di software libero indichi quale giurisdizione legale si applica, o in quale sede territoriale si risolveranno eventuali controversie.		È considerato accettabile che una licenza di software libero indichi quale giurisdizione legale si applica, o in quale sede territoriale si risolveranno eventuali controversie.
	Questo tipo di clausole non limitano la libertà del software, ma servono solo a regolare aspetti legali pratici.		Questo tipo di clausole non limitano la '''libertà''' del software, ma servono solo a regolare aspetti legali pratici.
	La maggior parte delle licenze di software libero si fondano su principi giuridici che variano a seconda del contesto normativo: negli Stati Uniti prevalgono i meccanismi di tutela tramite brevetto, mentre in Italia (e in generale in Europa) il software è protetto principalmente dal diritto d’autore ~~(copyright)~~.		La maggior parte delle licenze di software libero si fondano su principi giuridici che variano a seconda del contesto normativo: '''negli Stati Uniti prevalgono i meccanismi di tutela tramite brevetto''', mentre '''in Italia (e in generale in Europa) il software è protetto principalmente dal diritto d’autore'''.
	Questo comporta dei limiti: da un lato, il diritto d’autore impone restrizioni sull’uso e la distribuzione del software; dall’altro, la licenza libera interviene per neutralizzare o superare quei limiti, concedendo specifiche libertà all’utente.		Questo comporta dei limiti: da un lato, il diritto d’autore impone restrizioni sull’uso e la distribuzione del software; dall’altro, la licenza libera interviene per neutralizzare o superare quei limiti, concedendo specifiche libertà all’utente.
	Tuttavia, proprio perché la licenza opera nel contesto del diritto d’autore o del brevetto, essa stessa è soggetta a certi vincoli legali. Se una licenza, pur basata sul diritto d’autore, rispetta le condizioni designate da Stallman nella sua teorizzazione delle four freedoms, è improbabile, anche se non impossibile, che si possa incorrere in qualche problema di natura legale.		Tuttavia, proprio perché la licenza opera nel contesto del diritto d’autore o del brevetto, essa stessa è soggetta a certi vincoli legali. Se una licenza, pur basata sul diritto d’autore, rispetta le condizioni designate da Stallman nella sua teorizzazione delle ''four freedoms'', è improbabile, anche se non impossibile, che si possa incorrere in qualche problema di natura legale.
	Ciò nonostante, alcune licenze di software libero sono basate su contratti, i quali possono imporre una maggiore quantità di restrizioni: vi sono quindi molti modi possibili di infrangere quanto stabilito dalle '''condizioni di libertà''' di una licenza, rendendo complesso il processo di stipulazione di un contratto.		Ciò nonostante, alcune licenze di software libero sono basate su '''contratti''', i quali possono imporre una maggiore quantità di restrizioni: vi sono quindi molti modi possibili di infrangere quanto stabilito dalle '''condizioni di libertà''' di una licenza, rendendo complesso il processo di stipulazione di un contratto.
	Se una licenza fondata su un contratto legale introduce restrizioni ai diritti dell’utente che non rispettano i criteri fondamentali del software libero, allora tali clausole rappresentano una violazione della libertà garantita dalla licenza.		Se una licenza fondata su un contratto legale introduce restrizioni ai diritti dell’utente che non rispettano i criteri fondamentali del software libero, allora tali clausole rappresentano una violazione della '''libertà''' garantita dalla licenza.
	In altre parole, anche se il contratto è valido sul piano giuridico, non può limitare le libertà essenziali dell’utente, come l’uso, lo studio, la modifica o la ridistribuzione del software.<ref>Open Source Initiative (2025), Old Licenses Category, https://opensource.org/licenses-old/category</ref>		In altre parole, anche se il contratto è valido sul piano giuridico, non può limitare le '''libertà essenziali''' dell’utente, come l’uso, lo studio, la modifica o la ridistribuzione del software.<ref>Open Source Initiative (2025), Old Licenses Category, https://opensource.org/licenses-old/category</ref>

	== Contributi pubblici e privati su progetti open source ==		== Contributi pubblici e privati su progetti open source ==