[PATCH] MAINTAINERS: Remove some entries due to various compliance requirements.

[PATCH] MAINTAINERS: Remove some entries due to various compliance requirements.

[Greg Kroah-Hartman]

Remove some entries due to various compliance requirements. They can come
back in the future if sufficient documentation is provided.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 MAINTAINERS | 177 ----------------------------------------------------
 1 file changed, 177 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9d20ace6fa40..21b31c6d20d0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -258,12 +258,6 @@ L:	linux-acenic@sunsite.dk
 S:	Maintained
 F:	drivers/net/ethernet/alteon/acenic*
 
-ACER ASPIRE 1 EMBEDDED CONTROLLER DRIVER
-M:	Nikita Travkin <nikita@trvn.ru>
-S:	Maintained
-F:	Documentation/devicetree/bindings/platform/acer,aspire1-ec.yaml
-F:	drivers/platform/arm64/acer-aspire1-ec.c
-
 ACER ASPIRE ONE TEMPERATURE AND FAN DRIVER
 M:	Peter Kaestle <peter@piie.net>
 L:	platform-driver-x86@vger.kernel.org
@@ -888,7 +882,6 @@ F:	drivers/staging/media/sunxi/cedrus/
 
 ALPHA PORT
 M:	Richard Henderson <richard.henderson@linaro.org>
-M:	Ivan Kokshaysky <ink@jurassic.park.msu.ru>
 M:	Matt Turner <mattst88@gmail.com>
 L:	linux-alpha@vger.kernel.org
 S:	Odd Fixes
@@ -2263,12 +2256,6 @@ L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
 S:	Maintained
 F:	arch/arm/mach-ep93xx/ts72xx.c
 
-ARM/CIRRUS LOGIC CLPS711X ARM ARCHITECTURE
-M:	Alexander Shiyan <shc_work@mail.ru>
-L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
-S:	Odd Fixes
-N:	clps711x
-
 ARM/CIRRUS LOGIC EP93XX ARM ARCHITECTURE
 M:	Hartley Sweeten <hsweeten@visionengravers.com>
 M:	Alexander Sverdlin <alexander.sverdlin@gmail.com>
@@ -3815,14 +3802,6 @@ F:	drivers/video/backlight/
 F:	include/linux/backlight.h
 F:	include/linux/pwm_backlight.h
 
-BAIKAL-T1 PVT HARDWARE MONITOR DRIVER
-M:	Serge Semin <fancer.lancer@gmail.com>
-L:	linux-hwmon@vger.kernel.org
-S:	Supported
-F:	Documentation/devicetree/bindings/hwmon/baikal,bt1-pvt.yaml
-F:	Documentation/hwmon/bt1-pvt.rst
-F:	drivers/hwmon/bt1-pvt.[ch]
-
 BARCO P50 GPIO DRIVER
 M:	Santosh Kumar Yadav <santoshkumar.yadav@barco.com>
 M:	Peter Korsgaard <peter.korsgaard@barco.com>
@@ -6476,7 +6455,6 @@ F:	drivers/mtd/nand/raw/denali*
 
 DESIGNWARE EDMA CORE IP DRIVER
 M:	Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
-R:	Serge Semin <fancer.lancer@gmail.com>
 L:	dmaengine@vger.kernel.org
 S:	Maintained
 F:	drivers/dma/dw-edma/
@@ -9759,14 +9737,6 @@ F:	drivers/gpio/gpiolib-cdev.c
 F:	include/uapi/linux/gpio.h
 F:	tools/gpio/
 
-GRE DEMULTIPLEXER DRIVER
-M:	Dmitry Kozlov <xeb@mail.ru>
-L:	netdev@vger.kernel.org
-S:	Maintained
-F:	include/net/gre.h
-F:	net/ipv4/gre_demux.c
-F:	net/ipv4/gre_offload.c
-
 GRETH 10/100/1G Ethernet MAC device driver
 M:	Andreas Larsson <andreas@gaisler.com>
 L:	netdev@vger.kernel.org
@@ -12949,12 +12919,6 @@ S:	Maintained
 F:	drivers/ata/pata_arasan_cf.c
 F:	include/linux/pata_arasan_cf_data.h
 
-LIBATA PATA DRIVERS
-R:	Sergey Shtylyov <s.shtylyov@omp.ru>
-L:	linux-ide@vger.kernel.org
-F:	drivers/ata/ata_*.c
-F:	drivers/ata/pata_*.c
-
 LIBATA PATA FARADAY FTIDE010 AND GEMINI SATA BRIDGE DRIVERS
 M:	Linus Walleij <linus.walleij@linaro.org>
 L:	linux-ide@vger.kernel.org
@@ -12971,14 +12935,6 @@ F:	drivers/ata/ahci_platform.c
 F:	drivers/ata/libahci_platform.c
 F:	include/linux/ahci_platform.h
 
-LIBATA SATA AHCI SYNOPSYS DWC CONTROLLER DRIVER
-M:	Serge Semin <fancer.lancer@gmail.com>
-L:	linux-ide@vger.kernel.org
-S:	Maintained
-F:	Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml
-F:	Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml
-F:	drivers/ata/ahci_dwc.c
-
 LIBATA SATA PROMISE TX2/TX4 CONTROLLER DRIVER
 M:	Mikael Pettersson <mikpelinux@gmail.com>
 L:	linux-ide@vger.kernel.org
@@ -14174,16 +14130,6 @@ S:	Maintained
 T:	git git://linuxtv.org/media_tree.git
 F:	drivers/media/platform/nxp/imx-pxp.[ch]
 
-MEDIA DRIVERS FOR ASCOT2E
-M:	Sergey Kozlov <serjk@netup.ru>
-M:	Abylay Ospan <aospan@netup.ru>
-L:	linux-media@vger.kernel.org
-S:	Supported
-W:	https://linuxtv.org
-W:	http://netup.tv/
-T:	git git://linuxtv.org/media_tree.git
-F:	drivers/media/dvb-frontends/ascot2e*
-
 MEDIA DRIVERS FOR CXD2099AR CI CONTROLLERS
 M:	Jasmin Jessich <jasmin@anw.at>
 L:	linux-media@vger.kernel.org
@@ -14192,16 +14138,6 @@ W:	https://linuxtv.org
 T:	git git://linuxtv.org/media_tree.git
 F:	drivers/media/dvb-frontends/cxd2099*
 
-MEDIA DRIVERS FOR CXD2841ER
-M:	Sergey Kozlov <serjk@netup.ru>
-M:	Abylay Ospan <aospan@netup.ru>
-L:	linux-media@vger.kernel.org
-S:	Supported
-W:	https://linuxtv.org
-W:	http://netup.tv/
-T:	git git://linuxtv.org/media_tree.git
-F:	drivers/media/dvb-frontends/cxd2841er*
-
 MEDIA DRIVERS FOR CXD2880
 M:	Yasunari Takiguchi <Yasunari.Takiguchi@sony.com>
 L:	linux-media@vger.kernel.org
@@ -14246,35 +14182,6 @@ F:	drivers/media/platform/nxp/imx-mipi-csis.c
 F:	drivers/media/platform/nxp/imx7-media-csi.c
 F:	drivers/media/platform/nxp/imx8mq-mipi-csi2.c
 
-MEDIA DRIVERS FOR HELENE
-M:	Abylay Ospan <aospan@netup.ru>
-L:	linux-media@vger.kernel.org
-S:	Supported
-W:	https://linuxtv.org
-W:	http://netup.tv/
-T:	git git://linuxtv.org/media_tree.git
-F:	drivers/media/dvb-frontends/helene*
-
-MEDIA DRIVERS FOR HORUS3A
-M:	Sergey Kozlov <serjk@netup.ru>
-M:	Abylay Ospan <aospan@netup.ru>
-L:	linux-media@vger.kernel.org
-S:	Supported
-W:	https://linuxtv.org
-W:	http://netup.tv/
-T:	git git://linuxtv.org/media_tree.git
-F:	drivers/media/dvb-frontends/horus3a*
-
-MEDIA DRIVERS FOR LNBH25
-M:	Sergey Kozlov <serjk@netup.ru>
-M:	Abylay Ospan <aospan@netup.ru>
-L:	linux-media@vger.kernel.org
-S:	Supported
-W:	https://linuxtv.org
-W:	http://netup.tv/
-T:	git git://linuxtv.org/media_tree.git
-F:	drivers/media/dvb-frontends/lnbh25*
-
 MEDIA DRIVERS FOR MXL5XX TUNER DEMODULATORS
 L:	linux-media@vger.kernel.org
 S:	Orphan
@@ -14282,16 +14189,6 @@ W:	https://linuxtv.org
 T:	git git://linuxtv.org/media_tree.git
 F:	drivers/media/dvb-frontends/mxl5xx*
 
-MEDIA DRIVERS FOR NETUP PCI UNIVERSAL DVB devices
-M:	Sergey Kozlov <serjk@netup.ru>
-M:	Abylay Ospan <aospan@netup.ru>
-L:	linux-media@vger.kernel.org
-S:	Supported
-W:	https://linuxtv.org
-W:	http://netup.tv/
-T:	git git://linuxtv.org/media_tree.git
-F:	drivers/media/pci/netup_unidvb/*
-
 MEDIA DRIVERS FOR NVIDIA TEGRA - VDE
 M:	Dmitry Osipenko <digetx@gmail.com>
 L:	linux-media@vger.kernel.org
@@ -14935,13 +14832,6 @@ F:	drivers/mtd/
 F:	include/linux/mtd/
 F:	include/uapi/mtd/
 
-MEMSENSING MICROSYSTEMS MSA311 DRIVER
-M:	Dmitry Rokosov <ddrokosov@sberdevices.ru>
-L:	linux-iio@vger.kernel.org
-S:	Maintained
-F:	Documentation/devicetree/bindings/iio/accel/memsensing,msa311.yaml
-F:	drivers/iio/accel/msa311.c
-
 MEN A21 WATCHDOG DRIVER
 M:	Johannes Thumshirn <morbidrsa@gmail.com>
 L:	linux-watchdog@vger.kernel.org
@@ -15275,7 +15165,6 @@ F:	drivers/tty/serial/8250/8250_pci1xxxx.c
 
 MICROCHIP POLARFIRE FPGA DRIVERS
 M:	Conor Dooley <conor.dooley@microchip.com>
-R:	Vladimir Georgiev <v.georgiev@metrotek.ru>
 L:	linux-fpga@vger.kernel.org
 S:	Supported
 F:	Documentation/devicetree/bindings/fpga/microchip,mpf-spi-fpga-mgr.yaml
@@ -15530,17 +15419,6 @@ F:	arch/mips/
 F:	drivers/platform/mips/
 F:	include/dt-bindings/mips/
 
-MIPS BAIKAL-T1 PLATFORM
-M:	Serge Semin <fancer.lancer@gmail.com>
-L:	linux-mips@vger.kernel.org
-S:	Supported
-F:	Documentation/devicetree/bindings/bus/baikal,bt1-*.yaml
-F:	Documentation/devicetree/bindings/clock/baikal,bt1-*.yaml
-F:	drivers/bus/bt1-*.c
-F:	drivers/clk/baikal-t1/
-F:	drivers/memory/bt1-l2-ctl.c
-F:	drivers/mtd/maps/physmap-bt1-rom.[ch]
-
 MIPS BOSTON DEVELOPMENT BOARD
 M:	Paul Burton <paulburton@kernel.org>
 L:	linux-mips@vger.kernel.org
@@ -15553,7 +15431,6 @@ F:	include/dt-bindings/clock/boston-clock.h
 
 MIPS CORE DRIVERS
 M:	Thomas Bogendoerfer <tsbogend@alpha.franken.de>
-M:	Serge Semin <fancer.lancer@gmail.com>
 L:	linux-mips@vger.kernel.org
 S:	Supported
 F:	drivers/bus/mips_cdmm.c
@@ -16521,12 +16398,6 @@ F:	include/linux/ntb.h
 F:	include/linux/ntb_transport.h
 F:	tools/testing/selftests/ntb/
 
-NTB IDT DRIVER
-M:	Serge Semin <fancer.lancer@gmail.com>
-L:	ntb@lists.linux.dev
-S:	Supported
-F:	drivers/ntb/hw/idt/
-
 NTB INTEL DRIVER
 M:	Dave Jiang <dave.jiang@intel.com>
 L:	ntb@lists.linux.dev
@@ -18547,13 +18418,6 @@ F:	drivers/pps/
 F:	include/linux/pps*.h
 F:	include/uapi/linux/pps.h
 
-PPTP DRIVER
-M:	Dmitry Kozlov <xeb@mail.ru>
-L:	netdev@vger.kernel.org
-S:	Maintained
-W:	http://sourceforge.net/projects/accel-pptp
-F:	drivers/net/ppp/pptp.c
-
 PRESSURE STALL INFORMATION (PSI)
 M:	Johannes Weiner <hannes@cmpxchg.org>
 M:	Suren Baghdasaryan <surenb@google.com>
@@ -19636,15 +19500,6 @@ S:	Supported
 F:	Documentation/devicetree/bindings/i2c/renesas,iic-emev2.yaml
 F:	drivers/i2c/busses/i2c-emev2.c
 
-RENESAS ETHERNET AVB DRIVER
-R:	Sergey Shtylyov <s.shtylyov@omp.ru>
-L:	netdev@vger.kernel.org
-L:	linux-renesas-soc@vger.kernel.org
-F:	Documentation/devicetree/bindings/net/renesas,etheravb.yaml
-F:	drivers/net/ethernet/renesas/Kconfig
-F:	drivers/net/ethernet/renesas/Makefile
-F:	drivers/net/ethernet/renesas/ravb*
-
 RENESAS ETHERNET SWITCH DRIVER
 R:	Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
 L:	netdev@vger.kernel.org
@@ -19694,14 +19549,6 @@ F:	Documentation/devicetree/bindings/i2c/renesas,rmobile-iic.yaml
 F:	drivers/i2c/busses/i2c-rcar.c
 F:	drivers/i2c/busses/i2c-sh_mobile.c
 
-RENESAS R-CAR SATA DRIVER
-R:	Sergey Shtylyov <s.shtylyov@omp.ru>
-L:	linux-ide@vger.kernel.org
-L:	linux-renesas-soc@vger.kernel.org
-S:	Supported
-F:	Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml
-F:	drivers/ata/sata_rcar.c
-
 RENESAS R-CAR THERMAL DRIVERS
 M:	Niklas Söderlund <niklas.soderlund@ragnatech.se>
 L:	linux-renesas-soc@vger.kernel.org
@@ -19777,16 +19624,6 @@ S:	Supported
 F:	Documentation/devicetree/bindings/i2c/renesas,rzv2m.yaml
 F:	drivers/i2c/busses/i2c-rzv2m.c
 
-RENESAS SUPERH ETHERNET DRIVER
-R:	Sergey Shtylyov <s.shtylyov@omp.ru>
-L:	netdev@vger.kernel.org
-L:	linux-renesas-soc@vger.kernel.org
-F:	Documentation/devicetree/bindings/net/renesas,ether.yaml
-F:	drivers/net/ethernet/renesas/Kconfig
-F:	drivers/net/ethernet/renesas/Makefile
-F:	drivers/net/ethernet/renesas/sh_eth*
-F:	include/linux/sh_eth.h
-
 RENESAS USB PHY DRIVER
 M:	Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
 L:	linux-renesas-soc@vger.kernel.org
@@ -22440,19 +22277,11 @@ F:	drivers/tty/serial/8250/8250_lpss.c
 
 SYNOPSYS DESIGNWARE APB GPIO DRIVER
 M:	Hoan Tran <hoan@os.amperecomputing.com>
-M:	Serge Semin <fancer.lancer@gmail.com>
 L:	linux-gpio@vger.kernel.org
 S:	Maintained
 F:	Documentation/devicetree/bindings/gpio/snps,dw-apb-gpio.yaml
 F:	drivers/gpio/gpio-dwapb.c
 
-SYNOPSYS DESIGNWARE APB SSI DRIVER
-M:	Serge Semin <fancer.lancer@gmail.com>
-L:	linux-spi@vger.kernel.org
-S:	Supported
-F:	Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
-F:	drivers/spi/spi-dw*
-
 SYNOPSYS DESIGNWARE AXI DMAC DRIVER
 M:	Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
 S:	Maintained
@@ -23762,12 +23591,6 @@ L:	linux-input@vger.kernel.org
 S:	Maintained
 F:	drivers/hid/hid-udraw-ps3.c
 
-UFS FILESYSTEM
-M:	Evgeniy Dushistov <dushistov@mail.ru>
-S:	Maintained
-F:	Documentation/admin-guide/ufs.rst
-F:	fs/ufs/
-
 UHID USERSPACE HID IO DRIVER
 M:	David Rheinsberg <david@readahead.eu>
 L:	linux-input@vger.kernel.org
-- 
2.47.0

Re: [PATCH] MAINTAINERS: Remove some entries due to various compliance requirements.

[Geert Uytterhoeven]

 	Hi Greg,

Thanks for your patch, which is now commit 6e90b675cf942e50
("MAINTAINERS: Remove some entries due to various compliance
requirements.") in v6.12-rc4.

On Fri, 18 Oct 2024, Greg Kroah-Hartman wrote:
> Remove some entries due to various compliance requirements. They can come
> back in the future if sufficient documentation is provided.

This is very vague...
What are "various compliance requirements"?
What does "sufficient documentation" mean?

I can guess, but I think it's better to spell out the rules, as Linux
kernel development is done "in the open".  I am also afraid this is
opening the door for further (ab)use...

Gr{oetje,eeting}s,

 						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
 							    -- Linus Torvalds

Re: [PATCH] MAINTAINERS: Remove some entries due to various compliance requirements.

[Geert Uytterhoeven]

 	Hi Greg,

Thanks for your patch, which is now commit 6e90b675cf942e50
("MAINTAINERS: Remove some entries due to various compliance
requirements.") in v6.12-rc4.

On Fri, 18 Oct 2024, Greg Kroah-Hartman wrote:
> Remove some entries due to various compliance requirements. They can come
> back in the future if sufficient documentation is provided.
>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

[...]

> @@ -888,7 +882,6 @@ F:	drivers/staging/media/sunxi/cedrus/
>
> ALPHA PORT
> M:	Richard Henderson <richard.henderson@linaro.org>
> -M:	Ivan Kokshaysky <ink@jurassic.park.msu.ru>
> M:	Matt Turner <mattst88@gmail.com>
> L:	linux-alpha@vger.kernel.org
> S:	Odd Fixes
> @@ -2263,12 +2256,6 @@ L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> S:	Maintained
> F:	arch/arm/mach-ep93xx/ts72xx.c
>
> -ARM/CIRRUS LOGIC CLPS711X ARM ARCHITECTURE
> -M:	Alexander Shiyan <shc_work@mail.ru>
> -L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> -S:	Odd Fixes
> -N:	clps711x
> -

This also removes the mailing list entry, causing submitters of future
patches to forget CCing the mailing list.

Why not just drop the cancelled M:-entry instead, like you did above?

The same is true for several other sections.
I have sent a fix for the sections related to Renesas drivers[1].

> ARM/CIRRUS LOGIC EP93XX ARM ARCHITECTURE
> M:	Hartley Sweeten <hsweeten@visionengravers.com>
> M:	Alexander Sverdlin <alexander.sverdlin@gmail.com>

[1] "[PATCH/RFC] MAINTAINERS: Re-add cancelled Renesas driver sections"
     https://lore.kernel.org/all/0a189e2c4090a1b308e18005d2552e335bac354f.1729511337.git.geert+renesas@glider.be/

Gr{oetje,eeting}s,

 						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
 							    -- Linus Torvalds

Re: [PATCH] MAINTAINERS: Remove some entries due to various compliance requirements.

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 473 bytes --]


> > Remove some entries due to various compliance requirements. They can come
> > back in the future if sufficient documentation is provided.
> 
> This is very vague...
> What are "various compliance requirements"?
> What does "sufficient documentation" mean?
> 
> I can guess, but I think it's better to spell out the rules, as Linux
> kernel development is done "in the open".  I am also afraid this is
> opening the door for further (ab)use...

I agree.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] MAINTAINERS: Remove some entries due to various compliance requirements.

[WangYuli]

Although this commit has been merged, it's still important to know the specific reason (or even an example) that triggered this change for everyone here, right?

And those maintainers who have been removed should be notified.

It should be CC'd everyone who might need to be aware of this change, including the removed maintainers, other maintainers on the subsystem, and the subsystem's mailing list.

To ensure transparency.

Re: [PATCH] MAINTAINERS: Remove some entries due to various compliance requirements.

[Mingcong Bai]

Greetings all,

在 2024-10-23 14:30，WangYuli 写道：
> Although this commit has been merged, it's still important to know the 
> specific reason (or even an example) that triggered this change for 
> everyone here, right?
> 
> And those maintainers who have been removed should be notified.

Seconded.

> It should be CC'd everyone who might need to be aware of this change, 
> including the removed maintainers, other maintainers on the subsystem, 
> and the subsystem's mailing list.
> 
> To ensure transparency.

This patch is one such instance where we find ourselves questioning the 
legitimacy and indeed, the feasibility, of an international, open, and 
open source project. Vagueness breeds distrust.

It's not difficult to deduce what the "various compliance requirements" 
are and I'm sure Greg is aware of this. The Linux Foundation, if 
interested in continuing their governance role over the Linux kernel, 
should be ready to explain themselves over this decision. Greg and 
Linus, I'm not sure if I'm ready to believe that this is supposed to be 
a political show - but if this is the case, please leave the ground for 
the Foundation - they should be the one responsible and receiving the 
scrutiny (or insult, as I'm sure many - myself included - find this 
patch insulting).

So I repeat - call the decision-makers out and ask for their 
explanation.

Best Regards,
Mingcong Bai

Re: [PATCH] MAINTAINERS: Remove some entries due to various compliance requirements.

[Mingcong Bai]

No, no, no. Nuh, uh.

Greg has unfortunately decided to respond in private over a matter that 
by no means should be glossed over. Here below is our conversation:

---

Greetings,

在 2024-10-23 15:55，Greg KH 写道：

> On Wed, Oct 23, 2024 at 03:32:50PM +0800, Mingcong Bai wrote:
> 
>> Greetings all,
> 
> <offlist>

Request declined. Your response is now public knowledge (and hey, if 
this is not by your will, my apologies). Again, this matter requires 
public response.

> 在 2024-10-23 14:30，WangYuli 写道： Although this commit has been merged, 
> it's still important to know the
> specific reason (or even an example) that triggered this change for
> everyone here, right?
> 
> And those maintainers who have been removed should be notified.
> Seconded.

Sorry, but that's not how this is allowed to work.  Please contact your
company lawyers if you have any questions about this.  And this only
affects maintainers, as you aren't listed in the MAINTAINERS file, there
should not be any issue, but again, contact your company if you have any
questions as they know what is going on.

Just *wink* if you were compelled into this.

> thanks,
> 
> greg k-h

Best Regards,
Mingcong Bai

Re: [PATCH] MAINTAINERS: Remove some entries due to various compliance requirements.

[Mauro Carvalho Chehab]

Em Fri, 18 Oct 2024 13:31:34 +0200
Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:

> Remove some entries due to various compliance requirements. They can come
> back in the future if sufficient documentation is provided.
> 
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
>  
> -MEDIA DRIVERS FOR ASCOT2E
> -M:	Sergey Kozlov <serjk@netup.ru>
> -M:	Abylay Ospan <aospan@netup.ru>
> -L:	linux-media@vger.kernel.org
> -S:	Supported
> -W:	https://linuxtv.org
> -W:	http://netup.tv/
> -T:	git git://linuxtv.org/media_tree.git
> -F:	drivers/media/dvb-frontends/ascot2e*

Please don't remove media entries at MAINTAINERS. If there are
compliance requirements related to some maintainers, instead keep the
entry there removing just the M: fields.

In case the driver becomes Orphan, please add:
	M: Mauro Carvalho Chehab <kernel.org>

And change S: to:

	S: Odd Fixes

Regards,
Mauro

Re: [PATCH] MAINTAINERS: Remove some entries due to various compliance requirements.

[WangYuli]

[-- Attachment #1.1.1: Type: text/plain, Size: 1619 bytes --]

Haha, I received a similar off-list reply.

I deeply sympathize with Greg-kh's situation and his unspoken 
difficulties, although I don't understand why the MAINTAINERS file, as 
part of the kernel code, should be off-limits to non-maintainer 
developers, especially when this clearly isn't just about 'modifying the 
MAINTAINERS file.'

If any Linux developer tacitly approves of this, they're essentially 
giving a green light to some shady political actors from a certain 
country to coerce people into betraying it's constitution.

That's absurd. Again, my heart goes out to all (including Greg-kh) that 
affected by this.

I mean no offense to anyone, but this action will completely destroy the 
trust that developers worldwide have in the Linux kernel project and the 
entire Linux Foundation, and the politicians forcing you to do this 
clearly don't care about that.

To avoid becoming pawns in a political game and to prevent alienating 
all the developers who have contributed to the Linux kernel, I sincerely 
suggest that you maintainers revert this commit and promise not to do 
something like this again.

And I urge everyone who agrees that this is unreasonable to reply to 
"[PATCH] Revert "MAINTAINERS: Remove some entries due to various 
compliance requirements." with their own "Reviewed-by".

Remember: What sets humans apart from animals is our undying spirit of 
resistance. We cannot be domesticated or tamed by others.

Finally, I'd like to share a quote from Norse mythology: Only warriors 
who die in battle are worthy of entering Valhalla.

-- 
WangYuli

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 645 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [PATCH] MAINTAINERS: Remove some entries due to various compliance requirements.

[Anna Antonenko]

> > Although this commit has been merged, it's still important to know the
> > specific reason (or even an example) that triggered this change for
> > everyone here, right?
> >
> > And those maintainers who have been removed should be notified.
>
> Seconded
>
> <...omitted...>
>
> So I repeat - call the decision-makers out and ask for their
> explanation.

Seconded. I'm no Linux kernel developer, but as a user, I would still like
to know the reason behind a bunch of maintainers getting erased. I wouldn't
go as far as to claim that I sense malice, but there's definitely something
fishy. I would like a proper, public statement about what happened and why.

Re: [PATCH] MAINTAINERS: Remove some entries due to various compliance requirements.

[Jiaxun Yang]

[-- Attachment #1.1.1: Type: text/plain, Size: 2291 bytes --]



On 2024/10/23 09:26, Mingcong Bai wrote:
> No, no, no. Nuh, uh.
>
> Greg has unfortunately decided to respond in private over a matter 
> that by no means should be glossed over. Here below is our conversation:

I can't believe a senior maintainer is breaking our agreed netiquette 
[1], but that's happening.

> 在 2024-10-23 15:55，Greg KH 写道：
[...]
>
> Request declined. Your response is now public knowledge (and hey, if 
> this is not by your will, my apologies). Again, this matter requires 
> public response.
>
>> 在 2024-10-23 14:30，WangYuli 写道： Although this commit has been 
>> merged, it's still important to know the
>> specific reason (or even an example) that triggered this change for
>> everyone here, right?
>>
>> And those maintainers who have been removed should be notified.
>> Seconded.
>
> Sorry, but that's not how this is allowed to work.  Please contact your
> company lawyers if you have any questions about this.  And this only
> affects maintainers, as you aren't listed in the MAINTAINERS file, there
> should not be any issue, but again, contact your company if you have any
> questions as they know what is going on.

I think there are no regulations on earth preventing itself from being 
referenced.
Even if the regulation prevents further communication with affected bodies,
the wider community still deserves an explanation.

As a person with M entries I found this behavior appalling. It shakes mutual
trust between maintainers, as we all assumed that patches being applied are
well scrutinized.

Besides, many of us are working on kernel as hobbyist  in a personal 
capacity.
That means we don't have access to lawyers, especially US one. While I 
understand
corporate participants may be the majority of the community, please 
don't leave
hobbyists behind!

I've had some interactions with some of people being removed here, and I 
would
say they are all brilliant individuals. It's  really sad to see them 
being turned away :-(

>
> Just *wink* if you were compelled into this.
^ It sounds unprofessional to me.

Thanks
- Jiaxun

[1]: https://people.kernel.org/tglx/notes-about-netiquette-qw89
>
>> thanks,
>>
>> greg k-h
>
> Best Regards,
> Mingcong Bai
>

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 17207 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [PATCH] MAINTAINERS: Remove some entries due to various compliance requirements.

[Mingcong Bai]

Greetings again (oops),

I messed up the reference levels when I sent my disclosure. Jiaxun got 
most of the references right but the last sentence.

在 2024-10-23 17:53，Jiaxun Yang 写道：
> On 2024/10/23 09:26, Mingcong Bai wrote:
>> No, no, no. Nuh, uh.
>> 
>> Greg has unfortunately decided to respond in private over a matter 
>> that by no means should be glossed over. Here below is our 
>> conversation:
> 
> I can't believe a senior maintainer is breaking our agreed netiquette 
> [1], but that's happening.
> 
>> 在 2024-10-23 15:55，Greg KH 写道：
> [...]
>> 
>> Request declined. Your response is now public knowledge (and hey, if 
>> this is not by your will, my apologies). Again, this matter requires 
>> public response.
>> 
>>> 在 2024-10-23 14:30，WangYuli 写道： Although this commit has been merged, 
>>> it's still important to know the
>>> specific reason (or even an example) that triggered this change for
>>> everyone here, right?
>>> 
>>> And those maintainers who have been removed should be notified.
>>> Seconded.
>> 
>> Sorry, but that's not how this is allowed to work.  Please contact 
>> your
>> company lawyers if you have any questions about this.  And this only
>> affects maintainers, as you aren't listed in the MAINTAINERS file, 
>> there
>> should not be any issue, but again, contact your company if you have 
>> any
>> questions as they know what is going on.
> 
> I think there are no regulations on earth preventing itself from being 
> referenced.
> Even if the regulation prevents further communication with affected 
> bodies,
> the wider community still deserves an explanation.
> 
> As a person with M entries I found this behavior appalling. It shakes 
> mutual
> trust between maintainers, as we all assumed that patches being applied 
> are
> well scrutinized.
> 
> Besides, many of us are working on kernel as hobbyist  in a personal 
> capacity.
> That means we don't have access to lawyers, especially US one. While I 
> understand
> corporate participants may be the majority of the community, please 
> don't leave
> hobbyists behind!
> 
> I've had some interactions with some of people being removed here, and 
> I would
> say they are all brilliant individuals. It's  really sad to see them 
> being turned away :-(
> 
>> 
>> Just *wink* if you were compelled into this.
> ^ It sounds unprofessional to me.

For the record, I wrote that unprofessional sentence ("Just *wink*"), 
since it was private.

Best Regards,
Mingcong Bai

> 
> Thanks
> - Jiaxun
> 
> [1]: https://people.kernel.org/tglx/notes-about-netiquette-qw89
>> 
>>> thanks,
>>> 
>>> greg k-h
>> 
>> Best Regards,
>> Mingcong Bai
>> 

Re: [PATCH] MAINTAINERS: Remove some entries due to various compliance requirements.

[Nikita Shubin]

>>Remove some entries due to various compliance requirements. They can
come back in the future if sufficient documentation is provided.

Greg,

Among the all possiblities you had, you've chosen the most disgusting
and shady way of doing this, with no attempt at least moving them to
CREDITS - the thing they rightfully deserve for their efforts.

As a person with M entries i deeply disrespect the removal and whe way
it was done.

Re: [PATCH] MAINTAINERS: Remove some entries due to various compliance requirements

[jisralbasha]

Dear Greg and other LF members,

I'm writing to express my serious concerns about the recent removal of entries from the MAINTAINERS file without proper explanation. While I understand the statement cited "various compliance requirements," this vague justification is deeply troubling.

Blindly complying with demands for obscure changes sets a dangerous precedent. What happens next time? Will we see further removals, modifications, or even additions driven by external pressures rather than the best interests of the project and its community?

This incident raises fundamental questions about the autonomy and integrity of our open-source project.  Should we be at the mercy of unspecified "compliance requirements" that could potentially lead to harmful actions, such as:

"Update some entries due to various compliance requirements." (and explode some Russian laptops like pagers in Lebanon, or disable all intel processors in sanctioned countries).

I strongly urge the LF to reconsider this approach and prioritize transparency and community engagement in all decision-making processes. This includes providing detailed explanations for any future changes to critical project files like MAINTAINERS. Additionally, we should explore strategies to mitigate external pressures and ensure the long-term health and independence of our project.

P.S. Keep communications public

Re: [PATCH] MAINTAINERS: Remove some entries due to various compliance requirements.

[Lukas Wunner]

On Mon, Oct 21, 2024 at 09:49:56AM +0200, Geert Uytterhoeven wrote:
> On Fri, 18 Oct 2024, Greg Kroah-Hartman wrote:
> > Remove some entries due to various compliance requirements. They can come
> > back in the future if sufficient documentation is provided.
> 
> This is very vague...
> What are "various compliance requirements"?
> What does "sufficient documentation" mean?

Looking at what other organizations have done provides some clues.
E.g. the RIPE NCC initially took the stance:

   "The RIPE NCC provides critical services to its membership spread across
    a diverse geographical and political region.
    The Executive Board of the RIPE NCC believes that the means to communicate
    should not be affected by domestic political disputes, international
    conflicts or war. This includes the provision of correctly registered
    Internet numbering resources."
    https://www.ripe.net/about-us/news/ripe-ncc-executive-board-resolution-on-provision-of-critical-services/

However due to being governed by Dutch law, that policy had to be amended:

   "The Dutch Ministry of Foreign Affairs confirmed to us that IP resources
    are considered economic resources, as defined in the EU sanctions
    regulation, and must be frozen for sanctioned entities.
    The RIPE NCC complies with this restriction by freezing the registration
    (not the use) of the Internet number resources in the RIPE Database.
    This means that sanctioned entities cannot acquire further resources or
    transfer resources. However, we do not deregister their resources or
    terminate their Standard Service Agreement (SSA) if they are RIPE NCC
    members."
    https://www.ripe.net/membership/member-support/the-ripe-ncc-and-ukraine-russia/

At least the RIPE NCC was transparent in the process and seemingly did only
the absolute minimum to comply (freeze, but not deregister IP address blocks).
An approach that might be befitting for the kernel community / LF as well.

Thanks,

Lukas

[PATCH] MAINTAINERS: Remove some entries due to various compliance requirements.

[Jensen Huang]

Remove some entries due to various compliance requirements. They can come
back in the future if sufficient documentation is provided.

Signed-off-by: Jensen Huang <JensenHuangNVDIA@gmail.com>

---

Follow 6e90b67

---

Linus Torvalds said

"I'm Finnish. Did you think I'd be supporting Russian
aggression? Apparently it's not just lack of real news, it's lack of
history knowledge too."

So we should remove Israeli developers too, because Israel is committing aggression and genocide.

Link: https://lore.kernel.org/all/CAHk-=whNGNVnYHHSXUAsWds_MoZ-iEgRMQMxZZ0z-jY4uHT+Gg@mail.gmail.com/
---
 MAINTAINERS | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index e9659a5a7..9ce642d40 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2275,13 +2275,6 @@ S:	Maintained
 T:	git git://git.armlinux.org.uk/~rmk/linux-arm.git clkdev
 F:	drivers/clk/clkdev.c
 
-ARM/CONEXANT DIGICOLOR MACHINE SUPPORT
-M:	Baruch Siach <baruch@tkos.co.il>
-L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
-S:	Maintained
-F:	arch/arm/boot/dts/cnxt/
-N:	digicolor
-
 ARM/CORESIGHT FRAMEWORK AND DRIVERS
 M:	Suzuki K Poulose <suzuki.poulose@arm.com>
 R:	Mike Leach <mike.leach@linaro.org>
-- 
2.46.2

Re: [PATCH] MAINTAINERS: Remove some entries due to various compliance requirements.

[陈寒彤]

Well, the fact is that Linus Torvalds, our leader of Linux, is not **Palestinian** but **Finnish**.

Re: [PATCH] MAINTAINERS: Remove some entries due to various compliance requirements.

[James Bottomley]

> On Fri, 18 Oct 2024, Greg Kroah-Hartman wrote:
> > Remove some entries due to various compliance requirements. They
> > can come back in the future if sufficient documentation is
> > provided.
> 
> This is very vague...

We finally got clearance to publish the actual advice:

   If your company is on the U.S. OFAC SDN lists, subject to an OFAC
   sanctions program, or owned/controlled by a company on the list, our
   ability to collaborate with you will be subject to restrictions, and
   you cannot be in the MAINTAINERS file.

> What are "various compliance requirements"?
> What does "sufficient documentation" mean?

The documentation Greg is looking for (which a group of Lawyers at the
LF will verify) is that someone in the removed list doesn't actually
work for an OFAC SDN sanctioned entity.

> I can guess, but I think it's better to spell out the rules, as Linux
> kernel development is done "in the open". I am also afraid this is
> opening the door for further (ab)use...

I agree we should have been more transparent about this but I think it
would be hard for someone other than Greg to get a Maintainer removed
on the "compliance issue" grounds so it's probably not that open to
abuse.

Regards,

James

Re: [PATCH] MAINTAINERS: Remove some entries due to various compliance requirements.

[NotYourFox]

Thanks for clarification.
It could be a "good enough" explanation to settle things down. If not 
for Linus' reply.

One message made him lose most of the respect he earned in Russia for 
good things. More importantly, our trust in Linux and FOSS in general.
Very, very disappointing, even more to me as I don't see any better 
alternatives.

Linus is a developer, a hacker, and one of the names everyone thinks 
about when it comes to FOSS. Not one of those arrogant politicians. He 
should have never changed.

Signed,
forever a Linux user.

Re: [PATCH] MAINTAINERS: Remove some entries due to various compliance requirements.

[SekiBetu]

It's so sad that the most famous open source community is opening 
Pandora's Box

Re: [PATCH] MAINTAINERS: Remove some entries due to various compliance requirements.

[Angry Dev]

>> On Fri, 18 Oct 2024, Greg Kroah-Hartman wrote:
>>> Remove some entries due to various compliance requirements. They
>>> can come back in the future if sufficient documentation is
>>> provided.
>> This is very vague...
> We finally got clearance to publish the actual advice:
>
>     If your company is on the U.S. OFAC SDN lists, subject to an OFAC
>     sanctions program, or owned/controlled by a company on the list, our
>     ability to collaborate with you will be subject to restrictions, and
>     you cannot be in the MAINTAINERS file.
>
>> What are "various compliance requirements"?
>> What does "sufficient documentation" mean?
> The documentation Greg is looking for (which a group of Lawyers at the
> LF will verify) is that someone in the removed list doesn't actually
> work for an OFAC SDN sanctioned entity.
I'm pretty sure those sanction lists existed before LF did this move and
they never played a role up until now. It's necessary, I guess, to remember
that those lists are made by political entities for political reasons. If
it would be all so very clear, I really wonder why it is still possible to
work together for Russians and people/companies from the US on the ISS. I
don't really know, but I strongly guess there are companies invoked which
also work for the military on both sides. As most of you know there are
general elections in the US in a couple of days and it's not completely
unlikely that a very erratic and fickle person will be the next president.
It's also not very unlikely in that case, that those sanction lists get
extended because of "I don't like them: Put Em on the list.". So you are
giving a part of your power to US politicians, something nobody who
submitted code to the linux kernel ever agreed to. You are changing the
rules as you go. It's also important to remember that the linux kernel is
not a (commercial) product of the linux foundation or owned by them. It is
(currently) maintained by people who work for the (US based) linux
foundation and it is actually a problem for/of them and it looks a lot like
they (ab)used their technical power to get rid of it. (which can be seen on
the way it was done - which disrespects all rules of submitting a patch).
And as the cherry on top, everybody who disagrees is called a "Russian
Troll" by the project leader. I'm not - believe it or not: idgas. You
really should check your tone, especially if you run out of arguments. Or
is it you just hiding behind lawyers and want to emphasize your political
stand? I would agree in this particular case but neither your nor my
political stand can speak for a global project like linux. In any case: I'm
done with this project and hope somebody in free country will fork.

>> I can guess, but I think it's better to spell out the rules, as Linux
>> kernel development is done "in the open". I am also afraid this is
>> opening the door for further (ab)use...
> I agree we should have been more transparent about this but I think it
> would be hard for someone other than Greg to get a Maintainer removed
> on the "compliance issue" grounds so it's probably not that open to
> abuse.
>
> Regards,
>
> James
>
>
>

Re: [PATCH] MAINTAINERS: Remove some entries due to various compliance requirements.

[John Mcenroy]

Hello Linux Community


Alfred Tennyson
Freedom

Of old sat Freedom on the heights,
    The thunders breaking at her feet;
Above her shook the starry lights;
    She heard the torrent meet.

There in her place she did rejoice,
    Self-gather’d in her prophet-mind,
But fragments of her mighty voice
    Came rolling on the wind.

Then stepped she down thro’ town and field
    To mingle with the human race,
And part by part to men reveal’d
    The fullness of her face –

Grave mother of majestic works,
    From her isle-altar gazing down,
Who, Godlike, grasps the triple forks,
    And, king-like, wears the crown,

Her open eyes desire the truth.
    The wisdom of a thousand years
Is in them. May perpetual youth
    Keep dry their light from tears;

That her fair form may stand and shine,
    Make bright our days and light our dreams,
Turning to scorn with lips divine
    To falsehood of extremes.


Альфред Теннисон
Свобода

Свобода древле обитала
На высях гор; в сияньи звезд
Над нею небо трепетало,
Под ней дробился гром окрест.

Огнем пророческого духа
Там дивный лик её блистал;
Но мощный глас её до слуха
Порою к людям долетал.

Затем низшед к полям и градам,
Смешалась с смертною толпой
И понемногу нашим взглядам
Разоблачила образ свой.

Так, в мир явившись миролюбцем,
Меж нас воздвигла свой алтарь,
Вооружась, как бог трезубцем,
Блестя короною, как царь.

Её отверзтый взор стремится
Лишь к правде, к мудрости отцов.
О, пусть же вечно он не тмится
Слезой над тупостью слепцов!

О, пусть, воссев на трон не зыбкий,
Нам светит правдой сквозь туман
И уст божественной улыбкой
Рассеет крайностей обман!


Linux user
John Mcenroy
---
johnmcenroystudios@gmail.com

Re: [PATCH] MAINTAINERS: Remove some entries due to various compliance requirements.

[Alexander Pevzner]

Hi everybody,

My name is Alexander Pevzner, and I live in Russia, Moscow.

I'm probably one of these "Russian trolls", mentioned by Linus in his 
message a couple of days ago.

Regardless of that, I use Linux as my primary OS since 1.2.13 kernel (so 
about 30 years for now) and I've contributed few lines of code (or, most 
likely, few thousand of lines of code) to make driverless printing and 
scanning work on Linux, so if you use one of those modern multifuction 
printers, this is very likely that among other stuff you use one of 
couple of my projects already on our personal computer.

As for me, the free software movement is the important thing. Really 
important. It makes people to cooperate. Not only individuals, but 
people from competing corporations. The free software movement sometimes 
"glues" people stronger, that money interest, which often works to 
separate people.

The whole history of the humanity can be seen as a history of ugly wars 
(the war is always ugly regardless of its reasons, because it always 
kills the human in a person).

 From another side, the whole history of the humanity can be seem as a 
history of cooperation. It was cooperation that allowed us to get out of 
the caves into outer space, to create computers and to write operating 
systems and other software for them.

Any war will some day end and any government will some day become part 
of the history, but the story of human cooperation has a chance to 
outlive the history.

In that sense, free software works in direction just opposite to the 
war. It lets people to cooperate, to see humans in another person's eyes 
(and code). Even when we are separated by the war.

And it puts a lot of responsibility to the free software leaders, 
because they not only manage lines of code, but somehow define edges of 
the future of the entire humanity. At least, in some aspects.

As a professional, I'm trying to cleanly separate software development 
from any kind of politics (probably, the same we all expect from the 
medical doctors). When I receive PR for review or a bug report, I look 
only to proposed code changes or bug description, regardless on who send 
me it.

The Linux Foundation is the community of software professionals. I 
understand that this is US organization and it is sometimes obliged by 
the US laws and regulation.

What would I expect from the professional organization in a case like 
this. The following:
1. The clear public note, that according to some US regulation the 
people from the sanctioned organizations cannot longer act as kernel 
maintainers
2. The personal communication with each of them, with explanation what 
is going on and verification that these persons are under sanctions
3. The clear public note, now with the list of affected persons, 
explaining that they will be removed from the maintainers list and with 
the great thanks for the work that they have done before.
4. Inclusion of these peoples into the kernel's hall of fame (the 
CREDITS list)

Nothing of this has be done, unfortunately. This is very, very pity :(

--
With the best regards, Alexander Pevzner (pzz@apevzner.com)

Re: [PATCH] MAINTAINERS: Remove some entries due to various compliance requirements.

[metux]

On 24.10.24 17:39, James Bottomley wrote:

> The documentation Greg is looking for (which a group of Lawyers at the
> LF will verify) is that someone in the removed list doesn't actually
> work for an OFAC SDN sanctioned entity.

Aha, guilty until proven otherwise ?

Is that how things are handled in the "land of the free" ?


--mtx