This is version 1 of an official certification for open source hardware housed in the Open Source Hardware Association.  It outlines the purpose and goals of such a certification, and establishes the mechanisms for the operation of the certification process itself.

Primary Goals

  • Make it easier for the public to identify open source hardware.
  • Expand the reach of open hardware by making it easier for newer members to join the open source hardware community.

Brief Overview

This is an open source hardware certifications administered by OSHWA.  Users will self-certify compliance in order to use the certification logos.  In doing so, they will submit to oversight and enforcement by OSHWA.

This certification is designed to benefit at least two parts of the open source hardware community.  First, it benefits purchasers of open source hardware by making it easy to identify truly open source hardware in the marketplace.  Projects and products obtaining certification and displaying the certification logo clearly communicate a commonly agreed upon definition of openness with customers and users.  While certification is not a condition for openness, obtaining certification is a way to make it clear to others that a given project is open source hardware.

Second, the certification benefits creators of open source hardware.  By giving creators specific guidelines, certification allows open source hardware creators to confidently declare their projects and products as open source hardware.  Certification also allows creators to defend that declaration by pointing to compliance with specific criteria defined in the certification process.

The certification will operate as a self-certification.  Creators will not apply to OSHWA for certification.  Instead, creators will self-certify compliance with certification standards.  Self-certification will give creators the right to use the OSHWA open source hardware certification logo.  As part of the self-certification process, creators will agree to subject themselves to penalties for non-compliance.  OSHWA will be responsible for enforcing those penalties.

Clarifying Openness

While open source hardware is already well defined, one of the greatest challenges in creating an open source hardware certification is determining how to handle non-open components.  Full openness is a worthy goal, and companies and projects that strive towards it should be identified and commended. However, many well-known open source hardware projects and products strive towards openness but, by necessity, incorporate non-open components.   The open source hardware definition recognizes this reality, and provides guidance on how best to handle non-open components in the context of open source hardware.

In order to address this challenge, the OSHWA certification focuses on the creator’s contribution.  For the purposes of the certification, openness will be determined by the openness of the contribution made by the creators of the project.  A certified project will be required to share its entire contribution (including the contribution of affiliated corporate entities, if appropriate) in accordance with the open source hardware definition, but not expected to avoid third party closed components beyond its control.  A certified project should use open parts over equivalent non-open parts when they are available.  However, no project will be found in violation of the certification simply because it incorporates non-open parts beyond its control.

Finally, certifications are not available aspirationally.  A project or product that intends to be open source but is not yet open source is not eligible for certification.  This includes pre-production projects such as Kickstarter campaigns.  If the certification is used in a Kickstarter-type campaign, the project must at that time be in compliance with certification requirements.  To avoid confusion, projects should not advertise their intention to comply with certification standards until they have met certification standards.

Creator’s Contribution

The creator’s contribution is defined at everything within the creator’s control.  While some elements of a project may come from third parties beyond the scope of the creator’s control (for example, hex-only source files versus the full stack), the creator is required to fully open and document all elements within their control in compliance with the open source hardware definition.  If the creator is or is employed by a corporation, this obligation extends to any elements within the control of that corporation and associated entities.  This requirement is specifically designed to prevent corporations from creating “open subsidiaries” that make use of corporate technology without having to open the technology itself.  In some ways, this requirement can be thought of as a rule of “do the best you can,” while recognizing that the openness of some elements is beyond the control of any individual creator.

Certification

OSHWA open source hardware certification will operate on a fee-free, self-certifying basis. OSHWA will maintain a list of certification requirements at OSHWA.org, and creators are required to notify OSHWA that they intend to make use of the certification.  This notification will take the form of an email to a dedicated email address and its contents will be publicly displayed on the OSHWA website.  Notification will be intentionally lightweight, and OSHWA welcomes the creation and continued development of rich third party databases and listings of open source hardware projects and products.

By using OSHWA open source hardware certification logos and seals,  a creator is attesting that she is in compliance with all relevant requirements and is agreeing to comply with any penalties imposed by OSHWA for misuse.

Enforcement

OSHWA will work to enforce the use of certification marks and invites third parties to bring violations of certification marks by way of informal complaints.  Upon investigation of an alleged violation, OSHWA may impose escalating penalties for violations.  Alleged violators may elect to remove the OSHWA certification logo instead of remedying the violation.  In order to avoid penalties in such situations, alleged violators will be required to comply with a notification regime instigated by OSHWA designed to communicate the decision to impacted parties.

Complaints

Complaints are not required for OSHWA to initiate an investigation of a project or product.  Complaints can be brought by anyone if the complainant believes that an OSHWA open source hardware certification is being used without complying with requirements.  Complainants are highly encouraged to reach out to the potential violators before contacting  OSHWA – many good faith errors can easily be resolved once they are brought to the attention of responsible parties. If that direct contact fails to resolve the concern, complaints should be sent to a dedicated email address and should include as much information and context as possible in order to assist investigation.  Complaints will be investigated at OSHWA’s discretion.  As a general rule, complaints cannot be made anonymously to OSHWA.  However, unless it is relevant to the investigation, OSHWA will avoid disclosing the identity of the complainant to the target of the complaint.  Additionally, OSHWA reserves the right to allow anonymous complaints in extraordinary circumstances.

Penalties

Penalties for the use of OSHWA open source hardware certifications are designed to make it easy for violators to return to compliance (or become compliant in the first place).  As such, penalties are designed to escalate over time, giving violators multiple opportunities to comply before the imposition of significant penalties.  For each level of penalty, OSHWA will make best efforts to communicate with the party responsible for the project or product in question.  The responsible party will have a reasonable amount of time to respond to the complaint and to each layer of penalty before OSHWA imposes additional penalty.  OSHWA alone will determine if a project or product is in compliance and when to impose penalties.  As appropriate, OSHWA will lift penalties when projects become compliant.  Enforcement will consist of:

  • Bringing the alleged failure to comply to the attention of the responsible party and giving the responsible party an opportunity to respond and/or correct
  • A second attempt to contact the responsible party to structure a path towards compliance
  • Public listing of the non-compliant project or product on the OSHWA website
  • Monthly fines not to exceed $500 per month
  • Monthly fines not to exceed $1,000 per month
  • Monthly fines not to exceed $10,000 per month

12 thoughts on “Open Source Hardware Certification Version 1”

  1. I’m seeing a stark difference between this proposal and a free (libre) software license like the GPL. The GPL puts the burden of compliance on people making derivative works. OSHWC puts the burden of compliance on the original creator.

    That is, simply put, under the GPL you as a creator give up certain rights to your work, in exchange for an obligation on other people creating derivative works to do the same. You as a creator can sue other people for violating the license with regard to your works. You as an original creator do, however, not have any obligations to do anything in particular with your work to be GPL compliant, other than abstain from suing people who are using the work in accordance with the license.

    What the OSHWC aims to do is quite different. It’s a certification where all the burden is placed on the original creator. For very little benefit, you are expected to put yourself in danger of legal action in case your documentation is not good enough or if you don’t want to take the risk involved in waiting until a project has reached funding before opening it up.

    You may want to look to GPL and the FSF for inspiration. Place the rights on the shoulders of the creator, and the burden on the shoulders of people creating derivative works. Formulate it as a license like the GPL, but tailored for hardware. Let people transfer the copyright of their works to the foundation, giving the foundation the right to take legal action against license violators, at their discretion.

    As it stands currently, I’d mirror the concerns expressed above that there would be little incentive for creators to certify their workd with the OSHWC.

    1. This is a reasonable point and a direction we certainly could have taken. One of the main reasons we went with a certification instead of a license (and accepted the accompanying burden shifting) was a concern that licensing of hardware isn’t as clean as licensing of software. All of a software project is protected by copyright, so the power of the license is pretty straightforward. Copyright protection for hardware is a lot less comprehensive (and we assume that most projects won’t have patents for a variety of reasons) so relying on a license to control the use of hardware could lead to disappointment on the part of the licensee when she learns that an “unauthorized” use isn’t actually violating any concrete rights.

      1. “an “unauthorized” use isn’t actually violating any concrete rights.”

        Ha – again, I think you read this exactly the opposite way I would have.

        Because hardware has no de facto copyright protection, the most important thing the original creator does is simply to provide those materials on GitHub, etc. It’s even more important than the license (since the license in fact provides little protection for the creator or the ability to police unauthorized uses).

        That means there really isn’t a need for further certification. Either the maker is publishing materials, or they aren’t.

        And that is the primary thing we can – and should – communicate to customers. If they aren’t getting that message loud and clear from our own sites, a certification isn’t going to help.

        But having some consistent logo and description, that would have been useful for tying the movement together. Now, the whole thing is connected to a fine structure that makes no sense. As it stands, what you’ve done is to create a strong incentive for manufacturers like me to stay as far from OSHWA as we possibly can.

        And believe me, I will. Any tacet endorsement will only encourage a rift between manufacturers who are able to shoulder this additional added liability and those like us who can’t. I don’t want my project to be viewed as somehow “less open source” if this thing should somehow succeed. So I really, really want it to fail for that reason. And that’s unfortunate, but I can’t put a more diplomatic spin on it than that, sorry.

  2. It makes sense to go for fines in the first draft. You can always walk that back if there’s strong resistance but you can’t add it later. I disagree with fines, so add my name to the “strong resistance” list, but the negotiation strategy makes sense.

    Can you clarify what you mean by terms like “the public” and “the open source hardware community”? It seems like they have to be narrower than stated here. For example, the vast majority of humanity still doesn’t know what OSS is, so most of ‘the public’ will never be relevant to OSHW. Also, there are no barriers to entering the broad “open source hardware community” so that must be referring to something narrower, like the subset that wants more rules.

  3. Hi all.
    Huge job. Bravo to people who participated to this elaboration and redaction.
    If we understand well, the OSHWA logo is now linked to the respect of this terms of certification. OK. If so, clarify it across the Discuss list, and anywhere else.
    A negative comment, I’m afraid: fees will afraid everybody, particularly individual people or very and fragile small entities/project. We should accept that a second branch of opensource hardware umbrella could now appear (an other movement). As I explained, I would have preferred a “black-list” process, listing at the end the “bad” project who are not aligned with smart practices respecting the terms and conditions of the licence used. Licence is queen, OSHWA certification is OSHWA logo terms and condition of use.

  4. This is a great discussion touching on a lot of valid nuances, many of which I had not previously considered. To be sure there are a lot of gray areas. Discussions at the recent summit gave me a lot of food for thought.

    However what is inspiring me to post this comment is some recent research into a currently successful (meaning it has already passed it’s funding goal) crowdfunded project which claims to be Open Soure Hardware and is using the Open Source Logo. What I have learned is that the main processor used in the project has no publicly-released complete data sheets sufficient to program the part. No register list or address map. No details on how to control any specific features. To get this the manufacturer requires “… a customer contract with {I deleted the IC company name} (with license fee) to get chipset, full source code and complete version of datasheet, which allows customer to develop more complex product.” This is from the controller manufacturer support website in response to others asking for full data sheets. Based on what I am reading in the hot-off-the-press book “Building Open Source Hardware…” this fails the test of Open Source, as I understand it. Yet there is the campaign calling it just that. I have posted a question about this in the project comments (you must first be a backer to even ask the project founders a question, so I currently am) and I have not given specific details here because my purpose is not to ruffle any feathers or start a flame war. Perhaps this specific case can yet be resolved.

    This not-really-open-source project (IMO) is not an isolated case. Other manufacturers *do* publish full data sheets and sufficient details to properly use their parts (duh) without any special agreement or license fee. My point in mentioning all this is to express the hope that “Open Source” would really mean “sufficient documentation that I can actually program and use this hardware any way I wish”. Sometimes, at least, it seems to be pretty obvious when something meets this OSHW requirement and when it falls short. There should be a way to reward companies who are truly in the spirit of OSHW and to warn about those who appear to be just riding the coattails of a popular movement.

Comments are closed.