Last weekend, during the Open Hardware Summit, OSHWA unveiled version 1 of the Open Source Hardware Certification. This certification was the result of a community discussion process that began back on June 2nd and continues to this day. Since the announcement there has been a great discussion about the certification, including on Hackaday (including in the comments), in the comments for the original announcement, and on the Evil Mad Scientist blog. Those discussions have raised some concerns and shed light on some potential misunderstandings, and it seemed reasonable to begin to address both with a blog post.
First, OSHWA appreciates that the community takes this proposal seriously enough to discuss and debate it in the first place. It is called version 1 for a reason, and we pushed it forward knowing that it would inevitably evolve over time. That being said, we feel that the current proposal addresses many of the concerns that led to the start of this process in the first place.
What the Certification is Not
The OSHWA certification is not designed to place restrictions on the use of the term “open source hardware” or to restrict how people use the open source hardware open gear logo. Nothing in the proposal requires anyone to use the certification, or gives OSHWA the power to sanction a project that decides – for whatever reason – that the certification is not for them.
The certification is not designed to force everyone doing open source hardware into a single box, or to exert exclusive control over the world of open source hardware. Such a task would be impossible, and counter to the purpose of OSHWA.
What the Certification Attempts to Do
Instead, the certification process is designed to be an addition to the open source hardware landscape. It is being created to address a concern that has been raised a number of times by the community – easily the #1 request we get from the community and OSHWA members. In Windell Oskay’s post about the certification on Evil Mad Scientist, he accurately sums up the problem:
“But there is something  rotten, deeply rotten, in the world of open source hardware. And that is that the label “open source hardware,” either in words or represented by the OSHW logo (the keyhole-gear thing above) has been misused so much that it can’t really be trusted.
If you put that label on a piece of hardware, we might expect that this hardware meets the open hardware definition. The definition specifies (amongst other things) that you should be able to obtain the original design files (the “source”), and use them without a “noncommercial use” restriction (the “open”). But it seems like every day I hear about some drone, robot, or development board that turns out to be OSHWINO —Open Source Hardware In Name Only.”
This problem has a number of causes, including some of the licensing challenges related to open source hardware. Regardless, the certification was the result of OSHWA trying to find a way to give both creators and users of a piece of hardware a degree of certainty that hardware that called itself open source hardware actually complied with a commonly understood definition of open source hardware. That is, while anyone can call themselves open source hardware, only hardware that actually complied with the rules set out by OSHWA could call itself OSHWA-certified open source hardware.
The Value of Certification
There is no intrinsic value in certification. For users, it only matters if they feel that a certification provides them with useful information about a piece of hardware they are considering spending time with. For producers, it only matters if they believe that people will look for the certification and care if they find it.
Neither of these results are inevitable. Fortunately, if it turns out that the certification is not useful to people, it dies a quiet death of neglect.
OSHWA believes that – properly executed – it will be useful. That is why we are spending the time to create it and present it to the community. But it may be that there really isn’t a demand for a way to know that open source hardware complies with a commonly held definition of openness. Or it may be that there is a demand for such a thing, but that this certification isn’t the right way to achieve it. In either case, OSHWA will go back to the drawing board to try again.
Some members of the community have raised concerns about the enforcement mechanism for noncompliance, specifically the fines. As was explained in the presentation at the Summit, the enforcement mechanism is an attempt to balance two competing concerns.
On one hand, there has to be a way to punish bad actors who use the certification without complying with it. That punishment must be significant enough to deter abuse. Escalating fines are a good way to do that.
On the other hand, we are in the early days of open source hardware and there are not well established ways to apply the definition and best practices to every situation. In light of that, it is critical that creators acting in good faith have plenty of opportunities to discuss their goals and work towards a resolution before penalties are applied. The earliest stages of enforcement are designed to create that space.
OSHWA believes that the enforcement process outlined in the certification balances those two concerns. When reading the certification, it is important to remember that no one has to use the certification and that OSHWA has neither the interest, power, nor authority to punish projects that simply describe themselves as open source hardware and/or use the open gear logo. The entire regime only applies to projects that decide to opt in to the certification process.
Where We Go Now
The first hard part was taking a proposal through a process of community feedback and discussion. The next hard part is developing the legal license that will make the system described in the certification document enforceable for projects that opt in.
The execution of this next part is important as the development of the specification itself. We are cognizant of that, and are doing our best to create licensing language that is clear, approachable, and accurate. Part of doing that means being as transparent as possible about the process, and open to community feedback. That is why we launched this idea with a call for community input, and why this blog post exists today.
If you have concerns about the proposal, let us know. You can use the comments below, contact us, or open a discussion in the forums. In the meantime, we’re going to focus on finalizing the certification process and not screwing it up.
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.
- 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.
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.
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.
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.
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.
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 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 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
Last week OSHWA joined our friends at Public Knowledge, EFF, the Digital Right to Repair Coalition, and Public Citizen in telling the US Court of Appeals for the Federal Circuit that ownership matters. Why is ownership so important? Because owning something means that you have the right to fix it or change it or integrate it into something else without first asking permission from the original manufacturer. A manufacturer of an object shouldn’t use patent law to get a perpetual veto over how you use that object.
The case involves Lexmark (the 2d printer company). Over the years, Lexmark has tried to use pretty much every legal trick it could think of to lock down its printers and prevent people from using non-Lexmark toner. Having worked through all of its other options, in this case Lexmark turned to patent law.
Patents give patent owners a lot of control over objects. However, that control largely disappears when the owner decides to sell an object. My phone is chock full of patents that allow the manufacturer to prevent someone else from making one without permission. However, once I buy my phone, I can do pretty much whatever I want with it – paint it green, use it as a coaster, or sell it to the phone manufacturer’s ex that they hate. This limit to patent control is called “patent exhaustion.” Essentially, once you sell an object protected by patent, you have “exhausted” your patent control over it.
Lexmark is looking for a loophole to patent exhaustion. They argue that patent exhaustion only applies if the object was sold in the US. If the object was originally sold overseas, Lexmark argues, patent exhaustion should not apply. If this argument sounds vaguely familiar, the US Supreme Court heard a very similar case relating to copyright a few years ago. In that case, a student was buying official copies of textbooks in Thailand (at low Thai prices) and reselling them in California (at higher – but still lower than the publisher was charging – US prices). The Supreme Court rejected a foreign sale loophole for copyright protected books, and now we are urging the Federal Circuit to reject a foreign sale loophole for patent protected printer toner.
In addition to undermining the concept of ownership, allowing such a loophole would undermine confidence in the market. Imagine if you needed to research the supply chain history of everything you buy. Two identical objects on a shelf could be treated very differently by the law depending on where they happened to be originally sold by the manufacturer. How are you supposed to know which one you really get to own and which one is still under control of the original patent owner? That’s a research burden that serves no purpose.
Charles at Public Knowledge and Vera at EFF have good summaries of what is going on in this case. We at OSHWA are proud to be able to contribute to this effort and look forward to updating you as it develops.
Today the Open Source Hardware Association (OSHWA) is kicking off the process to create an Open Source Hardware Certification. In addition to all of the amazing things that will happen at this year’s Open Hardware Summit, our goal is to be able to roll out the first version of the Open Source Hardware certification this fall. In order to be able to do that, we need your input now. You can find all about the certification and the process here, but the rest of this post will give you a quick overview of what you need to know:
Who: The Open Source Hardware Community and the Open Source Hardware Association. if you are reading this, that probably means YOU.
What: A certification program for projects so that people can know that the project really is open source hardware.
When: From now until the Open Hardware Summit. The first deadline for comments and answers to the questions is June 26, 2015.
Where: Comments and answers are being collected in the Open Source Hardware Association forums. We are aiming to roll out the first version of the certification process at the Summit in Philadelphia.
Why: While the community has done great work on developing open source hardware principles, many people are still looking for a simple way to know that something really is open source hardware. Hopefully the certification will be a big step towards that goal.
How: The initial proposal is available here. Once you have read the proposal, weigh in on the questions in the forums here. The OSHWA board will use those answers to craft a final version of the proposal. If more input is needed, there may be a second round of questions for the community.
This is a discussion draft and proposal to create an official certification for open source hardware housed in the Open Source Hardware Association. It contains an overview of the proposal and raises some specific questions related to the development and implementation of a certification. Once you have read the draft, please provide feedback in the OSHWA forums.
This is a proposal to develop one or a series of open source hardware certifications administered by OSHWA. The certification requirements would be developed collaboratively with the community and could possibly vary by degree of openness . Users would self-certify compliance in order to use the certification logos.
A single certification threshold would have the benefit of clarity and simplicity. However, it may not contain enough flexibility to capture the diverse paths towards openness in the hardware world.
A tiered certification would have the potential to muddy the waters around what really is “open” and could potentially be gamed by bad actors. However, by creating a spectrum of certifications and examining their use over time, OSHWA could collect real-world information about what degree(s) of openness feels most viable to the community by tracking the adoption of the various tiers. Over time, the spectrum of licenses could be consolidated based on adoption rates (this evolutionary model was used by Creative Commons to simplify and focus their license structure over time), thus bringing additional clarity to what is and is not truly OSHW.
An additional benefit of certification could be to make it easier for “outsiders” to participate in OSHW by bringing additional clarity to the definition, thus expanding the reach of OSHW and its exposure to new communities. The following is a short sketch of elements of this proposal.
OSHWA is opening this proposal to the larger community because OSHWA is a community-driven organization and open source hardware succeeds on the strength of the open source hardware community. The goal of this process is to arrive at a consensus-based certification process for open source hardware.
In order to achieve these goals we have structured the following process:
June 2, 2015: Public release of proposal v1
June 26, 2015: Comment deadline on proposal v1
July 14, 2015: Public release of proposal v2 (if necessary)
August 7, 2015: Comment deadline on proposal v2 (if necessary)
Open Hardware Summit 2015: Release of Open Source Hardware Certification v1
Comments will be accepted via the OSHWA forums. Each specific question will have its own branch. There will also be a general branch that will act as a catchall for comments that don’t fit neatly into a specific question.
We have created the option for a second round of comments. This second round will be used if the first round comments do not indicate that the community is moving towards a consensus. If needed, the second round should give everyone a chance to weigh in on questions left unresolved in the first round. If the first round of comments point to a conclusion we may not have a second full round.
All comments will be reviewed by the Open Source Hardware Association board, which will also be responsible for revising and finalizing the proposal.
- Make it easier for the public to identify open source hardware.
- Move towards common expectations of what qualifies as open source hardware, including how non-open elements of putatively open source hardware is handled.
- Expand the reach of open hardware by making it easier for “outsiders” to participate by setting clear expectations and definitions.
- Encourage the creation of OSHW database
- Develop an additional sustainable funding source for OSHWA
The Open Source Hardware Definition and Open Source Hardware Best Practices were massive steps towards clarifying what actually qualifies as open hardware. However, questions still remain about how to apply the definition and best practices properly to a given project, and also about how closely a project must adhere to all of the best practices in order to qualify for opensource hardware certification. Notably, “open source hardware certified” and “open source hardware” do not have to be absolutely synonymous. The purpose of the certification process is to try and provide some sort of certification of compliance for others. Nothing in this certification process prevents someone from calling their project open source hardware. The certification only has meaning if, over time, the community decides that the existence of the certification helps them identify projects that comply with their understanding of what open source hardware means.
One way to handle questions relating to how to apply definitions and best practices to a given project would be to develop a single canonical litmus test for openness. This would create a clear distinction between what is “really open” and what is merely trading on the popularity of the term open source hardware. While bringing many benefits, a single test may not fully capture the community understanding of what qualifies as acceptable and unacceptable compromises in a move towards openness for a given project.
An alternative path is to develop a spectrum of tests of openness. As long as they are clearly differentiated, it would allow a project to navigate its specific limitations by claiming “partial openness,” “full openness,” or recognized degrees in between. The project could be transparent about its level of openness, but still get whatever credit it can get for incorporating some level of openness. Levels could be indicated via a level system (Gold OSHW, Silver OSHW, Bronze OSHW), a laundry/nutrition-style label, or other indicators.
Over time, a spectrum of tests could help give rise to a more accurate understanding of how creators actually apply open principles to hardware. The criteria that are embraced could be promoted, while the criteria that are avoided could be reconsidered and even depreciated.
Such a spectrum does come with downsides. It has the potential to make it even harder for end users to really understand what an “open” label means. It could also allow bad actors to game the system in order to claim openness for marketing purposes while avoiding adhering to the spirit of open source hardware.
Another advantage of formal certification would be to make it easier for “outsiders” – developers and companies without strong personal ties to the open source hardware community – to confidently offer their products up as OSHW. This is especially important in recruiting larger companies into the OSHW world. Of course, attracting larger companies into OSHW is a debatably valuable goal. The benefits of expanded awareness must be balanced against threats of being coopted and the watering down of the definition of true OSHW. However, if such an outcome is worth exploring, providing clarity and a glide path may make it easier for outside developers (both independents and those at larger companies) to embrace openness without fear of unintentionally violating misunderstood community norms.
In order to avoid turning OSHWA into a large certification bureaucracy, once developed the licenses could be offered up for self-certification. That would mean that anyone would be free to use the certifications as long as they felt that they complied with the terms of the certification.
Critically, self-certification would not simply mean that anyone could call themselves open source hardware. In order to self-certify, a project would need to agree to abide by open source hardware requirements. Perhaps more importantly, the project would also have to agree to comply with sanctions and penalties imposed by OSHWA if they were found not to comply with the requirements.
While it would still require OSHWA to enforce the certification rules, self registration is a low-impact alternative to a much more onerous system that required anyone to get formal pre-approval before adopting the certification.
While not required, certification users could be encouraged to register their certified projects with OSHWA (or a third party registrar) as part of downloading the registration logos. This could help create the long-discussed open hardware registry. Additionally, it could create a way for OSHWA to track and compare the uses of various flavors of certification (if such flavors of certification exist).
This proposal does not require the collection of any fees in order to function. However, certification logos could be used as a source of funding for OSHWA if OSHWA was so inclined. The lowest impact way to impose fees would be to impose either a one-time fee or royalty on the use of a certification logo in a commercial product. Such a fee could be tied to volume or revenue so that small projects would be exempt, but more successful products had to pay on a sliding scale. Of course, the fee would need to be low enough to avoid acting as a disincentive to adopt the certification logo.
There is a broad range of potential options when it comes to enforcing proper use of certification logos. Options include, but are not limited to, maintaining a “list of shame” online for companies and projects that misuse the logos, maintaining the option to demand the removal of a logo on noncomplying products, operating some sort of public complaint process to identify misuse, and even imposing some sort of financial penalty (perhaps after an opportunity to correct is given) for misuse of the logo. These options are not necessarily mutually exclusive.
Please provide your thoughts on the following questions. Explanations for your preferences are appreciated. You can also make general comments here.
- Is certification something that OSHWA should be looking into all?
- Do you prefer a single definition of openness or a spectrum of options? Please explain your preference. If you prefer a spectrum, do you have a preference between a tier-based spectrum or a nutrition/laundry label-style approach.
- Should it be possible for projects with non-open components to be certified as open source hardware? If so, how should the process handle such projects? Is a part-by-part label desirable because it gives specificity or undesirable because it complicates understanding the label for less technically sophisticated community members?
- Do you prefer a self-certification process or a process that involves pre-approval of certifications by OSHWA?
- Should registration be part of the certification process? If so, should there be a single central repository or a distributed set of repositories that comply with base-level requirements?
- Should certification require fees? If so, should those fees take into account the size of the person/company behind the project, the commercial nature of the product, and/or the number of units sold?
- What is an appropriate penalty for projects that fail to meet certification requirements? Should the penalty process include an opportunity for those projects to correct the error before the penalty is imposed?
- Should OSHWA maintain a public database of certification complaints and how those complaints were addressed? If so, should the entire process be public or should there be a grace period for private resolution?
- Should there be a distinction between mandatory requirements and simple best practices? If so, should there be some way to indicate that a project also/only complied with best practices?
- Is reaching out to companies outside of the current open source hardware community a goal worth pursuing?