What makes a humanoid robot open source?

Distinguish four layers of openness

An open-source humanoid robot should be evaluated layer by layer. A public SDK supplies a way to develop applications, but inspect its code and license separately. Open-source software requires rights as well as visibility: the Open Source Initiative's definition includes redistribution, source availability and derived works. A repository you can browse without those permissions is not equivalent to software meeting that definition. [s1]

Open hardware concerns the physical design. OSHWA's definition calls for documentation in the preferred format for making changes and clarity about which portions are released. Ask for editable CAD, drawings, electronics schematics, a bill of materials and assembly instructions. A bill of materials lists what to acquire; it should sit alongside usable design files and a stated license, rather than replace them. [s2]

Open firmware concerns the software running closer to the hardware, which may be separate from the application SDK. K-Scale's KOS repository describes a configurable robot firmware framework and provides source under MIT. That is evidence about that framework. It does not establish that every motor, sensor or controller in a resulting build has replaceable firmware; ask which components and build tools are actually covered. [s9]

Read the license for each component

Record each component's license, repository, revision and covered files. Unitree SDK2 identifies BSD-3-Clause and Reachy 2's Python SDK identifies Apache-2.0. Before distribution, check attribution, notice, source-release and same-license obligations in the applicable terms. Keep SDK permissions separate from CAD, actuator firmware, model weights and datasets, and request a license inventory for the components you intend to modify or redistribute. [s5] [s4]

Also look for inconsistent documentation. K-Bot's README describes hardware under CERN-OHL-S and software under GPL v3, while the opened top-level software LICENSE contains MIT text. Treat that as a scope question to resolve before reuse, rather than choosing whichever label suits your intended application. Check submodules and file notices and request clarification for the exact revision you plan to build. [s7] [s8]

Downloadable designs can have narrower permissions than an open-hardware definition. InMoov states CC-BY-NC on its download page. OSHWA's definition permits making and selling designs and rejects restrictions on fields of endeavor, including business use. The practical conclusion is to retain InMoov's stated noncommercial restriction in your assessment instead of calling its downloadable parts unrestricted open hardware. [s12] [s2]

SDK examples: Reachy 2, Unitree and ROBOTIS

Hugging Face's Pollen acquisition announcement describes Reachy 2 as an open-source, VR-compatible research platform and points to software, models and documentation. Its Python SDK repository provides installation instructions and generated API documentation under Apache-2.0. For a manipulation project, start by checking that the available interfaces expose the observations and commands your experiment needs, then verify the hardware package and the licenses of any additional resources. [s3] [s4]

Unitree SDK2 is a public repository with build examples and a BSD-3-Clause license. Hardware edition still matters: the R1 official shop says only EDU supports secondary development. Before purchasing, ask which control interfaces the specific edition permits and whether your intended SDK workflow is supported. Public SDK availability is useful evidence, but it should be connected to the exact purchased configuration. [s5] [s6]

ROBOTIS OP3's manual calls it an Open Platform Humanoid Project and separates demonstration modes, source code, the framework and recovery software in its documentation. Use those links to inspect the parts relevant to your work. The live table below is a shortlist of records with public SDK access, not a certification of all hardware or firmware licenses. The related open-source humanoid robots hub expands that shortlist. [s10]

Buildable designs: Poppy, K-Bot and InMoov

Poppy Humanoid's repository includes hardware and software materials, assembly guidance and a documented separation between Creative Commons BY-SA 4.0 hardware and GPL v3 software. It also distinguishes permission to use the technology from use of the Poppy name. For a build, inspect the exact parts and revision, confirm available actuators and electronics, and budget assembly and calibration before treating the repository as a ready-made robot. [s11]

K-Bot's repository exposes mechanical and electrical directories and links to control, inference and simulation projects. Its README labels it public alpha and warns of breaking changes; that label does not establish current development or availability. For a research fork, inspect those linked components and resolve the software-license conflict before distributing changes. Treat buildability, maintained documentation and access to parts as separate questions; the existence of a public design should not become an assumption about current supplier support. [s7] [s8]

InMoov's download page supplies part files and instructions, but states that its files use CC-BY-NC. It is a useful example of why DIY availability and licensing need separate entries in a comparison. If commercial reuse is intended, check the applicable license and seek separate permission where needed. For any DIY platform, confirm the mechanical design, control software and electronics documentation each cover the version you intend to assemble. [s12]

Check firmware access and the maintenance path

Ask what you can rebuild, flash and recover without vendor intervention. Request the firmware sources, board support, toolchain, flashing procedure and recovery documentation for relevant components. KOS illustrates a repository with native and cross-build instructions and robot-specific integration features. Evaluate that documented scope directly rather than treating a higher-level client library as evidence that the lower-level controller can be replaced. [s9]

Then plan maintenance at the same level as customization. Can you pin a working software revision, reproduce installation, restore the robot and obtain replacement parts? OP3's manual explicitly links programming and recovery resources, providing a useful documentation checklist. Test the required installation or simulation workflow before committing an experiment to a platform, and request written clarification for any recovery step that depends on access your team does not have. [s10]

Choose a research platform around the experiment

Write down the experiment's required observations, action interfaces and physical setup. Do you need locomotion, two-arm manipulation, precise joint commands, images, force feedback or a modified body? Reachy 2's SDK and the OP3 programming documentation are different starting points. Inspect the actual APIs and documentation against your requirements rather than ranking candidates by the phrase open source alone. [s4] [s10]

For reproducibility, select a documented hardware revision and pin the software and configuration used in each run. Check simulation support, calibration procedures and recorded data formats before buying. K-Bot links separate simulation and inference projects, while Unitree provides SDK examples; those resources need evaluation as concrete tools for your workflow, not as a promise that your experiment already works. [s7] [s5]

Finally, compare engineering time with purchase, assembly and support options. Require evidence for the layers you need and mark unresolved licenses or interfaces unknown. Poppy's separate licenses and InMoov's stated restrictions demonstrate why a binary open-source label loses useful detail. Use the live SDK table and related hub to find candidates, then keep a component-level openness record with your procurement decision. [s11] [s12]