Open Source Hardware

Hardware Open
Source
Matteo Di Pirro – 1074041
Tecnologie Open Source
Corso di Laurea in Informatica

Un po’ di storia…
Gli inizi
• Nel 1997 Bruce Perens fonda l’Open Hardware Certification Program con l'obiettivo di permettere ai
produttori di hardware di auto-certificare i loro prodotti come "aperti".
• I venditori di hardware certificato avevano il diritto di porre il logo del programma nei loro pacchetti
e di pubblicizzare il fatto che i loro dispositivi erano certificati.
• Chi comprava questi dispositivi aveva la sicurezza che, anche in caso di un cambio di sistema
operativo o di fallimento dei produttori originali, ci sarebbe stato del software scritto per quei
dispositivi.
• Uno dei primi tentativi di estendere le conquiste del software all’hardware.
• Apertura dominio www.openhardware.org.
• 1998:
• David Freeman fonda l’Open Hardware Specification Program (OHSpec).
• Troy Benjegerdens rende pubblica l’intenzione di applicare gli stessi principi del software open
source all’hardware (per progettazione e sviluppo).
• Reinoud Lamberts fonda Open Design Circuits.
• Tra il 1998 e il 1999 Graham Seaman fa vari tentativi di definire l’hardware open source.
2

3
Because copying hardware is so hard, the question of whether we're
allowed to do it is not vitally important. I see no social imperative for
free hardware designs like the imperative for free software. Freedom
to copy software is an important right because it is easy now--any
computer user can do it. Freedom to copy hardware is not as
important, because copying hardware is hard to do. Present-day chip
and board fabrication technology resembles the printing press.
Copying hardware is as difficult as copying books was in the age of the
printing press, or more so. So the ethical issue of copying hardware is
more like the ethical issue of copying books 50 years ago, than like the
issue of copying software today.
Richard Stallman, “On Free Hardware”. Linux Today, 1999
Lo scetticismo di Stallman

La rinascita
• I progetti menzionati fallirono tutti, ma nel 2005, grazie ad Arduino, il movimento riprese vita.
• 2007:
• Nascita di Open Graphics Project e di Trasversal Technology Inc ad opera di Timothy Miller.
• Nascita di Open Hardware Foundation, con l'obiettivo di facilitare la progettazione, lo sviluppo e la
produzione di hardware libero.
• Prima versione della Tucson Amateur Packet Radio Corporation Open Hardware License (TAPR
OHL), con lo scopo di salvaguardare i contributi alla corporazione da un possibile uso commerciale.
• Nel 2009, al Grounding Open Source Hardware summit nasce OHANDA (Open Hardware ANd Design
Alliance) con l’obiettivo di lanciare un servizio per la progettazione di hardware libero basato su un
modello di certificazione e registrazione.
• Definizione di quattro proprietà simili a quelle del software libero.
4

Le quattro proprietà
1. Libertà di usare il dispositivo per qualsiasi scopo.
2. Libertà di studiare come funziona un dispositivo e di cambiarlo.
• L'accesso completo ai documenti di progettazione è una ovvia precondizione.
3. Libertà di ridistribuire il dispositivo (e/o gli schemi di progettazione).
4. Libertà di migliorare il dispositivo, e/o gli schemi di progettazione, e di rilasciare i
miglioramenti al pubblico.
• In questo modo la comunità può trarre beneficio dai miglioramenti fatti.
5

OHANDA
• I progettisti desiderosi di applicare l’etichetta OHANDA dovevano registrarsi al sito e rispettare le quattro
proprietà.
• I produttori ricevevano un ID unico (OKEY). La coppia etichetta/OKEY veniva stampata e incisa su ogni
dispositivo.
• Il collegamento alla documentazione e ai produttori viaggiava con il dispositivo stesso.
• Obiettivi:
1. Rendere pubbliche abbastanza informazioni per poter provare a riprodurre il dispositivo.
2. Collezionare informazioni sulle innovazioni.
3. Garantire la trasparenza.
4. Rendere descrizione e documentazione accessibili pubblicamente.
5. Proteggere la conoscenza comune.
6. Rendere questo «standard» generico, universale e semplice.
6

Workshops e summits
• Nel 2010 Ayah Bdeir, e il suo consulente Creative Commons, John Wiibanks, ebbero varie discussioni
riguardo al lancio, alla gestione e alla protezione di compagnie che operano nel settore dell'hardware
open source.
• Opening Hardware workshop a New York, in concomitanza con un seminario su Arduino. Dalle idee
emerse viene creata la prima bozza di definizione (Open Source Hardware Definition 0.1).
• Un altro summit viene organizzato da Peter Semmelhack e Alicia Gibb, sempre a New York, nel
settembre 2010. Ci furono 320 partecipazioni, e da allora si tiene ogni anno.
• Grazie ai contributi di David Mellis e Windell Oskay si arrivò alla versione 1.0 della definizione. Da allora è
rimasta quella.
• Viene organizzata una competizione per il logo, con la vittoria di questo:
7

Il logo
8

Verso i giorni nostri…
• 2011:
• Nasce la CERN OHL con l’obiettivo di migliorare la qualità degli schemi dei dispositivi usati e di garantire agli utenti (includendo le
compagnie commerciali) la libertà di studiare, modificare e produrre i dispositivi stessi.
• Divisione tra Open Hardware e Open Source Hardware.
• In seguito alla divisione nasce l’Open Source Hardware Association (OSHWA)
• Concetto di «comunità per la comunità»
• Difesa del logo e scelta di non renderlo un marchio registrato.
• Aumento del ruolo e dei poteri dell’OSHWA
• Mantenimento della definizione in varie lingue
• Informazioni sugli standard.
• Educazione del pubblico
9

10
http://www.oshwa.org/wp-content/uploads/2014/08/what-is-open-source-hardware.jpg

Open Source Hardware Definition
I principi
• L’hardware open source è l’hardware il cui progetto è reso pubblico in modo che chiunque possa
studiare, modificare, distribuire, realizzare, e vendere il progetto o l’hardware basato su di esso.
• Il progetto dovrebbe essere disponibile in un formato che permetta modifiche.
• Componenti e materiali disponibili per tutti.
• Strumenti di progettazione open source.
• Condivisione di conoscenza.
11

Introduzione
• Open Source Hardware (OSHW) è un termine che si riferisce ad artefatti tangibili (macchine, apparecchi,
o altro) il cui design è stato rilasciato al pubblico in modo tale che chiunque possa fare, modificare,
distribuire e utilizzare questi dispositivi.
• Hardware e software.
• Garanzia e marchi di proprietà del produttore originale.
12

1 - La documentazione
L’hardware deve essere rilasciato con la documentazione, inclusi i file di progettazione, e deve
permettere la modifica e la distribuzione dei file di progettazione. Se la documentazione non è
fornita con il prodotto fisico, ci deve essere un modo ben pubblicizzato di ottenere tale
documentazione per non più di un ragionevole costo di riproduzione, preferibilmente il
download via Internet senza spese. La documentazione deve includere i file del progetto nel
formato preferito per apportare modifiche, ad esempio, il formato nativo del file di un
programma CAD. File di progettazione volutamente offuscati non sono ammessi. Forme
intermedie analoghe al codice informatico compilato, non sono ammessi come sostituti. La
licenza può richiedere che i file di progettazione siano forniti in formato aperto.
13

2 – Lo scopo
La documentazione per l’hardware deve indicare chiaramente quale parte del progetto, se non
tutto, è stato rilasciato sotto la licenza.
14

3 – Il software necessario
Se il progetto di licenza richiede software, embedded o di altro tipo (firmware o altro), per
funzionare adeguatamente e svolgere le sue funzioni essenziali, la licenza può richiedere che
una delle seguenti condizioni venga soddisfatta:
• Interfacce sufficientemente documentate, in modo tale che si possa scrivere il software open source
che consente al dispositivo di funzionare correttamente e di svolgere le sue funzioni essenziali. Per
esempio, questo può includere l’uso di diagrammi dettagliati della temporizzazione del segnale o
pseudocodice per illustrare chiaramente l’interfaccia in funzione.
• Software necessario rilasciato sotto una licenza open source approvata OSI.
15

4 – I lavori derivati
La licenza deve permettere modifiche e lavori derivati e deve consentire loro di essere distribuiti
sotto gli stessi termini della licenza del lavoro originale. La licenza deve consentire la
produzione, la vendita, la distribuzione e l’uso di prodotti creati dai file di progettazione, del
design dei file stessi, e dei derivati.
16

5 – La ridistribuzione libera
La licenza non può limitare alcuno dal vendere o donare la documentazione del progetto. La
licenza non può richiedere diritti o altri pagamenti per tale vendita. La licenza non richiede
alcuna royalty o tasse relative alla vendita del lavoro derivato.
17

6 – L’attribuzione
La licenza può richiedere documenti derivati, e le comunicazioni di copyright associate ai
dispositivi, per riportare l’attribuzione ai licenzianti quando si fa la distribuzione di file, prodotti
fabbricati e/o loro derivati. La licenza può richiedere che tali informazioni siano accessibili
all’utente finale utilizzando il dispositivo, ma non specifica un formato specifico di
visualizzazione. La licenza può richiedere che i lavori derivati abbiano un nome o un numero di
versione diversi dal progetto originale.
18

7 – Nessuna discriminazione di persone o gruppi
La licenza non deve discriminare alcuna persona o gruppo di persone.
19

8 – Nessuna discriminazione contro i campi di
applicazione
La licenza non deve impedire ad alcuno di fare uso del lavoro (compresi i prodotti hardware) in
uno specifico campo di attività. Per esempio, non deve limitare l’hardware che sia utilizzato in un
business, o di essere utilizzato nella ricerca nucleare.
20

9 – La distribuzione della licenza
I diritti concessi dalla licenza devono applicarsi a tutti coloro ai quali il lavoro viene ridistribuito
senza la necessità di esecuzione di una licenza supplementare per queste parti.
21

10 – La licenza non deve essere specifica per un
prodotto
I diritti concessi dalla licenza non devono dipendere dal lavoro di licenza di un particolare
prodotto. Se una parte viene estratta da un lavoro e usata o distribuita entro i termini della
licenza, coloro a cui viene ridistribuito il lavoro dovrebbero avere gli stessi diritti di quelli che
sono concessi per il lavoro originale.
22

11 – La licenza non deve limitare altro hardware o
software
La licenza non deve porre restrizioni ad altri elementi che sono aggregati con il lavoro di licenza,
ma non derivati da esso. Per esempio, la licenza non deve insistere sul fatto che tutti gli altri
componenti hardware venduti con la licenza siano open source.
23

12 – Licenza deve essere tecnologicamente
neutrale
Nessuna disposizione della licenza può essere basata su una tecnologia individuale, parti o
componenti, materiali o lo stile di interfaccia o l’uso.
24

Postfazione
I firmatari di questa definizione dell’Open Source Hardware riconoscono che il movimento open
source rappresenta solo un modo di condivisione delle informazioni. Noi incoraggiamo e
sosteniamo tutte le forme di apertura e di collaborazione, anche se non si adattano a questa
definizione.
25

Best Practicies
Elementi di un progetto di Hardware Open Source
La condivisione dei seguenti file dovrebbe essere presa in considerazione:
• Panoramica o Introduzione
• File progettuali originali
• Schemi 2D o file CAD.
• Schemi 3D.
• Schemi elettrici.
• Librerie per la modifica dei file software.
• Schemi tecnici aggiuntivi, se necessari.
• Blueprints.
• File di progetto ausiliari
• Schemi 2D esportati (in formati PNG, JPEG, SVG (meglio formati vettoriali).
• Schemi elettrici in formati portabili e pronti per la produzione
• Schemi aggiuntivi in formato portabile.
26

Best Practicies
Elementi di un progetto di Hardware Open Source
• Lista dei materiali
• Software e firmware.
• Foto.
• Istruzioni e altre spiegazioni
• Creazione dell’hardware.
• Uso dell’hardware.
• Progettazione razionale.
27

Best Practicies
Processi e prassi dell’OSHW
• Come progettare l’hardware.
• Software open source.
• Componenti largamente utilizzati.
• Dove memorizzare i file del progetto.
• Licenziare l’hardware.
• Copyleft
• Creative Commons BY-SA.
• GNU GPL.
• TAPR OHL e CERN OHL.
• Permissive
• Licenze BSD.
• Licenza MIT.
• Creative Commons BY.
• No a licenze che impediscono uso commerciale o lavori derivati.
28

Best Practicies
Processi e prassi dell’OSHW
• Distribuzione
• Fornire sempre i link ai file originali.
• Rendere disponibili i file sorgenti.
• Versionare l’hardware.
• Usare il logo dell’OSHW sul prodotto per chiarire quali parti sono open source e quali no.
• Non fare riferimento all’OSHW finché non sono resi disponibili gli schemi originali.
• Basi dell’hardware open source
• Rispettare i marchi registrati.
• Fare miglioramenti utili e rilasciarli open source.
• Condividere i cambiamenti con il creatore originale.
• Essere preparati al fatto che altri potrebbero copiare il progetto.
29

Open Source Hardware
Must
30
Created by the Open Source Hardware Association. Learn more at oshwa.org.
Documento distribuito con licenza CC BY-SA.
http://www.oshwa.org/wp-content/uploads/2014/08/OSHW-May-and-Must.pdf

May
31
Documento distribuito con licenza CC BY-SA.
http://www.oshwa.org/wp-content/uploads/2014/08/OSHW-May-and-Must.pdf

Checklist
32
http://www.oshwa.org/wp-content/uploads/2014/08/oshwchecklist.pdf

Tassonomia della documentazione
Questioni da affrontare
1. Cosa si vuole costruire?
2. Capacità e posizione geografica dei membri della comunità (lingue parlare e Paese di
distribuzione).
3. Come si accederà alla documentazione?
Il successo di un progetto di hardware open source dipende dalla documentazione. Senza
una documentazione facile da capire, un progetto non può essere riprodotto. Senza
riproduzione, un progetto non può crescere.
33

README.txt
• Fornisce una panoramica e guida sviluppatori e contributori attraverso la struttura del progetto.
• Rappresenta l’introduzione, e dovrebbe parlare dei seguenti aspetti:
• Progetto.
• Licenza.
• Attribuzione.
• Tempo di costruzione previsto.
• Costo.
• Livello di esperienza richiesto.
34

Pagina web e file sorgenti
• La pagina web è il punto di entrata al progetto.
• Può reindirizzare a pagine più aggiornate (ad esempio l’account Twitter).
• Può indicare come contattare gli sviluppatori.
• Può includere il logo, per rendere chiaro che quel progetto è open source.
• I file sorgenti sono gli schemi progettuali e le liste di materiali.
• Non devono essere protetti da copyright.
• Devono essere licenziati con licenze open source.
• Attenzione ai formati dei file e alle unità di misura usate.
35

Lista dei materiali e tutorial
• La lista dei materiali è parte integrante della documentazione. Da considerare:
• Traduzioni in più lingue.
• Fornitori affidabili e attivi.
• I datasheets devono essere parte della documentazione.
• Includere i file riguardanti eventuali stampe 3D.
• Includere la documentazione dei progetti riutilizzati.
• I tutorials sono un modo eccellente per educare la comunità.
• Possono essere in formato multimediale o testuale.
• La loro diffusione non ha vincoli.
• Regola della pausa pranzo.
• Bisogna conoscere la comunità per definire il linguaggio da usare.
36

FAQ e Comunità
• Le FAQ sono una parte fondamentale.
• Basi del progetto.
• Livello di esperienza richiesto.
• Come contribuire?
• Come risolvere i problemi più comuni?
• Una comunità forte dipende da dei contenuti forti.
• «Modellare» la comunità.
• «Colla» che tiene insieme la documentazione.
• Separa il progetto dalla «gente comune»
37

Conclusioni
La frustrazione nei confronti dei brevetti
38
It took 121 years for us to get the first 1
million patents. Now it takes more or less
six years to get another million patents.
Tom Ewig, This American Life

Conclusioni
Maturità
Il futuro dell’hardware open source è incerto.
• Alcuni software sono proprietari.
• Non tutti i livelli dell’hardware sono open.
• Materiali grezzi.
• Chip.
• Proprietà Intellettuale di Silicio (SIP) e aziende fabless.
• Caso del Parallax Propeller 1.
39

40
Above all, we hope that our free
software will give you the freedom to
innovate with Parallax!
Ken Gracey, CEO, Parallax Inc.
Conclusioni
Parallax Propeller 1

Conclusioni
Open Source Software VS Open Source Hardware
41
http://www.mouser.it/applications/article-open-source/

Conclusioni
L’hardware open source nel mondo accademico
• Per quanto riguarda la ricerca, l’hardware open source ha quattro benefici chiave:
1. Miglior realizzazione in laboratorio e prestazioni migliori;
2. Maggiore visibilità del progetto;
3. Maggiori possibilità di reclutamento e di trovare fondi;
4. Maggiore volontà degli studenti di lavorare la progetto.
• Sviluppo e condivisione come servizio per gli altri.
• Uso nell’insegnamento.
• Ingegneria.
• Altri corsi.
42

Conclusioni
Uno sguardo al futuro…
• Molta incertezza.
• Varie idee nate dalla comunità:
• «Laundry Label».
• Idea nata da Tom Igoe e Catarina Mota.
• Laundry Label VS Logo.
• Tantissime opportunità di sviluppo e progetti interessanti, anche per fini umanitari.
43

Conclusioni
Il Gamma Cardio CG
44
Gamma Cardio CG is the first open source
certified diagnostic electrocardiograph
with all the design disclosed in a book
from the concept stage to the
certification.
It is intended for anyone interested in
studying, and developing medical
instruments.
The Gamma Cardio CG Team

Conclusioni
Il Gamma Cardio CG
45http://www.gammacardiosoft.it/openecg/

Conclusioni
Speranze
46
I believe open source hardware will have an
important role in the computer industry in the
future, just as open source software has an
important role today.
Jeremy Bennett, Open Source for Hardware?, 2009

47
Groups working together in the open source community will quickly
surpass closed groups through innovation and utilizing one
another’s shared work. It’s not about reinventing the wheel; it’s
about cross-pollinating ideas, building upon, and hacking that wheel
to get to solutions that could not have been created otherwise.
Society has been open sourcing hardware for thousands of years—
it’s how we learn! It is only recent legal structures that have made
intellectual property a priority over sharing. I hope you consider
joining us in enjoying the benefits of open source hardware!
Alicia Gibb, Building Open Source Hardware, 2015
Conclusioni
Speranze

Bibliografia
• Jeremy Bennett. ≪Open Source for Hardware?≫ In: The Ring (2009). url:
http://www.embecosm.com/articles/ear1/open-source-hardware.pdf.
• Simone Cicero. «What Open Source Hardware can Learn from Software». In: Open Electronics (2013). url:
http://www.open-electronics.org/what-can-open-source-hardware-learn-from-software/.
• Alicia Gibb. Building Open Source Hardware. DIY Manufacturing for Hackers and Makers. A cura di Addison
Wesley. 2014.
• Ken Gracey. Propeller 1 Open Source. url: www.parallax.com/microcontrollers/propeller-1-opensource.
• David Mellis. Open-Source Hardware FAQ | Open Source Hardware Association. 2015. url:
www.oshwa.org/faq/.
• Open Hardware Licenses. 2011. url: www.ladyada.net/library/openhardware/license.html.
• OSHWA. Brief History of Open Source Hardware Organizations and Definitions | Open Source Hardware
Association. 2015. url: http://www.oshwa.org/research/brief-history-of-open-source-
hardwareorganizations-and-definitions/.
• OSHWA. Italian | Open Source Hardware Association. 2015. url: http://www.oshwa.org/definition/italian/.
• David Mellis e OSHWA Mailing List. Best Practices for Open-Source Hardware 1.0 | Open Source Hardware
Association. 2015. url: http://www.oshwa.org/sharing-best-practices/.
48

Bibliografia
• Erik Rubow. Open Source Hardware. Rapp. tecn. University of California, San Diego. Jacob School of
Engineering, 2008. url:
https://cseweb.ucsd.edu/classes/fa08/cse237a/topicresearch/erubow_tr_report.pdf.
• Gamma Cardio Soft. Gamma Cardio CG: the certified diagnostic Ecg under Open license. url:
www.gammacardiosoft.it/openecg/index.htm.
• Laura Sydell. 2013. url: www.thisamericanlife.org/radio-archives/episode/496/when-patentsattack-part-
two.
49

Open Source Hardware

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (8)

Similar to Open Source Hardware

Similar to Open Source Hardware (20)

Recently uploaded

Recently uploaded (8)

Open Source Hardware