An increasing number of initiatives from grassroots, academic and business communities adopt the practice of publicly releasing the design files of products they developed [1]. Altogether, these initiatives framed the concept of open source hardware (OSH) that extends the well-established approach to intellectual property management in open source software to the realms of physical artifacts [2]. This implements an alternative approach to conventional product development that bears a formidable potential for organizational and business innovation [3].
The process of charting a consistent identity based on commonly acknowledged definitions and assessable criteria is made difficult by the multifactorial and partly ill-defined nature of openness and freedom once applied to physical products [4]. In practice, the presupposed information disclosure is applied in very different ways, resulting from a large spectrum of interpretations of the concept of OSH [5]. This document aims to provide a definition that delivers clear criteria allowing to distinguish what is OSH from what it is not. It is the result of a standardization process involving major actors in the field and has been the object of a public consultation.
A significant part of the effort to standardize practices in OSH in the past has been performed by the Open Source Hardware Association (OSHWA). This initiative issued the most widely acknowledged definition of OSH [6] and published a comprehensive set of best practices [7]. Since 2016, it offers a self-certification scheme for OSH originators to signpost their compliance with this definition. The OSHWA Definition 1.0 states [6]:
“Open source hardware is hardware whose design is made publicly available so that anyone can study, modify, distribute, make, and sell the design or hardware based on that design.”
Despite the significant contribution it made to the field of OSH, this definition only focuses on the licensing aspects of product-related information disclosure and does not set concrete requirements regarding the content of the information to be disclosed. Thus it defines what “open” means in the context of technical documentation, but a widely acknowledged reference stating what minimal set of information constitutes the “source” of OSH is yet missing.
The present document addresses this gap by extending the OSHWA Definition 1.0 [6], which itself extends the Open Source Definition [8]. It acknowledges that OSH is not only a matter of licensing but also a matter of documentation contents.
By setting a frame for the documentation of OSH, the authors hope to support the consistent and transparent labelling of OSH, to contribute to the standardization and improvement of OSH practices, and ultimately to enable a more mainstream adoption of the principles of open source in the creation of physical artefacts.
Alongside with DIN SPEC 3105-2 “Open source hardware — Part 2: Community-based assessment” [9] this standard is the first standard published by DIN e.V. under a free/open license. Following the principles of open source, anybody can contribute to its further development online. Please refer to https://gitlab.com/OSEGermany/OHS to review the current state of ongoing processes and to contribute.
This standard delivers an unambiguous and operational definition of the concept of open source hardware and breaks it down into objective criteria for judging the compliance of a piece of hardware with this definition.
This standard sets requirements for technical documentation. It is designed to be complementary to existing standards and guidelines for technical documentation (e.g. VDI 4500) and is not aimed at superseding them. It focuses on the aspects of the technical documentation that are related to its compliance with the principles of open source.
The principles and definitions provided by the DIN SPEC 3105-1 “Open source hardware — Part 1: Requirements for technical documentation” set a frame for the DIN SPEC 3105-2 “Open source hardware — Part 2: Community-based assessment”[9] which in turn sets concrete and practical requirements for the establishment of assessment procedures.
This document builds upon the OSHWA Definition 1.0 [6] and the Open Source Definition [8].
There are no normative references in this document.
For the purposes of this document, the following terms and definitions apply.
DIN and DKE maintain terminological databases for use in standardization at the following addresses:
— DIN-TERMinologieportal: available at https://www.din.de/go/din-term
DKE-IEV: available at http://www.dke.de/DKE-IEV
any discrete (i.e. countable) physical artefact
EXAMPLE A machine, a device, a piece of equipment, or any other tangible object.
Note 1 to entry: A piece of hardware can be either a freestanding single component, an assembly that includes two or more components, or a component belonging to an assembly.
Note 2 to entry: The term piece of hardware indifferently refers to a unique physical artefact (e.g. a one-off prototype) or to the concept of a physical artefact that has been physically realized one or more times (e.g. a product model produced in series). Concepts of physical artefacts do not qualify as pieces of hardware as long as they have not been realized at least once.
Note 3 to entry: This document refers to physical objects as pieces of hardware since the word “hardware” is not countable in English. It is thus incorrect to write “a hardware”. Because this document refers to specific products, prototypes, or artefacts that qualify as OSH, it needs to make the word “hardware” countable. Using “piece of” allows to make of “hardware” a countable quantity. It makes it possible to write sentences like “how many pieces of hardware have been certified?”
Open license
license agreement that grants anyone with the right to reuse another creator’s work, giving four major freedoms: use, study, modify and distribute
EXAMPLE CC-BY 4.0[10], CC-BY-SA 4.0[11], GPLv3[12], CERN OHL v2[13]
Note 1 to entry: In this standard, a license complying with the requirements of at least one of the following definitions is considered a free/open license:
hardware for which a free right of any use belongs to the general public and whose documentation (3.8) is completely available and freely accessible on the Internet
Note 1 to entry: A piece of hardware (3.1) is qualified as open source when it's documentation (3.8)
Note 2 to entry: Such a piece of hardware (3.1) is therewith referred to as a piece of open source hardware (OSH), may be certified under terms defined by DIN SPEC 3105‑2, and labelled accordingly.
the right to study (3.4.1), to modify (3.4.2), to make (3.4.3), and to distribute (3.4.4)
Note 1 to entry: Granting these rights requires releasing the documentation (3.8) under a license complying with the requirements of the OSWHA Definition 1.0 [6]. Exercising these rights is bound to requirements regarding the content of the documentation (3.8). The four rights of open source hardware are detailed in the following subsections.
Note 2 to entry: The four rights of open source hardware are a translation of the “four essential freedoms” stated in the Free Software Definition [14] to the context of physical artefacts. These freedoms have been reinterpreted by the Open Source Hardware Association (OSHWA) as the possibility to “study, modify, distribute, make, and sell” hardware. This document reproduces the wording of the OSHWA, where selling is seen as a way of distribution among others.
effective possibility to access sufficient information to understand the design rationale of the piece of open source hardware (3.3) and its expected behaviour along its life cycle (3.10)
Note 1 to entry: The right to study includes access to the documentation (3.8) of the considered piece of open source hardware (3.3)
effective possibility to edit the documentation (3.8) and therewith to alter the design of the piece of open source hardware (3.3)
Note 1 to entry: The right to modify presupposes the right to study (3.4.1).
effective possibility to operate all activities belonging to the life cycle (3.10) of the piece of open source hardware (3.3)
EXAMPLE To manufacture the piece of open source hardware (3.3), to operate it, to carry out maintenance or to process it at its end-of-life.
Note 1 to entry: The right to make presupposes the right to study (3.4.1).
effective possibility to give or sell the piece of open source hardware (3.3) made based on the original or a modified version of the documentation (3.8)
category of production processes used to make the piece of open source hardware (3.3) or a set of physical features embedded in a function of the piece of open source hardware (3.3)
document that specifies requirements applying to the documentation (3.8) of open source hardware (3.3) from a given technology (3.5)
group of people addressed by the documentation (3.8)
Note 1 to entry: This group is characterized by a common state of knowledge and set of abilities enabling its members to use the documentation (3.8) in order to exercise the four rights of open source hardware (3.3). By default, the recipients are specialists in the fields of technologies (3.5) embedded in the piece of open source hardware (3.3), i.e. the persons skilled in the art corresponding to this technology (3.5). The documentation (3.8) can define recipients alternatively to include a larger group of people. However, in any case, the documentation (3.8) provides no less information than what specialists in the fields of technologies (3.5) embedded in the piece of open source hardware (3.3) would require exercising the four rights of open source hardware (3.3).
Note 2 to entry: In order to account for the contribution of multiple specialists required by the development and production of complex pieces of open source hardware (3.3), different recipients can eventually be defined for different parts of the documentation (3.8).
technical documentation; constitutes the “source code” of a piece of open source hardware (3.3)
clearly identifiable version of the documentation (3.8) that can be accessed in its entirety even after further modifications brought to the documentation (3.8)
network of successive and parallel activities required or implied by the realization of the piece of open source hardware (3.3)
Abb. | Term |
OSH | Open Source Hardware |
TsDC | Technology-specific Documentation Criteria |
The required documentation for a piece of OSH is derived from:
A TsDC defines a set of documents that splits into three subsets regarding to the three Life Cycle phases they are relevant for. The documentation may cover less then three Life Cycle phases, while covering the first phase (implementation), in compliance with the Recipients, is the minimum considered necessary[R(73] for a Piece of Hardware to qualify as OSH in the sense of the Four Rights of Open Source.
Open Source Hardware in this sense may be certified, by following DIN SPEC 3105-2, and labeled accordingly.
As a Piece of Hardware can consist of other Pieces of Hardware, an assembly can be covered by a set of Documentations and thus a set of TsDC’s may apply.
Section 3.3 states: “A Piece of Hardware can only qualify as OSH if all the Technologies it contains are covered by Technology-specific Documentation Criteria.” In other words, a Piece of Hardware embedding a Technology that is not covered by any approved TsDC can only qualify as OSH as soon as a new TsDC has been created and approved[JB74] [D(W75] [M(76] [M(77] , so all the Technologies embedded by the Piece of Hardware are covered by an approved TsDC.
[process description; still needs to be clarified with DIN]
i This document refers to physical objects as “pieces of hardware” since the word “hardware” cannot be used alone since it[R(78] is not countable in English. As a consequence, it is not correct to write “a hardware”, the same way it is not correct to write “a water” or “a equipment”. Equally, it is not correct to say “how many hardwares”, but rather “how much hardware” like “how much water”. [R(79] Because this document needs to refer to specific products, prototypes, or artefacts that qualify as OSH, it needs to make the word “hardware” countable. Using “piece of” allows to make of “hardware” a countable quantity. It makes it possible to write sentences like “how many pieces of hardware[D(W80] have been certified?”
ii Paper documents [ZL81] [M(82] do not qualify as Documentation. The first reason is that they are not editable[R(83] . Making modifications to paper documents requires reproducing the whole document. The second reason is that OSH is an Internet phenomenon and only really make sense in this context.
iii The Four Rights of Open Source are a translation of the “four essential freedoms” stated in the Free Software Definition (https://www.gnu.org/philosophy/free-sw.html.en) to the context of physical artefacts. These freedoms have been reinterpreted by the OSHWA as the possibility to “study, modify, distribute, make, and sell[ZL84] ” hardware. This document reproduces the wording of the OSHWA, where selling is seen as a way of distribution.
iv Conversion from a file format to another (especially conversion from edition formats [e.g. docx] to export formats [e.g. pdf]) is often bound to information losses[ZL85] . Converting a FreeCAD file into STEP is transforming a fully parametrized constraints- and feature-based model in to a static network of points (mesh) and losing the ability to edit the shape that is represented by the model or the mesh.
v Documentation does not only facilitate hardware replication or “making”. It also facilitates hardware operation, maintenance, repair, recycling, etc. This document makes no difference between the relative importance of these activities and considers them as equal. Therefore, in this document, the Four Rights of Open Source are not restricted to the sole hardware production phase and covers the whole hardware Life Cycle.
<some text>
Title | Covered Technology | Version | Location |
|
Title | Mechanical component | V1.0 | Hyperlink |
|
Title | Mechanical assembly | V1.0 | ||
Title | Electronic component | V1.0 | Hyperlink | |
Title | Electronic assembly | V1.0 | Hyperlink |
|
Title | Mechatronic assembly | V1.0 | Hyperlink | |
Title | Fluid mechanics | V1.0 | Hyperlink | |
Title | Textile | V1.0 | Hyperlink |
|
… | … | … | … |
|
[1] J. Bonvoisin, T. Buchert, M. Preidel, and R. Stark, “How collaborative is open source hardware? Insights from repository mining,” Design Science Journal, 2018.
[2] A. Powell, “Democratizing production through open source knowledge: from open software to open hardware:,” Media, Culture & Society, Aug. 2012.
[3] J. Bonvoisin and R. Mies, “Measuring Openness in Open Source Hardware with the Open-o-Meter,” Procedia CIRP, vol. 78, pp. 388–393, Jan. 2018.
[4] J. Bonvoisin, R. Mies, R. Stark, and J.-F. Boujut, “What is the ‘Source’ of Open Source Hardware?,” Journal of Open Hardware, vol. 1, no. 1, p. 18, 2017.
[5] Open Source Hardware Association, “Open Source Hardware (OSHW) Statement of Principles 1.0,” 2016. [Online]. Available: http://www.oshwa.org/definition/. [Accessed: 30-Mar-2016].
[6] Open Source Hardware Association, “Best Practices for Open-Source Hardware 1.0,” 18-Apr-2013. [Online]. Available: http://www.oshwa.org/sharing-best-practices/. [Accessed: 30-Mar-2016].
Open Source Initiative, “The Open Source Definition 1.0,” 22-Mar-2007. [Online]. Available: https://opensource.org/osd-annotated. [Accessed: 30-Mar-2016].