----

Introduction

Introduction

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 Numerous initiatives from grassroots, academic and business communities have developed products they released following open source principles [1][MH1] . Altogether, these initiatives framed the concept of Open Source Hardware (OSH) that extends the well-established approach to intellectual property at work [R(2] in Open Source Software management in open source software to the realms of physical artifacts [2]. They [D(W3] implement This implements an alternative approach to conventional technology [D(W4] development product development that bears a formidable potential [D(W5]  for organizational and business innovation [ZL6] [R(7] .In spite of a growing[D(W8]  popularity and relevance, the concept of OSH still experiences the typical issues faced[D(W9]  by any new concept seeking for settlement. 3].

The process of charting a consistent identity based on enforceable commonly acknowledged definitions and sharp compliance criteria[D(W10] [R(11]  is made difficult by the assessable criteria is made difficult by the multifactorial and partly ill-defined nature of openness and freedom once applied to physical products [34]. A thorough analysis of the usage made of the term in practice showed a wide range of documentation sharing practices In practice, the presupposed information disclosure is applied in very different ways, resulting from a large spectrum of interpretations of the concept of OSH [D(W12]  [45]. In order to gain in visibility in the public debate[D(W13]  and to support the establishment of a common ground[D(W14]  between actors, the term OSH needs to gain in consistency. It needs to be grounded in a 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 [D(W15] .A significant part of the effort to establish standards in OSH has been performed by the Open Source Hardware Association (OSHWA), who . This initiative issued the most widely acknowledged definition [D(W16]  of OSH [56] and collected published a comprehensive set of best practices [67]. Since 2016, the OSWHA it offers a self-certification scheme for OSH originators to signpost their compliance with this definition. However, the definition provided by the OSHWA remains vague[D(W17] , focuses on the licensing aspects of product-related information disclosure[D(W18]  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. Further efforts are required [D(W19] to set 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 [ZL20] [50 [6], which itself extends the Open Source Definition [78]. It acknowledges that OSH is not only a matter of licensing but also a matter of Documentation contents.[D(W21]  The OSHWA definition already addresses the licensing aspects of OSH. The present document addresses aspects of Documentation contents.documentation contents.

By By setting a frame for the Documentation documentation of OSH, this standard fosters comparability of OSH Documentation and contributes to the general improvement of its quality. Therewith, it supports the consistent and transparent labelling [D(W22] [R(23] of OSH and helps building the necessary[D(W24]  trust [D(W25] to 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.

This Alongside with DIN SPEC 3105-2 “Open source hardware — Part 2: Community-based assessment” [9] this standard is the first standard published by the DIN e.V. under a creative common free/open license. Following the principles of open source, anybody can contribute to its further development online. [JB26] [D(W27] [R(28] . Please refer to https://gitlab.com/OSEGermany/OHS to review the current state of ongoing processes and to contribute.

1    Scope

This standard delivers an unambiguous and operational definition of the concept of Open Source Hardware open source hardware and breaks it down into objective criteria for judging the compliance of a Piece piece of Hardware hardware with this definition.

This standard sets requirements for technical Documentationdocumentation. It is designed to be complementary to existing standards and guidelines for technical Documentation documentation (e.g. VDI 4500) and is not aimed at superseding them. It focuses on the aspects of the technical Documentation documentation that are related to its compliance with the principles of open source.

The principles and definitions provided by the DIN SPEC 3105DIN SPEC 3105-1 “Open Source Hardware – Requirements for Technical Documentation” source hardware — Part 1: Requirements for technical documentation” set a frame for the DIN SPEC 3105DIN SPEC 3105-2 “Open Source Hardware – peer-certification” source hardware — Part 2: Community-based assessment”[9] which in turn sets concrete and practical requirements for the establishment of certification assessment procedures.

2    Normative references

This document extends builds upon the OSHWA Definition 1.0 [56] and the Open Source Definition [8].

2    Normative references

There is are no other normative reference references in this document.

3    Terms and definitions

...

3.1  Piece of Hardware

The term “Piece of Hardwareⁱ” refers to any discrete (i.e. countable) physical artefact, e.g. a machine, a device, a piece of equipment, or any other tangible object fulfilling a function or purpose. 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. The term “Piece of Hardware” indifferently refers to a unique physical artefact (e.g. a prototype) or to the concept of a physical artefact that has been physically realized one or more times (e.g. a product model).

3.2   Open Source Hardware

A Piece of Hardware is qualified as open source when its Documentation 1) has been released under licensing terms complying with the OSHWA Definition 1.0 and therewith granting anyone with the Four Rights of Open Source and 2) provides enough information to enable Recipients to exercise these rights. Such a Piece of Hardware is therewith referred to as Open Source Hardware (OSH).

By derogating from the OSHWA Definition 1.0 the licensing terms, under which the Documentation of a piece of OSH has been released, may exclude military use.[R(30] 

3.3  Four Rights of Open Source                                     

The Four Rights of Open Sourceⁱⁱⁱ are in this DIN SPEC defined as the Right to Study, to Modify, to Make, and to Distribute. Granting these rights requires the release of the Documentation under a license compatible with the OSWHA Definition 1.0[ZL31] . Exercising these [D(W32] rights is eventually bound to requirements regarding the content of the Documentation. The Four Rights of Open Source are detailed in the following subsections.

3.3.1  Right to Study

The Right to Study refers to the effective possibility to Access sufficient information to understand the design rationale of a Piece of Hardware and its expected behavior along its Life Cycle. The Right to Study presupposes[R(33]  Access to the Documentation of the considered Piece of Hardware in a format that is of well-established use in the corresponding field of Technology or at least can be processed by software that is generally accessible to the Recipients.

3.3.2  Right to Modify

The Right to Modify refers to the effective possibility to edit the Documentation and therewith to alter the design of a Piece of Hardware. The Right to Modify presupposes the Right to Study as well as the Access[R(34]  to the Documentation of the considered Piece of Hardware in their original editable format or in a format that is of well-established use in the corresponding field of Technology, can be processed by software that is generally accessible to the Recipients, and that contains no less information than the original editable format^iv.

3.3.3  Right to Make

The Right to Make refers to the effective possibility to operate all activities belonging to the Life Cycle of the Piece of Hardware, e.g.[D(W35] [M(36]  to manufacture the Piece of Hardware, to operate it, to carry out maintenance or to process the Piece of Hardware at its end-of-life. The Right to Make presupposes the Right to Study.

3.3.4  Right to Distribute

The Right to Distribute refers to the effective possibility to 1) give or sell the original or a modified version of the original Documentation, to 2) give or sell a Piece of Hardware made based on the original or a modified version of the original Documentation, to 3) operate this Piece of Hardware, carry out maintenance or process it at its end-of-life for a third party[R(37] .

3.4  Technology[R(38] [R(39] 

A Piece of Hardware is the product of one or more Technologies[D(W40] , where Technologies are understood in the sense of craft [R(41] (e.g. woodworking, glassblowing) or in the sense of field of engineering (e.g. mechanical engineering, electronic engineering, or material engineering).

3.5   Technology-specific Documentation Criteria

A Technology-specific Documentation Criteria (TsDC) is a document that specifies additional requirements applying to the Documentation of hardware from a given Technology. Such a document:[M(42] 

• builds upon the present standard without superseding it;
• provides technology specific requirements for all phases of the Life Cycle;
• clearly refers to the present standard;
• is the result of a standardization process[D(W43] [M(44] [M(45] [M(46] .

The list of approved TsDCs is in Annex 1.[M(47] 

3.6  Recipients

The term “Recipients” refers to the group of people addressed by the Documentation; more specifically, the set of documents stated in the corresponding TsDC. This group is characterized by a common state of knowledge and set of abilities enabling members of the group to use the Documentation in order to exercise the Four Rights of Open Source. By default, the Recipients are professionals [R(48] in the fields of Technologies embedded in the Piece of Hardware. The Documentation can define Recipients alternatively to include a larger group of people. However, in any case, the Documentation provides no less information than what professionals in the fields of Technologies embedded in [D(W49] the Piece of Hardware would require to exercise the Four Rights of Open Source.

3.7   Documentation[M(50] 

The Documentation constitutes the “source code” of a Piece of Hardware. It is the set of digitalⁱⁱ documents enabling the execution of all activities belonging to the Life Cycle of a Piece of Hardware[R(51]  that are an original contribution of the creators of that Piece of Hardware[JB52] [D(W53] [M(54] .

The [R(55] Documentation of a piece of OSH contains sufficient and necessary information for the Recipients to understand all these activities without requiring any help from Documentation[M(56]  that is not publicly available[R(57] . Required documents can be represented by a reference to a publicly available document as long as it provides no less information than the originally required document[R(58] .

The Documentation of a piece of OSH bears references of:[M(59] 

1. its authors (and the creators of the Piece of Hardware, if different);
2. its licensing terms;
3. a functional description of the piece of OSH, e.g. what functions it is supposed to deliver, what is the problem it solves, for whom, etc.;
4. a list of Technologies embedded in the Piece of Hardware together with:
5. a mention of the Technology-specific Documentation Criteria[M(60]  respectively applying;
6. all documents required by the mentioned Technology-specific Documentation Criteria;
7. a name or working title given to the Piece of Hardware;
8. a Release number (including the Release date);
9. a version of the Piece of Hardware to which the released Documentation applies[R(61] .

The contents and form of the set of documents constituting the Documentation of a piece of OSH depends on 1) the Technologies embedded in the considered piece of hardware and 2) the knowledge and abilities of the Recipients. Further mandatory requirements applying to the Documentation of a Piece of OSH are given by the Technology-specific Documentation Criteria of the Technologies embedded in the Piece of Hardware. [R(62] A Piece of Hardware can only qualify as OSH if all the Technologies it contains are covered by Technology-specific Documentation Criteria[D(W63] .

3.8   Release

A Release refers to a clearly identifiable version of the Documentation that can be accessed in its entirety even after further modifications brought to the Documentation. A Release bears a release date and is unambiguously identified by a release number, e.g. a unique version number or [D(W64] hash code.

3.9   Access

Documentation is deemed as accessible when:

• the means of downloading it via the Internet is well-publicized and neither involve any charge or any moderation potentially conflicting with the principles of non-discrimination against persons or groups and non-discrimination against fields of endeavor[R(65] . [R(66] 
• the means of downloading it via the Internet is constantly active from the Release date and without interruption.

3.10  Life Cycle

The Life Cycle of a Piece of Hardware is the network of successive and parallel activities required or implied by the realization of the Piece of Hardware. These activities group into three main phases^v:

...

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

3.1  piece of hardware

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?”

3.2   Free License

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:

• Free Software Definition [14];
• Devian Free Software Guidelines [15];
• Open Source Definition [8];
• Definition of Free Cultural Works [16];
• The Open Definition [17];
• OSHWA Definition [6]. 

3.3 open source hardware OSH

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)

1. has been released under licensing terms complying with the OSHWA Definition 1.0 [6] (e.g. CERN OHL v2 [13]) and therewith granting anyone with the four rights of open source hardware (3.4);
2. provides enough information to enable recipients (3.6) to exercise these rights.

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.

3.4 four rights of open source hardware

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.

3.4.1  Right to Study

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)

3.4.2  Right to Modify

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).

3.4.3  Right to Make

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).

3.4.4  Right to Distribute

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)

1. the original or a modified version of the documentation (3.8) and
2. the piece of open source hardware (3.3) made based on the original or a modified version of the documentation (3.8)

3.5  technology

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)

3.6   technology-specific documentation criteria TSDC

document that specifies requirements applying to the documentation (3.8) of open source hardware (3.3) from a given technology (3.5)

3.7  recipients

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).

3.8   documentation

technical documentation; constitutes the “source code” of a piece of open source hardware (3.3)

3.9   documentation release

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)

3.10   lifecycle

network of successive and parallel activities required or implied by the realization of the piece of open source hardware (3.3)

...

4    Symbols and abbreviations[R(70] 

...