On Sun, 2018-09-16 at 10:17 +0200, Hans de Goede wrote: > Hi, > > On 14-09-18 20:03, Simo Sorce wrote: > > On Fri, 2018-09-14 at 19:37 +0200, Hans de Goede wrote: > > > Hi, > > > > > > On 09/13/2018 07:59 PM, Simo Sorce wrote: > > > > On Thu, 2018-09-13 at 16:07 +0200, Hans de Goede wrote: > > > > > Hi, > > > > > > > > > > On 10-09-18 14:40, Abhiram Kuchibhotla wrote: > > > > > > According to the LICENSE file in their git repo, the code in the repo seems to be gplv2. Not sure if that proves anything. I'll do the licensecheck -r later and update you guys. > > > > > > > > > > > > On Mon 10 Sep, 2018, 6:08 PM Richard Shaw, <hobbes1069@xxxxxxxxx <mailto:hobbes1069@xxxxxxxxx>> wrote: > > > > > > > > > > > > On Mon, Sep 10, 2018 at 7:27 AM Rex Dieter <rdieter@xxxxxxxxxxxx <mailto:rdieter@xxxxxxxxxxxx>> wrote: > > > > > > > > > > > > Jan Rybar wrote: > > > > > > > > > > > > > Hi Abhiram, > > > > > > > > > > > > > > you can make COPR. No one asks, no harm done, everyone's happy. > > > > > > > > > > > > I don't think copr is appropriate either, > > > > > > https://docs.pagure.org/copr.copr/user_documentation.html#faq > > > > > > > > > > > > To me, makes it pretty clear that if it can't be in fedora, it can't be in > > > > > > copr either. > > > > > > > > > > > > > > > > > > You need to go through the code (maybe use licensecheck -r to help) to see if all the code is acceptable. If so I'll defer to Neal on the COPR acceptability. Another alternative is until formal support is added to the kernel you can look at packaging it in RPM Fusion. If it's truly FOSS but just not acceptable because it's a kernel module it can go in the Free repository. If it's using proprietary code (even if the project is GPL licensed) then as long as it's redistributable, it can go in the Non-Free repository. > > > > > > > > > > > > > > > This looks like a standard realtek driver which realtek creates for Android devices > > > > > or some such. The code is not pretty (I really wish realtek would start contributing > > > > > proper drivers to the mainline kernel) but it usually is all GPL licensed, except > > > > > for the firmware for the NIC. I don't see firmware in the git repo, so the code > > > > > may need to be adjusted to use the kernels firmware-load mechanism (I assume > > > > > it has the firmware embedded atm). > > > > > > > > > > The firmware files themselves may be distributed under this license: > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/LICENCE.rtlwifi_firmware.txt > > > > > > > > > > Note I did not check the files in the git repo, I just took a quick peek > > > > > that it is a "standard" out of tree realtek driver. > > > > > > > > > > Also IANAL and TINLA. > > > > > > > > I also have to use this driver for a USB dongle that works very well > > > > ... when I remember to check dkms didn't fail to build on kernel > > > > upgrade ... > > > > > > > > There is no firmware needed apparently, but my dongle doesn't work with > > > > driver 5.2 which is the latest, so maybe a firmware is needed but the > > > > driver itself doesn't load it ? > > > > > > > > It would be really nice to have this driver in the kernel though as a > > > > huge amount of cheap dongles use this chipset family, what would be the > > > > process to get it in ? > > > > > > You can submit it for inclusion into drivers/staging, there are already > > > some realtek drivers for other chipsets there for similar reasons. > > > > > > Real inclusion would require a complete rewrite of the driver mostly. > > > > Sigh, and I guess there is no party (beyond Realtek) with enough > > interest/time to do that ... > > Well for some older chips Jes Sorensen did a new driver from scratch using > the GPL-ed Realtek code as hardware documentation, so it is possible for > a community member to do this if it itches hard enough for them. > > You could reach out the Jes and ask him how much work this was and if > he perhaps can write a blog post or 2 (or 3) to summarize his experience > with this. Thanks I'll ask him. Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
