This is an automated message from the Debian DFSG, Licensing & New Packages Team.
The Debian NEW review of mozc 3.33.6133+ds1-0.1 has been completed. Decision: ACCEPTED Reviewer: Andrew McMillan Review comment: Hi, Package is accepted, but a number of issues were found during the review which you mway want to fix for your next upload. 1. [important] [licensing] Standalone BSD-3-Clause paragraph is the NAIST/IpaDic text, not Google's; the real dictionary license paragraph is orphaned - Files: `debian/copyright (License: BSD-3-Clause; Files: src/data/dictionary_oss/*; License: BSD-3-Clause-with-ICOT-term)` - Evidence: `3. The name Nara Institute of Science and Technology may not be used to endorse or promote products derived from this software without specific prior written permission.` and `THIS SOFTWARE IS PROVIDED BY Nara Institute of Science and Technology ``AS IS''`; the actual license in `src/data/dictionary_oss/README.txt` is `Use, reproduction, and distribution of this software is permitted. ... A large portion of the dictionary entries originate from ICOT Free Software.` - Problem: The `License: BSD-3-Clause` paragraph binds `Files: *` (the whole Google codebase) to a NAIST-flavoured text naming NAIST as the disclaiming party, which misdescribes Google's actual BSD-3-Clause (root LICENSE uses the Google Inc. name clause). Conversely the dictionary files in `src/data/dictionary_oss/*` are actually licensed under the ICOT/NAIST text, which is reproduced in full only in the `License: BSD-3-Clause-with-ICOT-term` paragraph that no `Files:` stanza references, so that paragraph is dead weight and the dictionary files point at the wrong licence text. - Fix: Point `Files: src/data/dictionary_oss/*` at `License: BSD-3-Clause-with-ICOT-term`, and restore the plain Google `BSD-3-Clause` text (matching the root LICENSE) in the standalone `License: BSD-3-Clause` paragraph used by `Files: *`. 2. [important] [licensing] fcitx5 component: upstream GPL-2.0+ declaration (metainfo) and translations are not covered; Weng Xuetian not credited on the BSD fcitx5 sources - Files: `src/unix/fcitx5/org.fcitx.Fcitx5.Addon.Mozc.metainfo.xml.in:6`, `src/unix/fcitx5/po/*.po`, `src/unix/fcitx5/*.cc,*.h`, `debian/copyright` - Evidence: `<project_license>GPL-2.0+</project_license>`; po headers `This file is distributed under the same license as the fcitx5-mozc package.`; source headers such as `Copyright 2023-2023, Weng Xuetian <[email protected]> ... Redistribution and use in source and binary forms ...` - Problem: The metainfo installed in fcitx5-mozc and the `.po`/generated `.mo` translations declare the fcitx5-mozc addon as GPL-2.0+ (the translations are “same license as the fcitx5-mozc package”), but debian/copyright provides no GPL-2+ coverage at all: the fcitx5 sources fall under `Files: *` (BSD-3-Clause, Google) plus the four named LGPL-2+ CSSlayer files. The many fcitx5 `.cc/.h` files authored by Weng Xuetian under BSD-3-Clause are likewise attributed only to Google Inc. by the catch-all. The file's own licence declarations are therefore not accurately described. - Fix: Add a `Files:` stanza for the fcitx5 metainfo and `po/*` with the licence that actually applies (GPL-2+ if that is the fcitx5-mozc package licence, with a GPL-2+ License paragraph), and name Weng Xuetian as copyright holder on the BSD-3-Clause fcitx5 sources (or extend the 0001 patch stanza intent to the produced files). 3. [minor] [licensing] fcitx-artwork icons: marguerite's derived-work copyright not represented - Files: `mozc/source/*.svg` - Evidence: Upstream fcitx-artwork `mozc/README.md`: `Original Work Copyright 2010-2018, Google Inc. Derived Work Copyright 2013-2014 marguerite <[email protected]>` (BSD-3-Clause). - Problem: These SVGs (added by 0002-fcitx-artwork.patch) are BSD-3-Clause but the derived-work author is not named anywhere in debian/copyright; they are silently covered by `Files: *` as Google-only. - Fix: Add a `Files: mozc/source/*` stanza crediting marguerite (and Google) under BSD-3-Clause. 4. [minor] [licensing] material-design-icons sources are Apache-2.0 but attributed as BSD-3-Clause - Files: `src/third_party/material_icon_*/file/*.svg`, `src/third_party/material_icon_*/file/*.png`, `debian/copyright` - Evidence: 0007-Add-material-icons.patch header: `Author: Copyright (c) 2020, Google LLC`, `Origin: google/material-design-icons v4.0.0`, licensed Apache-2.0. - Problem: The icons added by 0007 (and the PNGs generated from them at build time and installed into mozc-data) are Apache-2.0, but they match the `Files: *` BSD-3-Clause stanza; the `License: Apache-2.0` paragraph is referenced only by the `Files: debian/patches/0007-Add-material-icons.patch` stanza. - Fix: Add `Files: src/third_party/material_icon_*/file/*` with `License: Apache-2.0`. 5. [minor] [licensing] Public-domain and non-Google test data are attributed to Google by the catch-all stanza - Files: `src/data/test/stress_test/sentences.txt`, `src/data/test/dictionary/*`, `src/data/dictionary_oss/*` - Evidence: sentences.txt: `the copyright of the original document is already expired`; dictionary_oss/README.txt: `Public Domain Dataです。使用・変更・配布に関しては一切の制限をつけません。` - Problem: These Aozora (public domain), IpaDic/ICOT and Okinawa data files are described only by `Files: *` as Google BSD-3-Clause; the attribution is inaccurate even though the licences are free. - Fix: Add Files stanzas covering `src/data/test/stress_test/*`, `src/data/test/dictionary/*` and the Okinawa portions on their own terms (public domain / ICOT). 6. [minor] [packaging] Stale debian/libmozc-protocol.install with no matching binary package - Files: `debian/libmozc-protocol.install`, `debian/control` - Evidence: `src/bazel-bin/ipc/libmozc_ipc_pb.so usr/lib/${DEB_HOST_MULTIARCH}/mozc/` and `src/bazel-bin/protocol/libmozc_protocol_pb.so ...`; there is no `Package: libmozc-protocol` stanza in `debian/control` (the dsc Package-List confirms no such binary), and no build target produces those `.so` files. - Problem: The package was added in the ~exp4 changelog and later dropped together with uim-mozc, but the install file was left behind. It is dead weight that confuses where the private shared libraries ended up; it does not break the build because nothing references those targets. - Fix: Delete `debian/libmozc-protocol.install` (nothing installs the private `.so` any more) or reintroduce/relink the package if the shared libraries are actually needed. 7. [minor] [packaging] debian/tests/hardening autopkgtest is broken (unset binaries array) - Files: `debian/tests/hardening`, `debian/tests/linkage`, `debian/tests/helper` - Evidence: hardening: `for binary in "${binaries[@]}"; do` but the `binaries` array is defined only in `debian/tests/linkage`, and `debian/tests/helper` only defines functions. - Problem: Run with `set -eu`, `${binaries[@]}` is an unbound variable, so the hardening autopkgtest aborts with a shell error instead of checking the hardenability of the installed binaries. - Fix: Move the `binaries` array into `debian/tests/helper` (or declare it in `debian/tests/hardening`). Thanks! Full review details: https://dfsg-new-queue.debian.org/reviews/mozc
