Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Ship third-party license notices for everything in the installer

Aperta
  • Qualcosa non va?
#1,941 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@Cedric921 ci sta già lavorando.

Dal 6/10/2026.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
42/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
electron, python, typescript
Ambito
devops, release

Direzione di ricerca

Read CONTRIBUTING.md, docs/architecture/about.md and docs/architecture/packaging.md; inspect electron-builder.yml and the listed fetch/build scripts to trace shipped artifacts. Start with about-settings.test.tsx and the license-generation test, then run the frontend and Electron tests and typecheck as listed. Done means generated notices for shipped dependencies are available offline in the app, the About documentation is updated, and the known-gap entry is removed.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

desktop documentation help wanted

The gap

docs/architecture/about.md lists this under Known gaps:

No third-party license notices ship with the app. Generating them needs the frontend's npm dependencies, the Python sidecars' packages and the bundled native binaries collected at build time.

Why it matters

Settings › About has a License section that says SurfSense is Apache 2.0 and links the repository's LICENSE. That is SurfSense's own licence. The installer also ships hundreds of other people's work — the renderer's npm tree, two frozen Python binaries, llama-server, sd-server, audio.cpp and the eSpeak-ng it phonemises through, and the embedding, voice and Docling parser packs — and none of their notices reach the user's machine.

Most of those licences (MIT, BSD, Apache 2.0) require the notice to travel with the binary. A user who wants to know what is in the app they installed, or a company deciding whether they may deploy it, has nowhere to look and no file to point at.

Where

Collect, do not add a dependency. pnpm licenses list --json ships with pnpm (the tree is pinned to [email protected]) and covers both npm trees. Python distribution metadata carries the licence and the classifier, readable from the environment uv sync already builds. The native binaries are fetched by pinned-version scripts that can fetch the licence file alongside the binary.

What done looks like

  • A user can read the notices for everything that shipped, from the running app, offline. The app is offline by default and the notices describe what is on this machine, so a link to the web is a weaker answer than a bundled file — but it is yours to choose, with the reason in the PR.
  • The notices are produced by the build from the pinned versions, not written by hand. A hand-maintained list is wrong the first time a dependency moves.
  • A dependency added to any of the three trees appears in the notices without anyone remembering to do anything.
  • Say what you did about the parts that resist automation: a native binary whose release carries no licence file, and a model pack, whose weights have licences of their own.
  • Update docs/architecture/about.md — the What it shows list describes the License line — and delete the Known gaps line in the same PR.

What not to change

The four rows in about-links.ts are constrained by external-url.ts, which drops anything outside surfsense.com, github.com/MODSetter/SurfSense and the Discord invite. Do not widen that allowlist to make a link work; it is an egress boundary, described in egress.

How to verify

surfsense_local/frontend/src/features/about/about-settings.test.tsx covers the About pane. Write the failing test first, on whichever half you start with: that the pane offers the notices, and that the generator produces an entry for a known dependency.

cd surfsense_local/frontend
pnpm test
cd ../electron
pnpm test
pnpm typecheck

Before you start

Read CONTRIBUTING.md, the about doc and the packaging doc, which is where the build's shape is described. Interface strings in surfsense_local follow the translate skill described in AGENTS.md — note that licence text itself is not interface text and is not translated. UI work follows the frontend-workflow skill. This is a big one; comment here with the approach you mean to take before you write much of it, and open your PR against dev, not main.

Lingua principale
Python
Stelle
16.3k
Fork
1.6k
Merge medio
17h 40m
PR unite (30g)
290

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di MODSetter/SurfSense

Tutte le issue di MODSetter/SurfSense

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.