Come for the great speakers and community, stay to find out about the brand new open source hardware certification program (tickets are still available).
After lots of work by lots of people stretching back . . . lots of time, OSHWA is finally ready to unveil our open source hardware certification program. The certification will be a way for the open source hardware community to know that when a project or product calls itself “open source hardware” they mean the version of “open source hardware” that complies with the community definition of open source hardware.
At the summit we’ll explain how you can get your stuff certified, how you can use the certification to learn more about stuff you get from other people, and other things that you might want to know about the certification. There’s no substitute for getting that information in person (trust me), so if you don’t already have tickets click here!
Throughout the month of October, OSHWA will be hosting several documentation days for anyone, individual or company, to participate. Documentation Days will be free, community organized events to document your most recent open source hardware project following the OSHW definition and guidelines. Look for documentation days from OSHWA’s board members and branches in their communities throughout October. Follow us on Twitter or Facebook to stay tuned and for dates and locations of our events and look for updates on our blog.
Why Documentation Days?
October is Open Source Hardware Month. This is the perfect time to document that project you haven’t gotten around to documenting but want to make it open source. Documenting your hardware is the most important step in open sourcing your hardware because it gives other people a way to use, build upon, and possibly improve it. Your well-documented designs will live on and take various shapes as other people use them, create derivatives and share them. It is much easier to ask the community for help or find collaborators with well-documented hardware. Publishing your design files publicly can also establish your hardware as prior art. If someone attempts to patent something similar, that prior art can prove that the hardware existed before the patent application, thus preventing it from being granted. Finally, more open source hardware documentation will set an example for others to open source and document their hardware! This year’s Documentation Days will help standardize key elements of good open source hardware documentation.
To bolster the community-written Open Source Hardware definition, OSHWA is launching the open source hardware certification in October as well. Take this opportunity to read about the certification and join the movement.
Who can host a Documentation Day?
Anyone can host a documentation day! OSHWA’s board members will be hosting documentation days in various locations, but we can’t be everywhere. It is unlikely that OSHWA will be able to help with costs of a documentation day, but below are some tips to keep it cheap.
How do you set up a documentation day?
Find a venue that has tables and chairs. Your local hackerspace may be a wonderfully aligned space to host a documentation day (and hopefully will not charge you a venue rate!). Public libraries may have free meeting rooms as well. Make sure the venue has lots of outlets for laptops – you may need to supply power strips.
Work with the venue to solidify a date. Send the date, time, location, and other details of your event to email@example.com and your event will appear on the OSHWA Events page. If you’d like some physical handouts, include your mailing address.
Set up a way to RSVP (Email, Meetup, Eventbrite) if necessary. This is optional. You know your local area better than we do.
Use this logo when promoting your event:
Promote the event. The event must be a free, public event. Tweet @oshwassociation and we will retweet your event. Use hashtag #DocumentationDay.
Day of event:
Thank people for coming, introduce your documentation day as part of OSHWA’s Documentation Day series. Show slides and materials given to you by OSHWA. Point people towards oshwa.org and certificate.oshwa.org with questions.
After documenting hardware projects, ask people to use hashtag #iopensourced and #oshw and link to what they’ve documented.
Document the documentation day! What worked? What didn’t? Did you and your participants develop any systems, processes, or templates that made creating documentation easier? Be sure to share them with the larger community.
Don’t forget to clean up the venue at the end of your event.
I was honored to lead a breakout session for the Maker to Manufacturer event hosted by the White House’s Office of Science and Technology. As the Executive Director of OSHWA, my break out session was on Open Source Hardware innovation. This is my take away from the individual viewpoints expressed by the group, highlighting what we can do as a community, as an industry, and from government and university perspectives. Below are the unedited notes from this breakout session. These ideas came from the collective participants in the breakout session and the views and ideas do not reflect those of the White House.
Our group discussed innovation through open source hardware through cross pollination in the open hardware community, industries, granting organizations, universities, and other institutions. In this way we can change what innovation looks like.
As a community, open source hardware needs to better explain the value proposition to the above listed institutions. We need to clarify the licensing around open source hardware, which OSHWA hopes to take a step toward with our certification process launching in Oct. With help, there could also be a database that grows out of the certification process with a space for contributing back and tracking changes. We need to offer educational experiences for policy makers and illustrate the social change and rapid innovation happening around open source hardware.
Within the government, the open source hardware community would like to be part of any process that might create limits though broad regulation around IP and hardware. We would like to see rethinking the standards and create scalable standards and taxonomies for open source hardware. We think it’s best for conversations in this space to strategically chose particular hardware fields to introduce, educate and change with open source hardware. Tax incentives for people to share their source publicly for the good of rapid innovation, foregoing a monopoly, would be well received in the community. Finally, we need the attention of the USPTO to alter the landscape of IP and be aware of open source prior art.
From a university perspective, a change must happen in the tech transfer offices for innovation to move forward at a university. Too often universities have IP constraints stemming from the Bayh-Dole Act which prohibits other inventions coming out of tax payer funded research and can even prohibit the inventor from continuing to innovate.
From an industry perspective, having a standard business case, such as royalties for creating a copy or derivative, would create a mutual respect. An understanding that risk adverse IP practices such as patents has a trickle down effect on innovation. In particular, open chipsets would be more useable. Industries could benefit from an open toolbox of the first 1,000 common pieces needed for any project, or a ‘simple things’ database containing source for the building blocks would be useful. In some industries also sharing test results with the source would be helpful.
At OSHWA we are reaching out to these four areas, community, government, university, and industry to assist in the changes reflected at this meeting.
Notes from the day, taken by Stephanie Santoso:
How do you innovate with open source hardware?
Moderated By Alicia Gibb, OSHWA
October is open source hardware month
We’re primed to create value with the public- we have lots of things that we can do.
Open source hardware is more of an IP concept. What policies currently stand in the
way of open innovation?
University ownership of IP is a big one.
Open source software- you know what the license is, you understand what it takes; but
with Creative Commons- you don’t even know what that means. It’s not clear what it is.
Hardware is weird because you can’t license it unless you have a patent. In October,
OSHWA will announce a certification (a trademark) to help Makers and entrepreneurs
understand the steps that they need to take to make sure their products are open
source based on OSHWA’s specific definitions.
Matt: What does this do for the feedback loop for users? Ex. Bizzy box (sp?)- users
weren’t contributing content back to the community. What is the feedback loop which
incentivizes people to contribute the modifications back to the community?
It would be great to have a clearly defined record system where you can track changes-
like a Github for hardware. When we look at open source hardware- we should look at
components- and what components you can open source too. Would be great to have
representatives from the semiconductor industry present at future conversations around
Maker to manufacturer. If they were repurposed to be reusable, this would be great.
Schematics for semiconductors are already available. Autodesk is creating a platform
where you can take modular components of your hardware design using an Autodesk
software platform and make them more openly accessible.
Venkat: Would be great to have a database of open source hardware that makers in
makerspaces can use, so people know what’s already out there and available.
Think about Texas Instruments- what’s the business case for a company to do open
source hardware? Why would TI or Intel care? You’d need to shift their mindset of how
they measure value- often its patents, but what about getting institutions to value
people who either develop open source hardware or contribute to open source hardware
projects in a similar manner?
Frank Gayle: Should talk to NIST about how we think about standards. Michelle: we
should talk about taxonomy and how open source hardware fits.
Fernando: I come from the pharma sector, which is different because it’s harder to
make a product mature. What’s the conceptual framework that moves us in this
direction? We don’t even have material property databases.
What about procedural processes? It’s hard to divide these processes into specific
pieces. There may be interest in small scale manufacturing, but for large scale
manufacturing, we need to rethink this.
Open source community- benefits will come for makers who are producing smaller scale
products. We are seeing that individuals are contributing to the open source hardware
community as a way to create a personal brand in some sense- open source represents
a certain set of values. Ex. We are seeing this on Hackaday’s open source project
How might we screw this up?
1) Not explaining the value proposition well
2) Speed to market trumps the IP value proposition- we should remember this. Sometimes
patenting isn’t the best use of your time because things are happening so fast and you
want to make it to market.
3) Regulations- be careful of this- regulations aren’t necessarily a bad thing, but we should
have an active role in providing input and engage with regulators very early on.
4) Not being about to create an effective cost model. If there’s an acknowledgement that
there is a publicly available use of technology for the process, then you can better justify
this to the organization.
5) Failing to recognize that huge social change may be required in order for organizations
to embrace open source hardware. Ex. Navy can be generally hesistant and risk averse.
If you want create something new, it can be an incredibly long approval process. In
some cases, it makes sense to acquire something from outside of the organization than
There is less than 45 days left until this years OHSummit. It is the first Summit we will have ever hosted on the west coast and we are thrilled to be going to Portland, Oregon- it is the perfect location, right between Seattle and SF.
One of the things that makes open source hardware licenses hard is that – unlike software – it isn’t always easy to determine what parts of a product (if any) are covered by copyright. Since traditional open source licenses rely on copyright to make them enforceable, understanding how copyright applies to a piece of open source hardware is the first step in deciding how you might want to license it.
Finding copyright can be complicated because it protects creative and decorative works (including code), but not functional items. Pieces of open source hardware often combine both creative and functional elements. This makes it critical to understand how to break out the copyright-protectable parts from the non-copyright-protectable ones.
Unfortunately, today in the United States there are at least ten different and somewhat contradictory tests to guide that process. That makes it hard for copyright experts to draw the line between copyrightable and non-copyrightable, and essentially impossible for everyone else.
That’s why OSHWA joined the International Costumbers Guild, Shapeways, Formlabs, Printrbot, the Organization for Transformative Works, the American Library Association, The Association of Research Libraries, and the Association of College and Research Libraries on a brief written by Public Knowledge in the Supreme Court case Star Athletica v. Varsity Brands. While the case is nominally about cheerleader uniforms (really), it boils down to a simple question: which test should be used to separate out the copyrightable and non-copyrightable elements of an object that includes both?
The brief does not advocate for a specific test. Instead, it simply urges the Supreme Court to pick a simple, easy to understand test. That clarity alone would be a huge benefit to the entire open source hardware community.
Although we are filing the brief now, the Court’s decision probably won’t be until next year. Once it comes out, we’ll do our best to explain what it means for the entire open source hardware community.
Hello all — as promised, as part of OSHWA’s work on the upcoming Open Source Hardware Certification program, we’ve created a GitHub repository to host design templates including the mark for different design programs, so that you can more easily put the mark onto circuit boards, packaging, and documentation. The repository also includes a README with guidelines and style suggestions for using the mark in various contexts, sizes, colors, and print technologies (as shown above).
This is a draft, and we intend to continue refining it as a set of recommendations on how to use the mark, and as a style guide if you’re looking for ideas on where and how to incorporate the mark into your designs and documentation.
OSHWA would like to announce Open Source Hardware Month for the month of October 2016. OSHWA is inviting you to participate in events that will add clarity to the open source hardware definition, invite more people to contribute to the movement, and provide education around how to publish a project or product as open source hardware.
Throughout the month of October, OSHWA will be hosting several documentation days for anyone, individual or company to participate. Documentation Days will be free, community organized events to document your most recent open source hardware project following the OSHW definition and guidelines. This is the perfect time to document that project you just haven’t gotten around to open sourcing. Look for documentation days from OSHWA’s board members and branches in their communities throughout October. Follow us on Twitter or Facebook to stay tuned and for dates and locations of our events and look for updates on our blog.
OSHWA will launch the first version of the open source hardware certification. This is an open source hardware certifications administered 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.
Users will self-certify compliance in order to use the certification logos. 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.
Open Hardware Summit
In addition to the documentation days and certification, as always OSHWA will be hosting our annual Open Hardware Summit in Portland, OR on October 7th. Tickets to the Summit are available and we’re currently looking for speakers and sponsors.
Join OSHWA Today!
The Open Source Hardware Association is a 501(c)3 non-profit organization dedicated to being the voice of the open hardware community, ensuring that technological knowledge is accessible to everyone, and encouraging the collaborative development of technology that serves education, environmental sustainability, and human welfare. Become a member of OSHWA today!
Hello all – we’re excited to announce a final design for the logo (mark) that will be used for OSHWA’s Open Hardware Certification program. We had a lot of great ideas submitted, and after collecting feedback from OSHWA members on the top six, we’ve developed a final mark based largely on ideas from Matt Maier’s submission (see comments from above post), which received the most support of the submitted designs. Thanks to Matt and to everyone who helped shape this design!
Here is the final design; it is aimed to be distinctive and readable at very small sizes, as you might find on a circuit board screenprint, or on the bottom of an open hardware object. Letters are spaced to prevent obscuring due to ink bleed, and it provides space for an optional unique identifier code which could be used to look up the design. And it prints in monochrome with an optional two-color option.
A full design guide and various pre-loaded design files will be posted soon, so stay tuned. Thanks!
A couple weeks ago, we made a call for ideas for a logo to be used in OSHWA’s upcoming Open Hardware Certification program, and we got some great submissions. From these, we’ve selected a handful of especially promising ideas and we’ll be sending a survey to OSHWA members shortly to solicit input on these, narrowing down the ideas towards a final logo.
Hi, all – Jeff Warren here, OSHWA board vice president.
You’ve probably been aware of the ongoing process by OSHWA to develop a certification program, with community input. Now we need to develop a graphic mark — the actual logo which would appear on Open Source Hardware objects, products, packaging, circuit boards, and documentation — by the end of March/early April. In light of that, today we’re making a call for ideas for what this might look like! We’ll keep an eye open here for 2 weeks, and announce next steps shortly afterward.
Note that this is NOT replacing the Open Source Hardware mark folks have been using — it’s a new certification mark, indicating that your project is part of the upcoming OSHWA certification program. Think of it like a “fair trade” or “certified organic” mark — extra assurance that the project really is open source hardware. A mark you can trust, because OSHWA won’t allow its use if you don’t comply with the Open Source Hardware Definition! It should be:
not like the OSI logo (no gears, keyholes in gears)
monochrome-friendly (it’ll have to be printed on circuit boards)
simple enough to read at ~¼ inch ~3mm, & ideally even smaller
consider space for a unique identifier, useable in a URL (say, up to 5 characters)
Not this mark — a new one! But this illustration posted by Windell Oskay nicely shows how the mark will need to be legible at varying sizes.
Post your ideas in the comments — please embed images so people can easily scan through them.
Please note! OSHWA may incorporate ideas or use complete submitted logos for the OSHWA open hardware certification. That means that by participating you are agreeing to transfer all rights in the design to OSHWA. Why do we need the rights? In order to control the logo and the terms of the certification, we need to control the rights connected to the logo. We understand that arrangement won’t work for everyone, but it is the only way we can make sure the logo does what it is supposed to do.
Update: So, in response to some comments here and on the OSHWA discuss list, the nature of trademark is that we can’t re-use elements from someone else’s trademark, especially in a similar field. So although I see the draw of basing ours off of CC, for example, that would not make for a good mark, legally speaking. And in general, to avoid confusion, I think it’s best if it’s *quite distinct* from other marks, including the gear logo referenced in the post.
Re: embedding images, sorry, for the time being, please just link to images, and we’ll work something out soon.