Talk:OSHW

I like the spirit of the definition, but I would propose two amendments for clarity:

• provides design files -> provides all relevant design files (otherwise hardware where only partial or incomplete design information is available would qualify)
• software it has developed that is essential to the proper functioning -> necessary or required instead of essential ("essential" is a very strong word, potentially allowing to exclude software that is usually required, but not absolute essential under all circumstances)

--Christian Siefkes 16:02, 21 April 2010 (UTC)

I like that you're riffing off the Open Source Definition, but let me give you a heads-up that the OSD talks about the license under which software may be distributed. The assumption is that if certain legal permissions are preserved, that the desired open source effect of collaborative development will occur. That is not necessarily true. Something more is needed, but we're not yet clear on how to put that into contract / agreement form.

128.153.100.220 14:57, 3 May 2010 (UTC) (Russ Nelson)

OSHardware vs OSDesign

I am looking for a CC-BY or CC-BY-SA type license for the Open Moto X project. However after spending a few hours time reading about TAPR, OSI, c,nn,m, CC and others my brain is struggling to understand if the various open source hardware licenses (including the OSHW license) are specifically for Hardware i.e: processors and associated systems that run software or if it might also be applied to physical objects in general that are also "hardware" but are more often referred to as "Designs". Of course the OMX bike will include a Battery Management System that will include hardware and software but I would prefer to use one (simple to understand) license if possible. I am hoping that OSHW might eventually be it. --Payo 13:55, 12 May 2010 (UTC)

CC Grant Application

CC is offering grants to help move projects such OSHW forward. Would such a grant be at all useful? see <http://wiki.creativecommons.org/Grants> for more information.--Payo 15:48, 3 June 2010 (UTC)

Broadening the definition

I like the definition in principle, but I think for broader commercial adoption the license needs a couple of tweaks.

First, the clause about requiring all OSHW to be released with essential code prevents any OSHW design from using proprietary sub-components. In an ideal world we could demand that all the vendors comply to OSHW so that we ourselves can release OSHW-compliant designs. However, in reality restricting all designs to only use OSHW-compliant hardware essentially relegates OSHW to only a small subset of components; unfortunately, some of the most interesting components -- high-end CPUs, cellular modems, wifi chipsets -- do not comply to this. So unless we want to define a world of OSHW that explicitly excludes using such components, I think the definition needs a little refinement.

I would propose softening it up such that the distributing body, system integrator, or immediate author is required to release only their own essential code and improvements. This means that only the value you or your organization that's attempting to create OSHW adds is required to be distributed and released, but you don't have to require vendors to also comply. It's a chicken and egg problem, and if enough people start releasing with OSHW eventually the ecosystem will convert, but for starters we are plugging into a closed ecosystem so this interoperability clause is essential for broad adoption, in my opinion. The devil is of course in the details of the definition, and there's ways people can work the system to "get around" releasing certain key components, but also the boundaries between components and system integration are much more clearly drawn on hardware than on software, where the distinction between libraries and the final program often melt away.

Second, the clause about the preferred format for modification doesn't set well with me either, because there is no universal preferred format for modification in the hardware world (unlike in the software world where ASCII text seems to be pretty common, and there's multiplicity of interoperable editors that can view and modify ASCII text -- if only hardware's biggest interchange problem was CR/LF!). I don't want to bake into the OSHW license any implicit "champion" for OSHW design tools, or to inadvertently promote one design tool over another. I'd suggest that the least common denominator for information exchange in hardware is a printed or printable schematic (PDF, PS, ASCII art, JPEGs) and that should the minimum for OSHW distribution; CAD-specific binaries are a nice plus when possible. To wit, the way the clause is written, certain large companies that make their own proprietary in-house design tool can distribute their schematics in their internal format, which nobody else can read because the CAD tool is proprietary, and yet claim to be compliant because they've released it in the form preferred for their hardware designers. Also, I don't want to have to install or license one copy of every possible CAD tool simply to view schematics, even if the tools are open source. As a first cut, a PDF is good, and then on follow-up I'll ask for binary CAD once I've had a review of the schematic.

Despite these concerns, I think that the definition overall is great progress and I'll sign it personally to keep the momentum going.

--bunnie

Open vs. Recursively Open

bunnie,

You seem to be contrasting two possible degrees of openness by saying that that "open" should impose few constraints on a thing's means of production and that "more open" might impose more constraints. This makes me think that we need another word. Perhaps "recursively open" is a good way to describe the kind of open hardware whose components and means of production are themselves recursively open?

--Michael Stone 12:04, 15 July 2010 (UTC)

Open Data Formats and CAD Tool License Conflicts

As it relates to the broader open source community, collaboration and contributions, requiring data be submitted in any tool vendor specific format could also risk conflict with 3. Derived Works. For example, CadSoft's EAGLE - used in a lot of open source hardware projects - has a Freeware version with a non-profit only criteria. A thousand Freeware contributors feeding a dozen Commercial-permitted maintainers doesn't sit well with me; contributing via Freeware may infect the project with the non-profit condition.

Excluding gerber and other low-level formats from 1. Documentation makes things even more complicated. At least that's an ASCII format that can be parsed and diff'd either directly or through some graphical XOR mechanisms.

All the more reasons to get gEDA and equivalents ramped up. ;-)

-- clothbot

I don't think it's fair to maintainers to tell them they can't demand submissions be made in the format of their choice any more than it is to say that they can't demand that submissions to a F/OSS project be in the language of that project. EDA/CAD tools are typically difficult to use and all merging of changes must be done by hand. It's too much to ask them to license, install, and learn some new tool as well.

If you don't like their choice, fork the project.

-- Pierce Nichols

I too can't wait for gEDA to ramp up. I've got a bunch of designs I want to licence under an open source agreement but my CAD package is very obscure. I don't feel right releasing those design files as they will be next to useless for the average user.

-- Daniel Garcia

Design representation file formats

In the Open Manufacturing community, one of the ideas that has spawned is this concept of thinking of STL/meshes/jpegs as kind of like "binary objects". Yes they are useful if you have the same machine that you "compiled" the object on, but they are not really design files in the sense that constructive solid geometry (CSG) or boundary representation (b-rep) CAD files are, like ISO 10303-21 (STEP) or IGES or the myriad of other formats. It's also interesting from a community education perspective, because a lot of people think that Google Sketchup is a CAD tool, and that Blender is a CAD tool (blendercad), when in reality the fundamental data representations are different. In my view, I would favor SVG over JPEG any day. I suspect that static image files are covered by Creative Commons licenses, and when we're talking about "modifications" to designs, that's like a diff applied to SVG or STEP. Right? Can we get a little more coherent in what we're talking about? :-) -- Bryan

Human Readable vs Best Practices

I see the current v0.3 OSHW content breaking out into two parts for a v0.4: base-level Human Readable requirements for OSHW to be considered "open source" (i.e. at least one human-readable representation of the underlying design) and Best Practices ( gEDA > EAGLE, Collada > STL, EDIF > Gerber, etc.)

-- Andrew (clothbot)

I endorse the requirement for human-readable design documents. In particular, I'd like to see solid BoMs and netlists for electronics designs and, to the extent possible, similar documentation for mechanical designs.

I'm not so fond of your best practices. gEDA is a long way from being where Eagle is, and even Eagle is somewhat low-powered compared to many pro-level CAD/EDA packages. EDIF is a substitute for Eagle/gEDA/etc files, not for Gerbers. I think Gerber 274X files should be considered the standard for board artwork -- all the tools speak it, it's human readable and modifiable, and every board house on the planet understands them. What's not to like?

-- Pierce Nichols

As it relates to Best Practices, it's that EAGLE Freeware "non-commercial" clause that has me more concerned.

-- Andrew (clothbot)

ZigBee, OSHW, & non-commercial licenses

It's impossible to create a product using ZigBee that meets the terms of the definition. The popular XBee modules are closed entirely, and it is impossible under the terms of the license for the ZigBee standard to create a ZigBee system that is compliant with this definition, specifically the non-discrimination clauses. This is because while the standard is freely available for non-commercial use, commercial users must pay a substantial license fee.

I would like to see the non-discrimination clauses modified in such a way that it is possible to implement ZigBee or other free for non-commercial use protocols/standards in OSHW.

--Pierce Nichols

Making a license around this

Fundamentally, the problem with patent law in the United States- where many of the signees are living- is that patents allow someone the right to "exclude others" from making, using, or selling the patented invention unless the patent has expired into the public domain. Open source software is able to function because of a hack on top of copyright law. However, there has been no such hack as of yet with patent law, especially since the moment you invent, build or design something, you are not issued a patent. For this reason and others, I have been spending time trying to figure out a way to make a license out of something that matches the OSI open source definition for hardware, knowing that the "rights" secured by copyright do not necessarily apply. It's a tricky question! There is lots of content on this subject in a public mailing list archive located here, like my transcripts from talking with various law firms, public discussion of how open source hardware might work, and various legal vehicles to make the legalities work out. -- Bryan