Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Ship third-party license notices for everything in the installer

Abierto
  • ¿Algo no está bien?
#1,941 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@Cedric921 ya está trabajando en esto.

Desde el 6/10/2026.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
42/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
electron, python, typescript
Área
devops, release

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Python
Estrellas
16.3k
Forks
1.6k
Merge medio
18 h 52 min
PR fusionados (30 d)
218

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de MODSetter/SurfSense

Todos los issues de MODSetter/SurfSense

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.