The "COPYING" file in espeak-ng is GPLv3 [2007] yet espeak-ng also includes a slew of other copyrights in the files COPYING.*: COPYING.APACHE COPYING.BSD2 COPYING.IEEE COPYING.UCD Some of these are listed in the licenses for the package: LICENSE="GPL-3+ Turkowski unicode" GPL-3+ -> COPYING Turkowski -> COPYING.IEEE (identical text) unicode -> COPYING.UCD (maybe) COPYING and COPYING.IEEE cover all the files, COPYING.UCD specifically includes only certain files. COPYING.APACHE and COPYING.BSD2 also cover all the files but are not required by Gentoo. Examining the source code suggests that Ken Turkowski only worked on two of the files: ./COPYING.IEEE:Ken Turkowski ./src/libespeak-ng/ieee80.c: * Implemented by Malcolm Slaney and Ken Turkowski. ./src/libespeak-ng/ieee80.c: * In 1991, Ken Turkowski implemented the conversions to and from ./src/libespeak-ng/ieee80.h: * Implemented by Malcolm Slaney and Ken Turkowski. ./src/libespeak-ng/ieee80.h: * In 1991, Ken Turkowski implemented the conversions to and from And those two files are Copyright Apple and have a completely different license: * This code may be used and freely distributed as long as it includes * this copyright notice and the above warranty information. Upstream Dunn might care to comment, but at this point there is no way in a million years I would accept the Turkowski copyright, despite, or maybe in this serious world, because of the humour. This may need an upstream fix; Dunn apparently attempted to convey the copyright of all the source code to Turkowski. The bug is a blocker, of a sort, but I left it normal because I have my own fork of espeak-ng so I have to disable espeak-ng builds anyway.
Hey Licenses team, can you give me some input on this -- should I have the Turkouski license listed? Thanks, William
COPYING.IEEE (aka Turkowski) says: "The source code available from this page may be freely downloaded and used in any applications for any purpose, as long as the code is used in its entirety and the copyright notice and warranty information is retained." This doesn't grant the right to modify the source code or to distribute modified versions, so it isn't open source by the usual definition. Strictly speaking, it doesn't even give us the right to redistribute and the ebuild would need to be mirror restricted. (In reply to John Bowler from comment #0) > And those two files are Copyright Apple and have a completely different > license: > > * This code may be used and freely distributed as long as it includes > * this copyright notice and the above warranty information. This at least would allow distribution. Still, it is a non-free license because modification is not allowed. I haven't checked what files are being linked with each other, but it may well be that the resulting binary cannot be distributed (because GPL licensed code is linked to non-free code). (In reply to William Hubbs from comment #1) > can you give me some input on this -- should I have the Turkouski > license listed? The ebuild reflects upstream's README.md and COPYING* files, so in that sense its LICENSE variable is correct. For the time being, I wouldn't add a mirror restriction either, because the Apple notice in the files allows redistribution. However, there clearly is an inconsistency which should be sorted out upstream. Their claim in README.md that it is "open source software" doesn't seem to be correct, because the ieee80.c code is non-free (both under the Turkowski and under the Apple license notice). I've also found two previous discussions about this (but I don't necessarily agree with their conclusion): Debian discussion: https://lists.debian.org/debian-accessibility/2016/09/msg00123.html Fedora discussion: https://www.spinics.net/linux/fedora/fedora-legal/msg02876.html Disclaimer: IANAL, TINLA
I don't think the code is actually used. The two files in question: src/libespeak-ng/ieee80.{c,h} are used in exactly one place, src/libespeak-ng/spect.c, and that only calls one very simply routine to read an old Motorola 10 byte floating point format. Tracing up this is used for "spect" file reading; apparently an audio file format. These files have the magic number "SPEC" and there are no such files in the source tree. In fact the code is, in turn, only used from the file "compiledata.c" and if I remember the code correctly (it's almost a year since I hacked at it last) the code in question is only used when building espeak-ng data files. For most uses this means it is build time only and, given that there are no such files in the source tree, that means it isn't used.
What matters is that the code in question is included in libespeak-ng.so and gets installed: $ nm /tmp/portage/app-accessibility/espeak-ng-1.50-r1/image/usr/lib64/libespeak-ng.so.1.1.49 | grep Ieee 0000000000028c80 t ConvertFromIeeeDouble 0000000000028f60 t ConvertFromIeeeExtended 0000000000028ae0 t ConvertFromIeeeSingle 0000000000028d80 t ConvertToIeeeDouble 0000000000029030 t ConvertToIeeeExtended 0000000000028b60 t ConvertToIeeeSingle
Reported upstream: https://github.com/espeak-ng/espeak-ng/issues/1072
(In reply to Ulrich Müller from comment #4) > What matters is that the code in question is included in libespeak-ng.so and > gets installed: > > $ nm > /tmp/portage/app-accessibility/espeak-ng-1.50-r1/image/usr/lib64/libespeak- > ng.so.1.1.49 | grep Ieee > 0000000000028c80 t ConvertFromIeeeDouble > 0000000000028f60 t ConvertFromIeeeExtended > 0000000000028ae0 t ConvertFromIeeeSingle > 0000000000028d80 t ConvertToIeeeDouble > 0000000000029030 t ConvertToIeeeExtended > 0000000000028b60 t ConvertToIeeeSingle Indeed. The point I was trying to make is that it's 37 lines of uncommented code that is 100% obvious and it is only required to support a moribund file format that I can find no documentation of on the Internet, not that I can find anything there these days. I'm tempted to provide a better unmarshalling function that would meet the needs of people who have to deal with data of this form. I'm not happy about converting NaNs to infinity, but there might be some way of persuading ldexp to generate a NaN in portable ANSI-C and converting to 0 seems safer to me than converting to inf.
I have submitted a pull request upstream: https://github.com/espeak-ng/espeak-ng/pull/1076
(In reply to Ulrich Müller from comment #7) > I have submitted a pull request upstream: > https://github.com/espeak-ng/espeak-ng/pull/1076 Merged upstream: https://github.com/espeak-ng/espeak-ng/commit/c7eb52fe14042126800083ed8a5609de88f1469f https://github.com/espeak-ng/espeak-ng/commit/889092c9d65a0604fcc14c2c8e1e04ff4b0c5a6c
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cdf457479fbe36c9045bf87c7028d0c187d3c910 commit cdf457479fbe36c9045bf87c7028d0c187d3c910 Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2022-02-11 09:08:31 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2022-02-11 09:09:15 +0000 app-accessibility/espeak-ng: Update LICENSE of live ebuild Bug: https://bugs.gentoo.org/832778 Package-Manager: Portage-3.0.30, Repoman-3.0.3 Signed-off-by: Ulrich Müller <ulm@gentoo.org> app-accessibility/espeak-ng/espeak-ng-9999.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Created attachment 764865 [details, diff] app-accessibility/espeak-ng: Replace non-free ieee80.c code
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b90a50fab78c1e2bacaeabd1d2ba4cd9be104dc7 commit b90a50fab78c1e2bacaeabd1d2ba4cd9be104dc7 Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2022-02-11 22:19:01 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2022-02-11 22:24:08 +0000 app-accessibility/espeak-ng: Replace non-free ieee80.c code Patch has been accepted upstream. Acked-by: William Hubbs <williamh@gentoo.org> Closes: https://bugs.gentoo.org/832778 Package-Manager: Portage-3.0.30, Repoman-3.0.3 Signed-off-by: Ulrich Müller <ulm@gentoo.org> app-accessibility/espeak-ng/Manifest | 1 + .../espeak-ng/espeak-ng-1.50-r2.ebuild | 85 ++++++++++++++++++++++ 2 files changed, 86 insertions(+)
