Skip to content

licensing: replace bundled libsndfile LGPL runtime path #1129

Open
Open
licensing: replace bundled libsndfile LGPL runtime path#1129
Labels
bugSomething isn't workingpriority: highHigh-priority or P1 workstatus: blockedBlocked by conflict, dependency, or required prerequisitetype: bugDefect or incorrect behavior

Description

@seonghobae
seonghobae
opened on Sep 1, 2026

Commercial-policy defect

BandScope's analysis engine directly depends on soundfile>=0.13.1. The Python soundfile package itself is BSD-3-Clause, but its documented binary-wheel/runtime path relies on libsndfile; platform wheels can bundle libsndfile, whose license is LGPL. ContextualWisdomLab does not accept GPL/LGPL/AGPL components as an inbound default for the commercial ecosystem.

Exact evidence

  • services/analysis-engine/pyproject.toml declares soundfile>=0.13.1 in the runtime dependency set.
  • python-soundfile 0.13.1 documentation states that SoundFile is based on libsndfile/CFFI/NumPy, that audio I/O is provided by LGPL libsndfile, and that binary wheels may ship their own libsndfile copy. It also states that SoundFile opens the formats libsndfile supports.
  • BandScope's current native product contract advertises WAV, MP3, FLAC, and M4A intake. The libsndfile upstream issue libsndfile/libsndfile#389 requesting AAC in an M4A/MP4 container remains open, so current SoundFile/libsndfile preflight cannot be treated as evidence that the advertised M4A contract is natively covered.
  • feat(analysis): enforce one canonical audio resource policy (#781) #985 therefore remains a preservation/evidence lane for the historical M4A fallback only; its audioread path may invoke an external decoder and widens authority from an admitted handle to a filesystem path. It is not a commercially approved replacement and must not be cherry-picked as a licensing workaround.
  • A fresh candidate scan found that current Symphonia supports AAC and MP4 in pure Rust, but its upstream license is MPL-2.0. That is not the preferred Apache-2.0/MIT/BSD-class inbound profile in this issue and therefore requires an explicit organization/legal policy decision before it can become the selected commercial boundary. Capability alone is not license admission.

Checking only the top-level Python package license or wrapper metadata is therefore insufficient for both the distributed/runtime dependency chain and the advertised supported-format contract.

Required outcome

Replace or remove the libsndfile-backed runtime path from the commercially supported BandScope product without weakening real-audio behavior.

Acceptance must include:

  1. a commercially permitted, organization-approved audio I/O boundary with exact transitive/native license provenance (prefer Apache-2.0/MIT/BSD-class permissive licensing; any other license requires explicit policy acceptance rather than assumption);
  2. equivalent or stronger decoding and metadata-preflight semantics for the formats BandScope actually advertises, including M4A/AAC, with rights-cleared realistic audio fixtures and recognized decode/resample reproducibility evidence;
  3. descriptor/byte-buffer-first admission where feasible so the replacement does not regress fix(audio): establish canonical local-audio resource policy #866's bounded, path-minimizing Resource Admission authority; any subprocess or filesystem-path fallback needs an explicit threat/resource contract;
  4. removal of the LGPL native dependency from lock/build/package/SBOM/release inputs rather than merely changing the Python wrapper;
  5. updated dependency policy, architecture, README/public docs, SBOM/NOTICE/third-party evidence where applicable;
  6. validation on mandatory Windows and macOS product lanes, including the advertised WAV/MP3/FLAC/M4A set, before commercial readiness is claimed.

Decision boundary

Do not select a decoder because it is Rust-only, pure Rust, or format-complete in isolation. Candidate evaluation must score license admissibility, exact AAC/M4A/WAV/MP3/FLAC coverage, descriptor/streaming API, bounded allocation behavior, deterministic resampling handoff, Windows/macOS packaging, vulnerability/supply-chain history, and maintenance health. Preserve #866 as the Resource Admission/Decode source authority until this issue has an approved replacement contract; then land the replacement through ordinary ancestry with real-audio RED→GREEN evidence and remove libsndfile from the actual product graph.

Do not solve this by suppressing native dependency inventory, pinning a different LGPL libsndfile build, treating wheel/container/process separation as a waiver of organization policy, silently dropping M4A from one layer while UI/native contracts still advertise it, or adopting an MPL/other candidate without the required policy decision.

Activity

  1. seonghobae commented on Sep 1, 2026

    @seonghobae
    seonghobae
    on Sep 1, 2026 – with ChatGPT Codex Connector
    CollaboratorAuthor

    Canonical implementation ownership should stay in the existing #781 Resource Admission & Decode vertical, currently PR #985 (feat/canonical-audio-resource-policy-781), rather than spawning another decoder micro-PR.

    Fresh code review confirms the compliance defect is broader than the direct soundfile declaration: protected/current #985 production decoding still reaches librosa.load from temporal analysis, stem separation, and bass transcription, while the metadata preflight directly uses soundfile.info with audioread fallback. Removing only the direct soundfile line therefore cannot prove libsndfile is absent from packaged/runtime inputs.

    Replacement decision boundary:

    • Do not use audioread→ffmpeg/GStreamer as a hidden workaround; it changes neither the requirement for exact native/transitive license provenance nor the supported-path acceptance contract.
    • Symphonia is the strongest single Rust technical candidate found for WAV/MP3/FLAC/AAC/MP4 coverage, but its MPL-2.0 license is explicitly review-class under the current organization SBOM/license control plane. It must not be silently treated as approved.
    • Dropping M4A/AAC would simplify a permissive pure-Rust decoder set but is a buyer-visible format regression and needs an explicit product decision.
    • The default engineering route that avoids a new reciprocal-code dependency is a dedicated Resource Admission & Decode Rust port using Windows Media Foundation and macOS AVFoundation on the product's mandatory Windows/macOS targets, exposed to Python only through a bounded typed adapter. Keep DSP/math ownership separate from the existing bandscope_numeric crate. This route still requires exact SDK/binding provenance and real Windows/macOS decode parity/resource evidence before licensing: replace bundled libsndfile LGPL runtime path #1129 can close.

    Acceptance for #985/#1129 must remove libsndfile from the actual lock/build/package/SBOM/release graph, route metadata probe and PCM decode through the same admitted decoder authority, preserve WAV/MP3/FLAC/M4A behavior unless the product owner explicitly changes the format contract, and exercise rights-safe real fixtures on mandatory Windows/macOS lanes. No predecessor checks/reviews transfer after that branch changes.

  2. seonghobae
    added
    bugSomething isn't working
    priority: highHigh-priority or P1 work
    status: blockedBlocked by conflict, dependency, or required prerequisite
    type: bugDefect or incorrect behavior
    on Sep 2, 2026

  3. seonghobae commented on Sep 2, 2026

    @seonghobae
    seonghobae
    on Sep 2, 2026 – with ChatGPT Codex Connector
    CollaboratorAuthor

    Fresh single-writer reconciliation: live PR state now identifies #866 (fix/audio-resource-policy-781@3a76907dd3df603cc65188fa6d5c97d583f744e4) as the canonical #781 Resource Admission & Decode implementation owner. #985 remains Draft preservation/reference work because its compressed-container M4A fallback and alternate error contract still contain unique behavior not yet transferred; it is not a second canonical writer and must not be closed until that behavior is reconstructed or explicitly retired with product/security evidence. Apply #1129’s libsndfile-removal work to #866/current semantic successor, preserving #985’s valid requirements without copying its path/subprocess authority blindly. The earlier comment naming #985 as canonical is therefore stale ownership metadata, not current implementation authority. No checks/reviews/approvals transfer between #985 and #866.

  4. seonghobae commented on Sep 3, 2026

    @seonghobae
    seonghobae
    on Sep 3, 2026 – with ChatGPT Codex Connector
    CollaboratorAuthor

    Fresh #1129 decoder-candidate triage, against canonical #866 exact head c5cc94feda19f8c75504abab9731717963309932 and live protected develop@acdbea6344fe1231c39535b575f4de35e4c607c9:

    The implementation boundary is still unresolved, but the candidate set is now narrower and materially different from the earlier platform-API-only recommendation.

    • Symphonia remains the mature single-stack technical candidate. Its upstream README currently lists AAC-LC, MP3, FLAC, OGG/Vorbis, WAV and ISO/MP4 demux/decoding support and explicitly licenses the project under MPL-2.0: https://github.com/pdeljanov/Symphonia . This preserves the current compressed-format product surface much better than a narrow WAV/FLAC-only replacement, but MPL-2.0 is not within licensing: replace bundled libsndfile LGPL runtime path #1129's current preferred MIT/Apache/BSD-class default. It therefore requires an explicit organization license-policy decision before adoption; do not treat technical fit as license approval.
    • RustAudio/audrey is cleanly dual MIT/Apache-2.0 and pure Rust, but upstream supports only FLAC, Ogg Vorbis, WAV and ALAC-in-CAF: https://github.com/RustAudio/audrey . It cannot preserve BandScope's current .mp3, .m4a/AAC, .aac and .opus-adjacent intake contract by itself, so adopting it alone would be a buyer-visible format regression rather than a transparent licensing: replace bundled libsndfile LGPL runtime path #1129 repair.
    • OxideAV is now a credible permissive-license candidate worth an executable spike: the organization states every crate is MIT, pure Rust/no C codec libraries for the software path, with MP4 plus AAC/MP3/FLAC/Vorbis/Opus coverage: https://github.com/OxideAV . However its own current workspace status marks Vorbis decode at about 86% and Opus decode at about 95%, and the Opus crate explicitly says its clean-room rebuild is still in progress. Those are release-readiness risks, not cosmetic gaps. Do not replace libsndfile with an immature stack and call commercial parity complete merely because the license is permissive.

    Decision consequence: there is currently no evidenced option that is simultaneously (a) already organization-approved under the preferred permissive-license policy, (b) mature across the full advertised compressed-format surface, and (c) ready to replace the current soundfile/librosa graph without real-audio/platform qualification. #1129 should therefore remain blocked on one explicit product/license decision, while engineering can prepare evidence without changing the supported-format contract:

    1. approve MPL-2.0 Symphonia for this bounded decoder component and then prove full real-audio parity/resources on Windows/macOS; or
    2. approve a BandScope-owned OxideAV qualification/hardening path, with no release claim until rights-cleared WAV/FLAC/MP3/AAC/M4A/Ogg/Opus fixtures, malformed/resource cases, fuzz/corpus evidence and Windows/macOS package/SBOM prove the exact subset; or
    3. deliberately reduce the supported-format contract to a permissive mature subset, which is a buyer-visible product decision and must update intake UI/docs/tests before implementation.

    Until one of those decisions is accepted, keep #866 as the single Resource Admission & Decode owner, keep #985 open as preservation evidence for the unsuperseded M4A behavior, and do not add a new decoder micro-PR. A technical spike must live in the canonical owner/successor, remain Draft, and must not remove soundfile/librosa or alter public format claims until the replacement proves exact lock/build/package/SBOM absence of libsndfile plus real decoded-audio parity.

  5. seonghobae commented on Sep 7, 2026

    @seonghobae
    seonghobae
    on Sep 7, 2026 – with ChatGPT Codex Connector
    CollaboratorAuthor

    Fresh commercial decoder gate on 2026-09-07:

    Therefore the commercial blocker is still an explicit product/license choice, not missing implementation effort that should be guessed by the writer: approve bounded MPL-2.0 Symphonia qualification; approve an OxideAV hardening/qualification path without release claims until real-audio/platform parity is proven; or explicitly reduce the supported-format contract. Until that decision exists, do not remove soundfile/librosa, alter advertised formats, or create a parallel decoder PR. Engineering evidence belongs in #866/current successor; #985 stays open only for unsuperseded M4A behavior.

  6. seonghobae commented on Sep 11, 2026

    @seonghobae
    seonghobae
    on Sep 11, 2026 – with ChatGPT Codex Connector
    CollaboratorAuthor

    Fresh commercial-decoder research narrows the preferred technical spike without selecting a license policy on assumption.

    Candidate: OS-native decode backend behind BandScope's existing Resource Admission contract. Keep #866 as descriptor/byte/resource authority, then hand only an already-admitted source to target-specific native decoders; return bounded PCM + source metadata into the Rust-owned deterministic resample/MIR path. Do not let the decoder backend become a second admission authority.

    Primary evidence checked 2026-09-11:

    Why this is preferable to the current fallback: it can remove the bundled libsndfile runtime rather than hide it, keeps decode in-process under OS-owned codec implementations, avoids audioread subprocess/path widening, and supports platform-realistic M4A/AAC. It also preserves the option to keep deterministic resampling, channel policy and MIR calculations in BandScope-owned Rust.

    Required RED/acceptance before adoption:

    1. Build a target-gated NativeAudioDecoder port with Windows Media Foundation and macOS AudioToolbox adapters. The domain port must expose source sample rate/channel count/frame count or duration before transformed PCM becomes authoritative.
    2. Feed it only through fix(audio): establish canonical local-audio resource policy #866's bounded admitted resource; if an OS API forces URL/path opening, document that ACL explicitly and revalidate same-file identity before and after open. No raw renderer-supplied path.
    3. Rights-cleared real fixtures for WAV/MP3/FLAC/M4A-AAC on both Windows and macOS: metadata parity, decoded duration/frame tolerance, channel mapping, finite samples, deterministic post-resample digest/metric tolerance, truncated/corrupt/oversized input, cancellation and cleanup.
    4. Runtime capability probing on Windows must fail closed with a typed unsupported-codec result rather than silently fetching/installing codecs. No network codec acquisition.
    5. Remove soundfile/libsndfile from pyproject/lock/build/package/SBOM and prove absence in packaged Windows/macOS artifacts. Keep feat(analysis): enforce one canonical audio resource policy (#781) #985 open until the M4A preservation requirement is demonstrated by this successor or the product format contract is explicitly changed.
    6. Capture platform minimum-version policy and the legal decision for using OS-provided AAC/MPEG-4 codec APIs. That legal/product policy decision is the remaining external blocker; technical feasibility no longer needs to be treated as wholly unknown.

    This is a candidate architecture/RED contract, not an Accepted ADR and not evidence that the current package is commercially clear.

  7. seonghobae commented on Sep 12, 2026

    @seonghobae
    seonghobae
    on Sep 12, 2026 – with ChatGPT Codex Connector
    CollaboratorAuthor

    Fresh primary-platform research narrows the native replacement candidate without making a licensing/policy acceptance claim.

    Windows / Media Foundation. Microsoft’s current Media Foundation format documentation states that the native MPEG-4 file source handles .m4a, .m4v, .mov, and .mp4, and that the native AAC decoder is available from Windows 7 onward. The dedicated MPEG-4 support page also lists the AAC Decoder and MPEG-4 File Source as in-box Media Foundation components. This makes a Windows Media Foundation adapter a technically credible candidate for advertised M4A/AAC intake without bundling libsndfile, subject to exact byte-stream/resource and packaging tests.

    Primary references:

    macOS / Audio Toolbox. Apple’s current Audio Toolbox API documents first-class kAudioFileM4AType, kAudioFileMPEG4Type, kAudioFileMP3Type, kAudioFileWAVEType, and kAudioFileFLACType file types, plus AAC decoding/encoding APIs. Audio Format Services exposes installed decoder discovery (kAudioFormatProperty_Decoders) and Audio File properties expose file/data format metadata. This makes Audio Toolbox a technically credible macOS candidate for descriptor/stream-oriented metadata admission + decode rather than an external audioread subprocess/path fallback.

    Primary references:

    This evidence does not settle the organization’s legal/inbound-license policy and does not by itself prove BandScope parity. Keep #1129 open. The next implementation/research boundary should compare a thin Rust-owned platform adapter pair (Media Foundation / Audio Toolbox) against the existing #866 contract with the same rights-cleared WAV/MP3/FLAC/M4A corpus: original-container metadata before transform, bounded byte/resource admission, duration/sample-rate/channel limits, deterministic PCM/resample handoff, malformed/truncated container fail-closed behavior, and Windows/macOS package/SBOM evidence. Prefer byte-stream/descriptor APIs where the platform allows them; any unavoidable filesystem path needs the existing app-owned publication/content-identity invariant rather than widening authority. Do not remove soundfile/libsndfile until that RED→GREEN parity and actual package-graph removal are proven.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingpriority: highHigh-priority or P1 workstatus: blockedBlocked by conflict, dependency, or required prerequisitetype: bugDefect or incorrect behavior

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions