Am 19.01.22 um 18:44 schrieb Jonas Smedegaard:
Quoting Stefan Weil (2022-01-19 18:07:28)
As I wrote in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949119#15
autoconf-archive is not needed for building because the two required
files are also provided as part of the Tesseract source tree.
Technically all options a), b) and c) use exactly those two files either
from the Tesseract source tree or from autoconf-archive during the build
process. Nothing of those files is part of the build results which get
installed. So a binary install package does not require a copyright
notice for any of those files.
I don't know the Debian rules for source packages. Do they require an
extra documentation of all copyrights for any file in the source
distribution? The licenses of both files don't demand that.
Thanks for elaborating.
The concern is not licensing, but maintenance. It is covered in Debian
Policy § 4.13:
https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies
Kind regards,
- Jonas
Generally I fully agree that embedding code from other projects is a bad
idea for obvious reasons.
In this case I decided to do it nevertheless.
We are talking of these two files:
% wc m4/ax_*
53 224 2104 m4/ax_check_compile_flag.m4
38 114 1274 m4/ax_split_version.m4
91 338 3378 total
The Debian autoconf-archive is nearly 6 MB. We had used autoconf-archive
since 2016. I removed that dependency in May 2018. Citing my commit message:
Remove autoconf-archive dependency
It creates much confusion and causes many issue reports,
so let us drop this dependency.
The two new files in the m4/ directory are current copies from GitHub
(https://github.com/autoconf-archive/autoconf-archive/).
Although I build a lot of different open source projects, I never missed
autoconf-archive after I had removed it from my build machines. It is
rarely required (= only by the former Tesseract code in my personal
experience) and therefore never preinstalled as far as I know. And
getting it can be really time consuming. Tesseract builds must work on
Linux / macOS / Windows in different variations, also on hosts where the
user has no root permission for installation of additional packages. The
FSF has machines in its build farm which not even have access to GitHub
to get a local copy of autoconf-archive.
As both files are rather small, simple and only used by configure, there
are no related security risks, and maintenance is rarely needed. And I
simply don't want to reinvent the wheel for checking compile flags or
splitting the version string because that's also no good alternative.
Regards
Stefan
