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 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 82: Line 67:
  
 
-- [http://clothbot.org/wiki/ Andrew (clothbot)]
 
-- [http://clothbot.org/wiki/ 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.
 
 
-- [http://clothbot.org/wiki/ Andrew (clothbot)]
 
 
It's not just a problem with Eagle -- there are a lot of desirable tools, libraries, and standards that are similarly encumbered. I'm particularly concerned about ZigBee because it impacts a project I'm working on right now, but it's a general problem and the definition as written does not address it. I'd like to see an explicit statement that recursive openness is not required for a project to qualify under this definition.
 
 
-- Pierce Nichols
 
 
We're actually in complete agreement.  As it currently stands, OSHW v0.3 won't scale to meet the needs of a working, hierarchical design flow with dependencies on black-box, legacy and/or protected IP.  Being the (IC) EDA geek that I am, I'm going to have to collect and organize all my thoughts before incorporating anything here.
 
 
-- [http://clothbot.org/wiki/ Andrew (clothbot)]
 
 
=== Least Common Denominator ===
 
The issue of "preferred modification format" is central if the point of the OSHW is to permit design modifications.  By way of example, if I want to conform to the OSHW but want to be able to squash anyone who modifies the design I could, in theory, release design documents in a proprietary format usable only from within proprietary software that I license under my terms.  I can then deny a license to the CAD software to anyone who attempts to modify the design.
 
 
It is non-trivial to re-create a design of any complexity, by which I mean to re-create an editable copy from a read-only copy such as a pdf.  Such a process would be large and error prone. Without the ability to edit the design and produce a modified product the "open" moniker is meaningless.
 
 
There is an analogous problem regarding Open Source Software which, to my mind, has not been addressed.  The code itself has long been considered to be the "design document" for a piece of software.  Unfortunately I believe this to be a flawed assumption.  The specification of a piece of software is it's human readable documentation, not it's code.  It is impossible to use, or understand the functioning of and hence understand how to modify, a program of any reasonable size without human readable documentation.  FLOSS does not require that a program's documentation be open, it requires only that the code be open.  Hence there is the problem of the program with open code but closed documentation.  Reproduction of the proprietary documentation in an open format is non-trivial, error prone, and critical to get right if one wishes to fork.  A program without documentation is both unusable and unmaintainable because without documentation/specification it's impossible to tell exactly what it is the program _should_ do.  (FWIW, we see this playing out right now with MySQL.  The MySQL code is open, but the documentation is closed.  There are supposedly forks of MySQL but none seem to be documented and so the functionality of the forks is entirely under Oracle's control, because Oracle owns the MySQL documentation.)  The problem of an open specification is hidden when it comes to open software but is an immediately apparent problem when it comes to open hardware.
 
 
I see no way around this other than to require design documents be published in a well-defined open format.  Deciding exactly what "a well-defined open format" is the tricky part.  My inclination would be to follow the lead of the IETF, which after all has lead to the production of a lot of inter-operable hardware.
 
 
An open format, a format in which OSHW design documents must be published, is one that itself has specifications which:
 
 
1) are available free of cost (and patent encumbrances!) and (copyleft clause here) can be freely re-distributed by anyone.
 
 
2) have at least 2 independent, working, inter-operable implementations (CAD programs).
 
 
These are strict requirements but are the only way I can see out of the problem.  Adopting them would certainly avoid bunny's concern about promoting a specific program.
 
 
If you wanted to fudge you could have 2 different OSHI definitions, a loose and a strict one.  The loose one would allow publication of design documents in an open but non-editable format where the strict one would conform to the requirements I suggest above regarding having an open editable design document.  Somehow this sounds like trouble in the making but does represent some sort of compromise.  At least those who use the "loose" form would then have a warning of potential problems.
 
 
-- Karl O. Pinc
 
 
There are no existing mechanical or electronic CAD formats that meet both prongs of your requirement. Even the ones that are nominally open and widely supported (EDIF, DXF) are treated as output or interchange formats by the existing applications.
 
 
-- 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]
 
 
SVG's not a CAD format; it's an output format. While just about every 3D modeler will import and export IGES (as well as STEP and STL) it's not really a native format for any of the ones I am familiar with. Therefore it is not the preferred format for doing modifications, and it does a poor job (at least IME -- mostly SolidWorks and Pro/E) of preserving higher level design data.
 
 
The closest thing to an open CAD format that meets the above definitions is DXF, simply because its core is well documented and it's widely supported. Autodesk's failure to document some of the more advanced features makes it only partially open, however.
 
 
-- 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 174: Line 75:
  
 
--Pierce Nichols
 
--Pierce Nichols
 
I spent some time [http://clothbot.com/wiki/Open_Source_Hardware mulling over it] last night, and I think that although the wording needs work, this ZigBee case might be roughly covered under ''10. License Must Not Restrict Other Hardware or Software''.  You should be free to control a ZigBee module (eg [http://www.digi.com/products/wireless/zigbee-mesh/xbee-zb-module.jsp#overview Digi XBee ZB]) as long as the licensing fee is incorporated into the off-the-shelf cost of the module.  I would expect that the manufacturer selling the ZigBee module should have paid that licensing fee.
 
 
The devil's in the details as always, but one idea I had was that the wording could change to accomodate some sort of [http://clothbot.com/wiki/Open_Source_Hardware#Box_Test box test] metrics for inclusions of non-OSHW dependencies.
 
 
Thoughts?
 
 
-- [http://clothbot.org/wiki/ Andrew Plumb]
 
 
There are a number of uCs on the market now which have integrated 802.15.4 radio hardware, such as that Atmega128RFA1. In order to get them to function in the intended way, you need some kind of network stack on them. If it's a ZigBee stack of any description, you'll at minimum run afoul of the non-discrimination clause.
 
 
However, a way out just occurred to me -- ZigBee is not the only standard network stack built on 802.11.4. The MAC layer protocol is not bound by restrictive licensing and I believe the uracolix project is putting together a truly free implementation. If you need to talk to an XBee module or other ZigBee things, you can download BitCloud yourself and cope with its non-free (and closed source) nature as you see fit.
 
 
-- Pierce Nichols
 
 
The more I think about it, the more I come to the conclusion that the box test solves essentially all of my issues.
 
 
-- Pierce Nichols
 
  
 
== Making a license around this ==
 
== 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 [http://groups.google.com/group/openmanufacturing 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. -- [http://heybryan.org/ Bryan]
 
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 [http://groups.google.com/group/openmanufacturing 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. -- [http://heybryan.org/ Bryan]
 
== OSHW Executive Summary ==
 
 
Here's what I've come up with so far in the way of what an ''executive summary'' of the OSHW Definition might look like:
 
 
# Documentation: Establish and facilitate the right to repair
 
# Necessary Software: Operates using Free Open Source Software
 
# Derived Works: The right to fork the project.
 
# Free Redistribution: Pay for parts, not permissions. No restriction on the sale of parts.
 
# Attribution: Give credit where it's due.
 
# No Discrimination Against Persons or Groups: Respect is earned.
 
# No Discrimination Against Fields of Endeavor: Make recommendations, not restrictions.
 
# Distribution of License: Share Alike.
 
# License Must Not Be Specific to a Product: The right to re-use.
 
# License Must Not Restrict Other Hardware Or Software: Play well with others.
 
# License Must Be Technology-Neutral: The right to modify.
 
 
Thoughts?
 
 
-- [http://clothbot.com/wiki/Open_Source_Hardware Andrew Plumb]
 
 
== Admins on this wiki ==
 
 
Hi,
 
 
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)