Quite remarkable. Here we have a developer of a kernel driver for Philips webcams. This kernel module works, but to fully support the cameras, it needs a binary-only module. However, the kernel developers have decided to clean up binary-only modules. The Philips webcam module is also affected. As a result, the USB subsystem maintainer removed a hook from the kernel module through which the binary-only module could attach itself to the kernel.
The module developer is now complaining that his module would be demoted to a second-class module because it could only be distributed as an externally maintained module, but not directly in the kernel tree—because without the hook, his binary-only module cannot be loaded. Out of spite, he throws in the towel and no longer wants to support the module at all.
Where is the logical error? With the kernel developers who reject binary-only modules and don't want backdoors for binary-only modules in the kernel? Hardly.
The module developer could simply continue operating and distributing his module outside the kernel. He just can't be distributed with the hook directly in the kernel. He could distribute kernel patches that patch the hook into the kernel source. He rejects both options.
Such or similar discussions come up repeatedly when individual developers fail with their great idea—and yes, sometimes the failure only comes after a few years because previous maintainers took a more relaxed view of the whole thing. But binary-only modules in the Linux kernel are a constant nuisance: not only can't you fix them because you don't have the source. You also can't do security reviews. And sorry, but any decent admin doesn't want hooks on their system through which unverifiable binary modules can plug into the kernel.
Ultimately, the whole thing comes down to whether Linux must support every piece of hardware, even if there are no open source drivers for it. That Linux can also serve proprietary interfaces is clear—simply develop subsystems outside the kernel and integrate them into the kernel. The support for this is built into the kernel. But must the kernel itself support such modules?
In my opinion, no. It's certainly a downgrade for modules with purely binary components when they can't be distributed along with the kernel. But modules with purely binary components are already second-class citizens in an open source system anyway.
Of course, it may be more complicated for the user (although with Debian GNU/Linux, for example, it's quite trivial to install module subsystems to the kernel), but it can hardly be the goal of an open source system to compromise its own principles to make something easier that isn't even a focus of that system.
The real cause of the problem doesn't lie in the behavior of the Linux subsystem maintainers. The real cause lies in Philips' stubbornness in not wanting to release parts of the driver.
The fact that the module author is now scorching the earth (deleting downloads, deleting the mailbox, deleting sources, FAQs, etc.) just proves that he doesn't get it. Well, someone else will probably take the source and all the stuff and continue operating it—probably outside the kernel. The author didn't get that either. Instead, he's acting like a stubborn child.