|
|
Log in / Subscribe / Register

Defining open hardware

October 18, 2023

This article was contributed by Koen Vervloesem

Open-source hardware (or open hardware) refers to hardware that is developed in a manner similar to open-source software. There's a widely accepted definition of open-source hardware, but it is probably not as well known as its open-source-software counterpart. In addition, there is a popular certification program that hardware makers can use to indicate which of their devices meets that criteria. But there are some vendors that are showing more enthusiasm than others in participating in the process—or in producing open hardware at all.

The leading organization advocating for open-source hardware is the Open Source Hardware Association (OSHWA). Established in 2012, it provides a definition of open-source hardware based on the Open Source Definition maintained by the Open Source Initiative. The OSHWA definition's introduction describes its main principle as:

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 principle is then made explicit in 12 criteria that are not unlike the ten criteria of the Open Source Definition.

OSHWA recommends eight licenses for open-source hardware in its FAQ. These are divided into two categories: copyleft licenses, which require derivative works to be released under the same license, and permissive licenses, which allow for proprietary derivatives. Recommended copyleft licenses include the non-hardware-specific GPL and Creative Commons Attribution-ShareAlike (CC-BY-SA), as well as the hardware-specific CERN Open Hardware license and TAPR Open Hardware License. Recommended permissive licenses include the non-hardware-specific FreeBSD license, MIT license, and Creative Commons Attribution (CC-BY), as well as the hardware-specific Solderpad Hardware license.

It's important to note that, as with open-source software, licenses that prohibit commercial use are not compatible with the OSHW definition. Since the creation of hardware invariably involves money, it's difficult to make use of a hardware design without some form of commercial activity.

OSHWA also has a set of best practices for creators of open-source hardware projects. For example, these recommend sharing the "original source files that you would use to make modifications to the hardware's design". While the best practices encourage using FOSS software for designing the hardware, they acknowledge the reality of proprietary programs and file formats in this domain and allow their use.

If we limit ourselves to printed-circuit boards (PCBs) such as microcontroller boards and single-board computers, then what needs to be shared includes mechanical drawings, electronic schematics, a bill of materials, and the design of the printed-circuit-board layout. If any of these components is lacking, the hardware can't be recreated.

One prominent example of hardware with limited information is the Raspberry Pi single-board computer. While some electronic schematics are published, they primarily show the pinouts of the connectors. These reduced schematics are useful for users or those who want to design add-on boards, but not for those who want to make their own version of a Raspberry Pi. According to the license information, the schematics are using the Attribution-NoDerivatives 4.0 International (CC BY-ND) license, which is not an open-source hardware license because it does not allow derivative works.

Self-certification program

In 2016, OSHWA set up a certification program, which relies on creators to voluntarily self-certify their projects. Doing so allows them to use a logo indicating their compliance with the OSHW definition.

OSHWA has the authority to revoke a certification, as it has done on a few occasions. The first time was in 2018 for the Motedis XYZ 3D printer because the project's documentation link was no longer working. After OSHWA was unable to obtain a copy of the documentation from the contact person in the certification application, the organization revoked the certification. This also happened for the Atmel SAM D10C Breakout Board by San Antonio Technologies for the same reason.

In 2022, OSHWA started publishing documentation for decertified hardware. This was possible because OSHWA had been archiving documentation as part of the certification process for a few years. In cases where the documentation is no longer available on the manufacturer's web site, OSHWA now publishes the documentation as part of the decertification process.

Earlier this year, OSHWA revoked the certification of the SparkFun DataLogger IoT – 9DoF. This was done at the request of SparkFun "due to accidental filing". While the hardware for the project was open-source, the firmware was not. This came as a surprise to users, because SparkFun is considered a big proponent of open hardware. SparkFun CTO Kirk Benell explained in a GitHub issue: "The OSHWA logo/cert was a mistake made by our system when we build [sic] the board -- everything ran on automatic and it wasn't checked before the release".

The list of certified open-source hardware projects on OSHWA's web site includes over 2,500 projects. These encompass a wide range of devices, including Arduino boards, add-on boards for Arduino and Raspberry Pi, drone flight controllers, 3D printers, smart speakers like the Mycroft Mark 1, and even electric vehicle charging stations. Adafruit, with almost 700 certified products, and SparkFun, with almost 600, have a significant presence on the list. Many of these certifications are for Arduino-compatible boards. Olimex, a smaller player, has 68 certified products, including ESP32 boards and its OLinuXino line of single-board computers running mainline Linux.

Each product page on the certification web site provides a direct link to the product's documentation. However, the hardware and software files are not directly accessible. To find the hardware schematics, you need to visit the referenced project web site and search for the appropriate files on that page. For example, for Adafruit products the hardware schematics are linked under the Technical Details header, while for SparkFun products the Documents tab shows them. Olimex shows a link to the hardware schematics under the Hardware heading.

In its blog article about the first decertification, OSHWA explained that it is trying to reduce duplication of effort, which is why it doesn't just serve the hardware's documentation on its own web site:

Developing and maintaining a feature-complete documentation hosting solution is beyond OSHWA’s core competency. Many good solutions for developing and maintaining software and documentation already exist online. Requiring certifiers to update and maintain yet another repository of documentation in order to certify was determined to be unnecessarily burdensome.

Other places to find open hardware

There are various other places where you can find open hardware that isn't necessarily following the OSHWA certification program. For example, OpenHardware.io contains more than 500 projects. For each project, a page shows the license, photos, a description, a bill of materials to order the parts, the source code for the associated software, and all the necessary design files for the hardware. The web site hosts sensor boards, relays, LED controllers, remote controls, Arduino and Raspberry Pi add-on boards, adapters and more. A lot of projects are still indicated as a "work in progress", though.

Kitspace hosts a smaller selection of interesting electronic designs. Notable offerings include a tiny Arm microcontroller board that fits into a USB port and barely protrudes, a tiny Arduino-compatible board, a WiFi air-pollution sensor board, and boards for the ESP8266 and ESP32 microcontrollers. The web site is sponsored by some PCB manufacturers, which results in direct links to these manufacturers from the product page to order the PCB.

Open hardware doesn't have to be about electronics, though. Thingiverse, a well-known web site in the world of 3D printing, provides a diverse range of open designs for 3D objects. Anyone can produce these objects with their own 3D printer using the shared STL files. Thingiverse offers a lot of tools and ornaments, as well as designs for enclosures for various microcontroller boards or SBCs.

Arduino and OSHWA

One of the most well-known open-hardware projects is Arduino, which offers microcontroller boards with an accompanying open-source development environment. The electronic schematics and design files of its boards are available under the CC-BY-SA license. This allows anyone to recreate these Arduino boards, although without using the trademarked Arduino name.

What is somewhat strange, though, for such a notable company in the open-hardware ecosystem, is that OSHWA's list of certified open-source hardware doesn't contain any official Arduino boards. Those boards seem to tick all of the boxes of the OSHW definition, but Arduino has chosen not to certify its products. That's even more surprising if you know that the list of endorsements of the OSHW definition includes Arduino founders Massimo Banzi, David Cuartielles, David Mellis, and Tom Igoe. They even helped create the definition. But when Adafruit recently asked Arduino if they would consider certifying any of its boards, the company declined.

Still, aside from a few mistakes with missing design files and licenses, Arduino has been releasing all of its boards as open hardware. This changed with the introduction of the Arduino Pro hardware, as Adafruit pointed out in a 2021 blog post. The product page of the Portenta H7 board only lists schematics and a data sheet, omitting the design files necessary for manufacturing the board. For a long time, Arduino's introduction page claimed: "All Arduino boards are completely open-source, empowering users to build them independently and eventually adapt them to their particular needs."

When Adafruit asked about this discrepancy, Arduino's Alessandro Ranellucci replied that, for the Arduino Pro line, the company wanted to "prevent counterfeiters from blindly downloading a file and manufacturing it without any R&D effort or contribution to the community". As a result, the company decided to publish the schematics without the design files necessary for manufacturing the board. The original statement on the introduction page has since been removed, and the page now says: "The plans of the Arduino boards are published under a Creative Commons license, so experienced circuit designers can make their own version of the module, extending it and improving it."

For now, Arduino seems to uphold its promise to keep its "products for makers" as open-source hardware (although not OSHWA-certified), but does not do the same for its Pro line; boards such as the Portenta C33 and the Portenta X8 have been released without design files. It's a bit concerning, though, that the newest non-Pro boards (like the Arduino Nano ESP32 and the Arduino UNO R4 WiFi) don't even mention "open" on their product pages or in their documentation. It's unfortunate that a big player like Arduino isn't taking a clearer position on open hardware.

As the OSHWA list of certified projects, along with other directories such as OpenHardware.io, Kitspace, and Thingiverse, show, there is already a lot of open hardware. We can hope that Arduino changes heart and renews its commitment to keep its products for makers open, whether OSHWA-certified or not. Arduino plays a significant role in this space, not only with its hardware, but also with its software ecosystem. Fortunately, companies such as Adafruit, SparkFun, and Olimex make a big effort to certify their hardware. So, those who wish to build upon OSHWA-certified hardware have a lot of alternatives to Arduino boards to choose from.


Index entries for this article
GuestArticlesVervloesem, Koen


to post comments

Defining open hardware

Posted Oct 18, 2023 15:07 UTC (Wed) by smurf (subscriber, #17840) [Link] (29 responses)

For hardware to really be open, the tools to read and modify the design files should also be open source.

Designs whose sources can only be opened with some closed-source design program are in a gray area here.

Thingiverse is even worse, as most of the designs on it is Freeware at best. STL files are not source code.

Defining open hardware

Posted Oct 18, 2023 16:53 UTC (Wed) by pizza (subscriber, #46) [Link] (27 responses)

> For hardware to really be open, the tools to read and modify the design files should also be open source.

That would permanently exclude the overwhelming majority of the otherwise-completely-open hardware.

Do you also claim that some GPL-licensed software isn't actually "Free" when you need some proprietary tools to compile or install it?

Defining open hardware

Posted Oct 18, 2023 18:14 UTC (Wed) by mb (subscriber, #50428) [Link] (22 responses)

>Do you also claim that some GPL-licensed software isn't actually "Free"
>when you need some proprietary tools to compile or install it?

Yes, absolutely.

Defining open hardware

Posted Oct 18, 2023 18:16 UTC (Wed) by calumapplepie (guest, #143655) [Link] (2 responses)

The GNU GPL existed before GCC or glibc did. There's still signs of that in the license; the system library exception, for instance.

Defining open hardware

Posted Oct 18, 2023 18:33 UTC (Wed) by mb (subscriber, #50428) [Link]

Correct.
But GNU did have a plan to remove these freedom restrictions.

I wrote software myself that is GPL licensed but needs a proprietary toolchain. Therefore, its freedoms are restricted in practice. It's less free than free software that is built on a free toolchain.

Defining open hardware

Posted Oct 18, 2023 19:02 UTC (Wed) by ballombe (subscriber, #9523) [Link]

> The GNU GPL existed before GCC or glibc did.

No, this is not historically correct. The GNU GPL was released two years after gcc to unify all the GNU software under a single license.

Defining open hardware

Posted Oct 18, 2023 19:35 UTC (Wed) by smurf (subscriber, #17840) [Link] (18 responses)

You can reuse the GPL-on-nonfree-toolchain source code as a basis to write a version that works with a free toolchain instead, and/or you can go ahead and write that free toolchain.

I cannot do that with a hardware design that's been created using a proprietary toolchain, delivered using an undocumented file format. In this case I do not have access to the source code – just to some secondary output (like the schematic-as-PDF and the layout-as-Gerber files) which I have to painstakingly re-enter, and a layout that I need to recreate by hand, before I can actually *start* exercising *any* of my Four Freedoms.

That's almost as bad as the oh-so-free designs on Thingiverse that don't ship sources – just some STLs which I have to reverse-engineer into my own CAD program if I want to do anything nontrivial with them.

Defining open hardware

Posted Oct 18, 2023 19:51 UTC (Wed) by pizza (subscriber, #46) [Link] (17 responses)

> I cannot do that with a hardware design that's been created using a proprietary toolchain, delivered using an undocumented file format.

Every EDA toolchain I've personally used [1] uses well-documented file formats, both for their inputs and outputs [2]. Of course, successfully *interpreting* those files without use of said proprietary tools is a different matter entirely.

But that's not at all the same thing.

The overwhelming majority of *all* hardware production requires use of proprietary toolchains and (especially) equipment. You want to advocate for incremental increased openness down the stack, great! That's a very worthy goal! But to blithely dismiss "Open hardware" as not-truly-open because it needs proprietary tooling is self-defeatingly myopic. One has to start somewhere.

[1] Eg the suites produced by Cadence, Mentor Graphics, even Xilinx's FPGA tools.
[2] On the input side: RTL (or component + netlists). On the output side, gerber files, component pick-n-place lists, etc.

Defining open hardware

Posted Oct 19, 2023 11:14 UTC (Thu) by spacefrogg (subscriber, #119608) [Link] (16 responses)

Yes, one has to start somewhere. I totally agree on that statement when it comes to practicing open-hardware development.

I totally not agree with it, when it means spoiling the fundamental definitions and concepts that shape our understanding of what open hardware means or is supposed to be meaning.

Hardware dependent on closed-source tools, and thus, the goodwill of a company, is not open. That is no meaningful definition of open hardware, but it is a practical approach towards open hardware. It is practical, because it generates public interest in hardware-designs otherwise inaccessible behind closed-source practices. This interest can (and usually does) enable the development of open-source toolchains, exactly because of their current dependence on commercial tools, which is impractical to the community for various reasons (price, extensibility, re-usability, integration into other flows).

Defining open hardware

Posted Oct 19, 2023 14:01 UTC (Thu) by pizza (subscriber, #46) [Link] (15 responses)

> Hardware dependent on closed-source tools, and thus, the goodwill of a company, is not open.

Then there is ZERO open hardware, and likely never will be.

You can have "Free Software" totally reliant on nonfree platforms to function. The same is true of hardware, and always will be until someone invents the universal molecular constructor and its patents expire.

Defining open hardware

Posted Oct 19, 2023 14:05 UTC (Thu) by mb (subscriber, #50428) [Link] (14 responses)

>You can have "Free Software" totally reliant on nonfree platforms to function.

Free is not only about "function". It's also about my ability to repurpose, modify and reuse it.
That is defacto restricted, if the required tools have a non free license and no Free alternatives exist.

>Then there is ZERO open hardware

It's not zero. But yes, it's not much.
There's work to do.

Defining open hardware

Posted Oct 19, 2023 14:20 UTC (Thu) by pizza (subscriber, #46) [Link] (13 responses)

> Free is not only about "function". It's also about my ability to repurpose, modify and reuse it.
> That is defacto restricted, if the required tools have a non free license and no Free alternatives exist.

And those never will exist, because at the bottom of the stack are VERY proprietary semiconductor fabs. (Or did you think your "open source RISC-V" processor just manufactures itself? OR that the CPU is able to communicate with the outside world without proprietary I/O blocks? Or utilize SRAMs that aren't also proprietary? Or, for that matter, _any_ of the analog components, including, say, the pad drivers?)

> It's not zero. But yes, it's not much.

No, it is zero, because there's no such thing as a "Free CPU" under your definition. Everything, at some level, ultimately relies on proprietary tooling. It's _possible_ to change that, but it's going to require (at minumum) tens of millions of dollars -- on an ongoing basis. Actually, scratch that -- those fabs themselves rely on proprietary tooling, and while that's also possible to replicate with something "open" , the price for that is going to be even higher.

So, no, saying that something can't be "Free" unless it only utilizes "free tooling" excludes literally *everything*. Even The FSF doesn't take such an extreme position.

Defining open hardware

Posted Oct 19, 2023 14:24 UTC (Thu) by mb (subscriber, #50428) [Link] (9 responses)

I was never talking about that.
I was talking about build toolchains for which no Free alternative exists when I create my own hardware. Not when I use existing hardware.

Free toolchains for hardware development do exist.

Defining open hardware

Posted Oct 19, 2023 14:29 UTC (Thu) by pizza (subscriber, #46) [Link] (8 responses)

> Free toolchains for hardware development do exist.

For some kinds of harwdare, sure. But you're the one who said that's not good enough.

Since your "free hardware" still uses proprietary components (that can't be studied/altered/modified/etc), it can't be free.

Defining open hardware

Posted Oct 19, 2023 14:45 UTC (Thu) by mb (subscriber, #50428) [Link] (7 responses)

>But you're the one who said that's not good enough.

No. You are talking about electrical components, as far as I understand your posts.
I am talking about the toolchain.

Of course there are shades of grey. But let me give a simple example:
If I publish my "Free" hardware design under a Free license and that design is published in a proprietary file format that can only be read by one proprietary tool chain, then that "Free" hardware design is not really fully Free in my opinion. That's what I'm saying.

Defining open hardware

Posted Oct 19, 2023 15:08 UTC (Thu) by pizza (subscriber, #46) [Link] (6 responses)

> If I publish my "Free" hardware design under a Free license and that design is published in a proprietary file format that can only be read by one proprietary tool chain, then that "Free" hardware design is not really fully Free in my opinion. That's what I'm saying.

No, It's still a "Free hardware design", albeit one that relies on a proprietary platform.

The Free Software movement started in much the same place, needing proprietary tools to do pretty much anything. Over time that changed, but to this day there is plenty of Free Software that still relies on proprietary platforms and their proprietary toolchains.

"Free" in these contexts has _only_ ever referred to the source/data/design files themselves (ie the stuff the author/creator created/modified) not the tools or platforms needed to work with them.

Defining open hardware

Posted Oct 19, 2023 16:34 UTC (Thu) by smurf (subscriber, #17840) [Link] (5 responses)

There are two material differences between the situation then, and somewhat-Open Hardware now.

(A) The Free Software movement started on systems that did come with a free-as-in-beer compiler. In contrast, vendors of commercial EDA systems might (or might not) supply a free viewer which may (or may not) run on your hardware, but which typically cannot be used to create the output required to make the circuit as-is, let alone modify it.

(B) You didn't / don't need a proprietary tools to even look at, let alone modify, free source code. It's ASCII, and the preferred way to view and modify it is "any text editor", doesn't matter which one, doesn't matter which platform, you only had to fight DOS/Windows vs. Mac vs. Unix CRLF conventions. :-/ Also, it didn't glue you to any particular hardware.

In stark contrast to this, the only way to do *anything* with a schematic and layout designed with $TOOL is to buy $TOOL (or, as the lawyers would have it, a license to use $TOOL). If $TOOL is not available for your platform, too bad, you're SOL. If the maker of $TOOL goes out of business and the thing fails to run on tomorrow's system, too bad again. That's lock-in, not freedom.

To be fair, if the file format is at least mostly-documented then the other thing you can do is to write a converter to KiCAD …

Defining open hardware

Posted Oct 19, 2023 22:24 UTC (Thu) by pizza (subscriber, #46) [Link] (4 responses)

> (A) The Free Software movement started on systems that did come with a free-as-in-beer compiler.

The software wasn't "free as in beer" -- it was bundled with the _very_ expensive hardware, and if you didn't have legitimate access to this hardware, you couldn't use the compiler. Furthermore said compiler (and hardware) had all sorts of quirks that made the software you wrote not (easily) portable to different systems. (These are among the reasons why GCC was such an important creation!)

> (B) You didn't / don't need a proprietary tools to even look at, let alone modify, free source code

The really expensive EDA tools I'm familiar with work with plaintext data files, both as their input and output, and are entirely built on top of scripting engines to the point where your saved "design" is a plaintext script. Everything about a design can be manipulated using nothing more than a text editor. Now granted, that's not necessarily the preferred way of visualizing or manipulating a design, but it doesn't make the design any less four-Freedoms Free.

> If the maker of $TOOL goes out of business and the thing fails to run on tomorrow's system, too bad again. That's lock-in, not freedom.

Yeah, and? Rely on _any_ proprietary component and you're ultimately at the (partial) mercy of its vendor. Does the fact that a given design relies on (say) a specific ESP32 part mean the design is "locked in" instead of Libre?

Defining open hardware

Posted Oct 20, 2023 6:20 UTC (Fri) by mb (subscriber, #50428) [Link] (3 responses)

>Does the fact that a given design relies on (say) a specific ESP32 part mean the design is "locked in" instead of Libre?

No, because there are alternatives. That is the opposite of locked-in.

Defining open hardware

Posted Oct 20, 2023 11:06 UTC (Fri) by farnz (subscriber, #17727) [Link] (2 responses)

If I rely on an ESP32-C6 chip in my design, and Espressif decide they're not selling to me, exactly what alternatives do I have without redoing my design (at least in part)?

I can obviously redo the design to use a different part, but the same applies if I have the ability to export (e.g.) a schematics PDF from Altium (a proprietary tool) as a PDF, or if I've got VHDL written against the Mentor Graphics tools for the Skywater PDK. But then I'm not "locked in" to the proprietary tools, because I can port between them; if being able to port from one tool o another is the "opposite of locked-in", then none of the proprietary hardware design tools are locked in, and designs in all of them are "Libre".

Defining open hardware

Posted Oct 20, 2023 12:58 UTC (Fri) by smurf (subscriber, #17840) [Link] (1 responses)

If you're lucky you have the PDF because the creator helpfully included a PDF export with the files. You often can't do it yourself without buying the tool, at which point a PDF export doesn't make sense.

The problem here is that a PDF is not the equivalent of source code. Source is whatever you use when you build things or make changes. You wouldn't accept the printout of the Linux kernel (OK, that's too big to print nowadays, but you get the point) as fulfilling the GPL's obligation to supply source code either, would you? Even though a printout is far easier to scan back into ASCII than a schematic's PDF …

Defining open hardware

Posted Oct 20, 2023 20:57 UTC (Fri) by farnz (subscriber, #17727) [Link]

But there are alternatives to using the proprietary tool, just like there's alternatives to using an ESP32-C6 chip; by the argument that you're not "locked in" because there are alternatives to the ESP32-C6 that aren't pin-compatible (and thus need a redesign to use), there's also no lock-in if you use a proprietary EDA tool, since there are alternatives.

Defining open hardware

Posted Oct 19, 2023 16:17 UTC (Thu) by paulj (subscriber, #341) [Link] (2 responses)

It's quite possible to build your own small semiconductor fab. There are university EEE departments with small scale fabs with lower end commercial tools. There is an engineer somewhere who's even built his own basic fab in his garage _with his own process_ - see http://sam.zeloof.xyz/

OK, you won't build nm-scale, millions-transistors, GHz chips with these any time soon. But... capabilities always get better, open source always expands its scope.

Defining open hardware

Posted Oct 19, 2023 16:19 UTC (Thu) by paulj (subscriber, #341) [Link]

Defining open hardware

Posted Oct 19, 2023 22:40 UTC (Thu) by pizza (subscriber, #46) [Link]

> It's quite possible to build your own small semiconductor fab. There are university EEE departments with small scale fabs with lower end commercial tools.

My alma matter had one too, but I shouldn't have to point out that those "lower end commercial tools" are still proprietary.

> There is an engineer somewhere who's even built his own basic fab in his garage _with his own process_ - see http://sam.zeloof.xyz/

While what he's accomplished is impressive, we need to keep things in perspective -- He is where the semiconductor industry was at *over half a century ago*

> But... capabilities always get better, open source always expands its scope.

The thing is, not unlike nuclear bombs, the science behind (even considerably more modern) semiconductor fabrication is well known; what makes it difficult is scaling your efforts to produce consistent, reliable results at sufficient volume (without killing yourself) -- and that takes a lot of startup and operating capital.

Defining open hardware

Posted Oct 18, 2023 18:22 UTC (Wed) by somlo (subscriber, #92421) [Link] (3 responses)

I guess "freedom" is a concept that has to be applied within a specified *scope*:

You can have a perfectly free software stack (self-hosting, even): a self-hosting free compiler that can compile a system library and kernel from free sources, and itself run on top of that kernel and system library. All other applications built from free sources with the free compiler on top of the free kernel & system library is additional, bonus freedom.

This all ignores the *hardware* it all runs on, which is most likely not free. If you want to extend freedom (and self-hosting) down the stack of abstraction layers, you can go as far as RTL (gateware) by using yosys/trellis/nextpnr (free software) to compile free HDL (cpu, soc) into FPGA bitstream.

Now you have a free software *and* gateware stack, but it runs on top of a proprietary physical layer.

The moment you have to ship your (presumably built from free sources with free software tools) ASIC masks to a chip foundry you don't control, you're stuck. There's no freedom (that I'm aware of) at that layer, because there are no free self-hosting chip foundries and/or fine-precision mechanical steppers and all the chemistry and materials science that goes into turning free masks into free silicon :)

If anyone here has read Diamond Age by Neal Stephenson, we're going to need self-replicating open-source nano-assemblers that can build ASICs from free sources (in addition to rebuilding their own components) for there to be ABSOLUTE freedom in (computer) hardware...

Defining open hardware

Posted Oct 18, 2023 19:27 UTC (Wed) by mithro (subscriber, #50469) [Link] (1 responses)

FWIW - The work that slomo has been doing on trying to get self hosting working with open source FPGA tools is really pushing openness further.

The is cool stuff that Fabulous (https://github.com/FPGA-Research-Manchester/FABulous) and OpenFPGA (https://github.com/lnis-uofu/SOFA) are doing is also making "open source FPGA" on top of "open transistors" a possibility (I put together a summary last year @ https://bit.ly/goog-fpga-22q3).

On the topic of keeping getting lower levels more open, it is worth mentioning things could trend in the right direction.

The open source manufacturable PDKs like Google's SKY130 (https://github.com/google/skywater-pdk) & GF180MCU (https://github.com/google/gf180mcu-pdk) and iHP's 130nm BiCMOS (https://github.com/IHP-GmbH/IHP-Open-PDK) help with this.

The machines in a 200mm foundry could in theory run on silicon created on 180nm / 130nm silicon. I know that a number are probably using much older silicon in many cases!

The NIST Nanotechnology Platform collaboration with Google (https://bit.ly/goog-nist) is also trying to get a lot of the raw data available (https://github.com/google/skywater-pdk-sky130-raw-data) and matching that with low level simulations with things like GDSFactory (https://github.com/gdsfactory/gdsfactory) and physical imaging (https://bit.ly/sky130-mpw1-testtile-notes). SemiMod is doing stuff for iHP's process (https://gitlab.com/dmt-development/ihp_sg13g2_compact_models).

Then there are people doing cool stuff to even get the actual processing information going like LibreSilicon (https://libresilicon.com/) and Sam Zealoof's stuff (http://sam.zeloof.xyz/). science.xyz who purchased the MEMSCap foundry is also publishing quite a lot of details at https://science.xyz/services/foundry/ .

Something like PragmaticIC's process technology could be an interesting position between between the large foundries (like GF / SkyWater) and the tiny backyard labs. They recently announced intention to do more open stuff in this area - https://www.pragmaticsemi.com/newsroom/blogs/democratisin... and claim possible wafer turn around times in weeks rather than months.

Defining open hardware

Posted Oct 18, 2023 19:36 UTC (Wed) by mithro (subscriber, #50469) [Link]

Then there is also awesome stuff like Ken Shirriff's work to make previously closed items open (https://www.righto.com/).

He recently started doing a writeup on the Intel 386 (https://www.righto.com/2023/10/intel-386-die-versions.html). Previously, he did Xilinx's first ever FPGA the XC2064 (https://www.righto.com/2020/09/reverse-engineering-first-...).

BTW I know quite a bit of "legacy" foundry equipment which uses both those parts.

Defining open hardware

Posted Oct 18, 2023 19:51 UTC (Wed) by brunowolff (guest, #71160) [Link]

> This all ignores the *hardware* it all runs on, which is most likely not free. If you want to extend freedom (and self-hosting) down the stack of abstraction layers, you can go as far as RTL (gateware) by using yosys/trellis/nextpnr (free software) to compile free HDL (cpu, soc) into FPGA bitstream.

> Now you have a free software *and* gateware stack, but it runs on top of a proprietary physical layer.

If you are willing to run on FPGAs, this might be good enough to ensure you control the hardware. Bunnie Huang has written some blog posts related to this and probably the most relavent two are:

Infra-Red, In Situ (IRIS) Inspection of Silicon (https://www.bunniestudios.com/blog/?p=6712)
Evaluating Precursor’s Hardware Security (https://www.bunniestudios.com/blog/?p=5979)

Defining open hardware

Posted Oct 19, 2023 0:11 UTC (Thu) by gerdesj (subscriber, #5446) [Link]

"Thingiverse is even worse, as most of the designs on it is Freeware at best. STL files are not source code."

You can publish whatever you like on Thingie, not just STLs. I have personally published a parametric design for a wedge for a DoorBird - not the most exciting thing but there you go. They have a OpenSCAD integration built in but it breaks rather often.

Anyway, there are shed loads of properly free models on Thingie. Yes, I get that .STL gets you an instance rather than something malleable - there are loads of those too.

Do you publish any models on Thingie or anywhere else?

Respects Your Freedom

Posted Oct 19, 2023 17:14 UTC (Thu) by Hobart (subscriber, #59974) [Link] (1 responses)

How does this compare/contrast with (also 2012) Respects Your Freedom?

https://ryf.fsf.org/about/criteria

Respects Your Freedom

Posted Oct 25, 2023 23:35 UTC (Wed) by pbonzini (subscriber, #60935) [Link]

RYF covers the software (and firmware) that comes with a physical product. It goes beyond mandating open source/free software, requiring that "the product software must be buildable using 100% free software that's released to the public, on a 100% free operating system that is released to the public" (so no Windows-only toolchains), no spying, and restrictions on patent-encumbered formats. However it does not cover the ability to make, modify the product itself.

Open Hardware covers the product itself and ensures (as mentioned in the article) that "anyone can make, modify, distribute, and use those things". It also covers the firmware that runs on the product, but it does not require it to be open source if the documentation makes it "straightforward to write open source software that allows the device to operate properly".

In other words, they mostly complement each other.

Defining open hardware - LGPL like license

Posted Oct 23, 2023 7:10 UTC (Mon) by ppisa (subscriber, #67307) [Link]

Dear readers, I would like suggestion for some copyleft license which would work as copyleft with boundary defined on signal level/pins going in/out to/from a license covered IP core.

It should work that way for IP core use in FPGA as well and in ASIC design. It can include even matching drivers sources etc... Even that I consider as ideal situation when whole design and complete tool-chain can be open source, enforcement of such requirements would make design incompatible with the most/all today options to realize it and there are not many companies which would be willing to pay for such solution and it would not get to users.

But it is critical for me, that the given core would be available in the source form to all users (LGPL) and all modified version would keep that requirements.

May it be that some of mentioned licenses fits well to these criteria, I have not read them this time yet, I have read some of them in past but in 2017 when I have prepared open project with Volkswagen none has been approved as safe to not lead to some future deadlock in OSADL consultation. Even that Volkswagen agreed with LGPL, I have negotiated BSD/MIT and provided additional payment for that less restrictive license and at the end the project into which I invested years of work, my company money etc. has turned slowly into license owned by our former student, legal for BSD, but not what I wanted and invested money, time and negotiated contracts over years.


Copyright © 2023, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds