Version 1.1 of the definition has been released. Please help updating it, contribute translations, and help us with the design of logos and buttons to identify free cultural works and licenses!

Editing Talk:OSHW

Jump to navigation Jump to search

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.

Latest revision Your text
Line 37: Line 37:
 
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.  
 
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.
+
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.  
  
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.
+
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 (in the software world, ASCII text seems to be pretty common). 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.  
 
Despite these concerns, I think that the definition overall is great progress and I'll sign it personally to keep the momentum going.  

Please note that all contributions to Definition of Free Cultural Works are considered to be released under the Attribution 2.5 (see Definition of Free Cultural Works:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to solve the following CAPTCHA:

Cancel Editing help (opens in new window)