replxx
replxx copied to clipboard
AmokHuginnsson
ConvertUTF.{cpp,h} are non-free
The ConvertUTF.{cpp,h} are non-free (and buggy/unmaintained), as discussed on the Debian mailing list:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823100
This poses problems for packaging/redistribution. Would it be possible to, perhaps, support linking with libicu for this purpose?
We're currently using linenoise-ng in Nix, and this is same issue is blocking an effort to package Nix for Debian. replxx looks nice, and if we could get this issue resolved here, it's possible we'd switch away from linenoise-ng.
Thanks!
I am quite open to use alternative to ConvertUTF.{cpp,h}, it can be ICU or some other conversion library, as long as the choice of the conversion library is preserved for users (and preferable handled by cmake). What I mean is that I would like for the users to still use ConvertUTF.{cpp,h} if they prefer to. That would mean abstracting out conversion interface. I will happily accept pull request implementing this change having all conversion backends working, I mean both ICU and ConvertUTF.{cpp,h}. Debian people could simply ignore ConvertUTF.{cpp,h} files and use ICU for their build. I still want to have ConvertUTF.{cpp,h} available for MSVCXX users sake as bringing ICU as hard dependency could significantly increase MSVCXX build difficulty.
We @arangodb have similar opinions on that. If you propose a patch to replace this by ICU (which is already one of the other arangodb dependencies) we could drop ConvertUTF.{CPP,}. However, we currently don't have the time to work on this.
If Debian is correct, and this code isn't open source, then I'll need to fix the problem before I can use replxx in my open source project. However, I notice that LLVM contains the same source file, and Debian contains an LLVM package.
I used apt-get source llvm-6.0-dev to get the latest version of the Debian source package for LLVM. The file lib/Support/ConvertUTF.cpp in LLVM is recognizably the same code, with the same original licence text. One difference is that the LLVM version of ConvertUTF.cpp has the LLVM licence pasted at the top of the file, before the Unicode licence.
So maybe this isn't actually a problem. Or maybe Debian can be made happy by copying the LLVM version of ConvertUTF.cpp, even though it's really the same code with the same licence. I doubt that there is any actual legal risk of "Unicode, Inc" suing users of replxx for licence violation. Why wouldn't they go after bigger targets like LLVM or Apple first?
@doug-moen Hello, thank you for taking interest in replxx.
I am not a lawyer. I could use llvm's version of ConvertUTF.{cpp,h} if some Debian maintainer confirmed that is would be sufficient. Using libicu is another option.
Unfortunatelly right now I do not have the time to take care of it. Fixing how special keys are handled (#6) is higher on my TODO list anyway.
Okay, thanks. I was trying to figure out if there is actually an issue that needs to be fixed. I'd volunteer to fix it myself if there was an actual problem. However, I wouldn't consider LLVM non-free or refuse to link to it due to its use of ConvertUTF, and for consistency I should treat replxx the same way.
So I decided there's no issue, and I'm now using replxx in my project, replacing GNU readline. Thanks for making the project.
Hi! I can suggest switch to utf8cpp library - It has native C++ API, and free license.
BTW, i had replaced ConvertUTF by utf8cpp in my projects. It works fine :)
@LoganDark replxx is C++ library, so actually it seems - normal: add C++ library instead of plain C library
Hi here,
As said @olegator77, utf8cpp library seems a good candidate. taglib project has encounter the same issue with ConvertUTF.{ccp,h} (see taglib/taglib#793) and has migrated to utf8cpp lib (see this pull-request: taglib/taglib#794)
Confirmation that this issue blocks inclusion to Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=2017179#c8
Suggestion to use code used by LLVM project, which has acceptable license:
https://github.com/AmokHuginnsson/replxx/issues/125#issuecomment-971127703
From https://bugzilla.redhat.com/show_bug.cgi?id=2017179#c9
--- Comment #9 from Zbigniew Jędrzejewski-Szmek [email protected] --- %{_libdir}/.so.
Please specify the SO VERSION here, don't use a glob. See https://docs.fedoraproject.org/en-US/packaging-guidelines/#_listing_shared_library_files
I don't think Unicode Strict can be accepted into Fedora, though. So we will have to wait on that issue. I have subscribed as well.
After looking at the original file, the license is problematic. The proposed solution of using the file in LLVM does not be a solution: I think LLVM is in "violation" of the literal license terms too, and they should not say that this file is available under the Apache2 license. I used quotes because it seems that the actual legal risk is negligible. Nevertheless, we want to keep everything kosher in Fedora, so we don't want to accept this minor violation.
utf8cpp seems like a better approach. [1] does a similar conversion, and it seems very straightforward. utf8cpp is in Fedora, so we'd want to just use the system library.
Note that this license was briefly discussed on legal@, but the question was sidestepped because the files weren't actually used [2].
[1] https://github.com/taglib/taglib/pull/794/files [2] https://lists.fedoraproject.org/archives/list/[email protected]/thread/KQEAGD4UCDRO2X5P4WYOOT5FUFWXJ4NP/#KQEAGD4UCDRO2X5P4WYOOT5FUFWXJ4NP
I created a Ubuntu PPA to build a 'libreplxx-dev' package (sudo apt install libreplxx-dev) and encountered this licensing issue. The debuild tool runs lintian on source packages and throws an error "E: replxx source: license-problem-convert-utf-code".
To address this I made patches that adopt the ConvertUTF.h and ConvertUTF.cpp files from the llvm-project commit 20451cb (https://github.com/llvm/llvm-project/commit/20451cb06b01167ff4614862736ca65bbfe46dfc) which have an updated license as described in previous comments.
Ubuntu PPA is here: https://launchpad.net/~siliconja/+archive/ubuntu/replxx/
Based on @siliconja's recommendation above, here is a PR: https://github.com/AmokHuginnsson/replxx/pull/142
Quick ping, any news on the PR above? Looks like lots of packaging pain gets unblocked when this is completed.
The PR is safe to merge without testing because the only change is to comments.