DFSG NEW review for python-opuslib-next version 1.3.1-1

Summary

• Licensing is DFSG-compliant and debian/copyright is accurate: No
• Packaging is of good quality: Yes
• Issues: 1 blocker, 0 important, 0 minor
• debian/watch: version 5
• debian/copyright: machine-readable
• Scan before the review: nothing found

Licensing

The code is free: everything is under the BSD-3-clause licence of LICENSE and pyproject.toml, with no non-free terms, no vendored third-party code and no built artefacts. debian/copyright is DEP-5 and names the right holder, but its stand-alone BSD-3-clause text is not the licence the files carry: both the third clause and the liability disclaimer name 'tastypie', a different project, where upstream's LICENSE names 'SvartalF' and ''. The file therefore misstates the licence text and must be corrected.

Packaging

The packaging is clean and conventional: debhelper compat 14 with dh-sequence-python3 and pybuild/hatchling, an Architecture: all package whose runtime dependency on libopus0 matches the ctypes load of libopus.so.0, tests properly confined to Build-Depends-Indep with <!nocheck>, a declared autopkgtest (autodep8's pybuild test is available on the system), correct Vcs-* fields, and Standards-Version 4.7.4.1 which equals the current Policy. No patches or maintainer scripts are needed and none are present. The only defect is in debian/copyright, reported under licensing.

Issues

1. [blocker] [licensing] debian/copyright's BSD-3-clause text is another project's notice, naming 'tastypie'

• Files: debian/copyright:26, debian/copyright:33, LICENSE:9, LICENSE:15
• Basis: checked, in the package or with a reference tool
• Evidence: debian/copyright: * Neither the name of the tastypie nor the and IN NO EVENT SHALL tastypie BE LIABLE FOR ANY; upstream LICENSE (identical in the .orig tarball): * Neither the name of the SvartalF nor the and IN NO EVENT SHALL <COPYRIGHT HOLDER> BE LIABLE FOR ANY
• Problem: The stand-alone License: BSD-3-clause paragraph is not the licence of the files it is attached to: it is the wording of the django-tastypie licence, evidently copied from another package, and names that unrelated project in the endorsement clause and in the liability disclaimer. The files are licensed under the notice in LICENSE, which names SvartalF and leaves the disclaimer's holder as a placeholder. The licence family is right, but the reproduced text is inaccurate, so debian/copyright does not correctly describe the licensing of the package (DEP-5 requires the full text of the licence actually granted, copyright-format 6.7/5.3).
• Fix: Replace the stand-alone BSD-3-clause paragraph with the text of upstream's LICENSE verbatim (SvartalF in the third clause, <COPYRIGHT HOLDER> in the disclaimer), so debian/copyright reproduces the licence the files carry. If the maintainer prefers the canonical BSD-3 template, use Kalicyh as the copyright holder consistently and say so; do not keep the tastypie wording.

Verified

• Read all of debian/ (changelog, control, copyright, rules, docs, salsa-ci.yml, source/format, upstream/metadata) and every upstream Python file, LICENSE, README.md, pyproject.toml, uv.lock and the GitHub workflows.
• The pre-review author check found no holder missing; the only copyright notices in the tree are LICENSE:1 Copyright (c) 2025, Kalicyh and opuslib_next/init.py:10 :copyright: Copyright (c) 2025, Kalicyh, both matching the Files: * stanza's Copyright: 2025, Kalicyh.
• debian/copyright is DEP-5 with the correct Format line; Files: * covers every upstream file and Files: debian/* the packaging; no Files-Excluded is needed.
• The licence is plainly free: BSD-3-clause as stated in LICENSE and pyproject.toml (license = "BSD-3-Clause"); no non-commercial, no-modification or field-of-use terms anywhere in the tree.
• No built or non-preferred-form files: no jars, class files, shared objects, bytecode, minified JS/CSS, PDFs, fonts or firmware. uv.lock is uv's generated dependency lock file (only package names, URLs and hashes) and is reproducible from pyproject.toml, so it is not a source-less artefact.
• No vendored third-party code or embedded copies of Debian libraries; the package is pure Python and loads the system libopus through ctypes.
• Build-Depends are satisfiable from the archive: debhelper-compat (= 14); dh-sequence-python3; dh-sequence-single-binary (provided by debhelper 14.5); pybuild-plugin-pyproject and python3-hatchling (1.30.1-2); python3-all. Build-Depends-Indep python3-pytest and libopus0 are needed only for the test run and carry <!nocheck>.
• The runtime Depends: libopus0 matches the code, which loads libopus.so.0 via ctypes.util.find_library.
• Testsuite: autopkgtest-pkg-pybuild is supported by autodep8 on this system (its pybuild generate script supplies pybuild-autopkgtest and @builddeps@); no debian/tests directory is needed for it.
• Standards-Version 4.7.4.1 equals the reviewing system's Policy version 4.7.4.1, so it is current.
• No debian/patches, no maintainer scripts, no links/dirs/install files, and none are needed; debhelper compat 14 adds the relationship substvars itself.
• Changelog is well formed: python-opuslib-next (1.3.1-1) unstable; urgency=medium, initial release closing an ITP, with a valid current date.
• uscan found the packaged version as the newest upstream release (upstream 1.3.1, packaged 1.3.1).

Not confirmed

• tests/decoder.py:6-7 and tests/encoder.py:7-9 say From the tests/test_opus_api.c; according to /usr/share/doc/libopus0/copyright, libopus's tests/* are copyright Xiph.Org Foundation and BSD-2-clause, neither of which appears in debian/copyright. Whether the Python tests are a port of that C file (and so a derived work needing its notice) cannot be checked without the libopus sources.
• README.md calls the project a fork of orion-labs/opuslib and the code keeps that API, but no notice from that project is present; whether any code was copied from it and its holder omitted could not be checked, as the original is not available here.
• The package was not built and its test suite was not run (read-only review); nothing in the tree suggests a certain build or test failure.

Proposed changes

None.