Open Discussion: Best Practice for Mislabeled Open Source Projects?

non-oshw

In looking around for examples of great open source hardware projects, we came across an unexpected number of projects and products labeled as open source hardware that, upon closer inspection, actually turn out not to meet the definition. Often, they’re using an inappropriate license— typically a “non-commercial license,” which is not only unenforceable but explicitly incompatible with open source values. Sometimes, they haven’t released the design files. Sometimes, a person has apparently misused the term “open source” to mean “closed and proprietary.” And sometimes you might see the open hardware logo used without any substance to back it up.

But what (if anything) can or should be done about it? We’d like to solicit your input as to the best ways to approach this problem.  Perhaps there are not any easy answers.

As a baseline, we think that it’s important to address the problem, and to do so earlier rather than later. To mislabel a product for sale as open source hardware may constitute false advertising, illegal in the US under state and federal law. In noncommercial projects where nothing is for sale, misusing the terms may help to set precedent that can damage the community’s understanding of open source. For instance, if enough people see non-commercial licenses on things labeled as be open source, they may assume that it is acceptable.

If you happen to know someone behind the project, you might consider contacting them directly to start a dialog about what it means for something to be “open source.”  Or, you could (hint hint hint) send them a link to this article, letting them know that you found it interesting!

But, what if you don’t have any personal connections to the people involved? It’s certainly not as easy. Sometimes you can initiate a dialog with a company, perhaps by asking about their design files or licenses. At the other end of the spectrum, people sometimes bring up options like public shaming. In our view, shaming is harmful to the open source community, and should be considered a last resort akin to violence. Rather, we as a community need to work towards positive ways to nudge people toward doing the right thing.

Please let us know what you think: what should you do when you come across a project mislabeled as open source hardware?

OSHWA on Creative Commons and Open Source

CC licenses
Over at OSHWA.org (of which I am a board member), there’s a blog post about different Creative Commons license choices, and their implications for open source projects:

The reason is that there is not a single entity called the “Creative Commons license.” Rather, Creative Commons offers a number of different licenses that can apply some rights and protections to your work, including the CC-BY and CC-BY-SA licenses which reflect open source values closely. [...]

Creative Commons also offers licenses that carry restrictions — against commercial use and/or derivative works — that are strictly incompatible with open source. The open source hardware definition states that a license for open source hardware “[...] shall allow for the manufacture, sale, distribution, and use of products created from the design files, the design files themselves, and derivatives thereof.” Thus, if you choose to release hardware under the banner of “open source,” that means that you agree to allow others to use your design commercially, as well as to create derivative works (and to use them commercially). Consequently, you cannot advertise your project or product as “open source” if it carries restrictions against either of those uses.

Image CC-BY creativecommons.org.

EE Times Interview on Open Source Hardware

Windell and Lenore and Three Fives kits

Photo by Rick Merrit, EE Times

EE Times came by and interviewed Windell in advance of his upcoming Maker Faire talk about best practices for Open Source Hardware.

…Big semiconductor companies are jumping on the bandwagon of open source reference boards. But their chips’ intellectual property remains carefully guarded corporate crown jewels. …

Open Hardware Summit 2014: Call for papers

OHS
The Call for Papers is now open for the 2014 Open Hardware Summit. This year’s summit will be September 30 and October 1 in Rome, Italy.

The Open Hardware Summit is the annual conference organized by the Open Source Hardware Association and the world’s first comprehensive conference on open hardware; a venue to discuss and draw attention to the rapidly growing Open Source Hardware movement. Speakers include world renowned leaders from industry, academia, and the maker community. Talks cover a wide range of subjects from electronics and mechanics to related fields such as digital fabrication, fashion technology, self-quantification devices, and DIY bio. Workshops focus on, but are not limited to, education, manufacturing, design, business, and law.

The call is on a short schedule this year: Submissions are due by 25th of May 2014.

OSHW Talk at 2014 Bay Area Maker Faire

Maker Faire 2014
Wearing my OSHWA hat, I’ll be giving a talk about Open Source Hardware at this year’s Bay Area Maker Faire:

Best Practices for Open Source Hardware in 2014
In the past year OSHWA, the Open Source Hardware Association, has worked with the community to develop a modern list of best practices for designing, releasing and building upon existing open source hardware projects. Windell Oskay, Vice President of OSHWA, will discuss recommended approaches, touching upon open source design tools, documentation, hosting, licenses, and other current issues. Time permitting, we will also take questions from the audience.

The talk is scheduled for Saturday, May 17, 4:45-5:00 pm. You can find the rest of the center stage schedule for Maker Faire right here.

Open Source Beehives

The Open Source Beehives project is currently running a crowdfunding campaign with the goal of gathering information from sensor equipped hives throughout the world to help solve bee population problems like colony collapse syndrome. The sensors can also be used by individual beekeepers to monitor the health of their hive.

Even without the sensors and the citizen science, their hive designs are beautiful.

WaterColorBot Software and Documentation

We’re wrapping up this week’s updates on the WaterColorBot project with some notes about software and documentation.

Documentation

Our guides for setting up and using the WaterColorBot are already extensive, and still growing. You can find them at the Evil Mad Scientist wiki, or get there with a shortcut: watercolorbot.com/docs.

getting started booklet
Getting Started with WaterColorBot
One of the most important parts of the WaterColorBot’s documentation is our booklet “Getting Started with WaterColorBot.” The booklet covers the process of assembling the WaterColorBot kit, basic usage, an overview of software options, and a host of tips and tricks. It’s available on our documentation site in PDF format.
video still
Assembly video
We’ve put together a setup video, walking through the steps of putting together the WaterColorBot kit. The video is strictly optional, and covers much of the same ground that the booklet does. You can watch it at http://watercolorbot.com/setup.html, or find it linked from our documentation page.

 

Software

There are, at present, three primary applications that you can use to control the WaterColorBot, each of which has unique advantages.

RoboPaint RT
RoboPaint RT
The simplest of the three programs is RoboPaint RT, which is the one that we featured in our Kickstarter video. RoboPaint RT is a “real time” application that allows you to paint with the WaterColorBot. It’s straightforward and manual: Click on a color in the paint palette to change to that color, click on the water to dip the brush in the water, and drag the brush to paint on your paper.

With RoboPaint RT, you can also replay your drawing to make multiple copies, and save the file to open up and print again later. This program can be a lot of fun to play with and is a great way to get acquainted with the WaterColorBot. For those with good artistic skill, it can also be a remarkably powerful program.

 

RoboPaint
RoboPaint
Next up is RoboPaint, another stand-alone application written by the WaterColorBot team. In RoboPaint, you can open existing artwork in SVG format, snap the colors to your paint palette, and paint the document. It also has a rudimentary edit mode that lets you create new drawings to print. If you’re starting with existing SVG artwork, RoboPaint is generally the best of the three programs to use for a few different reasons. Most importantly, it’s good at automatically filling in large solid regions of a painting.

 

Inkscape drawing
Inkscape, with extensions
The third primary application is Inkscape, a superb, free vector graphics editor, for which we have written an extension (a plugin) to control the WaterColorBot. Our extension provides fine grain control over exactly what will be painted, but more-or-less requires that you create the artwork within Inkscape to take full advantage of the features.

Above, the drawing used to make the Robo-painted thank you cards that we wrote about earlier this week.

Inkscape is also capable of importing artwork in PDF format (as well as tracing bitmap graphics to some extent), and saving as SVG graphics that can be used with RoboPaint. If you’ve ever used an Eggbot (and its Inkscape based driver) you might want to start here, before trying the other apps.

 
And if you like to code…
For developers (and people who just like to tinker with code), there are additional options:

- Rolling your own, starting with our examples. RoboPaint RT is written in Java/Processing, RoboPaint is written in JavaScript, and the Inkscape extensions are written in Python. These can provide a nice starting place, in a few different environments.

- Direct serial control. The “EBB” motor controller board used on the WaterColorBot can be independently controlled from any environment that can send serial data to your USB ports.  Its command set documentation is here.

- The RESTful API. RoboPaint includes the “CNCserver” API for WaterColorBot, documented here. You can use this interface to control the robot locally (from your computer) or remotely (from anywhere on the internet, if you enable the remote option within RoboPaint and tell the other computer what your IP address is). Currently this is a low-level API; we are working on a higher level version where you can simply send an SVG file for RoboPaint to process and paint.

 

WaterColorBot kits are shipping now, and we are still taking pre-orders for December shipment. 

OHS 2013 Highlights: NeoLucida

NeoLucida was the subject of one of the best presentations and demos at the 2013 Open Hardware Summit.

The NeoLucida is a drawing aid that allows you to trace what you see.  It’s the first portable, authentic camera lucida to be manufactured in nearly a century. We love camera lucidas, and we think they can help people understand art history in provocative new ways.

The NeoLucida is was launched in a wildly successful kickstarter campaign to make a modern version of a camera lucida available to a new generation of artists. It’s not a complicated device, but it is an extremely specialized one, and niche products like it are a place where open source hardware and crowdfunding can come together incredibly successfully. They were able to bring the cost of owning a camera lucida into the realm of possibility for artists who can’t afford antiques. By publishing how the device works and how they make it, they have increased understanding both of the device itself and of historical works of art made using it.

It was exciting to try out a NeoLucida during the demo session at the summit, especially after hearing about its history.

Open Medical Hardware: The Open Stent

Untitled
Untitled
The stent pictured above is an example of an Open Stent from NDC, makers of nitinol materials and devices, particularly for medical applications. In their introduction to the project, they write:

The first problem that we encounter when developing useful and practical educational resources for stent design is that every design we might want to use as an example is proprietary! That leaves us without much to talk about… So to solve this problem, the first step was to create a design to use as an example. The Open Stent is designed to be completely generic, but also realistic, and relatively easy to modify and extend to be useful for whatever purpose a designer intends.

In addition to publishing their draft of Open Stent Design, which they call “a practical guide and resource for design and analysis of a generic Nitinol stent,” NDC has provided extensive calculation tools and CAD files as well, to help others evaluate and create derivatives of the design.

The project is a fascinating open source hardware use case, where creating an open design provides a platform for education and discussion where none existed before.  It’s also very exciting to recognize this as an early example of open source hardware in the field of medical devices— one of the places where open hardware can potentially make a very big difference in the world.