On 2026-03-17 09:00, Mario Limonciello wrote:
Hi Mario,
This is meant as an intent-to-reject, see https://dfsg-new-
queue.debian.org/reviews/lemonade <https://dfsg-new-queue.debian.org/
reviews/lemonade> for the full conversation. I'm writing this mail in
the interest of transparency and engage in a more visible conversation
about this package.
Thank you, this has been a long road to /try/ to get this package in
good shape, including a lot of work upstream.
That's awesome to hear!
I believe the lemonade package is currently UNACCEPTABLE for inclusion
in any section of the Debian archive (main, contrib, or non-free).>
1. Runtime Download of Executable Binaries
The most critical blocker is the implementation of the "Backend
Manager" in src/cpp/server/backends/backend_utils.cpp. The software
contains logic to automatically download, extract, and execute
pre-compiled binaries from GitHub (specifically from
github.com/ggml-org/ <http:// github.com/ggml-org/> and
github.com/lemonade-sdk/ <http://github.com/ lemonade-sdk/>).
Policy Violation: Debian requires all software to be built from source
within the Debian infrastructure to ensure auditability and security.
Security Risk: The BackendUtils::install_from_github function fetches
executables (llama-server, whisper-server, etc.) at runtime. This
bypasses APT, prevents security patching by the Debian Security Team,
and introduces a significant attack vector (remote execution of
untrusted third-party binaries).
I will note I have worked out a 'system' llama-server backend
implementation upstream that will use llama.cpp from apt. It's one
possible source. The new fastflowlm backend will ONLY use system
provided binaries.
I plan to do the same for whisper and stable diffusion, but will need
more ITPs along the way. I wanted to prove it can work with llama.cpp
first.
This will take some time though to work out upstream and get those ITPs
in shape, so I want to ask what can be acceptable in the short term
knowing that's the north star?
Would a patch to disable all download functionality be good in your
mind for now? It will limit lemonade's usability (It would pretty much
only work with llama.cpp and FLM if installed), but it will then
improve with time as I do a system backend implementation for other
backends upstream.
I think that would address the concern I raised. This way, no
precompiled binaries are downloaded, and no (additional) burden is
placed on teams such as the security team.
2. Copyright and Licensing Failures
The debian/copyright file is incomplete and contains factual
inaccuracies:
License Incompatibility and Mislabeling: The file
src/cpp/include/lemon/ amdxdna_accel.h is licensed under GPL-2.0 WITH
Linux-syscall-note, but debian/copyright incorrectly labels it (via a
wildcard) as Apache-2.0. Apache-2.0 is generally considered
incompatible with GPL-2.0. While the Linux-syscall-note exception is
designed to allow linking with userspace, misrepresenting the license
of a core header file is a critical failure in the copyright review
process.
Are you sure? I did add this:
Files: src/cpp/include/lemon/amdxdna_accel.h
Copyright: 2022-2024, Advanced Micro Devices, Inc.
License: GPL-2.0
You are correct, I must have overlooked this. It seems to me that you
are claiming that the syscall exception allows this header to be used by
MIT/Apache 2.0 code. The package needs to clearly spell out the syscall
exception. Right now, debian/copyright doesn't even mention this
exception. I need to ask you to clarify Debian/copyright to be clear on
the licensing implications here.
Missing Attributions: The vendored ixwebsocket library (included in
debian/ixwebsocket) contains code from numerous authors not listed in
debian/copyright (e.g., Alex Hultman, Bjoern Hoehrmann, Salvatore
Sanfilippo).
I will double check the authors on this. Actually for the next version
I'm pushing upstream to switch to libwebsockets (which is packaged for
Debian already).
yeah. that sounds like an excellent idea.
Inaccurate Claims: debian/copyright attributes IXBase64.h to Machine
Zone, Inc., but the file header clearly states Copyright (c) 2016
tomykaira.
Wildcard Over-reach: The Files: * declaration claiming Apache-2.0 for
the entire tree is invalidated by the presence of GPL-2.0, MIT, ISC,
and BSD-3-Clause files throughout the src/ and debian/ directories
that are not properly scoped.
Hmm, I do have clauses for all of files that didn't match and had an
explicit license. The NOTICE.md (upstream's LICENSE) and package.json
(upstream's list of packages needed to build the web-app) didn't have
epxlicit licenses.
Without an explicit license, I'm afraid that we have to consider those
file non-distributable.
3. Missing Source for Generated Files (DFSG 2)
The source tarball contains several Windows-specific bitmap files used
for installers:
src/cpp/installer/installer_banner_wix.bmp
src/cpp/installer/top_banner.bmp
These files are provided without their "preferred form for
modification" (e.g., GIMP/Photoshop source files or SVG templates).
Under DFSG 2, every component of the source package must include its
source code. These are currently "sourceless blobs.".
It's unfortunate these were missed before by you and me in previous
reviews. I'll repack in the future to exclude them.
Thanks, that completely avoids the problem.
-rt
