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 totalThe 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