There’s more going on here than is visible from the out-of-context quote in the commit message.
And it's also pretty certain that posting this message into the eternal commit history can easily be interpreted as trying to make IBM look bad, which tends to not sit well with any employer.
Go as far back as the year 2004 and Intel's first generation of PCI-X (not PCI-E!) very expensive 10Gbps NICs for servers, and their FreeBSD drivers. Look at the man pages for them and the @intel.com email addresses who wrote the drivers and the man page.
In the case of something like an ethernet card the only persons who might have the appropriate knowledge to write a stable kernel driver probably are the same ones who designed it.
Sometimes though the community doesn't want just the knowledge of the corporation, we want it plus more.
We don't want DVD region restrictions. We don't want GPUs artificially restricted from mining Ethereum. These are the kind of things where an open source person can give a pull request to the repo to include an awesome feature that enables the hardware to do more than it is advertised to do and shove it to their corporate ass. That's the spirit of Linux.
If someone was able to make the IBM hardware do something that it was artificially restricted from doing, they should be able to issue a pull request to the repo and get it committed.
Oh let's not make sweeping statements haha, I want to play video games much more than I want the ice caps to melt so some ancaps can play multiplayer excel. I'm not usually onboard with vendor restrictions like these, but if the card self-destructed Inspector Gadget style when it detected crypto mining, I'd be okay with that.
And I say that as someone who has turned off their in-wall space heater and replaced it with a 3090 mining ETH when idle. No e-waste, no wasted power, (in this case) just a heater that pays you back.
brings to mind something I saw recently: "What is bitcoin? Well, it's like if you left your car idling 24x7 it would produce solved sudokus you can trade for black tar heroin"
Electric heating can be much more efficient than what's effectively resistive heating with 500%+ efficiencies being possible.
Search for "heat pumps" or watch: https://www.youtube.com/watch?v=7J52mDjZzto
Watched the video by the way, thanks!
If there were some hidden feature that was not enabled on an Intel 100Gbps NIC, which could be enabled in an open source driver, I'm 100% in favor of doing that. Thankfully there isn't (all praise to our benevolent corporate overlords), but I can certainly see a scenario with another vendor where there might be.
I hope that if Intel were to ever go down the route of big ugly closed source binary blob to make a 100Gbps NIC function properly, that people would go buy hardware from another vendor. With some basic consumer grade 1Gbps ethernet stuff you can see this now on a base debian install, where you need to enable the 'non-free' repo and install a .deb for a Broadcom provided driver to make a NIC work. Because their driver is considerably less freely licensed than Intel's. One of the reasons why I try to steer away from any Broadcom network interfaces whenever possible.
Or in any other category of hardware. With the current chip shortage and lack of viable competing options, it really sucks that there's literally two high performance GPU vendors that exist on the planet, Nvidia or AMD/ATI, and no other choices.
But thanks to open source, being able to look at the driver and understanding how that SFP check is done, some people at the Serve The Home forum were able to figure out which EEPROM bit needs to be flipped for these cards to accept any and all SFP modules: https://forums.servethehome.com/index.php?threads/patching-i...
I saw that and wrote an automated patcher as a quick python hack to automate that: https://gist.github.com/ixs/dbaac42730dea9bd124f26cbd439c58e
It wasn't the point being raised, however, which addressed knowledge requirements of writing network interface drivers.
/me runs off to google
Although if this happened and legitimate code was rejected by IBM, what could happen is a community backlash against IBM as a maintainer and the code could enter that way.
I'd assume the person has received confidential information about the IBM technology in question during his employment. Of course the Linux driver is open source so it cannot be a business secret. But typically there is much more knowledge than just the Linux source code. Using business secrets after your employment is most likely enforcable in many legislations. Damages or criminal charges or both.
Such an action would only decrease developer goodwill towards IBM. Needless to say, IBM is already not one of the "cool" companies to work for.
there is this stipulation of using a clean room in which to introduce your idea in order not to be sued for “stealing” intellectual property.
And often times, the same person cannot be used in that clean room.
The important bit might be: what state he is in. Then to a lesser extent, what kind of work he does for IBM and what kind of work he does on the kernel.
Is the way this was done maybe a bit hidebound, corporate and uncharitable? Yeah. It's IBM, duh. But absent other evidence it doesn't seem like this devleoper is being pulled off a project for using a personal email.