2. Single definition of openness or a spectrum of options

#1

The Open Source Hardware Association is taking input on the proposal for an open hardware certification in this forum. This thread is devoted to question # 2, which reads: “Do you prefer a single definition of openness or a spectrum of options? Please explain your preference. If you prefer a spectrum, do you have a preference between a tier-based spectrum or a nutrition/laundry label-style approach.” For other question forums, as well as a general comment forum, click [here].

#2

I would propose a spectrum. Hardware, unlike some other open domains, has many levels of potential openness. To demand full openness all the way down (including, say, materials within devices within a circuit board) is extremely hardcore, and if that were the only level of certification available, would limit open hardware certification to a tiny niche (for some time into the future). A scale would permit organisations or projects striving to be open, but perhaps not all the way there, to start out with some recognition for their efforts (community support, interest in products etc), and to still have a gold standard to work towards.

We should also remember that the certification goals are not to set the ‘gold standard’ for open hardware (which might point towards a single definition), but to make open hardware, in essence, easier to engage with (without diluting the principles).

Tiers or nutrition/laundry label could both give a clear sense of direction for projects starting out with some level of openness, in terms of being clear what was more open and therefore desirable. Tiers do this transparently; a modular labelling system would need to be clear about how to compare two labels from a consumer point of view.

#3

There must be a few choices, though I would not call it a spectrum. Where a project is as open as it can be without violating the laws of the land (export controls and perhaps other regulations come to mind), it still should be recognized as open, but only to a limited audience (US citizens in the export control example). There should be a definition and certification process which honors the efforts, but makes it clear that through no fault of the author, the project is not available to all.

#4

While it would be far clearer to have a single level of certification, I agree with the commenters above that it is impractical. I would like to +1 the comments by @lbj20 and @aharper. I think they have each identified an axis of openness. I think @lbj20 has identified an axis describing how far down the open source description applies: down to the atoms, down to the components, down to the sub-assemblies, at the system level, some mix of the above depending on what sub-system/component one is discussing, etc. I think @aharper has identified an axis describing who may have access to the source based on legal restrictions: citizens of country X, citizens of countries X, Y, and Z, everyone, etc.

The blog post that anchors this discussion mentioned the Creative Commons in the background of this question. That reminds me of another axis of openness we should discuss, namely the items that the Creative Commons and software licenses address, things like:

  • Attribution Only vs Share Alike
  • Library Style Licensing (LGPL) vs Standard Licensing (GPL)
  • Non-Commercial This one has been thoroughly discussed, including it for completeness sake)
  • Are there others that I am missing?

I bring this axis up for discussion because in my experience working as a software professional in several small businesses, industry will often not touch share-alike IP, but will happily work with attribution only (or even LGPL code) IP and share patches to the originating project. And I personally believe this kind of project adoption is essential if OSH is to have the same kind of impact FOSS has had on the world (and I very much want to see that happen both in general and to support the mission of Mach 30).

#5

I would like to see two levels: “fully open” and “mostly open”. “Mostly open” means that the hardware design source files are open, e.g., there are editable schematics, PCB design, BOM, and source code for programmable devices. These all need OSHW licenses. All components must be purchasable from distributors and no component can require an NDA to to get data sheets, “nearly complete” technical reference manuals, and similar documentation. With a “mostly open” design, you must have everything you need to modify the hardware design.

However, we all know that there are useful OSHW components that are missing important parts of the technical documentation. The most obvious offenders are GPUs that require a non-open “binary blob” and FPGAs that do not document the bistream format, requiring FPGA designers to use the vendor’s tools. If such components are used, the OSHW is at best “mostly open”. To get the gold “fully open” certification, all components must be fully documented for the purposes of writing software and include the details of (for example) GPU registers and FPGA bitstreams.

With a “fully open” design, you have everything you need to program your OSHW with free-as-in-freedom software, giving you full control over your hardware.

I believe calling attention to “mostly openness” would be helpful for making OSHW “fully open” in the long run.

JMO/YMMV

#6

I’ve been working in international standardisation for 20 years. There is no forum that I know of where they successfully had a convergent discussion on a definition of open. Don’t waste your/our time.

johnbeetem above seems to have a good approach.

#7

We already have a standard for openness, in the form of the open-source hardware definition (http://www.oshwa.org/definition/).

I realize that many open-source hardware projects build on non-open source components. To me, the clearest way to handle this is to describe which parts (or levels) of a project are open-source, e.g. this project is an open-source circuit design (which uses non-open source components). Having a single standard, in my opinion, would definitely not mean excluding anything that’s built on non-open source components. Similarly, plenty of open-source software runs on non-open source operating systems.

Mostly, I’m not sure how you’d define a clear of spectrum of openness, as the specifics seem likely to differ in every project. johnbeetem’s standard of “mostly open” already seems more restrictive than the current OSHW definition, and I doubt there’d be very many projects that could achieve his “fully open” standard. And while I think share-alike or not is a useful distinction, it’s not clear to me which you’d consider “more open”. Are there other thoughts on what the different levels would be?

#8

Technically, open source is a legal issue. If you license your copyright(s) under an open source license then it’s open source. So I assume what we’re discussing are non-copyrightable things like ideas (patents) and behaviors.

I think that two levels would be useful. One that outlines the absolute minimum necessary to be considered open source at all and another that outlines the maximum past which everybody should stop bothering you to be more open source. There are a lot of ways to be in between those two but I don’t think we need to officially itemize them.

#9

If it fits the current definition of Open Source Hardware, then it’s open, if it doesn’t then it’s not. Thought we’d covered that ground already.

#10

We need to consider the fact that ‘Hardware’ is diverse, It can be Electronics, Mechanical parts, wooden furniture, metal craft or may be a interesting chemical substance. Current definition on OSHWA website serves ideological purpose well. However, what it lacks is the degree of openness.

And since hardware is diverse, each type of hardware can be seen as made layers. Nutrition Label style approach can take care of the diverse hardware and also quantify Openness.

#11

Agreed, “hardware” in my mind is anything where the value is tangible or where the value can’t be captured digitally. You can look at pictures of cookies, and listen to descriptions of cookies, but the value of a cookie is in the eating.

But if we’re going to create a “laundry list” it should be something abstract. We shouldn’t try to analyze each of the different things in the world for its potential openness like Electronic Openness and Mechanical Openness and Electro-mechanical Openness and on to infinity.

Also, it shouldn’t hinge on things the developer can’t practically control. Like “instructions in multiple languages” would be fine for the maximum standard but not for the minimum standard.

#12

I’m afraid the notion of definition of openness will be at one moment fully 100% connected with, condition by, the conditions and terms under which the “thing” is delivered (published).

So, I would say “yes” for a definition, as the Creative Common or the FSF, trie to give across the choice of their different licenses regarding the notion of “copyleft” or “Free/Libre” or “permissivity”, and the notions of rights given:

  • one single notion of Openness
  • different possible options, making the “thing” openness or not, with different level of openness (or free/libre).

As this OSHWA definitions will be not legal, that means, those OSHWA defintions will integrate a term which indicate that a license will have to match with those definition.

As a consequence, that also could mean, that OSHWA will have to do as the FSF do for its list of licenses, explaining which licenses fit with which definition of openness and its levels.

The point is: FSF has begun to list licenses for non-software things, giving a benchmark of what fit with openness/free/libre notions. If OSHWA do so, will it be aligned with FSF, and what if it is not ? Will it generate a sort of “public war” which will decrease the value of OpenSource Hardware.

If so, that means the definition of Openness for tangible things, should certainty be done across a participative work on progress with free/libre/openness software definition cursor makers (FSF, CC, P2P, …).

Last but not least, on Single or Option concepts for hardware openness definition: currently, open hardware licenses do not include the software developed, alongside/included in, the work of progress of an open hardware. Or, sometime, this software is part of the hardware. Then, some of us, are currently writing new terms and conditions, or have already contracted, under terms of open hardware licence including a mechanism making the software automaticaly published under terms of listed free/libre/opensource software licenses.

What does it mean, and why to connect this to openness definition for hardware ? That means the definition should clear the fact that an hardware could be made with non-hardware components, and if those components are developed/published under an openness process as fully part of an opensource hardware process development, then those non-hardware components should also be published under openness terms and conditions.

Then, that will have a consequence: as CERN-OHL as TAPR-OHL will have to include software inside their articles, and make a bridge with free/libre/opensource software license by default as this for example:
“When people elaborate, an Hardware Creation made with both software elements and non-software elements, then those software elements are provided under the terms and definitions of one of the GNU-GPL compatible license officially listed by the FSF”

A definition, single, with options or not, with categories or not, will have effects on legal terms and conditions.

#13

Not a spectrum, but a level system is needed, because there are not a lot of open source (electronic) components (although open standard should be fine in my eyes for top level).
I would say:
Gold: All source file’s (design, firmware, drivers) are available in open format’s, all components are open source, open standard or public domain.
Silver: All source file’s (design, firmware, drivers) are available in open format’s.
Bronze: Open design, all the design source file’s are available. Firmware and drivers are because of legal restrictions or component manufacturer restrictions not or not completely open source. Firmware and drivers are made available for use and distribution world wide.

For all licenses a restricted use clause makes it non-open.