I'm loving the ideas/thoughts/etc here! Perhaps, we could add a Roadmap item for non-GPLv2 stuff? Personally, there are just a few items that I'd love to have which are not GPLv2. I'd hate to block on sorting this out now, when I suspect there will be some more input/concerns/etc. Pat On Mon, 2021-05-24 at 22:10 +0200, Peter Georg wrote: > > > On 23/05/2021 21.00, Jeffrey E Altman wrote: > > On 5/23/2021 10:32 AM, Peter Georg > > (peter.georg at physik.uni-regensburg.de) wrote: > > > Thanks to everyone for the input so far. I updated the original > > > proposal to reflect your input. In case I forgot something, > > > please let > > > me know. > > > > This looks very good so far. One comment below: > > > > > === 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. > > > > > > === Third-party external kernel modules === > > > > Might I suggest "out-of-kernel modules" instead of "third-party > > external > > kernel modules". > > modules". "out-of-tree kernel modules" is probably a better > description > than "thrid-party external kernel modules". Hence I'm thinking about > doing a s/thrid-party external/out-of-tree/g. But then I probably > should > also s/in-kernel/in-tree kernel/g. > > Opinions? > > Dicussing details like this, I think we are on a good way :) > > > > > > This SIG also aims to provide third-party kernel modules for > > > CentOS > > > Stream not (yet) available in upstream kernel. > > > > The "not (yet)" makes me wonder what the criteria for inclusion > > are. Is > > it a requirement that the module might be accepted into the > > upstream > > kernel if submitted? If this is the intent, I believe that would > > exclude two categories of modules. First, modules that provide > > functionality already provided by an actively maintained in-kernel > > module. Second, modules whose licenses are not listed in > > include/linux/license.h. > > think it has been. I currently don't see why we should restrict the > SIG > to modules that might be accepted into upstream kernel. > The restriction to GPL v2 compatible licenses is there due to legal > reasons. Is there any reason why we should restrict ourselves to > kernel > modules that might be accepted into upstream? > > > > > Later on the "What's not in scope" section says: > > > > > * Third-party kernel modules with a non GPL v2 compatible > > license > > which is overly broad. Might I suggest: > > > > [BEGIN] > > ==== Out-of-kernel modules ===== > > > > might be accepted into the upstream kernel if submitted. This > > category > > excludes: > > > > * modules whose primary functionality is already provided by an > > actively maintained in-kernel module. > > This restriction might be problematic in some cases. E.g. if an > existing > probably want to provide this kernel module even though the existing > in-kernel module has not yet been replaced in upstream (and > especially > not been backported). A somewhat recent example: exFAT. > > > > > * modules whose licenses are not included in > > include/linux/license.h > > (see license_is_gpl_compatible()). > > [END] > > I'd probably change this section only a litte bit to avoid confusion > and > add an explanation for the restriction to GPL v2 copatible: > > [BEGIN] > === Out-of-tree kernel modules === > This SIG also aims to provide out-of-tree kernel modules for CentOS > legal reasons. > [END] > > The "GPL v2" restriction is mentioned twice in the description then. > However I think this might not be bad at all. > > > > > I hope this is helpful. > > > > Jeffrey Altman > > > > > > > > _______________________________________________ > > CentOS-devel mailing list > > CentOS-devel at centos.org > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.centos.org_mailman_listinfo_centos-2Ddevel&d=DwIGaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=Gc5dbCAZDpcQgcW8Y3VLNBDtiz6uK2V3ChYaIp92CIc&s=v4nyPMV-KZGJQHgAPo-LePp-DT9bA65FjFSTYP13PWc&e= > > > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.centos.org_mailman_listinfo_centos-2Ddevel&d=DwIGaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=Gc5dbCAZDpcQgcW8Y3VLNBDtiz6uK2V3ChYaIp92CIc&s=v4nyPMV-KZGJQHgAPo-LePp-DT9bA65FjFSTYP13PWc&e= >