You might recall a few weeks ago that I requested from a well-known large and somewhat litigious company the source code of the modification they made to a certain GPL debugger, and that they grudgingly agreed after a long time.
So I set out to work on the pile of code they sent me and managed to extract their modifications and port them fo the latest version of that GPL tool... apart from one driver for their debug probes that we use throughout our company: the cunning bastards left a stub in the open-source debugger (I have the code for that) and that stubs talks to the rest of the driver in the form of a closed-source TCP server.
It's a blatant trick to go around the GPL by taking advantage of the grey area surrounding linking in the GPL - i.e. the question of whether a closed-source program can be linked to GPL code and not become GPL itself, which still hasn't been tested in court to my knowledge. If I recall correctly, the FSF is of the opinion that anything that dynamically links to GPL code becomes GPL too, but that's just an opinion.
And of course, here in this case, the aforementioned company added one degree of separation between their closed-source driver and the GPL tool that uses it by making it a server, so whatever argument against linking to GPL code becomes even weaker.
Anyway, as you can imagine, I'm disappointed: my work is 90% there, but I still don't have that one driver and their closed-source faux-server is half-broken and dog-slow because of the time it takes to spawn the server and communicate with it through TCP, and I can't fix it. And I'm 100% certain that if I asked them to send me the source code for that, they'd tell me to suck eggs.
But here's what happened: I got so tired of their shenanigans that I started investigating other debug probes I could use instead of their proprietary junk. And after quite a lot of investigation, I found one solution based on open hardware and open software that, with some careful configuration, works 2x to 3x faster than their proprietary debug probe. Wow! I didn't even know it was possible, and I probably wouldn't have researched it if I had had all I needed to make what we already own works.
Long story short: I proposed that my company replace all our existing proprietary debug probes with the open hardware one and my boss agreed. That's like 20 probes in total, between R&D, testing and production, and at the tune $266.99 per probe for the original proprietary one, that's $5339.80 the egregious GPL-violating company won't get from us. Not to mention renewal of the license for their IDE that we've been using for almost 2 decades, because finally, at long last, after over a month of solid work, I finally managed to free up our source code from their vendor lock-in and make it compile, debug and flash using open-source tools from start to finish!
So yeah, I didn't get what I originally wanted from that company. That's the bad news. But in the end I ended up better off without it, and that's the good news ๐
Great to hear this story of success. That plus
Reminds me of Schneider's stupid proprietary dongle for programming their PLCs. It's just a CH341 in a funny shaped case that fits into the funny shaped slot on the PLC, where it plugs onto an ordinary 0.1" pin header to talk logic level serial.
Plus it has a custom USB ID of course. Probably costs $2 to manufacture, sells for almost $300 as well.
This one is kind of the same thing: it's a bone-stock FTDI 4232H probe with a bit of logic tacked on to disable the chip without a custom init command and a custom USB PID/VID. All I need their driver for is to enable the chip. After that, I can just use the open-source FTDI driver. But the driver makes everything super-slow, so the point is kind of moot anyway.
Probably another attempt to go around the GPL actually, because they use the FTDI driver to talk to the chip (because the open-source libusb is very slow in Windows) and that too can't be linked to the GPL debugging tool. So the probe masquerades as a custom device.