On 20/05/2021 20.11, Neal Gompa wrote: > On Thu, May 20, 2021 at 2:08 PM Peter Georg > <peter.georg at physik.uni-regensburg.de> wrote: >> >> On 20/05/2021 17.22, Patrick Riehecky wrote: >>> Adding notes in line below: >>> >>> On Wed, 2021-05-19 at 17:56 +0200, Peter Georg wrote: >>>> Dear all, >>>> >>>> I'd like to propose a SIG for CentOS Stream. Please see the proposal >>>> below. >>>> >>>> Note: In case anyone has a better suggestion for a name, please let >>>> me >>>> know. I'm really terrible at naming things. And sorry in advance for >>>> any >>>> spelling or grammar mistakes (I'm not a native english speaker). >>>> >>>> For everyone following the previously posted "RFC: Stream Kernel SIG >>>> Proposal": The goal of the "kmods" SIG proposed here has previously >>>> been >>>> proposed to be added to a potential "Stream Kernel SIG" as a fifth >>>> goal. >>>> However it seems to make sense to split the various different goals >>>> into >>>> seperate SIGs. >>>> >>>> Disclaimer: I used the Hyperscale SIG description >>>> ( >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.centos.org_SpecialInterestGroup_Hyperscale&d=DwICAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=pGCREeRni9c5EX2L12UG18KzS_jp_PQxqbJohJOAHmI&s=Y8Rc2wfIQTiG6pW9V55QTQmMkjJEFYkhtAZdWRjBXlA&e= >>>> ) as a template. >>>> I hope that's OK. >>>> >>> >>> The more we can reuse things that work and make a cleaner/better/easier >>> process the happier we will all be :) >>> >>>> >>>> Best, >>>> >>>> Peter >>>> >>>> >>>> Proposal: >>>> = kmods SIG = >>>> >>>> == Goals == >>>> The kmods SIG will focus on providing kernel modules currently not >>>> available in CentOS Stream. >>>> >>>> == Status == >>>> Proposed: RFC and looking for a sponsoring Governing Board member >>> >>> As a board member I hereby indicate a willingness to sponsor. If >>> another board member is passionate about this, I'll be happy to hand it >>> over to them. I've regularly made use of external kmods (for old >>> hardware and proprietary hardware)and would strongly like to see them >>> continue in Stream! >>> >>>> >>>> == What's in scope == >>>> This SIG is a good place for any kernel module that is beneficial to >>>> CentOS Stream, but cannot be directly contributed to any of the >>>> involved >>>> upstream projects. These kernel modules may be divided in three >>>> categories: >>>> >>>> === Restore support for deprecated devices === >>>> The CentOS Stream kernel includes several kernel modules for which >>>> the >>>> list of supported devices has been limited by Red Hat. This SIG aims >>>> to >>>> many deprecated and removed devices as possible. >>>> >>>> A close collaboration with the kernel-plus developers is desired for >>>> these kernel modules. >>>> >>>> === In-kernel modules not enabled for CentOS Stream === >>>> Many in-kernel modules are simply disabled for the CentOS Stream >>>> kernel. >>>> This may either be due to drivers being deprecated and removed >>>> compared >>>> to older CentOS major releases or never being enabled in the first >>>> place. This SIG aims to provide these in-kernel drivers as external >>>> kernel modules to enable CentOS Stream running on a broader range of >>>> available hardware and provide other beneficial functionality. >>>> >>>> A close collaboration with the kernel-plus developers is desired for >>>> these kernel modules. In addition it is desired to work with upstream >>>> to >>>> get any valuable kernel modules directly into the CentOS Stream >>>> kernel. >>>> >>>> === Third-party external kernel modules === >>>> This SIG also aims to provide third-party kernel modules for CentOS >>>> Stream not (yet) available in upstream kernel. >>>> >>>> == What's not in scope == >>>> Anything that can be contributed directly to any of the involved >>>> upstream projects is not in scope. This includes, but is not limited >>>> to: >>>> >>>> * New user space packages: These should be submitted to Fedora/EPEL >>>> * Support for new architectures currently not supported by CentOS >>>> Stream >>>> * Third-party kernel modules with non compatible license >>>> >>> >>> Echoing other thoughts, packages in EPEL should be installable by folks >>> with or without the SIG. So I'd suggest anything that isn't dependent >>> on the kmods, should go into EPEL, but things that are kmod specific >>> should probably stay within the SIG. In theory, if userspace is tied >>> to the kmod, synchronizing updates would be cleaner if things were in >>> just the one place. >> >> Makes sense. I'll wait for further input on this point and will then try >> to come up with a better solution. >>> I'm a bit concerned that "non compatible license" is a bit vague. >>> Would this exclude DRBD, ZFS on Linux, OpenAFS, or nVidia? The nVidia >>> bits seem to be 'yes, it is excluded', I'm less sure on the other two. >> >> Concerning your examples: Afaik the CDDL (ZFS) is considered a free >> software license by the FSF. So I assume this should be fine. >> The nVidia bits are probably not allowed. >> > > OpenZFS has not been allowed per Red Hat Legal, so I don't think you > can do that. Well, as I said: I'm not a lawyer :) But good to know, thanks! Does this mean that legally the same restrictions that apply to getting a package into RHEL also apply to packages provided by a CentOS SIG? > Nvidia is more obviously not allowed as proprietary software. > > >