We consider this automatically true if the device firmware is open-source even if some experimental and diagnostic codes are poorly documented. For proprietary firmware, this is a question about public availability and completeness of vendor documentation for the command protocols the device accepts. Submitters are encouraged to include an evidence URL pointing to same.

A comment URL should point to the source repository. We distinguish between "vendor open source" (stock vendor firmare is in an open-source repository) and Community open-source (a community project supports a firmware build for the device).

To qualify for a 'yes' answer, all externally-controllable features and settings of the device must be accessible and controllable from open-source software, including but not limited to an open-source slicer.

To qualify, the vendor must not restrict locally controllable features to a subset of what can be done via any cloud service the vendor provides.

To qualify a a freedom-friendly device, software updates must be under the control and at the discretion of the user.

For this to be the case, parts vulnerable to failure must be repairable entirely with third-party parts, and sufficient technical documentation has to be available from the vendor or parts suppliers to actually do it. By "vulnerable to failure" we mean to include any moving part and any electronics, not passive structure and cases. This question is failed if any parts are single-source proprietary; also if they are deliberately rendered unreplaceable and unserviceable; also if the technical documentation to do repair and tinkering is witheld. The product notes should be more specific about the proprietary and semi-proprietary parts, if any.

This question assesses how the vendor interacts with open-source software and third-party developers of tools, materials, and firmware. We distinguish between:

No support: Vendor is hostile, obstructive, or conssitently fails to share key technical information.

Passive support: Vendor is not formally involved but is tolerant of community efforts and may offer occasional help or information.

Active support: Vendor contributes profiles or documentation, helps community developers, or actively coordinates with open-source projects.

We want to encourage vendors to move up this scale, even if they don't have the will or resources fully commit to formal policies.

One of the motivations for the foundation of MFR was the move by one major vendor in early 2025 to lock out control software not pre-approved by them. They partially backed away from this move after uproar from the community. We want vendors to be on notice that behavior like this will cost them sales.

This question evaluates whether the device allows the use of third-party consumables such as filaments, resins, or other material cartridges. To qualify for 'Yes', Devices should not enforce artificial restrictions—such as DRM, chip authentication, or vendor lock-in—that prevent or discourage the use of non-proprietary materials. Use of RFID or similar identification technology on spools or cartridges is acceptable for convenience (e.g., material tracking in multi-filament systems), provided there is a documented manual override or fallback that allows use of third-party or self-supplied materials without degrading functionality.