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 publish the changes below to finish undoing the edit.

Latest revision Your text
Line 1: Line 1:
==Untitled==
Well, first you have to define "Open" :^) I saw some traces of "consortium disease" already in this definition, but really, it's a start on a really thorny subject. For example, it could be perverted by releasing design files that only work on a particular vendor's product. In fact, at this point, any design files are likely usable only on one tool, closed or Open. For example, many release Eagle files. I've downloaded it, it does nice work, it was free ($), but it is most definitely not Open. At least it runs on Linux. Doesn't this immediately put restrictions on the hardware? If you use their free ($) version, it's for non-profit use only. Does this make these designs invalid
for automation work? Are they free? I can solve the problem by using only OSS for my designs, but will the term Open Hardware mean anything? No, by the most common of existing examples. It's broken from the start. And as we have already seen, the tiniest crack will be exploited and we will see extremely perverse examples of "Open Hardware". Not meaning to pick on CadSoft in particular.
And I could discern the clauses added by those whose ox would be gored.
Regards
Curt Wuollet
I like the spirit of the definition, but I would propose two amendments for clarity:
I like the spirit of the definition, but I would propose two amendments for clarity:


Line 25: Line 13:


I am looking for a CC-BY or CC-BY-SA type license for the [http://www.openmotox.org 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. --[[User:Payo|Payo]] 13:55, 12 May 2010 (UTC)
I am looking for a CC-BY or CC-BY-SA type license for the [http://www.openmotox.org 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. --[[User:Payo|Payo]] 13:55, 12 May 2010 (UTC)
There is a article which suggest that the term "Open Design" is used for such cases. The article  [http://www.engr.uky.edu/psl/omne/download/BazaarDesignOpenMicroAndNanofabricationEquipment.PDF Bazaar Design of Nano and
Micro Manufacturing Equipment] is however a bit old, and is perhaps talking about yet another kind of hardware (manufacturing equipment). It seems like the problem is that a product like the Open Moto X is a combination of a Mechanical Design (Frame, brake system etc.), Hardware (ABS control circuits, Battery interface, etc.) Software (Battery management, diagnostics, etc.) AND design as in the visual appearance of the Bike (Bodywork, visual profile, look, etc.). When you combine these different aereas of "design" you reach in to the realm of licensing, copyright and patenting. Perhaps also design protection. I'm sure the people at both openecology.org and local-motors.com have the same kinds of troubles, and it would be a very useful expansion of the OSHW to handle all of these things, if that is a possibility.


== CC Grant Application ==
== CC Grant Application ==
Line 125: Line 110:


-- Pierce Nichols
-- Pierce Nichols
:What is wrong with an interchange format?  If it truly "interchanges", ports between different editing applications, then that's what's wanted.
:-- Karl O. Pinc
::There are two problems I see with interchange formats as opposed to native formats -- one philosophical and one practical. The philosophical one is that they are not the preferred format for making modifications; that's a key plank of every open source definition I have seen. The practical one is what gets left on the cutting room floor when the conversion is made. There's never a perfect 1-to-1 mapping between formats; some filters and format pairs are better than others, but you always lose something.
::-- Pierce Nichols


Uh, Pierece, consider SVG and IGES. I also suggest that if there are any format-related restrictions, we should be specific about what our goals are. For instance, I am tired of downloading an open source hardware project only to find that it is defined in the STL format, which while an "open" format, is pretty much useless for design purposes (which is what open source hardware is about, presumably). -- [http://heybryan.org/ Bryan]
Uh, Pierece, consider SVG and IGES. I also suggest that if there are any format-related restrictions, we should be specific about what our goals are. For instance, I am tired of downloading an open source hardware project only to find that it is defined in the STL format, which while an "open" format, is pretty much useless for design purposes (which is what open source hardware is about, presumably). -- [http://heybryan.org/ Bryan]
Line 141: Line 118:


-- Pierce Nichols
-- Pierce Nichols
Bryan, that gets to the krux of the matter.  The OSHW Definition itself needs to be format-agnostic.  As long as a given project's works are available in a human-readable format, an unencrypted manufacturable format, and the source files in which edits are performed, it should be considered Open Source Hardware.
* If the design files are available in human-readable form then I (the end user/consumer) can understand how things work, debug problems, and "edit" my hardware.  This is also the most future-proof format you'll ever get.
** Think of all those 50yo tube radios with schematics pasted to their insides.  They can still be fixed and re-built from scratch if you can source or make the parts yourself.
** Worst-case, I will be able to re-capture the project into my preferred design environment and fork to my heart's content independent of whether the manufacturable and/or editable forms are accessible.
* If a manufacturable format is present, I can send the DXF drawings to the machine shop, gerber to the factory, STL to the fab house, and/or print off my own versions of that specific implementation.
** I can import these files into the editor of my choice and do tweaks as needed, or instantiate them as required in my own project(s).
** This is less future-proof in that "manufacturable" changes over time.  For example, most semiconductor fabs won't take designs on rubylith these days; GDSII is the norm.  The forward-port can be automated, but it might be faster to start with the human-readable source to adapt to everything else that has changed in the meantime.
* If the source design files and databases are available, I might be able to do edits directly, but for legacy reasons I don't depend on that being possible for all time.
** This may very well be the least future-proof option of them all.
** Choose an tool-agnostic formats where you can to future-proof them. I prefer plain-text and zipped XML (OpenOffice, Collada, even MS Office XML) because they preserve the hierarchy and are easy to postprocess in nearly all programming and scripting languages.  When necessary, I parse "native" formats into an XML intermediary to do the same.
** It should be up to the project managers to define what subset of formats submissions (if any) may be made in.
That's the way I see things for the time being; I reserve the right to change my mind. ;-)
-- [http://clothbot.com/wiki/Open_Source_Hardware Andrew Plumb]
Seems everyone is more or less on the same page here. Is it the case that there needs to be some effort to design the intermediate exchange format?
With Human readable formats and manufacturing documents being the minimum required, if this ends up the defacto standard then information interchange will be very inefficient.
Migrations between editing environments should be fast and efficient to aid the momentum of this movement.
-- Stephen Leahey


== ZigBee, OSHW, & non-commercial licenses ==
== ZigBee, OSHW, & non-commercial licenses ==
Line 222: Line 174:


if folks who have worked on the OSHW are interested in helping admin/maintain this wiki, please leave a note on my talk page. It would be nice to be able to keep the wiki open, but that requires some regular maintenance actions against spam/vandalism.--[[User:Erik Möller|Erik Möller]] 16:52, 16 July 2010 (UTC)
if folks who have worked on the OSHW are interested in helping admin/maintain this wiki, please leave a note on my talk page. It would be nice to be able to keep the wiki open, but that requires some regular maintenance actions against spam/vandalism.--[[User:Erik Möller|Erik Möller]] 16:52, 16 July 2010 (UTC)
== Conditions for Free Technologies ==
[http://wiki.biores.de/mw/index.php/Free_Technology_Guide Free Technology Guide] - Here you can find some conditions for free technologies, I have worked out. The principles of Open Source Software must be completed, because there are other possibilities to monopolize hardware technologies compared with software technologies. [http://wiki.biores.de/mw/index.php/Leitfaden_f%C3%BCr_freie_Technologien (Original text in German)] --[[User:Michael Klotsche | Michael Klotsche]] 13:13, 01 January 2012
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)