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

29 thoughts on “Open Source Hardware Certification Version 1”

  1. What I see is: massive monetary fines based on an undefined gray area of “compliance” with zero transparency of what qualifies as a violation, how enforcement decisions are made, and how the organization enforcing them is governed.

    There’s simply no reason any sane person would ever voluntarily subject themselves to this kind of punishing liability. Actually, there’s no reason to voluntarily subject oneself to this particular certification in the first place.

    And without many volunteers, any such logo would be entirely meaningless.

    Here’s the good news: no one will violate your certification. The bad news: no one will use it, either, save for the people who cooked it up in the first place.

    1. Apologies, some mistake with the form – I don’t need to be anonymous; I’ll happily say this publicly. A voluntary certification is a good idea; doing it this way is not.

      1. You may very well be right. The logo is only useful is people see it as representing something they care about. If the logo is not a useful signal then the reasons to use it start to dwindle.

        Based on the feedback we got from the community both before and during this process, we believe that there is significant community interest in the certification. However, only time will tell if that instinct is correct.

        As for the lack of transparency, you might find some comfort in the “file cabinet” page above.

        Finally, on the “voluntary certification is a good idea; doing is this way is not” front, we had a fairly robust discussion about the proposal in the forums. Did you raise your concerns there?

        1. I’m not sure what concern I would have raised. I’m certainly raising it now. We are fairly busy being in the business of making open source hardware; we aren’t always poking around in forums.

          And actually, my worst nightmare would be that people would decide this was a “useful signal” – because there’s no way in hell as an open source hardware manufacturer that we could put ourselves in front of this liability.

          1. — and it’s fine, I get it; we won’t attempt to use the logo. I believe we can effectively illustrate our commitment in practice with licenses and available documentation.

            But the original motivation behind the logo before this certification idea was to somehow band people together around the idea. Or so I thought. So I’m a little befuddled as why you’d create a system of disincentives to actually use it.

            Reading this:
            https://www.oshwa.org/forums/topic/10-reaching-out-to-companies-outside-of-current-osh-community/

            I mean, how are you defining “the open source hardware community?” I have no idea, but my sense is, if you polled manufacturers, they’d probably ask the questions I’m asking – why should we volunteer for this certification, when there’s no clear incentive, no clear sense of whether we’re in compliance or not, and very clear dangers to wind up owing thousands of dollars?

          2. That’s a totally fair opinion. The incentive is to be able to use the certification logo. If the value of the logo doesn’t outweigh our concerns, as you rightly point out you are under no obligation to use it. If you would like to try and use the logo but are worried about specific barriers, I’d love to discuss it with you. Shoot me an email at hello@michaelweinberg.org and we can find a time for a real-time chat.

            And that offer is open to anyone who is reading these comments. We’re trying to find a way to make this work for anyone who want it to work for them. If there are things that we can do to make that possible I want to hear about them.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

    1. That seems exactly right – and I couldn’t agree more. But I can’t imagine that any logo or terminology would make this any clearer. In fact, this whole discussion makes me think that what we really need is to do this:

      1. As manufacturers, help users find their way to the actual open source material – the code, the schematics, the documentation, the license.

      2. As customers, make sure the first step is to look for the stuff in step 1.

      I think a lot of us do those two things, so then,

      3. Educate people to do #1 and #2.

      I don’t think certification or logos have anything to do with making this happen, let alone a penalty system. In fact, if anything, they might steal focus from the real work of getting people to educate themselves on what they’re doing. And I can direct that even at myself; we haven’t done a good job of that.

      1. Bruce Boyes’ story is a perfect example of why a controlled logo is needed. In this case, a freely available logo and terminology have been misused. Without some penalty, i.e. trademark infringement fines (ironically), what good would a certified logo be?

        If someone wants to support Open Source and believes they might need a product’s openness sometime after their purchase, the certification provides confidence, without having to do the background investigation ourselves. And, that’s all it’s meant to do.

        Use case: You buy a widget. You find it does almost, but not exactly what you want. You open it up and try to modify it. It turns out you need the data sheet for the controller chip. It’s not available, so only now do you discover the “open source” claim was bogus. In the future, you waste a bunch of time for every purchase to make sure it really is open. The certification is an efficiency, so that only *once* does the research and verification have to be done and everyone else can rely on it.

        The OSHWA doesn’t have the resources (I assume) to do this research and verification. So, they are relying on the manufacturer to self-certify. The penalties are there to incentivise the manufacturer to be truthful in this self-certification. I don’t see how else you would accomplish this.

        1. Someone in the certifying body should speak to this, but I can’t imagine that fines would be the *first* step to bring into compliance, a manufacturer who had violated the agreement for certification. It would more likely be a message saying “Hey, we noticed you don’t provide the data sheet for the controller. Would you be willing to make his freely available?”

Comments are closed.