New package: rtl8192eu-dkms-2022.12.29

[Phicem]

Purpose of this package

This package is necessary for using some versions of TP-Link TL-WN823N (because in-kernel rtl8xxxx module does not work properly for those devices).

Quality requirement

• This is a new package and it conforms to the quality requirements
  --> The source repository does not provide releases

Have the results of the proposed changes been tested?

• I use the packages affected by the proposed changes on a regular basis and confirm this PR works for me
  On a x86_64 (glibc) system, with TP-Link TL-WN823N v2/v3

[Phicem]

Force-pushed on Apr 16, 2022 to update the base branch AND the package itself

[github-actions]

Pull Requests become stale 90 days after last activity and are closed 14 days after that. If this pull request is still relevant bump it or assign it.

[Phicem]

I'm bumping this pull request because I believe this package deserves to be in Void.

[github-actions]

Pull Requests become stale 90 days after last activity and are closed 14 days after that. If this pull request is still relevant bump it or assign it.

[paper42]

I am not interested in merging this package, just leaving some comments.

[paper42]

The original code is copyrighted, but I don't know by whom. The driver download does not contain license information; please open an issue if you are the copyright holder.

That doesn't look like GPL2

[Phicem]

I think it's not as bad as it looks.

The comment that you quoted above refers to the original code (first commit of the repo), which is downloadable from DLINK website. I tried to get into depth into what was released under GPL and what was not.

In the original code

• There is no general license information
• the Makefile (and some other trivial config files and trivial scripts) have no author and no license information
• most of the 333 source files (.h and .c) have license information (GPL2), except 39 files
• there are 16 .c files without license information:
  • 2 files have no author information (./core/rtw_wapi.c and ./core/rtw_wapi_sms4.c)
  • 12 files have an author name ("Cosa") (./hal/OUTSRC-BTCoexist/HalBtc*)
  • 2 files are Copyright Realtek (./hal/rtl8192e/Hal8192EPwrSeq.c and ./os_dep/linux/wifi_regd.c)
• there are 23 header files without license information.

In current code

Recent versions of the repo (which would be what would be packaged here) have even less license-less files:

• the Makefile (and some other trivial config files and trivial scripts) still have no author or license information
• all but 4 of the 512 source files (.h and .c) have license information (GPLv2)
• there is 1 .c file without license information:
  • this file is ./hal/btc/halbtc8192e2ant.c
  • this file mentions an author name ("Cosa") in the history section
  • this file exists in a different form in many other repositories, including the linux kernel itself, with GPL license. What I mean by 'different form' is that the code has undergone many changes, but the mentioned author is the same. See for instance: in the linux kernel
• there are 3 header files without author or license information
  • one is a trivial file ./include/rtw_version.h
  • the second one is ./hal/btc/halbtc8192e2ant.h and also exists in the linux kernel in another form (many changes in the code but same base)
  • the thirst one is ./hal/phydm/phydm_regtable.h but is a long list of trivial #define

Conclusion

Apart from the makefile and some trivial scripts and headers, there are only two files that are not explicitely GPLed : ./hal/btc/halbtc8192e2ant.c and its corresponding header. The fact that modified versions of these files can be found as GPL-released files tends to reassure me, but still, I have no proof that the exact files we use are GPL. Moreover, I have no license information at all about the makefile.

If we say that this is a problem, could we put the package in the nonfree repository, with a license field like license="GPL-2.0-only, custom:unknown"?

[paper42]

if they don't have releases, then this package doesn't really meet our quality requirements

[Phicem]

Yes, you are right. I saw some exceptions in existing packages, including other realtek drivers like rtl8812au-dkms, rtl8822bu-dkms, and rtl8821cu-dkms, so I thought it was okay (and I still think that these are legitimate exceptions). But I should not say that the package meets Void quality requirements. I will edit my package presentation.

[classabbyamp]

this upstream has v5 of the driver and at least has branches for versions

[Phicem]

I switched to the suggested upstream. It seems to work equally well.

[github-actions]

Pull Requests become stale 90 days after last activity and are closed 14 days after that. If this pull request is still relevant bump it or assign it.

[github-actions]

Pull Requests become stale 90 days after last activity and are closed 14 days after that. If this pull request is still relevant bump it or assign it.