Revoking Certification for US002346

Today OSHWA is revoking the certification for the SparkFun DataLogger IoT – 9DoF, UID US002346. We are taking this action because the owner of the UID (SparkFun) asked that the certification be reversed due to accidental filing. While the hardware for this project is open source, the firmware is not.

An effective certification program requires ongoing monitoring of certified hardware, both by OSHWA and by the larger open source hardware community.  OSHWA prefers to work with responsible parties to resolve problems with certified hardware and views decertification as a last resort. 

We discuss the decertification process in more detail in our blog post about the first decertification.  You can learn more about the certification program on the certification page and certification FAQs.

A certification logo with the UID crossed out

Revoking Certification for mini:: hardware family

Today OSHWA is revoking the certification for the following hardware:

mini::bike DE000107
mini::lab DE000106
mini::base DE000093
mini::pit DE000096
mini::grid DE000095
mini::out DE000094

We are taking this action because the documentation is no longer publicly available and the parties responsible for the hardware have indicated that they are not in a position to republish it.  The absence of the documentation was brought to our attention by a member of the open source hardware community.

In the past, we have fully removed decertified hardware from the certification directory. However, this time we are keeping the listing in the directory and making two changes:

  1. We are adding “(revoked)” after the hardware name to make it clear that the hardware is no longer certified.
  2. We have updated the documentation links to point to versions of the documentation OSHWA archived at the time of certification.

This second change is possible because OSHWA started archiving documentation as part of the certification process a number of years ago. This archived documentation is usually stored privately. OSHWA does this, in part, in order to avoid creating an alternative (and not updated) documentation archive that competes with the creator’s active documentation. In cases where the documentation is no longer available and OSHWA has an archive copy, OSHWA will add documentation for decertified hardware to https://github.com/oshwa-terminated-cert-docs-repo as part of the decertification process.

An effective certification program requires ongoing monitoring of certified hardware, both by OSHWA and by the larger open source hardware community.  OSHWA prefers to work with responsible parties to resolve problems with certified hardware and views decertification as a last resort. 

We discuss the decertification process in more detail in our blog post about the first decertification.  You can learn more about the certification program on the certification page and certification FAQs. Finally, if you have questions about the certification process, or want to report a problem with a piece of certified hardware, you can always reach out to certification@oshwa.org

Revoking Certification for ES000022

Today OSHWA is revoking the certification for the Atmel SAM D10C Breakout Board by San Antonio Technologies, ESPJ, UID ES000022. We are taking this action because the documentation is no longer publicly available and the parties responsible for the hardware have been unresponsive to our requests to republish it.  This was brought to our attention by a member of the open source hardware community.

An effective certification program requires ongoing monitoring of certified hardware, both by OSHWA and by the larger open source hardware community.  OSHWA prefers to work with responsible parties to resolve problems with certified hardware and views decertification as a last resort. 

We discuss the decertification process in more detail in our blog post about the first decertification.  You can learn more about the certification program on the certification page and certification FAQs.

Graphic representation of the open source hardware universe as being larger than just microcontrollers

The State of Open Source Hardware in 2021

Today OSHWA, in collaboration with the Engelberg Center on Innovation Law & Policy at NYU Law, is excited to launch The 2021 State of Open Source Hardware.  This graphic report builds on data from OSHWA’s Open Hardware Certification Program, the annual Open Hardware Summit, and the annual Open Hardware Community Survey.

Map showing the geographic reach of open source hardware registrations over time.

The state of open source hardware is strong.  In the eleven years since the first Open Hardware Summit we have seen open hardware grow, with new communities creating new hardware for new uses around the world.  Hundreds of pieces of open source hardware have been certified as compliant with the Open Hardware Definition from countries on every continent except Antarctica. 

Chart linking the types of certified open source hardware to the countries where the hardware comes from.

A wide range of companies have been built and grown on the foundation of open source hardware.  Dozens of Ada Lovelace Fellows have helped to diversify the open hardware community.  Nonprofit organizations in academia, conservation, science, medical, and more have helped to broaden the impact of open hardware in innumerable ways.  

The results of the community survey makes it clear that people come to open hardware for a range of reasons and use open hardware to address a range of needs.  However they start with open hardware, once they start using it they are hooked. Community members study designs, adapt them, and build upon existing designs in order to achieve their goals.  Open hardware is used in teaching, the development of commercial products, and everything in between.
What are you waiting for? Click over, check it out, and let us know what you think.  While the state of open source hardware is strong in 2021, we think it may get even stronger in the future.

hardwarex + OSHWA certification logo

HardwareX Integrates OSHWA Certification into Paper Submission Process

Today we are excited to announce that the open hardware journal HardwareX is integrating OSHWA certifications into their paper submission process.  

HardwareX is an open access journal that focuses on free and open source designing, building, and customizing of scientific hardware.  It has long used the Open Source Hardware Definition as a requirement for submissions.  Now HardwareX is also integrating the OSHWA hardware certification program into the paper submission process.

First, HardwareX has updated its guide for authors to encourage (although not require) authors to certify their hardware for open source compliance before, during, or after submitting to HardwareX.  This is a win for authors and for HardwareX.  Authors can use the certification process to make sure that their hardware meets the Open Source Hardware Definition.  Certification is often an iterative process where OSHWA helps creators meet all of the Definition’s requirements.  HardwareX can rely on the OSHWA certification to confirm that hardware complies with the Definition, freeing up resources to review the papers themselves.

Second, OSHWA and HardwareX are standardizing ways to connect HardwareX articles to the Certification Directory.  HardwareX will include OSHWA certification UIDs in their specification tables for articles that include certified hardware.  Creators can update their certification directory listing with the “#HX” tag in the project description, and add a link to the HardwareX manuscript.

As the open hardware community grows, so too do our institutions.  We look forward to finding new ways to collaborate with all of the parts of the community in the future.  If you would like to connect with the certification program, please reach out at info@oshwa.org, check out our certification program API, or just certify your own hardware directly!

Announcing the Open Source Hardware Certification API

Today we are excited to announce the launch of a read/write API for our Open Source Hardware Certification program. This API will make it easier to apply for certification directly from where you already document your hardware, as well as empower research, visualizations, and explorations of currently certified hardware.

OSHWA’s Open Source Hardware Certification program has long been an easy way for creators and users alike to identify hardware that complies with the community definition of open source hardware.  Since its creation in 2016, this free program has certified hardware from over 45 countries on every continent except Antarctica.  Whenever you see the certification logo on hardware:

You know that it complies with the definition and that the documentation can be found using its unique identifier (UID).

What’s New?

The new API supports both read and write access to the certification process.  

Write access means that you can submit certification applications directly instead of using the application form.  If you already have all of the application information in a system, there is no need to retype them into a webform.

We hope that this will make it easier for entities that certify large amounts of hardware to build the certification process directly into their standard workflow.  We are also working with popular platforms to integrate a ‘certify’ button directly into their systems.  

Read access gives you access to information about hardware that has already been certified.  This will make it easier to explore the data for research, create compelling visualizations of certified hardware, and build customized lenses to understand what is happening in open source hardware.  

What Happens Now?

The first thing you can do is get a key and start exploring the API itself.  The team at Objectively has created detailed documentation, code snippets, and sandboxes that make it easy to test out all of the features.  

In the longer term, we hope that the community will build better ways to both submit applications for certification and present information about certified hardware.  OSHWA expects to maintain our application form and certification list for the foreseeable future.  That being said, we are also happy to share (and possibly cede) the stage to better ways to get information into and out of the system as they come along.  

For now, let us know what you do with the API!  You can tweet to us @OHSummit or send us an email at certification@oshwa.org.

2020 Open Source Hardware Weather Report

Today OSHWA, in collaboration with the Engelberg Center on Innovation Law & Policy at NYU Law, is thrilled to release the 2020 Open Source Hardware Weather Report.  The report is a snapshot of the open source hardware community as it exists in 2020, ten years after the first Open Hardware Summit.  It helps existing members of the open source hardware community take stock of where it is, and new members of the community understand the state of affairs today.

The open source hardware community has grown tremendously in the past decade.  That growth is a testament to the viability of the idea of open source hardware.  It can also create challenges when the community wants to talk to itself – let alone create welcoming pathways for new community members.  

The 2020 report allows the open source hardware world to collectively identify what is working, share insights, and rally around shared challenges.  It distills lessons learned and describes the collective understanding of the state of open source hardware.  The report provides guidelines for how open source hardware can be a viable approach to hardware development, as well as identifies situations where open source hardware may not be the strongest approach.  It also examines challenges that remain unresolved in 2020, along with opportunities for open source hardware in the future.

Like any weather report, this document is a snapshot of a moment in time.  It was originally  intended to flow from an in-person workshop held in connection with the tenth anniversary Open Hardware Summit at the Engelberg Center. When the Summit went virtual, that workshop transformed into a series of interviews with a cross section of the open source hardware community.

Common themes, concerns, and challenges emerged during those discussions.  The report provides an opportunity to summarize, distill, and universalize those insights.  It makes it easier for the community to understand what is working in most places, and what challenges still demand our collective attention.

While this report is distilled from community input, it will also benefit from additional thoughts, concerns, and observations.  That is why, in addition to the ‘stable release’ version captured in the PDF, we have also uploaded it to a github wiki.  That is where we invite comments from the community, both on the substance of the report and on the form of the report itself. Let us know if a snapshot report is useful to you, and what we can do to make it more useful in the future.

Finally, thank you to everyone who took the time to contribute to this report.  Some – but certainly not all – of them are listed in the acknowledgement section of the report.  We also welcome outreach from other members of the community who did not participate this year, especially if they might be interested in participating in a future report.

New CERN Open Source Hardware Licenses Mark A Major Step Forward

Earlier this month CERN (yes, that CERN) announced version 2.0 of their open hardware licenses (announcement and additional context from them). Version 2.0 of the license comes in three flavors of permissiveness and marks a major step forward in open source hardware (OSHW) licensing. It is the result of seven (!) years of work by a team lead by Myriam Ayass, Andrew Katz, and Javier Serrano. Before getting to what these licenses are doing, this post will provide some background on why open source hardware licensing is so complicated in the first place.

While the world of open source software licensing is full of passionate disputes, everyone more or less agrees on one basic point: software is fully protected by copyright. Software is ‘born closed’ because the moment it is written it is automatically protected by copyright. If the creator of that software wants to share it with others, she needs to affirmatively give others permission to build on it. In doing so she can be confident that her license covers 100% of the software.

At least at an abstract level, that makes open source software licenses fairly binary: either there is no license or there is a license that covers everything.

Things are not as clean in open source hardware. Hardware includes software (sometimes). It also includes actual hardware, along with documentation that is distinct from both. Hardware’s software is protected by copyright. The hardware itself could be protected by an idiosyncratic mix of rights (more on that in a second) that include copyright, patent, and even trademark. The result of this is, at a minimum, an OSHW license needs to be aware of the fact that there may be many moving intellectual property pieces connected to a single piece of hardware – a fairly stark contrast to open source software’s ‘everything covered by copyright’ situation.

OSHW Licenses are Hard 2: Coverage is Hard to Generalize

The (at least superficially) straightforward relationship between software and copyright makes it easy to give generalized advice about licensing and to develop licenses that are useful in a broad range of situations. A lawyer can be fairly confident that the advice “you need a copyright license” is correct for any software package even without having to look at the software itself. That, in turn, means it is safe for non-lawyers to adopt “I need a copyright license for my software” as a rule of thumb, confident that it will be correct in the vast majority of cases. It also means that software developers can be confident that the obligations they impose on downstream users – like an obligation to share any contributions to the software – are legally enforceable.

As suggested above, hardware can be much more idiosyncratic. The physical elements of hardware might be protected by copyright – in whole or in part – or they might not. That means that the hardware might be born closed like software, or it might be born open, free of automatic copyright protection, and available for sharing without the need for a license. The flip side of this ambiguity is that a creator may be able to enforce obligations on future users (such as the classic copyleft sharing obligations) for some hardware, but not for other hardware. Expectations misalignment with regards to these kinds of obligations can create problems for creators and users alike.

All of this means that it can be hard to create a reliable software-style licensing rule of thumb for OSHW creators. Many OSHW creators end up following the practices of projects that went before them and hoping for the best. In fact, this ‘follow others’ model is the premise for the educational guidance that the OSHWA makes available.

OSHWA’s Approach

One of the many questions all of this sets up is a bundling vs breakout approach to licensing. Is it better to try and create an omni-license that covers the IP related to software, hardware, and documentation for OSHW, or to suggest users pick three licenses – one for software, one for hardware, and one for documentation? A creator could make very different choices about sharing the three elements, so the omni approach could get complicated fast. At the same time, having three distinct licenses is a lot more complicated than just having one.

OSHWA ultimately decided to go with the three license approach in our certification program. This was driven in part by the realization that there were already mature licenses for software (OSI-approved open source software licenses) and documentation (Creative Commons licenses). That allowed OSHWA to take a “don’t do anything new if you can avoid it” approach to licensing education. It also required us to recommend licenses for hardware.

Existing OSHW Licenses

While many open source hardware creators use software (such as the GPL) or documentation (Creative Commons) licenses for hardware, neither of those licenses were really written with hardware in mind. Fortunately, there were three existing hardware licenses. OSHWA provided a quick comparison between the three licenses: CERN 1.2, Solderpad, and TAPR. Although all of these licenses were good first steps, they were all developed fairly early in the history of open source hardware. Solderpad and TAPR in particular were essentially designed to add hardware wrappers to existing open source software licenses.

CERN 2.0

CERN’s 2.0 licenses have been informed by all of the developments and thinking around open source hardware and licensing in the seven years between the release of 1.2 and today. In recognition that creators may be interested in multiple types of openness and obligations on downstream users, they come in the flavors: the strongly reciprocal S variant, the weakly reciprocal W variant, and the permissive P variant. While this structure makes it hard to mix reciprocities (by, for example, requiring strong reciprocity on documentation and weak reciprocity on the hardware itself), they provide a clear way for hardware creators to license the hardware portion of their projects. This is a deeply reasonable approach.

CERN’s ‘Available Components’

One evergreen question for open source hardware is ‘open down to what?’ Your design may be open, but does that mean that all of your components have to be open as well? Did you have to use open source software to create the design? Running on an open source operating system? Running on open source silicon?

OSHWA’s certification program addressed this question with the concept of the ‘creator contribution.’ The idea is that the creator must make available and openly license everything within her power to make available and open. Generally those will be her designs, code, and documentation. It is fine to include components sourced from third parties (even non-open components) as long as they are generally available without requiring an NDA to access.

CERN’s ‘available component’ definition achieves much the same goal. As long as a component is generally and readily available, and described with enough information to understand their interfaces, they do not themselves have to be open. Of course, both the contours of the creator contribution and available component may vary from hardware to hardware. Hopefully time and experience will help give us all a better sense of how to draw the lines.

Let’s See How it Goes

This post has mostly focused on the CERN license’s role in helping making ‘born closed’ components more open through licensing. There is a flip side to all of this: what happens when a license is used on a ‘born open’ piece of hardware. That can give both users and creators a distorted sense of their obligations when using a piece of hardware. However, that is probably a problem for public education, not license design.

This is an exciting time for open source hardware. CERN’s new license is a big step forward in licensing. As it is adopted and used we will learn what works, what doesn’t, and what tweaks might be helpful. The best way to do that is to use it yourself and see how it fits.

How We Made the Open Hardware Summit All Virtual in Less Than a Week

Screenshot from a panel discussion

First, thank you again to everyone – speakers, participants, and sponsors – for a fantastic 10th anniversary Open Hardware Summit.  We knew the 10th anniversary Summit would be one for the ages, although we didn’t quite expect it to be because it became the first virtual Summit. 

Thanks to the timing of the Summit, the 10th anniversary Summit ended up being many people’s first virtual summit of the Covid-19 era (that includes the organizers).  Unfortunately it looks like it is unlikely to be the last. In the hopes of helping event organizers struggling with the same challenges, this blog post outlines the decisions we made and the steps we took to make it happen.

Quick Context

The Open Hardware Summit is an annual gathering of the open source hardware community held by the Open Source Hardware Association (OSHWA).  This year OSHWA partnered with the Engelberg Center on Innovation Law & Policy at NYU Law to host the event in New York City.  The event usually brings together hundreds of community members and speakers from around the world.  It was scheduled for March 13, 2020.

While the situation has been evolving for some time, as recently as March 5th (8 days before the Summit) we thought that holding a reduced in-person version of the event was the right decision.  By March 8 (5 days before the Summit) that was no longer tenable and we announced that the Summit was going all virtual.  That was the right decision, but what does going all virtual mean?

Priorities

We had two major priorities for the virtual Summit:

  1. Online streaming video of all of the speakers and panels.
  2. A community space for discussions and coming together.

Video

The live stream of the Summit had to be both accessible to our viewers and easy to join for our speakers and panelists.  After considering some options and consulting with experts in our community (huge thank you to Phil Torrone at Adafruit for the guidance), we concluded that a combination of YouTube and StreamYard would be the best option.

YouTube worked for our community because it is easily accessible on a wide range of platforms in most of the world.  That meant that just about everyone would be able to see the Summit from wherever they were.

StreamYard made it easy to manage the backend.  Speakers could join a virtual green room before their talk and our technical testing the day before the Summit made it clear that it was easy for them to share their slide presentations as well.  One of the members of the Summit team was able to easily add and remove people (and their screens) to the live feed, along with stills and slides for introductions, sponsors, and everything else.

Community Space

We also looked at a number of options for online discussions.  We decided that a discord server would be the best option for the open source hardware community. Discord allowed us to open the space to anyone who wanted to join, while at the same time giving us moderation control over the discussion (huge thank you for Lenore Edman from Evil Mad Scientist Laboratories for jumping in as a moderator).  Many community members were already comfortable with discord, which was also a bonus.

We also decided to use discord for a version of Q&A for the speakers.  One option would have been to try and integrate video questions from the audience into the live stream. That would have been technically possible with StreamYard (probably…), but it seemed like an unnecessary logistical complication for the organizers.  As an alternative we decided to set up separate discord channels for each of the speakers. That allowed the speakers to end their talk and move to their discord channel for further discussions.

One unexpected and welcome development was that the discord server grew into a larger community hub, with channels devoted to solutions to Covid-19, community announcements, hacking the conference badge, and even virtual conference tips.  We may decide to maintain the server well beyond the Summit as a community space.

It Mostly Worked

We scheduled brief runthroughs with all of the speakers the day before the Summit. Everyone had a chance to get comfortable with the process and work out any last minute problems.  On the day of the Summit we embedded the livestream in the Summit site, along with a link to the discord server for discussion. There were a few audio glitches where speakers had to briefly drop out, but all things considered it went pretty smoothly.

Once the Summit was over the entire livestream of the Summit was posted automatically to OSHWA’s YouTube channel.  Within a day or two we had broken out all of the individual talks into a video playlist and pulled the audio from our panel discussion into a stand alone podcast episode.

To the extent that things worked, one of the big reasons was the nature of the OSHWA community.  Besides being generally great and supportive (no small thing), the open source hardware community already sees itself as a community and is already comfortable with connecting via online tools.  That made it easy for them to enthusiastically watch the live stream and jump into the online discussion. Not all types of events have this starting point, which may suggest that they are not great candidates for this type of virtual structure.

If you are reading this because you are working on your own virtual event, good luck!  We are happy to answer questions if you have them. Email us at info@oshwa.org. StreamYard also has a referral program, so if you drop us a line at info@oshwa.org we can give you a $10 credit if you want it.

The 2020 Open Hardware Summit is Going Virtual

In our last update we promised to continue to monitor the coronavirus situation and to update the community as things evolved. Today we are announcing that things have evolved, and explaining what that means for the community and the Summit.

  1. We are switching to an all-virtual summit for 2020.  We are coordinating with speakers to move all presentations to streaming online video.  You can expect a schedule similar to the one we have already announced, as well as a robust set of online chat options for the community to discuss the day’s events.
  2. We also still plan on holding the pre-party happy hour the evening of March 12 for community members who are in NYC.  The happy hour is free to anyone who is able to attend. If you are in the area we look forward to seeing you there.  However, we do not recommend traveling to NYC just for the happy hour.  
  3. We continue to offer full refunds on tickets to anyone who has purchased tickets to the Summit.  Contact info@oshwa.org for more details.
  4. We will be sending full swag bags to all ticket holders.
  5. Next year’s summit will be in NYC again on April 9, 2021. Mark your calendars!

While we are sorry to have to make this change, we are still excited about this year’s Summit.   We have a fantastic lineup of speakers and even more OSHWA announcements planned. While we know that many members of our community will be disappointed not to be able to see each other in person this year, we look forward to seeing all of you virtually on Friday and in person in 2021.

Thank you all again for being part of the open source hardware community!