This post originally appeared on the OSHWA blog.

Today at the Open Hardware Summit OSHWA launched version 2.0 of the open source hardware certification program. We have a new website, a new directory, and lots of new resources for learning about open source hardware. You should really check it out.

We announced our intention to create this new version of the certification back in March. Since then we have been working in consultation with the board and the community to develop a new version of the site. Version 2 of the certification site uses specific examples from the community to illustrate best practices and licensing decisions for creators of open source hardware.

Launched in 2016, the original certification program has been a success. We have certified over 200 pieces of hardware from 27 countries on 5 continents. The certification logo is making it easier to find open source hardware that meets the community definition of open source hardware and the certification process makes it easier to incorporate best practices into releasing open source hardware.

With that being said, there is always room for improvement. In addition to the community, with the support of the Alfred P. Sloan Foundation we have been working with the Technology Law and Policy Clinic at NYU Law and the design team at Objectively think through the best way to make version 2 work for everyone.

Besides overhauling the look and feel of the site (embedding google docs in wordpress pages helped us get the program up and running quickly, but that approach admittedly comes with some design limitations), OSHWA had three primary goals for the the new website:

Consolidate Information

Since its founding, OSHWA has created a series of fantastic resources such as best practices and FAQs to help the community develop open hardware. Each of these resources was developed in response to specific concerns, building up on existing resources and expanding explanations.

One side effect of that development history is that resources sometimes contained overlapping information that did not completely align. It could also be hard to know exactly where to go to find a specific answer.

The new certification site borrows from the previously-developed resources and consolidates them into a unified presentation. OSHWA has worked hard to create paths that are helpful for new members of the community just getting up to speed and existing members who want to take a deeper dive into something specific. The new site allows you to skim along the top of information related to open source hardware and then immerse yourself in information when something catches your eye.

Licensing Guidance

There is no getting around the fact that licensing open source hardware is more complicated than licensing open source software. There are multiple elements to consider (hardware, software, documentation, etc.), multiple types of intellectual property at play, and some ambiguity around what is even protectable.

For the first time, OSHWA is providing specific guidance on licensing. That guidance comes in two forms.

First, OSHWA recommends explicitly and individually licensing hardware, software, and documentation associated with a piece of certified hardware. This will bring true clarity to future users. The certification application now requires you to specify a license for each of these elements.

Second, OSHWA recommends specific licenses for each of those elements. These recommendations are not exclusive, and OSHWA is happy to consider adding additional licenses as they are developed or as the community requests. The recommended licences were chosen in an attempt to make it easy to pick a license that works for you. This process is further simplified by providing examples of existing certified hardware that use a given license. That means that users who are not sure which license to use can simply follow in the path of other hardware creators that they trust.

Searchability

The first version of the certification directory was a google spreadsheet embedded in a web page. That made it easy to get certified hardware listed online. It made it hard to actually explore the directory.

The new certification directory fundamentally redesigns the user experience. It is now easy to find hardware, search by features, and drill down into what is really available. We hope that this makes the directory a much more useful resource for the community.

Next Steps

Version 2 is the newest version of the certification process, but it does not have to be the last. Play around with it, certify something, and let us know what you think. If you have ideas for features or information, or licenses you think we missed, please let us know in the forums.

This post originally appeared on the OSHWA blog.

Today, for the first time in the history in the Open Source Hardware Certification Program, OSHWA is revoking the certification for hardware. OSHWA is revoking the certification for the MOTEDIS XYZ 3D printer, with the UID ES000001, because the documentation is no longer publicly available. We have attempted to contact Motedis with a request to re-post the documentation but they have not been responsive.

Since this is the first time OSHWA has revoked a certification, we want to explain what happened, as well as what we will do in order to help prevent this type of situation in the future.

What happened

A few weeks ago, a community member wrote in and noted that the documentation link for the XYZ was no longer live. After reaching out to the contact person listed in the certification application, we have been unable to obtain a copy of the documentation to post publicly. Without the documentation, the XYZ is no longer in compliance with the program. Therefore OSWHA revoked the certification.

What it means

Revoking the certification means that going forward the XYZ can no longer be advertised as being certified open source hardware. It does not mean that Motedis’ failure to provide documentation today makes them retroactively in violation of the certification rules. The certification requires that the documentation be available at the time of certification. It does not require the certifying party to commit to making a copy of that documentation available in perpetuity. This is a burden that is unreasonable to expect of a party applying for certification.

What now

When the Certification program was being developed, there was a debate over whether or not OSHWA should try and host a repository of all of the certified hardware. One advantage of such a centralized repository would have been to allow OSHWA itself to maintain archive copies of documentation.

However, that approach also comes with costs. Developing and maintaining a feature-complete documentation hosting solution is beyond OSHWA’s core competency. Many good solutions for developing and maintaining software and documentation already exist online. Requiring certifiers to update and maintain yet another repository of documentation in order to certify was determined to be unnecessarily burdensome. Instead, the certification directory supports links which point to the place where the developers already host and maintain their documentation.

OSHWA continues to believe that this decentralized approach is correct. Nonetheless, the first revocation of certification provides us with an opportunity to consider improvements. OSHWA has started to investigate a process that would allow us to archive a version of all documentation. This archive would not be used at the primary documentation storage location. Instead, it would only be used in the event that the original documentation was no longer available. That would allow users of hardware to access documentation even after the responsible party stops supporting it as open.

If you have thoughts about this, please let us know in the forums.

This post originally appeared on the OSHWA blog.

We at OSHWA are excited to announce that the OSHWA Certification process has an officially registered trademark. This registration will make it easier for OSHWA to prevent people from using the OSHWA Open Source Hardware Certification logo if they have not actually gone through the certification process. We hope this will give the community more confidence when they see the OSHWA certification logo on hardware out in the world.

While there are many good faith ways to describe something as “open source hardware,” OSHWA considers certified projects to have met the gold standard of open source hardware by formally committing to comply with all of the elements of the community definition.

Are Trademarks Compatible with Open Source Hardware?

Trademarks are not in conflict with open source hardware. Trademarks are designed to indicate the origins of goods, not to control their reproduction. Knowing who produced something is especially important with hardware, because who actually manufactured hardware can be just as important to its reliability as who designed it.

Trademarks also do not prevent someone else from building on or using hardware that is protected by the mark. Companies like Lulzbot, Evil Mad Scientist, Adafruit, and Sparkfun all make open source hardware that anyone can copy, improve, or build upon. What people cannot do is pretend that their version of the hardware came from one of those companies by selling their version under the brand name of the original creator. That makes sense, because the original creator is no longer responsible for the new versions.

When creators have invited the world to make use of their open hardware, trademarks are how we know which pieces of hardware still come from the original designer. OSHWA believe that strong brand identities are compatible with a vibrant open source hardware ecosystem.

What OSHWA’s Trademark Means

The OSHWA Open Source Hardware Certification process is designed to make it easy for end users to quickly tell if their hardware meets the community definition of Open Source Hardware. When you see the OSHWA certification logo, you know what “open source hardware” really means.

The trademark will allow us to control how people use the certification logo out in the world. In concrete terms, it means that someone who fraudulently uses the OSHWA certification logo on hardware that does not meet the community definition is infringing on the OSHWA trademark. That means that OSHWA could bring a trademark infringement action against that person. This will allow OSHWA to protect the integrity of the certification mark.

What OSHWA’s Trademark Doesn’t Mean

As we noted in a post at the outset of the certification development process, OSHWA has no interest in controlling, nor ability to control, who gets to use the term “open source hardware.” Similarly, OSHWA does not have, nor desire, any control over who gets to use the Gear Logo and when they get to use it. Open Source Hardware is a concept that was developed by the community and continues to evolve as the community evolves.

Instead, OSHWA’s trademark will allow OSHWA to control the OSHWA-specific certification process. If the community definition of open source hardware is important to you, the OSHWA certification logo will be an easy way to know that the hardware you are holding matches that definition.

What is Next?

We are getting excited to launch version 2.0 of the certification process at the Summit this September. One of the big goals of 2.0 is to make it even easier to understand how licensing works with open source hardware, and make it easy to explore hardware that has already been certified. If you are at the Summit you will be able to see that launch in person. If you can’t make it, keep an eye on this space for updates.

Also, a huge thank you to the students of the Juelsgaard Intellectual Property and Innovation Clinic at Stanford University Law School for guiding OSHWA through the registration process.

Thoughts? Questions? You can always find OSHWA on Twitter, Facebook, and in the forums.

I originally wrote this post on April 14, immediately after the hearing it describes. At the time I assumed that the video of the proceeding would be released soon, so I held it in drafts until I could add the relevant videos. As it is now early July, I decided to post what I have as is. I’ll add the videos if/when the Copyright Office ever posts them.

Update July 29: the videos are live

On April 13 the US Copyright Office held a hearing on my petition for a rule to make it clear that unlocking 3D printers does not violate copyright law. Specifically, the request is for a rule to make it clear that using consumables (filament, powder, whatever) that do not come from the company that made the printer does not violate copyright law. Background on this process starts here. You can watch the entire video of the proceeding here:

I’ll pull out some clips and explain what happened in the rest of this post.

How We Got Here

As always, it is worth noting that it is strange to even imagine that copyright law would have anything to say about what kind of stuff you put in a 3D printer. In fact, I don’t believe that it does. However, there is enough ambiguity around the question that I think it is worth asking for clarification from the Copyright Office on the issue. The connection with copyright law is this: the same law that makes it illegal to break digital locks on DVDs so you can rip them might also make it illegal to trick a 3D printer into using material that did not come from the company that manufactured it. (These locks are often referred to as “DRM” - Digital Rights Management - or “TPM” - technical protection measures.)

In 2015 the Copyright Office issued a rule that exempted tricking 3D printers into using third party materials from that law. However, the Copyright Office’s rule was narrow. It did not apply if the printer was making things that are used in commerce and whose physical production is subject to legal or regulatory oversight. Those qualifications are pretty broad. This hearing was reducing or eliminating them.

I have argued that the carve out swallowed the rule because all physical production is subject to some sort of legal or regulatory oversight. The 3D printing company Stratasys argued that the carve out was important because it helped protect the safety of manufactured physical parts. My response to that argument is that the safety of manufactured physical parts is entirely unrelated to copyright law.

The Hearing

Prior to the hearing, the entire debate had taken place in the form of written petitions and comments to the Copyright Office. In my comments I had largely argued my position on policy grounds: the carve out language was unreasonably broad and appeared to address a concern that 1) was not supported in the record, and 2) better addressed by the expert regulatory agencies such as the FAA and FDA. Essentially I was arguing that the carve out imposed costs in the form of ambiguity without any corresponding (copyright-related) benefits.

The Less Good Parts of the Hearing

At the start of the hearing, the Copyright Office immediately called me out for not providing specific examples of individuals harmed by what I feel is a problematic carve out:

(This is clip starts the last time they called me out - check out the 5:50, 8:40, 11:36, and 14:37 marks for some other examples)

They repeatedly asked for specific instances of non-theoretical harm. I had not provided any in the record and was not prepared to provide any during the hearing. In part this was because I felt at the time that it was unreasonably burdensome to require an individual to provide that level of evidentiary support as part of a request.

Nonetheless, I am sympathetic with the idea that the Copyright Office may feel that they need evidence of specific, non-theoretical harm in order to grant an exception to a law. By the end of the hearing it appeared that if the Copyright Office felt that they needed specific examples of harm they would request it from me. At that point I will ask the community to help me identify those examples. (note 7/5/18 - the Copyright Office has sent out post-hearing follow up questions to some participants. They did not send any to me or Stratasys. Only time will tell what that means.)

The Better Parts of the Hearing

Fortunately, that was not the extent of the hearing. The Copyright Office took time to try and understand why the supply chain integrity arguments made by Stratasys were relevant to a copyright rulemaking. There were two specific lines of questioning that struck me as encouraging.

First, there was a discussion focusing on the harms that would occur if the digital locks (the TPMs) were broken on the 3D printer software. As it had in its written comments, Stratasys focused on the impact that broken TPMs would have on the physical integrity of printed parts. When the Copyright Office asked Stratasys about the impact that broken TPMs would have on infringement of the software itself, Stratasys stated that it had never really considered that question.

Since the entire purpose of the copyright law against breaking TPMs is to prevent infringement of the work protected by the TPM, this was a telling admission from Stratasys. To me it highlighted how unrelated Stratasys’ concerns were to copyright law. Hopefully the Copyright Office sees it that way.

Second, there was a discussion around testing of parts. Stratasys provided examples of parts that had failed various quality checks (the nice thing about 3D printing hearings is that there are always physical things to pass around). Stratasys explained how important it was to do testing of physical parts and how third party materials might result in parts that failed to meet the quality standards.

At that point the Copyright Office asked if the same quality testing needed to be done on parts printed with Stratasys material and third party material. Stratasys answered that it did.

I also found this to be an encouraging answer. If Stratasys had stated that its materials allowed manufacturers to skip the quality testing, then it might be able to argue that third party materials could introduce undetected defects into the supply chain. However, if every part needs to be tested no matter where the input material comes from, it is unlikely that third party material will introduce hidden defects into the supply chain.

It is, of course, worth noting again that supply chain integrity has nothing to do with copyright law. Nonetheless, it is still helpful when an opposing argument falls apart, even if that argument is not particularly relevant.

Next Steps

Now, we wait. At some point the Copyright Office will make a recommendation to the Librarian of Congress. The Librarian will then issue a final decision. I’ll add a new post when that happens.

This project is designed to answer the question “if I leave my house now, how long will I have to wait for my subway train?”  One way to answer that question is “if you leave right now you won’t have to wait at all”.

The project uses a raspberry pi zero to connect the NYC MTA real time arrival data with neopixels.  The neopixels give you an indication of how far trains are away from the station.  Importantly, the alerts are  not based on the absolute time until the train arrives at the station (”A train will arrive at the station in 5 minutes”).  Instead, the alerts are aware of how long it takes to walk to the station from my apartment and are therefore based on the time from the station when you get there (”If you leave now and walk to the station, there will be a train arriving in the station 5 minutes after you get there.”).

A few quick notes before getting into the details.  First, the way you arrange the indicator lights is essentially arbitrary.  We happened to abstract them out into strips.  However, you could do spirals or overlay them on a map or whatever you want.  Second, and speaking of maps, this project builds on the never quite finished metro-and-bikeshare map project from when I lived in DC. That one combines reading from the WMATA api and the DC bikeshare API with an eye towards lights integrated into a map.  If you are in DC it may or may  not be helpful for you. Third, the parts of this that parse the MTA’s API is 100% reliant on Chris Griffin’s real time countdown subway display.  The NYC subway API is more robust than DC’s, which means it is like a million times harder to parse if you (like me) don’t know what you are doing.  Chris’ code made everything a lot easier.

The basic outline of the project is as follows: 

1. Poll the MTA API to find out when trains will arrive at your station
   
2. Pull out the trains you care about
3. Assign them to the relevant indicator lights
4. Repeat

Bill of Materials

• Rasbperry Pi Zero W (you’ll need a power supply too)
  
• Neopixels (however many lights you want)
• Diodes (you only  need one)
• 0.1uF capacitors (I used 1 for ever 4 neopixels)
• 4700uF capacitor
• Female DC power adapter
• Wires
• Some sort of pushbutton (if you want the pause feature)

If you decide to go with the physical layout I used you will also need

• Mirrored acrylic (I got mind at Canal Plastics)
  
• The brackets (available in the repo and on thingiverse)

Software

I’m assuming you already have your pi connected to your home network to get this rolling. One thing that I did discover is that you can transfer an SD card from a regular pi to a pi zero. That allowed me to prototype this entire thing on a full sized pi (with headers) before shifting it onto the zero.

Tumblr is bad at formatting code so I’ll just point to the github repo here for the entire code.  I’ll use this section to walk through important parts of the code.

#variables to hold the lists
arrival_times_york_south = []
arrival_times_york_north = []
arrival_times_high_south_a = []
arrival_times_high_north_a = []
arrival_times_high_south_c = []
arrival_times_high_north_c = []

This section creates the station lists.  For my purposes I care about three stations: York, High Street (A line), and High Street (C line).  Each station has two directions.  Modify these as relevant for the stations you care about.

#variables to hold the station IDs
HighS = [‘A40S’]
HighN = ['A40N’]
YorkS = ['F18S’]
YorkN = ['F18N’]

These hold the UIDs for the stations within the MTA API.  Someone made a helpful heroku app to help you find the ids that you care about.

#variables to hold the walk times
HighWalk = 13
YorkWalk = 7

This is how  long it takes you to walk to the station.  This is used to customize the alert time for your location.

def grabber(station_ID, station_URL, station_line):

This function adds the arrival times to the station for every train that is in they system.  Since the MTA API has data for when every train running will reach every station, the output here can be a dozen or so numbers that are as  high as 60 minutes out.

def lighter(arrival_list, time_start, light_one, light_two, light_three, light_four, light_five, line_R, line_G, line_B):

This function decides which of the neopixels to turn on.  “arrival_list” is the output from grabber, “time_start” will be how long it takes to walk to the station, the “light_x” is the the neopixels associated with that station in that direction, and “line_X” are the RGB colors associated with the line.  The idea here is that you tell the function when trains are coming, how to correct those arrival times for you walking to the station, what the indicator lights are, and what color they should be when they are on.

The block of if statements in this function that start with 

if  int(item) == time_start:

decide what these lights mean.  I decided to make five lights for each direction.  They are:

• leave now
  
• 1-2 minutes until leave  now
• 3-4 minutes until leave now
• 5-7 minutes until leave now
• 8-12 minutes until leave now

These are relatively arbitrary categories can you can change them so that they work for you.  As noted above, the basic idea is to get a sense of how long you have until you need to leave and how many trains are coming reasonably soon.  Note that the lights can’t tell the difference between 1 train being in a category and 2 or more trains being in that category.  Also, I suppose this is where I should mention that these lights are only as accurate as the MTA info they are based on.

def blackout():

This function turns off the lights at night.  It has slightly different times for weekdays and weekends.

def pause_button(channel):

This function is for a pause button that temporarily turns off the lights during a time when they would otherwise be on.  I don’t know if I’m going to use it (as of this moment the off time is set to 30 seconds) but if the lights are somewhere that you’ll want to be able to shut them off for random reasons this allows you to do so.

while True:

Having  built these functions, this loop actually runs them. It ends by pausing for 5 seconds.  This is a shorter amount of time than necessary and was originally 30 seconds (this probably doesn’t need to be updated more than once a minute).  However, I’ve found that the actual downloading and parsing of the MTA data can take 15-20 seconds (sometimes even more) so I shortened it to 5 seconds.

Hardware

Here’s the wiring diagram:

I ended up putting the diodes every fourth neopixel.

After drilling the holes in the acrylic sheet I put the neopixel through the hole and soldered in the wires:

Here’s an image of all of them chained together:

Wired together with the harness:

And soldered in with the pi:

And that’s more or less it. Once you have things connected to your network just pick a place to hag it up.  Now you may or may not be late to a subway train again, depending on the accuracy of the MTA API data.