Third-party notices

This repository's own code is governed by LICENSE.md. The following third-party material is bundled into shipped artifacts.

Fonts compiled into the application

brep-app bundles four font faces, and none of them are ours. This repository ships no font file at all: the BrepIcons.ttf icon face it used to carry was retired when every icon became inline SVG artwork (BREP_app/assets/glyphs/, compiled into src/icons.rs by build.rs), so an icon character is now only a key into that catalog, never something a font renders. The four faces arrive through eframe's default_fonts feature, which pulls epaint_default_fonts — a crate whose entire contents are four include_bytes! constants, so those faces are linked into every native binary and every wasm module built from BREP_app/ whether or not the UI ends up drawing with them.

Sketch text in BREP_render also uses the bundled Ubuntu Light and Hack fonts to generate saved vector outlines, parsed by ttf-parser (MIT OR Apache-2.0).

epaint_default_fonts declares its terms as (MIT OR Apache-2.0) AND OFL-1.1 AND Ubuntu-font-1.0. The AND is the part that matters: the OFL-1.1 and Ubuntu-font-1.0 obligations are not discharged by taking the MIT or Apache-2.0 option on the crate's own code — both licences require their notice to travel with the font. A binary release of brep-app (the .exe, the native binary, or the wasm bundle) must therefore carry the four notice files listed above, copied from the epaint_default_fonts source in the Cargo registry. Publishing BREP_app to crates.io as source does not raise this, because the consumer resolves epaint_default_fonts from crates.io with its notice files intact. The generated help site (BREP_docs, run by ./build.sh app into BREP_app/web/help/) reproduces those four notice texts on its Third-party crate licences page, read from the epaint_default_fonts package at build time, so the wasm bundle served together with web/help/ carries them; a native binary shipped on its own still needs the files beside it.

All UI text is drawn with the operating system's default monospace font, located and read at runtime via fontconfig — it is not bundled or redistributed. On wasm, or on a native machine without fontconfig, the epaint_default_fonts faces above are the fallback that is actually rendered.

KiCad symbols kept as test fixtures

BREP_ecad_core keeps two KiCad symbol library files as test fixtures (kicad_symbols in BREP_ecad_core/src/fixtures.rs). No compiled binary links them unless a consumer asks for them: the module compiles only for BREP_ecad_core's own tests and for crates that request its fixtures feature as a dev-dependency (BREP_ecad_egui, BREP_app), and Cargo keeps a dev-dependency's features out of a normal build.

The source files do travel, however. fixtures reads them with include_str!, so a package that left them out could not build with that feature, and assets/kicad/** is therefore in BREP_ecad_core's include list: the published .crate archive redistributes these two files, with their own licence and provenance beside them. The electronics editors place parts, which carry their own symbols, so they have no starter library.

Both are selections from https://gitlab.com/kicad/libraries/kicad-symbols at revision a9012d8971ef2ea3243ffc9f19a5b4f153d8b334 (KiCad 9.0.0); BREP_ecad_core/assets/kicad/PROVENANCE.json records the selection and the changes made. The licence, with the exception, is BREP_ecad_core/assets/kicad/LICENSE.md, which travels with the two files both in the source tree and in the published archive, as CC-BY-SA requires of a redistributed selection.

PLM frontend vendor bundles

The PLM server embeds self-hosted TOAST UI Editor 3.2.2 JavaScript/CSS and DOMPurify 3.4.16 JavaScript. TOAST UI Editor is distributed under the MIT licence; DOMPurify offers Apache-2.0 OR MPL-2.0, and this distribution uses Apache-2.0. The TOAST UI browser bundle also retains its embedded third-party copyright and licence notices, including its DOMPurify 2.3.3 dependency.

Full licence texts are shipped at BREP_plm/web/vendor/TOAST-UI-LICENSE and BREP_plm/web/vendor/DOMPurify-LICENSE; versions.json records pinned versions and SHA-256 hashes. The production frontend modules are project-owned source.

Rust crate dependencies

Verified with cargo metadata --format-version 1 on 2026-09-09 against the BREP_app graph (the superset — it resolves the kernel, gizmos, render, reconstruction, RANSAC and MCP-core crates plus every registry dependency of all of them, across every target and including dev-dependencies).

• 488 packages in the BREP_app graph, 481 of them third-party; 83 in the BREP_kernel graph, 82 third-party.
• Zero packages carry a copyleft-only licence. Every non-repo package is usable under a permissive term: 238 MIT OR Apache-2.0, 93 MIT, 36 Apache-2.0 OR MIT, 18 Unicode-3.0 (the ICU4X family), 15 MIT/Apache-2.0, 12 Apache-2.0, and a long tail of Zlib / ISC / BSD / Unlicense / BSL-1.0 / CC0-1.0 / CDLA-Permissive-2.0.
• Three packages offer a copyleft term as one option among others, and the permissive option is taken in each case: self_cell (Apache-2.0 OR GPL-2.0-only) and r-efi ×2 (MIT OR Apache-2.0 OR LGPL-2.1-or-later).
• Four packages use AND in their licence expression — the packages whose obligation cannot be satisfied by picking one term. Every one of them is a normal (not dev-only) dependency of BREP_app:

Only epaint_default_fonts conjoins font licences, which is why it gets the table above; the other three impose ordinary permissive-notice obligations, so a binary release must ship each of those crates' own licence texts alongside the four font notices. In the BREP_kernel graph unicode-ident is the sole AND expression; it arrives through the kernel's unconditional wasm-bindgen dependency (wasm-bindgen → wasm-bindgen-shared), so it is linked on every target the kernel builds for, not only wasm.

• Every BREP* package itself declares no SPDX license; they carry license-file = "LICENSE.md", which is this repository's own non-standard licence. Automated scanners will report them as unknown rather than permissive.

To regenerate the inventory after a dependency change:

cargo install cargo-license
cd BREP_app && cargo license

(Neither cargo-license, cargo-deny nor cargo-about was installed when the above was verified; cargo metadata's license field was read directly instead. It reports the same declared expressions those tools consume.)

The counts above are a snapshot. The help site's Third-party crate licences page is generated from cargo metadata on every ./build.sh app, so it lists the crates actually resolved for the build it ships with, grouped by licence expression.

Network endpoints reached by the application

brep-app contacts two of this project's own public services. Neither carries a credential and neither is contacted unless the user acts:

• https://api.step.parts/v1 — the step.parts model library, queried when the user opens the Assembly workbench's library panel (src/panels/step_parts.rs).
• https://next.brep.io/api/report — the reports endpoint, POSTed to only when the user submits the in-app "Submit Bug" form (src/panels/bug_report.rs).