How do you feel about this article? Help us to provide better content for you.
Thank you! Your feedback has been received.
There was a problem submitting your feedback, please try again later.
What do you think of this article?
Environmental Sensor Development Kit meets well-defined standard for open-source compliance and what this means for users and developers, together with some history.
In this article we take a look at Open Source Hardware Association Certification, what this means in practice, the history behind it and the benefits it affords. Providing an insight also into the certification process for the ESDK platform, which was developed to support the Air Quality Project. But first, let’s start by taking a look at exactly what open-source hardware is.
What is Open Source Hardware?
Put simply, open-source hardware takes the principles and core practices of open-source software and applies these to hardware design. Which is to say that, instead of software source code, hardware design artefacts — such as CAD models, PCB design databases and FPGA RTL code — are published under liberal terms. Of course, some projects, such as the ESDK and the Air Quality project which builds upon this, are comprised of both open-source software and hardware elements.
There are key differences between hardware and software, such as how you might collaborate on the engineering of one versus the other — given that software source code is text which may be easily viewed and edited, whereas e.g. CAD models require specialist software to do the same — but from an open source perspective they are creative works that adhere to the same principles.
Open Source Licensing
Licensing is fundamental to open source and in short, what this does is to permit you to do something which would otherwise be illegal; if I own copyright on a creative work and someone copies this without a license to do so, they would be breaking the law. Hence to permit study, use, modification and the creation of derivative designs, I can publish my PCB files and mechanical CAD models etc. using a licence that explicitly enables this. Typically with some conditions.
Open source licences tend to include at the very least disclaimers concerning fitness for purpose and the most basic conditions tend to be that you must give credit to the creator and attribute them. While some licences will stipulate that you must publish derivative designs under the same licence.
However, an immutable fact of open source and one which has over the years has variously been misunderstood, is that open source is inherently commercial. Which is to say that you can use open-source software and hardware, be it of your own creation or a third party, to make money. Conversely, you simply cannot publish software source code or a hardware design and claim that it is open source, if the terms that it is published under preclude commercial use.
The Open Source Definition (OSD)
The Open Source Initiative logo.
This brings us nicely to the Open Source Definition, without which there would be a great deal of contention over what constitutes open source.
The OSD states 10 criteria and rather than go through each in detail here, we’ll simply summarise and see the above link for comprehensive details. Although note that this was drafted many years ago and with only software in mind, but the principles can equally be applied to hardware.
The definition states that the software source code (or in our case the hardware equivalent) must be made available and freely distributed without the requirement for fees to be paid. Modifications and derivative works must be permitted. There must be no discrimination against persons or groups, nor against any particular field of endeavour. The licence must not be specific to a particular product, nor restrict other software, and it must be technology-neutral.
So although drafted with software in mind, we can easily see how to apply these principles to the licensing of hardware designs. For example, we could not publish a design under a licence which precludes commercial use or publish only Gerber files or schematics, and at the same time meet the OSD criteria; this would discriminate against field of endeavour, and not constitute the equivalent of the source code (with a PCB design this would be the EDA tool files).
This is straightforward enough, but back when open-source hardware was a relatively new paradigm and the nascent movement was growing at an exponential rate, its definition gave rise to some confusion. In many cases, this was genuine misunderstanding, while in some there were attempts to actually alter its path and put it at odds with the very nature of open-source.
Some creators published designs advertised as open source under non-commercial licences, while some vendors advertised “open source” products with only PDF schematics available. Journalists would sometimes refer to single-board computers (SBCs) as “open source hardware”, simply because they ran open source software — despite hardware designs not being available. Even one board member of an open source software foundation was noted as suggesting that there were different definitions of open source hardware, despite the fact that the OSD remained applicable.
The Open Source Hardware (OSHW) Definition
The Open Source Hardware Association logo.
The Open Source Hardware Definition sought to bring additional clarity and this was based heavily on the original OSD, with changes mostly to use terminology that is a better fit for hardware, plus some additional criteria regarding documentation and making the scope clear (perhaps not all of the hardware design is open source), and concerning software necessary to operate the hardware.
Broadly speaking, we can say that the OSD and OSHW Definition are pretty much the same, certainly in terms of the spirit and principle outcome.
The OSHW Definition was a community effort driven by the Open Source Hardware Association and it was well received, with signatories including myself and many others who were actively involved in one way or another driving the open source hardware movement forwards.
Though I have to admit, that should anyone ask for or question the definition of open source hardware, I continue to simply point to the OSD, which is absolutely pivotal to open source.
The Open Source Hardware Logo was the first attempt at having a recognisable brand for marketing open source hardware as a wider movement and something which adds value. As can be seen, this once again borrows from open source software and is heavily based on the Open Source Initiative (stewards of the OSD) logo.
Designs which comply with the Open Source Hardware Definition may add the logo to their PCB silkscreen or otherwise apply it to hardware, as well as using it in marketing. As such, the logo and the Open Source Hardware Definition together provide a sort of self-certification scheme. Albeit a rather relaxed scheme and the logo has been used in contexts where it shouldn’t have been, with little recourse, both legally and in terms of resources, to bring about compliance.
Enter formal certification from the Open Source Hardware Association.
Like a number of others when first announced, I have to confess to initially having had serious reservations about the OSHWA Certification scheme partly because I didn’t see the need for a third way to define open-source hardware. Also because not all details were initially clear and a suggestion of signing up to increasing financial penalties for non-compliance, sounded decidedly unattractive.
However, we’ll come on to the certification scheme details and suffice to say that I’ve since arrived at the conclusion that it can be of significant benefit since it assures a certain level of compliance insofar as this is easily achievable — and importantly, it is optional; hardware can still be open source without it being certified, but it makes it quicker and easier to recognise when it is.
In order to certify an open-source hardware project the following materials are required to be published under recognised open-source licences:
- Software (if any)
In addition, to which, the applicant must confirm key things such as, “The project is licensed in a way to allow for modifications and derivative works without commercial restriction”, and “There is no restriction on the use by persons or groups, or by the field of endeavor.” In effect reconfirming that which is stated by the licence, so as to ensure there is absolutely no ambiguity.
The applicant must also confirm that “Where possible, I have chosen to use components in my hardware that are openly licensed”. A somewhat softer requirement of good intention, while not constraining the project in such a way that it might incur additional costs, compromise functionality, or actually in the majority of cases, prove impossible.
In addition to basic criteria, the certification programme has:
- A set of overall requirements which must be complied with
- A certification mark licence agreement
- Certification mark usage guidelines
The requirements provide an overview and describe the process, along with details of the term of certification (1 year and then renewed annually) and versioning (each version of a project must have its own registration). It also includes details of the enforcement process.
The licence agreement is the legal document which grants permission to use the certification mark, albeit with certain terms and conditions. The agreement also states the enforcement process and has clauses covering typical things such as indemnification, warranties and governing law etc.
The enforcement provisions are perhaps the most contentious since they state that monthly fines may be applied for non-compliance, starting at $500/month and increasing at the two-year mark up to $10,000/month. However, it is important to remember that non-compliance means using the mark when you do not have a right to. Which may be a result of having never secured certification in the first place, or possibly having achieved certification and then using the mark with another version — later or earlier hardware revision — and which has not been certified.
Furthermore, fines for non-compliance are only imposed after a period of 180 days from first being notified, with additional measures being taken prior to this. In short, the primary objective is to protect the mark and maintain its value, by ensuring one of either compliance or cease of use.
Just to be absolutely clear, it is creators who use the mark without having gained certification who may be fined and not customers or end users.
It is this enforcement lever which fundamentally affords the certification mark far greater value than the open-source hardware logo, with fines only as a last resort. In addition, each certified project is assigned a unique ID (UID), which may be combined with the mark for use by the creator, and is recorded in a directory of projects that is maintained by the Open Source Hardware Association.
Plot of the v1.0 ESDK Main board with OSHWA Certification mark.
Certifying the ESDK was straightforward enough. The Solderpad Hardware License had already been selected for the hardware design and Apache 2.0 was used for the associated software. One omission is that a licence had not been applied to the documentation, so Creative Commons Attribution 4.0 International was selected for this and added to the GitHub repo.
The application process is driven by a simple online form with four sections, where you enter details of the individual or organisation, project, licensing and so forth. Confirming also key criteria as discussed earlier and agreeing with the terms, including those of the OSHWA Open Source Hardware Certification Mark License Agreement. If completing on behalf of an organisation, this will obviously need to be completed by someone with appropriate authority, and corporate legal counsel will very likely want to review the agreement first.
Plot of the v1.0 ESDK NO2 module with OSHWA Certification mark.
Following submission, it was only a matter of around a few weeks — and across the festive period, at that — before confirmation was received back from OSHWA. At this point, the silkscreen was updated on all the boards to bump the revision to v1.0 and add the certification mark. These changes have now been pushed to GitHub. Obviously, should a third party now create a derivative version of any of the boards, the mark would have to be removed, along with the RS DesignSpark logo. However, a new application could then be made to OSHWA for certification.
The ESDK has been assigned UID UK000045 and can now be found listed in the certification directory.
The OSHWA Certification programme is no different to those operated by industry organisations such as the USB Implementers Forum (USB-IF); no permission or agreements are required for integrating USB, but companies must have a valid USB-IF Trademark License Agreement and certify products in order to use the USB-IF logos; hardware which meets the Open Source/Open Source Hardware Definition is still open source hardware and is just not OSHWA Certified.
What OSHWA Certification adds is a level of assurance that a particular version of a hardware design is in fact open source and conforms to the associated best practice. It makes it easier and quicker to identify open-source hardware projects. Importantly, it is entirely optional, does not attempt to redefine open-source hardware and you can choose to certify or not.