https://freedomdefined.org/api.php?action=feedcontributions&user=Clothbot&feedformat=atomDefinition of Free Cultural Works - User contributions [en]2024-03-29T09:22:55ZUser contributionsMediaWiki 1.38.4https://freedomdefined.org/index.php?title=OSHW&diff=9150OSHW2011-02-09T01:13:12Z<p>Clothbot: /* Endorsements */</p>
<hr />
<div>This page hosts the current proposed Open Source Hardware (OSHW) Statement of Principles and Definition v1.0. The statement of principles is a high-level overview of the ideals of open-source hardware. The definition is an attempt to apply those ideals to a standard by which to evaluate licenses for hardware designs.<br />
<br />
To endorse the Open Source Hardware Definition 1.0, please add your name (and affiliation) <br />
[http://freedomdefined.org/OSHW#Endorsements below]<br />
<br />
[http://freedomdefined.org/OSHW_older_drafts Older drafts of the definition are also available]. <br />
<br />
Compiled community feedback from previous versions of the Definition can be found [http://www.openhardwaresummit.org/compiled-feedback/ here]<br />
<br />
If you would like to propose changes to the statement of principles or definition, please do so on the [http://freedomdefined.org/OSHW_draft work-in-progress draft]. And, please edit while signed in, not anonymously.<br />
<br />
<br />
''Please join the conversation about the definition [http://openhardwaresummit.org/forum here]''<br />
<br />
== Open Source Hardware (OSHW) Statement of Principles 1.0 ==<br />
<br />
Open source hardware is hardware whose design is made publicly available so that anyone can study, modify, distribute, make and sell the design or hardware based on that design. The hardware's source, the design from which it is made, is available in the preferred format for making modifications to it. Ideally, open source hardware uses readily-available components and materials, standard processes, open infrastructure, unrestricted content, and open-source design tools to maximize the ability of individuals to make and use hardware. Open source hardware gives people the freedom to control their technology while sharing knowledge and encouraging commerce through the open exchange of designs.<br />
<br />
== Open Source Hardware (OSHW) Definition 1.0 ==<br />
<br />
''OSHW Draft Definition 1.0 is based on the [http://opensource.org/docs/osd Open Source Definition] for Open Source Software and [http://freedomdefined.org/OSHW_older_drafts draft OSHW definition 0.5]. The definition is derived from the [http://www.opensource.org/docs/osd Open Source Definition], which was created by Bruce Perens and the Debian developers as the Debian Free Software Guidelines. Videos and Documentation of the Opening Hardware workshop which kicked off the below definition are available [http://www.eyebeam.org/projects/Opening-hardware here].''<br />
''Please join the conversation about the definition [http://openhardwaresummit.org/forum here]''<br />
<br />
'''Introduction'''<br />
<br />
Open Source Hardware (OSHW) is a term for tangible artifacts -- machines, devices, or other physical things -- whose design has been released to the public in such a way that anyone can make, modify, distribute, and use those things. This definition is intended to help provide guidelines for the development and evaluation of licenses for Open Source Hardware.<br />
<br />
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. Accordingly, persons or companies producing items ("products") under an OSHW license have an obligation not to imply that such products are manufactured, sold, warrantied, or otherwise sanctioned by the original designer and also not to make use of any trademarks owned by the original designer.<br />
<br />
The distribution terms of Open Source Hardware must comply with the following criteria:<br />
<br />
'''1. Documentation'''<br />
<br />
The hardware must be released with documentation including design files, and must allow modification and distribution of the design files. Where documentation is not furnished with the physical product, there must be a well-publicized means of obtaining this documentation for no more than a reasonable reproduction cost, preferably downloading via the Internet without charge. The documentation must include design files in the preferred format for making changes, for example the native file format of a CAD program. Deliberately obfuscated design files are not allowed. Intermediate forms analogous to compiled computer code -- such as printer-ready copper artwork from a CAD program -- are not allowed as substitutes. The license may require that the design files are provided in fully-documented, open format(s). <br />
<br />
'''2. Scope'''<br />
<br />
The documentation for the hardware must clearly specify what portion of the design, if not all, is being released under the license. <br />
<br />
'''3. Necessary Software'''<br />
<br />
If the licensed design requires software, embedded or otherwise, to operate properly and fulfill its essential functions, then the license may require that one of the following conditions are met:<br />
<br />
a) The interfaces are sufficiently documented such that it could reasonably be considered straightforward to write open source software that allows the device to operate properly and fulfill its essential functions. For example, this may include the use of detailed signal timing diagrams or pseudocode to clearly illustrate the interface in operation.<br />
<br />
b) The necessary software is released under an OSI-approved open source license.<br />
<br />
'''4. Derived Works'''<br />
<br />
The license shall allow modifications and derived works, and shall allow them to be distributed under the same terms as the license of the original work. The license shall allow for the manufacture, sale, distribution, and use of products created from the design files, the design files themselves, and derivatives therof.<br />
<br />
'''5. Free redistribution'''<br />
<br />
The license shall not restrict any party from selling or giving away the project documentation. The license shall not require a royalty or other fee for such sale. The license shall not require any royalty or fee related to the sale of derived works.<br />
<br />
'''6. Attribution'''<br />
<br />
The license may require derived documents, and copyright notices associated with devices, to provide attribution to the licensors when distributing design files, manufactured products, and/or derivatives thereof. The license may require that this information be accessible to the end-user using the device normally, but shall not specify a specific format of display. The license may require derived works to carry a different name or version number from the original design.<br />
<br />
'''7. No Discrimination Against Persons or Groups'''<br />
<br />
The license must not discriminate against any person or group of persons.<br />
<br />
'''8. No Discrimination Against Fields of Endeavor'''<br />
<br />
The license must not restrict anyone from making use of the work (including manufactured hardware) in a specific field of endeavor. For example, it must not restrict the hardware from being used in a business, or from being used in nuclear research.<br />
<br />
'''9. Distribution of License'''<br />
<br />
The rights granted by the license must apply to all to whom the work is redistributed without the need for execution of an additional license by those parties.<br />
<br />
'''10. License Must Not Be Specific to a Product'''<br />
<br />
The rights granted by the license must not depend on the licensed work being part of a particular product. If a portion is extracted from a work and used or distributed within the terms of the license, all parties to whom that work is redistributed should have the same rights as those that are granted for the original work.<br />
<br />
'''11. License Must Not Restrict Other Hardware or Software'''<br />
<br />
The license must not place restrictions on other items that are aggregated with the licensed work but not derivative of it. For example, the license must not insist that all other hardware sold with the licensed item be open source, nor that only open source software be used external to the device.<br />
<br />
'''12. License Must Be Technology-Neutral'''<br />
<br />
No provision of the license may be predicated on any individual technology, specific part or component, material, or style of interface or use thereof. <br />
<br />
<br />
<br />
'''Afterword'''<br />
<br />
The signatories of this Open Source Hardware definition recognize that the open source movement represents only one way of sharing information. We encourage and support all forms of openness and collaboration, whether or not they fit this definition.<br />
<br />
== Licenses and Hardware ==<br />
<br />
In promoting Open Hardware, it is important not to unintentionally deceive designers regarding the extent to which their licenses actually can control their designs. Under U.S. law, and law in many other places, copyright does not apply to electronic designs. Patents do. The result is that an Open Hardware license can in general be used to restrict the ''plans'' but probably ''not'' the manufactured devices or even restatements of the same design that are not textual copies of the original. The applicable section of copyright law is 17.102(b), which says:<br />
<br />
:''In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.''<br />
<br />
== Endorsements ==<br />
<br />
OSHW Draft Definition 1.0 has been endorsed by the following persons and/or organization as of February 9th, 2011.<br />
Please feel free to add (''your own'' names) to this section. Listing your affiliation is optional for personal endorsements, and endorsements are presumed to be personal unless the organization name is listed separately.<br />
<br />
''Please join the conversation about the definition [http://openhardwaresummit.org/forum here]''<br />
<br />
* Ayah Bdeir, [http://www.littleBits.cc littleBits.cc]/[http://www.eyebeam.org Eyebeam]/[http://www.creativecommons.org Creative Commons]<br />
* Christian Siefkes, [http://www.keimform.de/ keimform.de]<br />
* John Wilbanks, [http://www.creativecommons.org Creative Commons]<br />
* Windell Oskay, [http://evilmadscience.com/ Evil Mad Science]<br />
* Limor Fried, [http://www.adafruit.com/ Adafruit Industries]<br />
* Phillip Torrone, [http://www.makezine.com/ MAKE magazine] [http://www.adafruit.com/ Adafruit Industries]<br />
* Massimo Banzi [http://www.arduino.cc Arduino]<br />
* Ben Leduc-Mills [http://l3d.cs.colorado.edu/~ctg/Craft_Tech.html Craft Technology Lab]<br />
* Nathan Seidle [http://www.sparkfun.com SparkFun Electronics]<br />
* Tom Igoe, [http://www.arduino.cc Arduino] [http://itp.nyu.edu ITP, NYU]<br />
* David Carrier, [http://www.parallax.com Parallax Inc.]<br />
* Bryan Bishop, [http://gnusha.org/skdb/ SKDB] [http://humanityplus.org/ Humanity+]<br />
* Andrew Plumb, [http://clothbot.com/wiki/Main_Page ClothBot Designs]</div>Clothbothttps://freedomdefined.org/index.php?title=Talk:OSHW&diff=8188Talk:OSHW2010-07-17T18:59:11Z<p>Clothbot: /* Least Common Denominator */</p>
<hr />
<div>I like the spirit of the definition, but I would propose two amendments for clarity:<br />
<br />
* provides design files -> provides ''all relevant'' design files (otherwise hardware where only partial or incomplete design information is available would qualify)<br />
* 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)<br />
<br />
--[[User:ChristianSiefkes|Christian Siefkes]] 16:02, 21 April 2010 (UTC)<br />
<br />
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.<br />
<br />
[[Special:Contributions/128.153.100.220|128.153.100.220]] 14:57, 3 May 2010 (UTC) (Russ Nelson)<br />
<br />
== OSHardware vs OSDesign ==<br />
<br />
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)<br />
<br />
== CC Grant Application ==<br />
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.--[[User:Payo|Payo]] 15:48, 3 June 2010 (UTC)<br />
<br />
== Broadening the definition ==<br />
I like the definition in principle, but I think for broader commercial adoption the license needs a couple of tweaks.<br />
<br />
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. <br />
<br />
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.<br />
<br />
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.<br />
<br />
Despite these concerns, I think that the definition overall is great progress and I'll sign it personally to keep the momentum going. <br />
<br />
--bunnie<br />
<br />
=== Open vs. Recursively Open ===<br />
<br />
bunnie,<br />
<br />
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?<br />
<br />
--[[User:Mstone|Michael Stone]] 12:04, 15 July 2010 (UTC)<br />
<br />
=== Open Data Formats and CAD Tool License Conflicts ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
All the more reasons to get gEDA and equivalents ramped up. ;-)<br />
<br />
-- clothbot<br />
<br />
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.<br />
<br />
If you don't like their choice, fork the project. <br />
<br />
-- Pierce Nichols<br />
<br />
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.<br />
<br />
-- Daniel Garcia<br />
<br />
=== Design representation file formats ===<br />
<br />
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? :-) -- [http://heybryan.org/ Bryan]<br />
<br />
=== Human Readable vs Best Practices ===<br />
<br />
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.)<br />
<br />
-- [http://clothbot.org/wiki/ Andrew (clothbot)]<br />
<br />
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. <br />
<br />
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?<br />
<br />
-- Pierce Nichols<br />
<br />
As it relates to Best Practices, it's that EAGLE Freeware "non-commercial" clause that has me more concerned.<br />
<br />
-- [http://clothbot.org/wiki/ Andrew (clothbot)]<br />
<br />
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.<br />
<br />
-- Pierce Nichols<br />
<br />
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.<br />
<br />
-- [http://clothbot.org/wiki/ Andrew (clothbot)]<br />
<br />
=== Least Common Denominator ===<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
An open format, a format in which OSHW design documents must be published, is one that itself has specifications which:<br />
<br />
1) are available free of cost (and patent encumbrances!) and (copyleft clause here) can be freely re-distributed by anyone.<br />
<br />
2) have at least 2 independent, working, inter-operable implementations (CAD programs).<br />
<br />
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.<br />
<br />
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.<br />
<br />
-- Karl O. Pinc<br />
<br />
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.<br />
<br />
-- Pierce Nichols<br />
<br />
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]<br />
<br />
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.<br />
<br />
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.<br />
<br />
-- Pierce Nichols<br />
<br />
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.<br />
<br />
* 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.<br />
** 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.<br />
** 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.<br />
* 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.<br />
** 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).<br />
** 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.<br />
* 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.<br />
** This may very well be the least future-proof option of them all.<br />
** 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.<br />
** It should be up to the project managers to define what subset of formats submissions (if any) may be made in.<br />
<br />
That's the way I see things for the time being; I reserve the right to change my mind. ;-)<br />
<br />
-- [http://clothbot.com/wiki/Open_Source_Hardware Andrew Plumb]<br />
<br />
== ZigBee, OSHW, & non-commercial licenses ==<br />
<br />
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. <br />
<br />
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.<br />
<br />
--Pierce Nichols<br />
<br />
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.<br />
<br />
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.<br />
<br />
Thoughts?<br />
<br />
-- [http://clothbot.org/wiki/ Andrew Plumb]<br />
<br />
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. <br />
<br />
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.<br />
<br />
-- Pierce Nichols<br />
<br />
The more I think about it, the more I come to the conclusion that the box test solves essentially all of my issues.<br />
<br />
-- Pierce Nichols<br />
<br />
== Making a license around this ==<br />
<br />
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]<br />
<br />
== OSHW Executive Summary ==<br />
<br />
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:<br />
<br />
# Documentation: Establish and facilitate the right to repair<br />
# Necessary Software: Operates using Free Open Source Software<br />
# Derived Works: The right to fork the project.<br />
# Free Redistribution: Pay for parts, not permissions. No restriction on the sale of parts.<br />
# Attribution: Give credit where it's due.<br />
# No Discrimination Against Persons or Groups: Respect is earned.<br />
# No Discrimination Against Fields of Endeavor: Make recommendations, not restrictions.<br />
# Distribution of License: Share Alike.<br />
# License Must Not Be Specific to a Product: The right to re-use.<br />
# License Must Not Restrict Other Hardware Or Software: Play well with others.<br />
# License Must Be Technology-Neutral: The right to modify.<br />
<br />
Thoughts?<br />
<br />
-- [http://clothbot.com/wiki/Open_Source_Hardware Andrew Plumb]<br />
<br />
== Admins on this wiki ==<br />
<br />
Hi,<br />
<br />
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)</div>Clothbothttps://freedomdefined.org/index.php?title=OSHW&diff=8174OSHW2010-07-16T21:04:33Z<p>Clothbot: /* Endorsements */</p>
<hr />
<div>== Open Source Hardware (OSHW) Draft Definition version 0.3 ==<br />
<br />
''OSHW Draft Definition 0.3 is based on the [http://opensource.org/docs/osd Open Source Definition] for Open Source Software and [http://freedomdefined.org/OSHW_older_drafts draft OSHW definition 0.2]. The definition is derived from the [http://www.opensource.org/docs/osd Open Source Definition], which was created by Bruce Perens and the Debian developers as the Debian Free Software Guidelines. Videos and Documentation of the Opening Hardware workshop which kicked off the below definition are available [http://www.eyebeam.org/projects/Opening-hardware here].''<br />
''Please join the conversation about the definition [http://openhardwaresummit.org/forum here]''<br />
<br />
'''Introduction'''<br />
<br />
Open Source Hardware (OSHW) is a term for tangible artifacts -- machines, devices, or other physical things -- whose design has been released to the public in such a way that anyone can make, modify, distribute, and use those things. This definition is intended to help provide guidelines for the development and evaluation of licenses for Open Source Hardware.<br />
<br />
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. Accordingly, persons or companies producing items ("products") under an OSHW license have an obligation not to imply that such products are manufactured, sold, warrantied, or otherwise sanctioned by the original designer and also not to make use of any trademarks owned by the original designer.<br />
<br />
The distribution terms of Open Source Hardware must comply with the following criteria:<br />
<br />
'''1. Documentation'''<br />
<br />
The hardware must be released with documentation including design files, and must allow modification and distribution of the design files. Where documentation is not furnished with the physical product, there must be a well-publicized means of obtaining this documentation for no more than a reasonable reproduction cost, preferably downloading via the Internet without charge. The documentation must include design files in the preferred form which a hardware developer would use to modify the design. Deliberately obfuscated design files are not allowed. Intermediate forms analogous to compiled computer code -- such as printer-ready copper artwork from a CAD program -- are not allowed as substitutes. Should the documentation be created utilizing a proprietary CAD program, an open document format shall be provided, ex. pdf; iges; step; etc.<br />
<br />
'''2. Necessary Software'''<br />
<br />
If the hardware requires software, embedded or otherwise, to operate properly and fulfill its essential functions, then the documentation requirement must also include at least one of the following: The necessary software, released under an OSI-approved open source license, or other sufficient documentation such that it could reasonably be considered straightforward to write open source software that allows the device to operate properly and fulfill its essential functions.<br />
<br />
'''3. Derived Works'''<br />
<br />
The license shall allow modifications and derived works, and shall allow them to be distributed under the same terms as the license of the original hardware. The license shall allow for the manufacture, sale, distribution, and use of products created from the design files or derivatives of the design files.<br />
<br />
'''4. Free redistribution'''<br />
<br />
The license shall not restrict any party from selling or giving away the project documentation as a component of an aggregate distribution containing designs from several different sources. The license shall not require a royalty or other fee for such sale. The license shall not require any royalty or fee related to the sale of derived works.<br />
<br />
'''5. Attribution'''<br />
<br />
The license shall require derived works to provide attribution to the original designer when distributing design files, manufactured products, and/or derivatives thereof. The license shall also require derived works to carry a different name or version number from the original design.<br />
<br />
'''6. No Discrimination Against Persons or Groups'''<br />
<br />
The license must not discriminate against any person or group of persons.<br />
<br />
'''7. No Discrimination Against Fields of Endeavor'''<br />
<br />
The license must not restrict anyone from making use of the hardware in a specific field of endeavor. For example, it may not restrict the hardware from being used in a business, or from being used in nuclear research.<br />
<br />
'''8. Distribution of License'''<br />
<br />
The rights attached to the hardware must apply to all to whom the product or documentation is redistributed without the need for execution of an additional license by those parties.<br />
<br />
'''9. License Must Not Be Specific to a Product'''<br />
<br />
The rights attached to the hardware must not depend on the hardware being part of a particular larger product. If the hardware is extracted from that product and used or distributed within the terms of the hardware license, all parties to whom the hardware is redistributed should have the same rights as those that are granted in conjunction with the original distribution.<br />
<br />
'''10. License Must Not Restrict Other Hardware or Software'''<br />
<br />
The license must not place restrictions on other hardware or software that may be distributed or used with the licensed hardware. For example, the license must not insist that all other hardware sold at the same time be open source, nor that only open source software be used in conjunction with the hardware.<br />
<br />
'''11. License Must Be Technology-Neutral'''<br />
<br />
No provision of the license may be predicated on any individual technology or style of interface. <br />
<br />
'''12. Consideration of Future Licensing Version(s)'''<br />
<br />
As long as the future license version satisfies the criteria that a contiguous compatibility lineage exists starting from the license version of the original covered work, the original license shall automatically migrate to said future license version.<br />
<br />
<br />
'''Afterword'''<br />
<br />
The signatories of this Open Source Hardware definition recognize that the open source movement represents only one way of sharing information. We encourage and support all forms of openness and collaboration, whether or not they fit this definition.<br />
<br />
== Endorsements ==<br />
<br />
OSHW Draft Definition 0.3 is endorsed by the following persons and/or organizations. Please feel free to add (''your own'' names) to this section. Listing your affiliation is optional for personal endorsements, and endorsements are presumed to be personal unless the organization name is listed separately.<br />
<br />
''Please join the conversation about the definition [http://openhardwaresummit.org/forum here]''<br />
<br />
* David A. Mellis, MIT Media Lab and Arduino<br />
* Limor Fried, Adafruit Industries<br />
* Phillip Torrone, Make and Adafruit Industries<br />
* Leah Buechley, MIT Media Lab<br />
* Chris Anderson, Wired and DIY Drones<br />
* Nathan Seidle, SparkFun Electronics<br />
* Alicia Gibb, Bug Labs<br />
* Massimo Banzi, Arduino<br />
* Tom Igoe, Arduino, ITP/NYU<br />
* Zach Smith, MakerBot Industries<br />
* Bre Pettis, makerBot Industries<br />
* Andrew "bunnie" Huang, bunniestudios<br />
* Becky Stern, MAKE<br />
* Windell Oskay, Evil Mad Scientist Laboratories<br />
* John Wilbanks, Creative Commons<br />
* Jonathan Kuniholm, Open Prosthetics Project/Shared Design Alliance<br />
* Ayah Bdeir, littleBits.cc/Eyebeam/Creative Commons<br />
* David Ford, Blue Labs<br />
* Vitorino Ramos, LaSEEB - Evolutionary Systems and Biomedical Engineering Lab., IST, Technical University of Lisbon, Lisbon, PORTUGAL.<br />
* Charles Gantt, The Makers Workbench<br />
* Dave Hrynkiw, Solarbotics Ltd. / HVW Technologies<br />
* Raúl C Oviedo - Ayuda [http://ayudaelectronica.com Electronica] Company - [http://ayudaelectronica.com/licencia-open-source-hardware-oshw-espanol/ Spanish version of the license]<br />
* Stephen Eaton, Strobotics, Australia<br />
* Brent Picasso, Autosport Labs http://www.autosportlabs.net<br />
* Will Pickering, FunGizmos<br />
* Ronen Kadushin, Open Design<br />
* Aaron Nielsen, .:oomlout:.<br />
* Jay Woods, Woods R&E<br />
* Barton Dring, buildlog.net - Open Source Laser Cutter<br />
* Diego Spinola, Hackeneering<br />
* Shigeru Kobayashi, Gainer and Funnel<br />
* Sean Auriti, Alpha One Labs http://www.alphaonelabs.com<br />
* Shashikiran Ganesh, India<br />
* Sébastien Bourdeauducq, Milkymist<br />
* Eric Pan, Seeed Studio<br />
* Paul Youlten, [http://www.openmotox.org Open Moto X]<br />
* Nathan Oostendorp, SourceForge.net<br />
* Don Wilcher, MaDon Research http://www.family-science.net<br />
* Chris Prince, Regulus Tech<br />
* Daniel Reetz, DIYBookScanner.org<br />
* Harland R. Coles, Energy X Systems Ltd.<br />
* Julián da Silva Gillig, RobotGroup http://robotgroup.com.ar<br />
* Charles Collis, [http://adciv.org AdCiv.org]<br />
* Andy Gelme, [http://hackmelbourne.org Connected Community HackerSpace], Melbourne, Australia and [http://geekscape.org Geekscape Pty. Ltd.]<br />
* Jonathan Oxer, [http://www.freetronics.com Freetronics]<br />
* Daniel Garcia, [http://www.protostack.com Protostack]<br />
* Fletcher McBeth, President, VHDL Inc.<br />
* Joseph S. Terry, Jr., [http://www.VIVEnergySystems.com]<br />
* Marc Alexander, [http://www.freetronics.com Freetronics]<br />
* Rhys Chinchen, Melbourne VIC Australia<br />
* Florin Cocos, Youritronics<br />
* Catarina Mota, [http://openmaterials.org openMaterials]<br />
* Bryan Bishop, [http://groups.google.com/group/openmanufacturing Open Manufacturing Group]<br />
* Lubos Medovarsky, [http://accelera-networks.com Accelera Networks]<br />
* Ben Leduc-Mills, [http://l3d.cs.colorado.edu/~ctg/Craft_Tech.html Craft Technology Lab], CU Boulder<br />
* Chris Walker, Secret Labs<br />
*David Gapen, [http://handmadecircuits.com Handmade Circuits]<br />
* Tiago Rodrigues, [http://lusorobotica.com LusoRobótica] PORTUGAL<br />
* Michael Stephens, [http://www.flakelabs.com FLAKElabs]<br />
* Constantin Craciun, [http://www.harkopen.com Harkopen.com]<br />
* Alessandro Lambardi, [http://www.5volt.eu 5volt.eu]<br />
* Michael Provenzano, CEO Progunn R&D Industries<br />
* Matt Howard, CIO, [http://www.etech.ohio.gov eTech Ohio]<br />
* Michael Eber, CTO, [http://www.kineteka.com Kineteka Systems / PodGizmo]<br />
* Andrew Plumb, [http://clothbot.org/wiki/ ClothBot]</div>Clothbothttps://freedomdefined.org/index.php?title=Talk:OSHW&diff=8159Talk:OSHW2010-07-16T11:51:34Z<p>Clothbot: </p>
<hr />
<div>I like the spirit of the definition, but I would propose two amendments for clarity:<br />
<br />
* provides design files -> provides ''all relevant'' design files (otherwise hardware where only partial or incomplete design information is available would qualify)<br />
* 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)<br />
<br />
--[[User:ChristianSiefkes|Christian Siefkes]] 16:02, 21 April 2010 (UTC)<br />
<br />
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.<br />
<br />
[[Special:Contributions/128.153.100.220|128.153.100.220]] 14:57, 3 May 2010 (UTC) (Russ Nelson)<br />
<br />
== OSHardware vs OSDesign ==<br />
<br />
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)<br />
<br />
== CC Grant Application ==<br />
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.--[[User:Payo|Payo]] 15:48, 3 June 2010 (UTC)<br />
<br />
== Broadening the definition ==<br />
I like the definition in principle, but I think for broader commercial adoption the license needs a couple of tweaks.<br />
<br />
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. <br />
<br />
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.<br />
<br />
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.<br />
<br />
Despite these concerns, I think that the definition overall is great progress and I'll sign it personally to keep the momentum going. <br />
<br />
--bunnie<br />
<br />
=== Open vs. Recursively Open ===<br />
<br />
bunnie,<br />
<br />
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?<br />
<br />
--[[User:Mstone|Michael Stone]] 12:04, 15 July 2010 (UTC)<br />
<br />
=== Open Data Formats and CAD Tool License Conflicts ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
All the more reasons to get gEDA and equivalents ramped up. ;-)<br />
<br />
-- clothbot<br />
<br />
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.<br />
<br />
If you don't like their choice, fork the project. <br />
<br />
-- Pierce Nichols<br />
<br />
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.<br />
<br />
-- Daniel Garcia<br />
<br />
=== Design representation file formats ===<br />
<br />
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? :-) -- [http://heybryan.org/ Bryan]<br />
<br />
=== Human Readable vs Best Practices ===<br />
<br />
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.)<br />
<br />
-- [http://clothbot.org/wiki/ Andrew (clothbot)]<br />
<br />
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. <br />
<br />
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?<br />
<br />
-- Pierce Nichols<br />
<br />
As it relates to Best Practices, it's that EAGLE Freeware "non-commercial" clause that has me more concerned.<br />
<br />
-- [http://clothbot.org/wiki/ Andrew (clothbot)]<br />
<br />
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.<br />
<br />
-- Pierce Nichols<br />
<br />
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.<br />
<br />
-- [http://clothbot.org/wiki/ Andrew (clothbot)]<br />
<br />
== ZigBee, OSHW, & non-commercial licenses ==<br />
<br />
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. <br />
<br />
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.<br />
<br />
--Pierce Nichols<br />
<br />
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.<br />
<br />
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.<br />
<br />
Thoughts?<br />
<br />
-- [http://clothbot.org/wiki/ Andrew Plumb]<br />
<br />
== Making a license around this ==<br />
<br />
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]<br />
<br />
== OSHW Executive Summary ==<br />
<br />
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:<br />
<br />
# Documentation: Establish and facilitate the right to repair<br />
# Necessary Software: Operates using Free Open Source Software<br />
# Derived Works: The right to fork the project.<br />
# Free Redistribution: Pay for parts, not permissions. No restriction on the sale of parts.<br />
# Attribution: Give credit where it's due.<br />
# No Discrimination Against Persons or Groups: Respect is earned.<br />
# No Discrimination Against Fields of Endeavor: Make recommendations, not restrictions.<br />
# Distribution of License: Share Alike.<br />
# License Must Not Be Specific to a Product: The right to re-use.<br />
# License Must Not Restrict Other Hardware Or Software: Play well with others.<br />
# License Must Be Technology-Neutral: The right to modify.<br />
<br />
Thoughts?<br />
<br />
-- [http://clothbot.com/wiki/Open_Source_Hardware Andrew Plumb]</div>Clothbothttps://freedomdefined.org/index.php?title=Talk:OSHW&diff=8158Talk:OSHW2010-07-16T11:08:34Z<p>Clothbot: /* ZigBee, OSHW, & non-commercial licenses */</p>
<hr />
<div>I like the spirit of the definition, but I would propose two amendments for clarity:<br />
<br />
* provides design files -> provides ''all relevant'' design files (otherwise hardware where only partial or incomplete design information is available would qualify)<br />
* 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)<br />
<br />
--[[User:ChristianSiefkes|Christian Siefkes]] 16:02, 21 April 2010 (UTC)<br />
<br />
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.<br />
<br />
[[Special:Contributions/128.153.100.220|128.153.100.220]] 14:57, 3 May 2010 (UTC) (Russ Nelson)<br />
<br />
== OSHardware vs OSDesign ==<br />
<br />
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)<br />
<br />
== CC Grant Application ==<br />
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.--[[User:Payo|Payo]] 15:48, 3 June 2010 (UTC)<br />
<br />
== Broadening the definition ==<br />
I like the definition in principle, but I think for broader commercial adoption the license needs a couple of tweaks.<br />
<br />
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. <br />
<br />
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.<br />
<br />
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.<br />
<br />
Despite these concerns, I think that the definition overall is great progress and I'll sign it personally to keep the momentum going. <br />
<br />
--bunnie<br />
<br />
=== Open vs. Recursively Open ===<br />
<br />
bunnie,<br />
<br />
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?<br />
<br />
--[[User:Mstone|Michael Stone]] 12:04, 15 July 2010 (UTC)<br />
<br />
=== Open Data Formats and CAD Tool License Conflicts ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
All the more reasons to get gEDA and equivalents ramped up. ;-)<br />
<br />
-- clothbot<br />
<br />
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.<br />
<br />
If you don't like their choice, fork the project. <br />
<br />
-- Pierce Nichols<br />
<br />
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.<br />
<br />
-- Daniel Garcia<br />
<br />
=== Design representation file formats ===<br />
<br />
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? :-) -- [http://heybryan.org/ Bryan]<br />
<br />
=== Human Readable vs Best Practices ===<br />
<br />
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.)<br />
<br />
-- [http://clothbot.org/wiki/ Andrew (clothbot)]<br />
<br />
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. <br />
<br />
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?<br />
<br />
-- Pierce Nichols<br />
<br />
As it relates to Best Practices, it's that EAGLE Freeware "non-commercial" clause that has me more concerned.<br />
<br />
-- [http://clothbot.org/wiki/ Andrew (clothbot)]<br />
<br />
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.<br />
<br />
-- Pierce Nichols<br />
<br />
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.<br />
<br />
-- [http://clothbot.org/wiki/ Andrew (clothbot)]<br />
<br />
== ZigBee, OSHW, & non-commercial licenses ==<br />
<br />
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. <br />
<br />
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.<br />
<br />
--Pierce Nichols<br />
<br />
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.<br />
<br />
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.<br />
<br />
Thoughts?<br />
<br />
-- [http://clothbot.org/wiki/ Andrew Plumb]<br />
<br />
== Making a license around this ==<br />
<br />
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]</div>Clothbothttps://freedomdefined.org/index.php?title=Talk:OSHW&diff=8151Talk:OSHW2010-07-15T21:24:45Z<p>Clothbot: /* Human Readable vs Best Practices */</p>
<hr />
<div>I like the spirit of the definition, but I would propose two amendments for clarity:<br />
<br />
* provides design files -> provides ''all relevant'' design files (otherwise hardware where only partial or incomplete design information is available would qualify)<br />
* 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)<br />
<br />
--[[User:ChristianSiefkes|Christian Siefkes]] 16:02, 21 April 2010 (UTC)<br />
<br />
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.<br />
<br />
[[Special:Contributions/128.153.100.220|128.153.100.220]] 14:57, 3 May 2010 (UTC) (Russ Nelson)<br />
<br />
== OSHardware vs OSDesign ==<br />
<br />
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)<br />
<br />
== CC Grant Application ==<br />
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.--[[User:Payo|Payo]] 15:48, 3 June 2010 (UTC)<br />
<br />
== Broadening the definition ==<br />
I like the definition in principle, but I think for broader commercial adoption the license needs a couple of tweaks.<br />
<br />
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. <br />
<br />
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.<br />
<br />
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.<br />
<br />
Despite these concerns, I think that the definition overall is great progress and I'll sign it personally to keep the momentum going. <br />
<br />
--bunnie<br />
<br />
=== Open vs. Recursively Open ===<br />
<br />
bunnie,<br />
<br />
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?<br />
<br />
--[[User:Mstone|Michael Stone]] 12:04, 15 July 2010 (UTC)<br />
<br />
=== Open Data Formats and CAD Tool License Conflicts ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
All the more reasons to get gEDA and equivalents ramped up. ;-)<br />
<br />
-- clothbot<br />
<br />
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.<br />
<br />
If you don't like their choice, fork the project. <br />
<br />
-- Pierce Nichols<br />
<br />
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.<br />
<br />
-- Daniel Garcia<br />
<br />
=== Design representation file formats ===<br />
<br />
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? :-) -- [http://heybryan.org/ Bryan]<br />
<br />
=== Human Readable vs Best Practices ===<br />
<br />
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.)<br />
<br />
-- [http://clothbot.org/wiki/ Andrew (clothbot)]<br />
<br />
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. <br />
<br />
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?<br />
<br />
-- Pierce Nichols<br />
<br />
As it relates to Best Practices, it's that EAGLE Freeware "non-commercial" clause that has me more concerned.<br />
<br />
-- [http://clothbot.org/wiki/ Andrew (clothbot)]<br />
<br />
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.<br />
<br />
-- Pierce Nichols<br />
<br />
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.<br />
<br />
-- [http://clothbot.org/wiki/ Andrew (clothbot)]<br />
<br />
== ZigBee, OSHW, & non-commercial licenses ==<br />
<br />
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. <br />
<br />
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.<br />
<br />
--Pierce Nichols<br />
<br />
== Making a license around this ==<br />
<br />
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]</div>Clothbothttps://freedomdefined.org/index.php?title=Talk:OSHW&diff=8143Talk:OSHW2010-07-15T19:54:32Z<p>Clothbot: /* Human Readable vs Best Practices */</p>
<hr />
<div>I like the spirit of the definition, but I would propose two amendments for clarity:<br />
<br />
* provides design files -> provides ''all relevant'' design files (otherwise hardware where only partial or incomplete design information is available would qualify)<br />
* 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)<br />
<br />
--[[User:ChristianSiefkes|Christian Siefkes]] 16:02, 21 April 2010 (UTC)<br />
<br />
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.<br />
<br />
[[Special:Contributions/128.153.100.220|128.153.100.220]] 14:57, 3 May 2010 (UTC) (Russ Nelson)<br />
<br />
== OSHardware vs OSDesign ==<br />
<br />
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)<br />
<br />
== CC Grant Application ==<br />
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.--[[User:Payo|Payo]] 15:48, 3 June 2010 (UTC)<br />
<br />
== Broadening the definition ==<br />
I like the definition in principle, but I think for broader commercial adoption the license needs a couple of tweaks.<br />
<br />
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. <br />
<br />
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.<br />
<br />
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.<br />
<br />
Despite these concerns, I think that the definition overall is great progress and I'll sign it personally to keep the momentum going. <br />
<br />
--bunnie<br />
<br />
=== Open vs. Recursively Open ===<br />
<br />
bunnie,<br />
<br />
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?<br />
<br />
--[[User:Mstone|Michael Stone]] 12:04, 15 July 2010 (UTC)<br />
<br />
=== Open Data Formats and CAD Tool License Conflicts ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
All the more reasons to get gEDA and equivalents ramped up. ;-)<br />
<br />
-- clothbot<br />
<br />
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.<br />
<br />
If you don't like their choice, fork the project. <br />
<br />
-- Pierce Nichols<br />
<br />
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.<br />
<br />
-- Daniel Garcia<br />
<br />
=== Design representation file formats ===<br />
<br />
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? :-) -- [http://heybryan.org/ Bryan]<br />
<br />
=== Human Readable vs Best Practices ===<br />
<br />
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.)<br />
<br />
-- [http://clothbot.org/wiki/ Andrew (clothbot)]<br />
<br />
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. <br />
<br />
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?<br />
<br />
-- Pierce Nichols<br />
<br />
As it relates to Best Practices, it's that EAGLE Freeware "non-commercial" clause that has me more concerned.<br />
<br />
-- [http://clothbot.org/wiki/ Andrew (clothbot)]<br />
<br />
== ZigBee, OSHW, & non-commercial licenses ==<br />
<br />
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. <br />
<br />
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.<br />
<br />
--Pierce Nichols<br />
<br />
== Making a license around this ==<br />
<br />
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]</div>Clothbothttps://freedomdefined.org/index.php?title=Talk:OSHW&diff=8139Talk:OSHW2010-07-15T16:56:23Z<p>Clothbot: /* Design representation file formats */</p>
<hr />
<div>I like the spirit of the definition, but I would propose two amendments for clarity:<br />
<br />
* provides design files -> provides ''all relevant'' design files (otherwise hardware where only partial or incomplete design information is available would qualify)<br />
* 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)<br />
<br />
--[[User:ChristianSiefkes|Christian Siefkes]] 16:02, 21 April 2010 (UTC)<br />
<br />
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.<br />
<br />
[[Special:Contributions/128.153.100.220|128.153.100.220]] 14:57, 3 May 2010 (UTC) (Russ Nelson)<br />
<br />
== OSHardware vs OSDesign ==<br />
<br />
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)<br />
<br />
== CC Grant Application ==<br />
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.--[[User:Payo|Payo]] 15:48, 3 June 2010 (UTC)<br />
<br />
== Broadening the definition ==<br />
I like the definition in principle, but I think for broader commercial adoption the license needs a couple of tweaks.<br />
<br />
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. <br />
<br />
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.<br />
<br />
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.<br />
<br />
Despite these concerns, I think that the definition overall is great progress and I'll sign it personally to keep the momentum going. <br />
<br />
--bunnie<br />
<br />
=== Open vs. Recursively Open ===<br />
<br />
bunnie,<br />
<br />
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?<br />
<br />
--[[User:Mstone|Michael Stone]] 12:04, 15 July 2010 (UTC)<br />
<br />
=== Open Data Formats and CAD Tool License Conflicts ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
All the more reasons to get gEDA and equivalents ramped up. ;-)<br />
<br />
-- clothbot<br />
<br />
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.<br />
<br />
If you don't like their choice, fork the project. <br />
<br />
-- Pierce Nichols<br />
<br />
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.<br />
<br />
-- Daniel Garcia<br />
<br />
=== Design representation file formats ===<br />
<br />
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? :-) -- [http://heybryan.org/ Bryan]<br />
<br />
=== Human Readable vs Best Practices ===<br />
<br />
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.)<br />
<br />
-- [http://clothbot.org/wiki/ Andrew (clothbot)]<br />
<br />
== ZigBee, OSHW, & non-commercial licenses ==<br />
<br />
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. <br />
<br />
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.<br />
<br />
--Pierce Nichols<br />
<br />
== Making a license around this ==<br />
<br />
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]</div>Clothbothttps://freedomdefined.org/index.php?title=Talk:OSHW&diff=8093Talk:OSHW2010-07-14T09:55:57Z<p>Clothbot: /* Broadening the definition */</p>
<hr />
<div>I like the spirit of the definition, but I would propose two amendments for clarity:<br />
<br />
* provides design files -> provides ''all relevant'' design files (otherwise hardware where only partial or incomplete design information is available would qualify)<br />
* 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)<br />
<br />
--[[User:ChristianSiefkes|Christian Siefkes]] 16:02, 21 April 2010 (UTC)<br />
<br />
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.<br />
<br />
[[Special:Contributions/128.153.100.220|128.153.100.220]] 14:57, 3 May 2010 (UTC) (Russ Nelson)<br />
<br />
== OSHardware vs OSDesign ==<br />
<br />
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)<br />
<br />
== CC Grant Application ==<br />
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.--[[User:Payo|Payo]] 15:48, 3 June 2010 (UTC)<br />
<br />
== Broadening the definition ==<br />
I like the definition in principle, but I think for broader commercial adoption the license needs a couple of tweaks.<br />
<br />
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. <br />
<br />
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.<br />
<br />
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.<br />
<br />
Despite these concerns, I think that the definition overall is great progress and I'll sign it personally to keep the momentum going. <br />
<br />
--bunnie<br />
<br />
=== Open Data Formats and CAD Tool License Conflicts ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
All the more reasons to get gEDA and equivalents ramped up. ;-)<br />
<br />
-- clothbot<br />
<br />
== ZigBee, OSHW, & non-commercial licenses ==<br />
<br />
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. <br />
<br />
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.<br />
<br />
--Pierce Nichols</div>Clothbot