Welcome Thea Flowers, New OSHWA Board President

I am thrilled to be able to welcome Thea “Stargirl” Flowers as the new OSHWA Board President!

As many members of the OSHWA community already know, Thea is a creative technologist and passionate open source advocate.  She is the creator of the Winterbloom open source synthesizers (many of which are OSHWA certified).  Thea is also the creator of KiCanvas, a maintainer of CircuitPython, and a former Python Software Foundation Fellow.  Oh, and she recently redesigned the certification mark brand guide.

While this marks the end of my tenure as OSHWA Board President, I am excited to remain on the board and support Thea, Alicia, and OSHWA however I can.  I also want to thank Alicia and the OSHWA board(s) for allowing me to serve as Board President for the past few years.  It has been fantastic to be a part of OSHWA’s growth and maturation.

I know the rest of the OSHWA community joins me in celebrating Thea’s new role, and is eager to benefit from the energy and ideas she brings with her.

OSHWA Files Brief in Support of Using, Repairing, and Hacking Things You Own

Earlier this month OSHWA, along with Public Knowledge, the Digital Right to Repair Coalition, Software Freedom Conservancy, iFixIt, and scholars of property and technology law, filed a brief in the US Court of Appeals supporting the principle that owning something means that you get to decide how to use it.  While that principle has been part of US (and, before there was a US, British) law for centuries, recent attempts to protect copyright have worked to undermine it.

We filed the brief in a case that EFF has brought on behalf of Dr. Matthew Green and Dr. bunnie Huang (someone who is well known to the open source hardware community) challenging the constitutionality of parts of the US law that prevent access to digital works.This issue is important to the open source hardware community because owning hardware is a critical part of building and sharing hardware.

The Issue

The case focuses on Section 1201 of the Digital Millennium Copyright Act (DMCA).  The DMCA is probably best known for its Section 512 notice and takedown regime for works protected by copyright online (that’s the “DMCA” in a “DMCA Notice” or “DMCA Takedown” that removes videos from YouTube).  Section 1201 is a different part of the law that creates legal protections for digital locks that limit access to copyright-protected works.  

Basically, Section 1201 is a special law that makes it illegal to break DRM.  And as long as DRM prevents you from using your toaster how you see fit, you don’t really own it. 

These protections were originally designed to protect digital media – think the encryption of DVDs.  However, since code is protected by copyright, and just about everything has code embedded in it, the 1201 protections undermine ownership rights in a huge range of things.

The brief illustrates how 1201-protected DRM undermines traditional rules of ownership in a number of different ways:

  • The right to repair: DRM blocks third-party parts or fixes, monopolizing the repair market or forcing consumers to throw away near-working devices.
  • The right to exclude: DRM spies on consumers and opens insecure backdoors on their computers, allowing malicious software to enter from anywhere.
  • The right to use: DRM prevents consumers from using their devices as they wish. A coffee machine’s DRM may prohibit the brewing of other companies’ coffee pods, for example. 
  • The right to possess: Device manufacturers have leveraged DRM to dispossess consumers of their purchases, without legal justification.

The Challenge

This case is challenging Section 1201 on First Amendment grounds.  As written, the law imposes content-based restrictions on speech.  Tools for circumventing DRM can advise users on how and why to protect their property rights.  Prohibiting them means that the law gives legal benefits to anti-ownership DRM software while criminalizing pro-ownership DRM-circumvention software.

Additionally, whatever one thinks about using DRM to protect digital media, the current law is not well tailored to achieve that goal.  Today, DRM has been added to all sorts of devices that are very far from “digital media” in any reasonable sense.  As the brief notes: 

“Devices like refrigerators have [DRM] not to stop rampant refrigerator copyright piracy, but so manufacturers can maintain market dominance, block competition, and force wasteful consumerism that boosts those manufacturers’ bottom lines.”  

These uses of DRM are protected by the current law but have nothing to do with protecting digital media.

What’s Next

This brief is part of an appeal in the U.S. Court of Appeals for the District of Columbia Circuit.  It will be argued in the coming months.  EFF’s page on the case is here.

We want to end this post with a huge thank you to Professor Charles Duan, the author of our brief.  Professor Duan does a great job of bringing clarity to this important issue facing the open source hardware community. Plus, you always know any brief written by him will include citations reaching back centuries.  This brief shows that case law reaching back to 1604 is still relevant to questions about ownership today!

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.