Show a source link in the web UI, naming the running version (AGPL §13)

[guycorbaz]

What

Show a link to opencmdb's source from the web UI itself — a small footer line on every page,
naming the running version and pointing at the code that produced it.

Why

opencmdb is licensed AGPL-3.0-or-later, and the AGPL's distinguishing clause is §13, Remote
Network Interaction: someone who modifies opencmdb and lets other people use it over a network
must offer those users the source of their modified version. The licence text says how, in the
"How to Apply" appendix:

If your software can interact with users remotely through a computer network, you should also
make sure that it provides a way for users to get its source. For example, if your program is a
web application, its interface could display a "Source" link that leads users to an archive of
the code.

opencmdb is a web application, so this is the case the text is describing.

Two honest qualifications, so this issue is not mistaken for a compliance emergency:

1. As the upstream author serving unmodified code, there is no obligation here. §13 binds whoever
   modifies and serves; it does not oblige the original author to publish a link to their own
   already-public repository.
2. So this is recommended practice, not a fix. Its real value is downstream: a forker who deploys a
   modified opencmdb inherits a UI that already carries the link, which makes their §13 obligation
   discoverable instead of something they have to read the licence to learn.

It also fits the product's own thesis. A tool built on the premise that documentation must not lie
about reality should be able to say which version of itself is running.

The actual decision: what does the link point at?

This is the part worth deciding rather than defaulting.

• Pointing at master is one line and almost free — and it is the weaker answer. It tells a
  user where the project lives, not where this running binary came from. Under §13 the thing a
  user is entitled to is the source of the version being served.
• Pointing at the running version is what the clause is actually about. Today
  CARGO_PKG_VERSION is available at runtime (already used in crates/opencmdb-bin/src/metrics.rs)
  so .../releases/tag/v0.1.1 is reachable with no new machinery. That covers every released build.
• Pointing at the exact commit would cover builds that are not a release tag — a fork's main,
  a local build, a CI image. That needs the git SHA embedded at build time, which the binary does
  not carry today. It is a small addition, but it is a new build-time input and should be a
  deliberate choice rather than a side effect of this issue.

Suggested resolution: version-tag link now, SHA later if and when non-release builds are something
people actually run. Recording the reasoning either way matters more than the choice.

Scope

• A footer on the page(s) the UI serves. crates/opencmdb-bin/templates/gap.html currently has no
  footer at all — it ends at </body> — so this adds one rather than editing one.
• The line should carry: the project name, the running version, a link to the source, and the
  licence identifier.
• It must survive the bilingual rule (EN/FR via rust-i18n) like every other UI string.
• Out of scope: an in-app source archive download. The licence permits pointing at a public
  repository, and shipping a tarball endpoint from a network-mapping tool is a larger decision.

Related

• The licence landed in the repo on 2026-07-22 (LICENSE, AGPL-3.0-or-later verbatim); before that
  the identifier was declared only in the Cargo.tomls and the README.
• Issue No administration surface is planned — settings have nowhere to live in the UI #12 (no administration surface) will introduce more UI chrome; if that lands first, the
  footer belongs in the shared layout it creates rather than in a single template.