you can delete this comment if you like.

“It is important to note that hardware is different from software in that physical resources must always be committed for the creation of physical goods.”

I am extremely surprised that this license would not acknowledge that software requires physical resources. See the New Yorker’s interview with Saul Griffith for evidence of the eruption in resources necessary to support the world wide web. Distributing software does *not* have zero-marginal cost. Webservers, databases, networks, hard drives, etc, all require resources.

Hardware vs. software is an outdated dichotomy from the early days of computing. The two terms only exist relatively. The harder parts to change of a system are its hardware, the easier parts are its software. ASICS, FPGAs, PCBs, software radios, switching power supplies, configuration files, etc., all exist somewhere in between those extremes. In fact, it’s not yet clear how e.g. case design would fit into all of this. Are plastic gadget (DVD player, synthesizer, etc.) cases hardware?

You must regard that the GPL is *one form* of Open Source Software (OSS), just as BSD, MIT, and CC are others. Labeling *this* license “OSHW” is overly broad and would cause confusion with other open source hardware licenses.

1. “The hardware must be released with documentation”

This would prevent people from releasing open source hardware under this license without documenting it. This is an important part of the world today – those who reverse-engineer. It will be more successful to let people legally reverse-engineer designs, than force vendors to release their design files. Also, as written, this term is ambiguous about releasing design files without releasing the hardware. Perhaps a vendor would only like to make design files available to those who buy the products? That is still open source, but different from the way you might be thinking about it.

“Intermediate forms ” is ambiguous. I offer the same critique as point #2, which is endemic to all DIY. How far should it extend?

e.g. if “printer-ready copper artwork from a CAD program”
is disallowed, then under what criteria would you allow e.g. .brd and .sch files describing a laptop? They’re both output from the same software, yet the .brd and .sch files require a single vendor’s for-pay piece of software, while the printer-ready artwork could be used in conjunction with many different pieces of free software. What if someone only wanted to release the schematic for their design, without the layout?

2. “If the hardware requires software,”

How far does this extend? Hardware requires software, which requires software. Is a silicon chip a platform, and the paths within it software? If I use a chip, do I demand rights to its software such as the Hardware Description Language for it? Do I demand the source code for the HDL compiler? CAD files for the lithography equipment to make it?

“could reasonably be considered straightforward”

How could writing e.g. device drivers (and many other programming tasks) *ever* be considered straightforward? I’m serious. You can not stipulate common sense, never mind advanced skills. This could never be argued successfully in front of a judge. Case in point, the Apple iPod, generation 3, had errors in the silicon w/r/t the dual-processor cache. It was nearly impossible to figure that out, but a German kid did it.

***As a more practical alternative: require the device to be designed to *allow* people to change the software image within it. For example, changing the software image on a dishwasher, vehicle, etc.

3. “must allow them to be distributed under the same terms as the license”

Most licenses maintain their power by *requiring* that derived works uphold the same license. Must allow != require.

#6 is unclear. It can not hold any legal power because it is unclear. Maybe it’s trying to avoid associating OSH with racial discrimination??? However, the goal of a license is discrimination among groups of persons, their works, practices, and cultures. It’s best to own up to that at the onset and target the practices you want to replace with earnest justifications.

#9 and #11 are very unclear. Their phrasing needs to be disentangled. And examples would be valuable, too.

Good luck with this guys! If I’m done with my thesis by 9/23, I’ll take part :^)

This document, when it is finished, will be the standard used to *evaluate* open source hardware licenses, just as the Open Source Definition is used to evaluate open source software licenses. The license itself will be the document that really needs to be vetted strongly to hold up in court, and this definition will be the one that the community– and hopefully the OSI in particular –uses to evaluate whether a given license is valid open source hardware license.

>I am extremely surprised that this license would not acknowledge that software
>requires physical resources.

This isn’t a license. Also, resources needed for software can be huge. This doesn’t say otherwise. Physical resources are *always* needed for copying hardware. Usually permanently. There is a real difference because there is a physical artifact that must be supported under laws that treat physical objects differently from software.

>You must regard that the GPL is *one form* of Open Source Software (OSS),
>just as BSD, MIT, and CC are others. Labeling *this* license “OSHW” is overly
>broad and would cause confusion with other open source hardware licenses.

No. This is specifically NOT a license. This definition is meant to be compatible with many different hardware licenses, ranging from very restrictive to very permissive.

>This would prevent people from releasing open source hardware under this license without documenting it.

Where do you draw the line? In software, do you really think that it makes sense to release a piece of software as “open source” without releasing any of the source code? Saying that you allow a piece of software to be reverse-engineered does not mean that it’s open source. That would be, “closed source, but you’re allowed to reverse engineer it.”

>What if someone only wanted to release the schematic for their design, without the layout?

I believe that different portions of a design could be released, separately, each under open source licenses. However, it’s important to be clear that the overall product is not labeled as open source in that case.

>”could reasonably be considered straightforward” How could writing e.g. device drivers (and many other programming tasks) *ever* be considered straightforward?

If you have the full hardware documentation, where each chip lists what each register does, then it’s straightforward. Not easy, but straightforward. If you have a proprietary chip, with a proprietary interface that you need the “secret password” for, then you need to release that password. This clause basically means that you don’t need to release software for it if the hardware is fully documented.

>. “must allow them to be distributed under the same terms as the license” Most licenses maintain their power by *requiring* that derived works uphold the same license. Must allow != require.

This is about allowing permissive or restrictive licenses to be constructed that are compatible with the definition. You yourself seem to recognized that there are different types of license out there.

>#9 and #11 are very unclear. Their phrasing needs to be disentangled. And examples would be valuable, too.

These are in analogy with the corresponding terms of the OSD. These prevent certain types of loopholes that would allow you to label something as open source when it’s anything but.