It would be a little nonsensical for the community to say that IBM does not control the "IBM Power SRIOV Virtual NIC Device Driver," which is located in the drivers/net/ethernet/ibm directory, and which according to this very same MAINTAINERS file is maintained by three other IBM employees.
That is a fair point to make, and indeed if you look at the commits for other very vendor specific open source network interfaces (like Intel's 10Gbps and 100Gbps NICs), the manufacturer has a very close relationship to publishing drivers for this sort of stuff.
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.
> only persons who might have the appropriate knowledge
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.
> We don't want GPUs artificially restricted from mining Ethereum.
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.
> much more than I want the ice caps to melt so some ancaps can play multiplayer excel.
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"
Someone else mentioned heat pumps to me in this context too, I'm unfortunately really limited in what I can use in my apartment. It's a condo complex made of brick put up in 1906 - without heating or air conditioning. I'm not in a position to install external hardware. My parents have a heat pump set-up in their house though!
I absolutely agree - in the case of Intel, they've been relatively benevolent and open about publishing the full details of drivers for their NICs, because they have a market demand to sell more NICs.
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.
To use most SFP+'s with Intel NICs, one has to load ixgbe with allow_unsupported_sfp=1 due to Intel's wanking. Ultimately this isn't a huge deal, but it's still an instance of corporate crap needlessly complicating Free software.
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...
Another popular solution in an environment where you might have to support six different vendors' equipment, some of which is closed source (juniper, etc) and demands certain SFP+ EEPROM codes, from one pool of spare equipment, is to purchase the optics with blank eeproms and a coding box to write the vendor ID code onto them over i2c bus as needed. There's four or five transceiver companies I can think of now which provide the solution to do that.
Don Becker had the advantage of working for NASA, a.k.a. the federal government, where everything is automatically public domain. Even classified information developed by the U.S. government isn't copyrighted, it just isn't available (to me, and probably not to you). We owe a great debt of gratitude to Mr. Becker as a true public servant.
If they want to control it they can create their own repo and distribute it on their website. If it's going in the Linux kernel tree it should not be subject to single-handed decisions by a corporation.
This person can also quit IBM, therefore being subject to no contractual obligation, and then change the "IBM Power SRIOV Virtual NIC Device Driver" entirely free of constraint as long as their code pass review. IBM has no control over the code, only the people it pays to change it.
That's not quite right. If IBM is listed as maintainers for this driver, then any patches would necessarily go through them to end up in the mainline tree. And they could decide to reject patches from the person in question.
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.
> This person can also quit IBM, therefore being subject to no contractual obligation, and then change the "IBM Power SRIOV Virtual NIC Device Driver" entirely free
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.
That's a fair point about clean room implementation. However, I can see IBM shooting themselves in the foot suing a kernel developer over an email address change, if said developer quits beforehand.
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.
