bharatgraph / NOTICE.md
abinazebinoy's picture
fix(frontend): vendor D3.js locally instead of loading from CDN (N-2/F-14)
a18c616
|
Raw History Blame Contribute Delete
8.1 kB

Third-Party Notices

BharatGraph is licensed under the MIT License (see LICENSE). This project depends on a number of third-party open-source packages and, for the optional PDF-export feature, a set of native system libraries. Their licenses are listed below.

This file resolves two items flagged by the industry-grade repository audit (August 2026): Finding Lic-1 (fake-useragent's license, previously unverified) and Finding D-7 (no NOTICE/attribution file existed anywhere in the repository, required before any installer bundling these dependencies directly ships).

Scope note: this file is a licensing inventory, current as of the audit date above. It establishes what's bundled and under what terms -- it does not by itself complete every packaging-time compliance step (in particular, the LGPL "user can relink" requirement discussed under Pango, Cairo, and GDK-Pixbuf below is a distribution-mechanism decision, not a paperwork one, and needs to be revisited once an actual Windows installer pipeline is chosen -- see PHASE_ROADMAP.md's desktop-migration track).


Direct Python dependencies (requirements.txt)

Verified individually via each package's own PyPI metadata, official repository, or (for fake-useragent) its pyproject.toml directly, not assumed from memory.

Package License Copyleft? Note
requests Apache-2.0 No
beautifulsoup4 MIT No
feedparser BSD-2-Clause No
lxml BSD-3-Clause No
fake-useragent Apache-2.0 No Resolved (Lic-1): confirmed via the project's own pyproject.toml (license = "Apache-2.0"), corroborated independently by conda-forge's feedstock metadata. The audit's automated PyPI/GitHub metadata check returned empty at the time -- the SPDX license identifier was added to the package's own pyproject.toml relatively recently (see its "Add SPDX license identifier" changelog entry), which explains the earlier miss.
pandas BSD-3-Clause No
numpy BSD-3-Clause No
scipy BSD-3-Clause No
neo4j (driver) Apache-2.0 No
networkx BSD-3-Clause No
fastapi MIT No
uvicorn BSD-3-Clause No
python-dotenv BSD-3-Clause No
jinja2 BSD-3-Clause No
spacy MIT No Ships a separately-licensed model -- see below
sentence-transformers Apache-2.0 No Ships separately-licensed models -- see below
weasyprint BSD-3-Clause No, but see below The Python package itself is BSD-3-Clause; its native rendering dependencies are not -- see the dedicated section below
pdfplumber MIT No
loguru MIT No
schedule MIT No

Bundled AI models

Following the model_selector tiering fix (Findings R-2/R-3/R-4), each of these tasks can now load any of its three tier variants depending on the detected hardware profile, not just one fixed model -- all three variants per task are listed below, not just the one previously hardcoded.

Model Used by Tier License
xx_ent_wiki_sm ai/nlp_extractor.py (NER) low MIT, per its own model card / spacy-models release metadata
en_core_web_sm ai/nlp_extractor.py (NER) medium (and the guaranteed fallback on low/high if the tier-specific model isn't installed) MIT, matching the spaCy models project's stated license
en_core_web_trf ai/nlp_extractor.py (NER) high MIT, per its own model card / spacy-models release metadata
paraphrase-MiniLM-L3-v2 ai/shadow_draft_detector.py, processing/entity_resolver_v2.py (embeddings) low Apache-2.0, per its model card
all-MiniLM-L6-v2 ai/shadow_draft_detector.py, processing/entity_resolver_v2.py (embeddings) medium Apache-2.0, per its model card
paraphrase-multilingual-MiniLM-L12-v2 ai/shadow_draft_detector.py, processing/entity_resolver_v2.py (embeddings) high Apache-2.0, per its model card

None of the six introduces a copyleft obligation.


Frontend JavaScript dependencies (vendored files)

File Package / version License Source Note
frontend/js/vendor/d3.min.js d3 7.9.0 ISC (Copyright 2010-2023 Mike Bostock) https://registry.npmjs.org/d3/-/d3-7.9.0.tgz, dist/d3.min.js Resolves Finding N-2/F-14: previously loaded from cdnjs.cloudflare.com with no working offline fallback (window._d3Failed was set on load failure but never read anywhere). Vendored locally instead -- same exact version as the CDN reference it replaces, so no API-compatibility change. SHA-256 of the vendored file: f2094bbf6141b359722c4fe454eb6c4b0f0e42cc10cc7af921fc158fceb86539. ISC is a permissive license functionally equivalent to MIT/BSD-2-Clause -- requires only that the copyright/permission notice (above) be preserved; this file's own header comment already carries it (// https://d3js.org v7.9.0 Copyright 2010-2023 Mike Bostock). No copyleft obligation.

WeasyPrint's native rendering stack (only relevant if PDF export is bundled into a distributable installer)

WeasyPrint (the Python package) depends on native C libraries it does not itself provide. In the current Docker-based web deployment, these are installed via apt-get at container-build time -- dynamically linking against system-provided libraries this way does not trigger the source-availability obligations that statically bundling them into a distributed installer would. That distinction is why this section exists: it becomes a live compliance question the moment a desktop installer vendors these libraries directly, per PHASE_ROADMAP.md's D2/D3 packaging phases.

Licenses below verified individually against each project's own authoritative source (its repository's COPYING file or, where the project publishes one, its official license page) -- not assumed to be uniform across the group, which turns out to matter: HarfBuzz is not LGPL, despite being part of the same rendering pipeline as three libraries that are.

Library License Verified via LGPL relink obligation applies?
Pango LGPL v2.1 (or later) Pango's own COPYING file (GNOME/pango repository) Yes
Cairo LGPL v2.1 or MPL v1.1 (dual-licensed, redistributor's choice) Cairo's own licensing documentation Yes, if the LGPL branch is chosen (or MPL's equivalent terms if that branch is chosen instead)
GDK-Pixbuf LGPL-2.1-or-later Package metadata (matches upstream GTK project licensing) Yes
HarfBuzz MIT ("Old MIT" license) -- not LGPL HarfBuzz's own COPYING file (harfbuzz/harfbuzz repository) No -- MIT only requires the license text and copyright notice to be included, not a relink mechanism

What the LGPL relink obligation actually means for a bundled installer: for Pango, Cairo (if the LGPL option is used), and GDK-Pixbuf specifically, the LGPL requires that an end user be able to replace or relink the LGPL-licensed component with a modified version of their own -- typically satisfied for a Windows installer by shipping these as separate, replaceable .dll files rather than statically linking them into a single monolithic executable, plus including the LGPL license text and a notice of which files it covers (this file, updated at packaging time, can serve as that notice). This has not been implemented or verified against any actual installer build -- no Windows/PyInstaller build has been executed in this project as of this writing (see PHASE_ROADMAP.md) -- and needs a real compliance pass once a specific installer pipeline exists, not just this inventory.


Sources checked, not assumed

Every license above was verified against the dependency's own authoritative metadata or source repository at the time this file was written (August 2026). Licenses for actively-maintained open-source packages can change between major versions; if any dependency in requirements.txt is upgraded to a new major version, re-verify its license before assuming this file still applies unchanged.