Unicode-3.0 license text missing

[stefan6419846]

This package includes data derived from the Unicode data files. While some indication is available, the corresponding Unicode-3.0 license (https://www.unicode.org/license.txt) requires to include the corresponding license/notice inside the distribution or docs. This does not seem to be the case.

The preferred way would be to include the corresponding license/notice into the existing license files (or a dedicated license file) to fulfill this requirement from your side, but make it easy for users of your library to include proper attribution as well.

[jquast]

What if I delete all Unicode data files and material retrieved from Unicode.org so that any automatic test requires first fetching the requisite data files by manual or automatic process?

[stefan6419846]

At least the test files like https://github.com/jquast/wcwidth/blob/master/tests/emoji-zwj-sequences.txt contain at least some basic headers with a license reference. If this is considered sufficient can be discussed.

I am mostly talking about the auto-generated actual code files like https://github.com/jquast/wcwidth/blob/master/wcwidth/table_ambiguous.py, which only have a very basic source file and timestamp as an indicator. Downloading/generating these on the fly will most likely be an issue on restricted systems.

[jquast]

As for automatic tests, they can simply "skip if the test file doesn't exist", I can ensure 100% coverage by downloading the files as-needed in CI. As for the automaticly generated tables, are you sure this is sufficient to "derive"? In that way, you and I are "deriving" from unicode data files to have this very conversation, so i'm not sure where the line is drawn, please provide guidance.

If a downstream re-packager, like a linux distro wants to verify the tests work, then maybe they could package and release unicode data files as a co-dependency. I could remove "Unicode" entirely from this project, I could call it "multibyte encoding compatible" or something.

@evrial if you could help by submitting a PR for what is suggested, update pyproject.toml and wcwidth/__init__.py for the new version, and enter a new changelog entry with SEMVER and date of the next release that works for you and #197

[jquast]

Have you contacted Markus Kuhn about his published wcwidth.c with derived tables and citation of Unicode versions 5.0? Please suggest if this file is a license violation, http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c

[stefan6419846]

As for the automaticly generated tables, are you sure this is sufficient to "derive"? In that way, you and I are "deriving" from unicode data files to have this very conversation, so i'm not sure where the line is drawn, please provide guidance.

Even if you copy the original data files as-is, you would have to include the necessary notices. Thus, for the affected files it should not matter how to interpret your variant of the Unicode data files (id est, being a derivative or a copy) - including the original copyright notice should always be necessary.

Have you contacted Markus Kuhn about his published wcwidth.c with derived tables and citation of Unicode versions 5.0? Please suggest if this file is a license violation, http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c

No, I have not, because I am not knowingly using his code and/or did not stumble upon his, but yours. Given that it is based upon Unicode 5.0, the actual data would have a similar license: https://web.archive.org/web/20060615150202/http://www.unicode.org/copyright.html For this reason, wcwidth.c tends to have the same issue.

Disclaimer: I am not a lawyer, but just someone who regularly deals with FOSS licensing aspects.

[jquast]

I don't mean to be argumentative, I am not a lawyer either, can we agree plainly: if wcwidth git source code, python sdist and wheel do not contain any unicode data files, then there is no need to add Unicode's license restrictions to wcwidth?

Can you show me the unicode license attached to any major gnu libc, musl, etc. libraries with POSIX wcwidth(3) and wcswidth(3), which depends on derived data? The reason I point out Markus Kuhn's wcwidth.c is because 99% of every modern wcwidth implementation is derived from it, including mine. There are hundreds of public derived copies of this code, probably every terminal emulator tested here, so please suggest carefully this would require great coordination

[evrial]

@evrial if you could help by submitting a PR for what is suggested, update pyproject.toml and wcwidth/__init__.py for the new version, and enter a new changelog entry with SEMVER and date of the next release that works for you and #197

I call this one non-issue unless we talk to a lawyer from Unicode, Inc.

[stefan6419846]

I don't mean to be argumentative, I am not a lawyer either, can we agree plainly: if wcwidth git source code, python sdist and wheel do not contain any unicode data files, then there is no need to add Unicode's license restrictions to wcwidth?

If you reproduce external work to some extent, you have to consider the original license and usually should include the license of the original work. There might be special cases, like trivial code, which does not need this, but this does not seem to apply here.

Just because others do it some way does not mean it is correct. It should not really hurt to just ship the corresponding notice with your code. The final obligation to ship the correct copyrights and notices is with final product distributors (mostly commercial), while you disclaim all warranty to have done everything to the best of your knowledge by attaching the MIT license.

It is your repository and package, thus it is up to you to decide on how to continue with this.

[evrial]

In the world of software development, there is a big difference between implementing a standard and redistributing protected code or data files. The Unicode Standard is an open specification. Using it is like using the laws of physics or the rules of English grammar—you are following a set of instructions on how to represent text.

[jquast]

If you have any success persuading a project like GNU with FSF, or openbsd with /usr/bin/less containing variations of the same, please reference any file or discussion where they agree to attach unicode license for derived data of category codes. I will delete all unicode data files from the project's next release.