Contribute to the development of an international open source hardware standard

[access2perspectives]

Hi GOSH friends,
below I forward you an offer/inquiry to contribute to the development of an international open source hardware standard, initiated by r0g_agency partner Open Source Ecology Germany.

If you are interested to contribute please get in touch with Moe aka Martin Häuer martin.haeuer@ose-germany.de directly.
Best /jo.

Jo Havemann
Global Innovation Gathering e.V.
Wilhelmine-Gemberg-Weg 14
10179 Berlin, Germany

w: globalinnovationgathering.org
e: jo@globalinnovationgathering.org

in: https://www.linkedin.com/GIG
t: @weareGIG

---------- Forwarded message ---------
From: Martin Häuer martin.haeuer@ose-germany.de

Subject: DIN SPEC Open Source Hardware
To: jo@globalinnovationgathering.org

Dear sir or madam,
I would appreciate your efforts in making open source hardware part of the mainstream in product development and beyond.
We would like you to join the process of elaborating a national (to start with) standard in Germany (DIN SPEC) that we are kickstarting now. We believe that this standard will make a big impact for the open source hardware movement - especially regarding the cooperations between open source hardware projects (and investors).

Here is a summary of our project:

# The Starting Point

There are different approaches to what may be called Open Source Hardware or Open Source Product Development, for example. These approaches are sometimes incompatible with each other. There is simply no common definition of when something can be considered open source hardware (and to what extent).

# Our Solution

At a meeting with representatives of the German Institut for Standardisation (DIN), they were very much in favour of the principles of open science and technology. Open Source Ecology Germany would like to initiate the process of publishing a standard precisely for this purpose:

What is Open Source Hardware (incl. possible gradations)?
Which Licenses can be considered as Open Source Hardware? The current potential Open Source Hardware Licenses are partially or fully incompatible to each other and therefore could not be combined.

A combination of open guidelines and DIN SPEC is currently being considered as a solution.

A DIN SPEC is a kind of “pre-standard” that is published via the same channels as an ordinary DIN standard, but is freely accessible (free download) and can be created much less bureaucratic than a classical DIN standard. The preparation of a DIN SPEC is usually associated with a cost of 25,000 € (on the DIN side alone). Currently there is a call for tenders for the remission of these costs. DIN gives our project very good chances of winning.

In order to keep the standard always up to date and to guarantee open collaboration after the publication of the DIN SPEC a guideline is to be issued. This means that any new knowledge gained in this direction can be made immediately accessible without issuing a new version of the DIN SPEC. Simultaneously, a guideline can cover further areas: for example, a simple flowchart for trabsfering a development or adevelopment process into the open source hardware framework.

# Your contribution

I would like to invite you to collaborate on this standard. Your competence in this subject will certainly be very appreciated at the round table. The deadline for application is the 30th September 2018. Please contact me as soon as possible so that I can include you in the project plan.

Currently I am in contact with the following organizations and companies:

• Open Source Hardware Association
• OPENiT Agency
• OPEN! (TU Berlin)
• Open Knowledge Foundation Deutschland
• Wikimedia Commons
• cos(h) (Kooperation mit HAW Hamburg & HOOU)
• Open Design Magazin
• Physikalisch-Technische Bundesanstalt (PTB) / Open Source Imaging
• Institute for Advanced Sustainability Studies e.V. (IASS)
• Institut für Technikfolgenabschätzung und Systemanalyse (ITAS)
• Sono Motors GmbH
• Carla Cargo
  and various individual experts.

If you have further suggestions for organizations and companies you would like to see at the round table, you are welcome to forward me directly to them or to send me their contact information. I will take care of everything else.

Just to avoid misunderstandings: This will NOT become a standard by Open Source Ecology Germany. It should become an open standard for everyone who contributes. Open Source Ecology Germany takes care of the coordination in advance an will be one of the organizations at the round table.

Thank you very much for your attention. Let me know, if you have any further questions.

–
Martin Häuer
Open Source Ecology Germany e.V. (non-profit)
martin.haeuer@ose-germany.de
+49 151 28258755

Knobelsdorffstraße 22
14059 Berlin

Startseite | OSE-Germany e.V.

[jcm80]

There is simply no common definition of when something can be considered open source hardware (and to what extent).

In the spirit of openness and citing previous work, I would have expected to see some mention of the OSHWA definition of open source hardware and why that’s considered not to be commonly accepted or to be insufficient in this context.

Great to see an attempt to embed this in a national standards framework, I’m just unclear because of the omission above if this is editing existing work to fit the German standards framework or creating a whole new definition/standard. The work on guidelines for open hardware development processes seems to me more useful than further work on a definition. However, splitting out components of the project, process and documentation and how open they are like Jérémy Bonvoisin’s work on “What is the “Source” of Open Source Hardware?” would also be interesting.

(I appreciate @access2perspectives is reposting this so we don’t have the original author on the thread, but I’m interested in other people’s thoughts!)

Jenny

[access2perspectives]

Thanks, @jcm80, for the response on this. I have forwarded your remarks to Martin.
Looks as if it is just the right time to engage an international community of Open Hardware experts like GOSH in this, to avoid building yet another standard from scratch. The OSHWA definition looks pretty detailed and reasonable. And yet, given the complexity of the topic as outlined in Bonvoisin’s work and how to fit that into national standards might be a worthwhile endeavour.
Could we open a discussion thread on this where also Martin could be part of to collect the views from within the GOSH community?

[jcm80]

Martin could join the GOSH forum and this thread if he’d like to! It’s open to anyone to participate.

[jarancio]

This will be addressed at next GOSH gathering in Shenzhen, as many members of the community are working on similar topics. I’d wait for this input, valuable as it’s community-generated and discussed ao vivo with diverse representatives all over the world.

Also, I’d definetely reach out to the Open Hardware License people working at CERN.

[Moe]

Hi, thanks for you nice (and pretty fast) reply. And of course the invitation to this forum!

OSHWA made a great definition and it can/will be a base for an official national standard (DIN defines the official state of art and is a great baseline for an international standard like ISO). This might raise the seriousness of the movement pretty much. Also there are different, very interessting approaches like the open-o-meter that might be included in a standard. (https://opensourcedesign.cc/wiki/index.php/Open-O-meter)

However, OSHWA (as far as I know) does not define any license, but only gives restrictions for licenses and how to use them. Open Source Hardware often comes with

the hardware itself --> CERN OHL
software (control module etc.) --> e.g. GPL 3
documentation --> e.g. CC

But these cannot be combined yet as listed in a solid way. For example CC can include a section about “non-commercial” (NC) which can not be applied practically to a product development process. Furthermore it is not fully defined, what data and in what format under what condition for collaboration has to be shared to call a Hardware as Open Source (some people talk about Teslas approach as Open Source, but it’s not). So first of all, there are besides the definition a lot of details to cover, that might help developers to get a strait guideline what steps are necessary. But we don’t want to find these details alone obviously this is the role of the Open Source Hardware experts and community (besides Jérémy is also in already )

So, if you would like to be part of the process or have any further questions, just let me know.

regards
-Martin

[JBonvoisin]

Hi all,

The DIN SPEC 3105 is now officially out. Woop woop!

A lot has been done within the two years that have passed since the first message in this thread. Let me give a short summary of what happened and give an overview of the results (@Moe correct me if I am wrong!).

Background

The starting point of the DIN SPEC 3105 initiative is that the Open Source Hardware Definition gathered by the OSHWA is a great thing, BUT it is quite vague when it comes to define what the “source” of hardware is. Leaning upon the Open Source Definition, it sets quite explicite requirements in terms of hardware documentation licensing, but it says little about what should be included in the documentation. OSHWA’s best practices deliver some insights, but these are recommendations and are very generic. So the idea was to extend the OSHWA definition into a comprehensive OSH definition that sets concrete, clear, verifiable requirements in terms of licensing AND documentation contents.

The project started around two years ago led by @Moe and some GOSH community members involved in the working group (thanks @access2perspectives cessary funding so we can have an official standardisation process at the German Standardisation Organisation. (Why the German Standardisation Organisation? Just a matter of opportunities and contacts. I guess we could have done it with any other standardisation organisation.) It took approx. one year to come to a first draft and one another year to make sure this draft complies with the formal requirements of the German Standardisation Organisation. Looking back at these two years, I have the feeling it was easier to find consensus within the working group and with the OSH community than with the formal requirements of the DIN. Which is a good thing since it means we agreed on the contents!

The working group was composed of: Felix Arndt (Open Source Imaging and Fair GmbH), Tobias Burkert, Lukas Schattenhofer, Mehera Hassan, Robert Mies (TU Berlin), Jerry de Vos (Precious Plastic), Fabian Flüchter (IP Center Bucerius Law School), Martin Häuer, Dietrich Jäger, Timm Wille (Open Source Ecology Germany e.V.), Brynmor John (Field Ready), Manuel Moritz, Tobias Redlich (Helmut Schmidt University), Christian Schmidt-Gütter (Cradle to Cradle e.V.), Emilio Velis (Appropedia Foundation), Joost van Well (Cleopa GmbH), Diderik van Wingerden (think.innovation), Tobias Wenzel (Journal of Open Hardware), Lukas Winter (Physikalisch Technische Bundesanstalt), Lars Zimmermann (Mifactori – Open Circularity) and myself. We had also contacts with a lot of other members of the broad OSH community and gathered quite a lot of feedback, including from OSHWA members.

What is the result of this working group?

A standard in two parts:

• DIN SPEC 3105-1:2020-07, Open Source Hardware - Part 1: Requirements for Technical Documentation. This document delivers an unambiguous definition of the term Open Source Hardware based on objective and enforceable criteria.
• DIN SPEC 3105-2:2020-07, Open Source Hardware - Part 2: Community-Based Assessment. This document defines requirements for an assessment procedure for OSH products based on reviews by OSH community members, emulating the model of peer-review used in scientific publishing.

Where to find it?

• On the official DIN webshop. You can download there the official DIN documents free of charge, however they require a registration (not cool). Here are the links:
• DIN SPEC 3105-1:2020-07
• DIN SPEC 3105-2:2020-07
• On the GitLab repo of the working group. Here it is completely open, no charge, no registration. You can find there the “preprints” of the documents, so to say. That is: same contents, different layout. Here are the links:
• DIN_SPEC_3105-1.md, alternatively as PDF here
• DIN_SPEC_3105-2.md, alternatively as PDF here

What’s new in there?

DIN SPEC 3105 Part 1

Here I would just shamelessely copy and past a chunck of a paper @Tobey , @jcm80 and @Moe wrote for the Journal of Open Hardware to report about current standardisation initiatives in OSH (still under review, preprint available here):

• [The DIN SPEC 3105-1] "breaks down the requirement made by the OSHWA Definition 1.0 to enable “anyone [to] study, modify, distribute, make, and sell the design or hardware” into clear, actionable ways to meet that requirement. Therewith, it defines four “Rights of Open Source” transposing the “four essential freedoms” stated in the Free Software Definition (Free Software Foundation 2019) and links them with concrete requirements in terms of documentation content. These rights are the right to study, to modify, to make, and to distribute.

• It acknowledges that OSH is not only a matter of licensing but also a matter of documentation contents. It differentiates between granting the four rights of open source and enabling others to effectively exercise these rights.

• It acknowledges that the content of the documentation to be shared depends on the hardware technologies embedded in the product under consideration (e.g. electronic hardware). To account for these dependencies, the specification only dictates generic requirements in terms of documentation contents. These contents are in turn specified by so-called “Technology-specific Documentation Criteria” which are specific for each technology.

• It acknowledges that the content of the documentation also depends on the audience targeted by the documentation. It is not practicable to allow “anyone [to] study, modify, distribute, make, and sell the design or hardware” since not everyone has the same capacity to read and make use of product documentation. Instead, documentation is required to address a defined group of recipients. The default is that documentation must provide no less information than what specialists in the fields of this technology would require to exercise the four rights of open source hardware. This allows setting a set of practical minimal expectations in terms of documentation format and completeness that can be outperformed by documenters.

• It adopts a product life cycle perspective, considering that “making” a product is not only about manufacturing it, it is also about using, maintaining, updating and processing it at end-of-life. It defines documentation as information allowing to operate all activities belonging to the product life cycle, from raw material extraction to end-of-life. Therewith, it drops the arbitrary and artificial barrier made by previous standards between production and the rest of the life cycle."

About the “Technology-specific Documentation Criteria”-thing: the idea is that not all “hardware” is equal when it comes to documentation. For example, the documents you need to reproduce 3D-printed gimmick are not the same you need to reproduce a full-sized humanoid robot. In the first case, it does not make sense to ask for a BoM or assembly instructions, but these documents may be essential in the second case. The DIN SPEC 3105 Part 1 takes account of this and defines a generic frame that is complemented by technology specific documentation criteria (TSDC). In the current version of the standard, the TSDCs are pretty light touch in order to facilitate adoption and not to put too much burden on the autors/documenters. Later, when we will have more experience in using the standard, we will be able to narrow down these criteria.

DIN SPEC 3105 Part 2

The idea of the second part is to create a “peer-certification” process allowing the OSH community to certify hardware instead of paying horrendous amounts of money to intransparent third party certification agencies. This process copies open peer-review processes at play in some scientific journals (and what we are working on for the Journal of Open Hardware): all reviews are public and included in the published material. That way, it is very difficuly to cheat and there is a greater chance that the assessment represents on average the view of the community.

Where we stand

The cool thing about this standard is that it is open source itself. It is the first ever standard published by DIN under a CC-BY-SA 4.0 license. This was required to enable a new kind of open standardisation process: from now on, any new version of this standard will be established in the community instead of within a closed working group as usual in standardisation bodies. I think @Moe and other people who dealt with DIN in this project can be especially proud to have made a national standardisation body revise their practices and working on new open processes they may further develop in the future.

The governance guidelines for participating in the further development of the standard itself and the technology specific documentation criteria are respectively here and here. That is: if you think something has to be improved in the current versions, flag an issue in the GitLab repo, join the discussions, fork and edit, the scene is yours!

To conclude

There would be a lot to say about this initiative and even more about how to use it. I tried to say a lot in condensed form and I guess that some parts will not be clear. So maybe I just leave it here and wait for the questions

Maybe @Moe and friends can also tell us a bit more about future steps and associated projects where this standard will be applied?

[Moe]

Whooohooo thanks @JBonvoisin
I didn’t expect such a fast and complete posting here in the forum

Regarding your question for associated projects or applications: I know of the following so far ↓

• OPEN!NEXT (of course) → EU H2020 project to build the ICT infrastructure for OSH + testing business models in the field
• The OSHI → a graph database to connect OSH modules; a metadata standard (building on OKHv1) is to be developed and may be included in the next update of DIN SPEC 3105-1
• The OHO → crawler-based search engine for OSH & DIY; projects can be filtered for standard compliance (once we have any there); we are building a section to enable reviews of hardware designs (still alpha); once published, people can review OSH and the OHO team issues attestations as soon as all misalignments have been resolved and the complete design has been approved at least twice. So OHO is becoming our first ‘conformity assessment body according to DIN SPEC 3105-2’
• OPEN.Effect → assessing the capacities and obstacles of the OSH community in COVID-19 crisis response. DIN SPEC 3105 will be used to assess the maturity level of projects
• IEEE OSCom → a programme to let IEEE members review open source projects (e.g. hardware )

I may have forgotten a few. Lots of stuff happening lately. Besides that DIN is planning more projects with us.

• We have been invited for the circular economy section of the innovation conference (important people coming);
• we’ve been the first concept approved for the digital summit (Merkel and other important people comming);
• DIN is interested in making DIN SPEC 3105 an ISO standard (I pitched it to the corresponding consortium a couple of weeks ago… still a long way to go :D)
• DIN is planning a standardisation bundle for a circular economy for next year. That would be proactive standardisation which is sadly unusual.

If I forgot anyone, please write me so I can edit this post

And again: A HUGE thank you to all of you the work in your field, tireless support and for pushing OSH in science. The world needs that

[Moe]

What we need meanwhile are

1. reviewers for OSH and
2. reviewers for our TsDC

To review the TsDC, just click on the link and share your feedback with us via open issues, forks, merge requests […] or however you like

To become a reviewer for OSH please contact me directly (this forum, telegram or mail). As everything is still in a very early stage, we do not have a registration site yet.

keep it up!

[julianstirling]

When the TsDC says that it is mandatory for an “assembly (general)” should have “joining technology” and “junctions” “defined in CAD model, specified in assembly drawing”. Does that imply that this standard feels that any piece of OSH which comprises of assembled parts is non compliant if there is not CAD assembly.

It is worth noting that most of us in GOSH don’t use proprietary CAD software with fully fledged assembly tools. FreeCAD has a few unofficial, continually changing assembly workbenches, OpenSCAD had nothing. Most of of us take photos of the assembly process and write documentation, something that if done well is of more use than a CAD assembly.

[Tobey]

Well spotted!

[Moe]

Sorry for my late reply @julianstirling ; didn’t get any notification for some reason.
Short answer: No. Geometry must be clear. Same for joining technology etc. If those are specified in a CAD assembly → great! If people prefer to do it via photos and descriptions in a text document → not super editable, but works as well.
That’s also the reason why we split the requirements into “information” (that’s what needs to be provided) and “common source file” (that’s how people usually provide this information; take an alternative path if needed).

Very nice question BTW I feel that I should clarify this point (among others) in a FAQ or so