far2l
far2l copied to clipboard
elfmz
licensing / debian packaging #977790
lintian complains about this file:
utils/src/ConvertUTF.c
details: https://lintian.debian.org/tags/license-problem-convert-utf-code.html
anything you want to do about that?
i also get these:
E: far2l: embedded-library usr/lib/far2l/Plugins/colorer/plug/colorer.far-plug-wide: zlib
N: The given ELF object appears to have been statically linked to a
N: library. Doing this is strongly discouraged due to the extra work needed
N: by the security team to fix all the extra embedded copies or trigger the
N: package rebuilds, as appropriate.
N:
N: If the package uses a modified version of the given library it is highly
N: recommended to coordinate with the library's maintainer to include the
N: changes on the system version of the library.
N:
N: Refer to Debian Policy Manual section 4.13 (Convenience copies of code)
N: for details.
N:
N: Severity: error
N:
N: Check: binaries
E: far2l: embedded-library usr/lib/far2l/Plugins/multiarc/plug/multiarc.far-plug-mb: pcre3
E: far2l source: license-problem-convert-utf-code utils/src/ConvertUTF.c (above description)
E: far2l: possible-gpl-code-linked-with-openssl
N: This package appears to be covered by the GNU GPL but depends on the
N: OpenSSL libssl package and does not mention a license exemption or
N: exception for OpenSSL in its copyright file. The GPL (including version
N: 3) is incompatible with some terms of the OpenSSL license, and therefore
N: Debian does not allow GPL-licensed code linked with OpenSSL libraries
N: unless there is a license exception explicitly permitting this.
N:
N: If only the Debian packaging, or some other part of the package not
N: linked with OpenSSL, is covered by the GNU GPL, please add a Lintian
N: override for this tag. Lintian currently has no good way of
N: distinguishing between that case and problematic packages.
N:
N: Severity: error
N:
N: Check: debian/copyright
also these:
I: far2l: spelling-error-in-binary usr/bin/far2l Nam Name
I: far2l: spelling-error-in-binary usr/bin/far2l wihout without
I: far2l: spelling-error-in-binary usr/lib/far2l/Plugins/NetRocks/plug/NetRocks-FTP.broker responce response
I: far2l: spelling-error-in-binary usr/lib/far2l/Plugins/NetRocks/plug/NetRocks-SFTP.broker authentification authentication
I: far2l: spelling-error-in-binary usr/lib/far2l/Plugins/colorer/plug/colorer.far-plug-wide Qoute Quote
I: far2l: spelling-error-in-manpage usr/share/man/man1/far2l.1.gz "Allows to" "Allows one to"
License of ConvertUTF.cpp is on top of that file https://github.com/elfmz/far2l/blob/master/utils/src/ConvertUTF.c and its fully compatible with GPL: https://en.wikipedia.org/wiki/University_of_Illinois/NCSA_Open_Source_License
regarding embedded zip library - its obviously need to be converted to be not statically linked-in and its not something unknown, however colorer by itself requires deep refactoring to be updated to recent DB that caused posponing all suchproblems
Regarding openssl problem - its unclear for me what should i do to resolve that? i found that link https://people.gnome.org/~markmc/openssl-and-the-gpl and there suggested following:
One recommended way around this GPL incompatibility is to add an OpenSSL exemption when you license your code under the GPL. See this mail from debian-legal to a developer which suggests the following wording for the exemption:
- In addition, as a special exception, the copyright holders give
- permission to link the code of portions of this program with the
- OpenSSL library under certain conditions as described in each
- individual source file, and distribute linked combinations
- including the two.
- You must obey the GNU General Public License in all respects
- for all of the code used other than OpenSSL. If you modify
- file(s) with this exception, you may extend this exception to your
- version of the file(s), but you are not obligated to do so. If you
- do not wish to do so, delete this exception statement from your
- version. If you delete this exception statement from all source
- files in the program, then also delete it here.
so i should just copy above into end of LICENSE.txt and that will resolve issue?
Ура, все используемые far2l общеизвестные либы теперь динамически линкуются? :)
Ну, кроме UCD, который, как я понял, используется для угадывания кодировки файлов, и для которого, похоже, нет распространенных готовых пакетов. А, хм, вижу в multiarc'е кусочки p7zip и unrar ещё.
Added required paragraph to license by commit https://github.com/elfmz/far2l/commit/b4b94ea7fa0ab80412ffdbe74335839554aba16d However have to acknowledge all contributors about this, if someone need to tell something against this change, please speak now (so in this case likely will need to revert this change and will think how to get rid of OpenSSL), or forever hold your peace :) @svost @invy @lieff @techtonik @sxored @anteo @singalen @Alter-1 @m32 @unxed @russiandesman @yurikoles @rampitec @randolf @cycleg @dstogov @thinkingerrol @ZOleg73 @dvlom @iliakonnov @akozlins @MikeMirzayanov @j2969719 @corporateshark @michaellukashov @vodek3 @igorklopov @sev- @pg83 @miotio @Gravityzwell @colier @itspec-ru @hypersw @vasilievip @developerxyzw @Devoter @tsunamaru @movsw @trexinc @denis-adamchuk
OpenSSL is a good stuff that keeps internets secure, so I no objections from my side.
only problem left is convertutf, which can be fixed with a later version/updated license too: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864729#26
current state: https://mentors.debian.net/package/far2l/
(once that last thing above is fixed, it can be in debian and ubuntu, and people can just run apt install far2l)
only problem left is convertutf
@elfmz can't we just implement wrappers around WinPort charset conversion routines as replacement?
There're C++-own features: https://www.inf.pucrs.br/~flash/lapro2ec/cppreference/w/cpp/locale/wstring_convert.html Some problem that in few cases need to use CalcSpaceUTF* functions (added by me) that don't do conversions but just calculate needed space to hold result, so performance may be degraded in that cases. And in overall need to estimate performance of native C++ convertions against this code. If it will be good then there will be no problems to get rid of this code, otherwise may consider to re-implement it or borrow some another code/library equally fast. Another question is how it behaves on semi-broken sequences
WinPort's functions already behave relatively fast (at least, comparing to iconv), support semi-broken sequences well (AFAIK) and support space calculation also. Why not just use them?
cuz its able to convert to/from UTF16 (as Windows has) but not UTF32 (as *nix have). For supported by it codepages UTF16 codepoints are UCS-2 and directly mapped into UCS-4 thus its wchars can be just typecasted into native ones. But its not so for some other sequences, and better to have UTF8<->UTF32 convertion without surprises.
Does the rest of far2l code already work fine with UTF-32 and 4-byte characters so it make sense to worry about it right now? ;-)
Btw, what about this version? Is it licence-compatible with Debian? @alexmyczko https://github.com/bro/bro/blob/master/src/ConvertUTF.c
Can we just use it as replacement?
and to make copies of this file in any form for internal or external distribution as long as this notice remains attached
Another possible replacement: https://github.com/silnrsi/teckit/commit/3e24aa054f51fcdbbcb3adff77d7640d247456b7
I tend to use native C++ abilities if they will show good enough performance. Lets wait for some results likely at weekend.
https://github.com/bro/bro/blob/master/src/ConvertUTF.c
I think so. IANAL.
an this link i was given some time ago: https://web.archive.org/web/20160207060203/https://bugs.chromium.org/p/google-breakpad/issues/detail?id=270
Updated to
https://github.com/bro/bro/blob/master/src/ConvertUTF.c
just for fun
Builds and runs ok.
Make far2l Debian-compatible with one mouse click: https://github.com/elfmz/far2l/pull/1060
:)