This is probably the biggest and most successful example of utilizing non-permissive open source licensing for the public good - I’m curious why so many places I’ve worked have insisted on avoiding using libraries with GPL licenses in favor of MIT licensed projects, while at the same time hosting all of their services on different flavors of Linux.
It definitely seems like MIT is favored by big corps but at the end of the day, they’ll use GPL licensed code if it’s the best option. Which makes me wonder why it’s so demonized.
Compatibility with proprietary dependencies that the company cannot control. If I'm not mistaken, GPL requires the release of the dependencies' source code too if there are no other implementations around.
I would be happy to hear from anyone who knows about this subject if what I'm saying is correct.
It depended on whether the programs were distributed together. So it wasn't okay to link against OpenSSL for GNU/Linux distributions (although interpretations varied). For a time, this was used to push GNUTLS as an alternative to OpenSSL. But it was generally agreed upon that it was okay to link against CryptoAPI on Windows because you would not distribute Windows code along with your GPL binaries.
> I’m curious why so many places I’ve worked have insisted on avoiding using libraries with GPL licenses in favor of MIT licensed projects
Because failing to manage their GPL obligations led to a lawsuit for D-Link followed by a compulsion to release a lot more code than they ever planned to share online, to the company's detriment.
You can pretty much look at the stock value before and after they lost the lawsuit. There was, notably, a big value spike immediately after, but the value then settled down to an average of around 15 a share, markedly below their previous 30 a share.
For some companies, the value is in the proprietary content and using GPL would be shooting themselves in the foot.
I think that a lot of companies stepped back from the GPL when GPLv3 was announced, because it puts some pretty severe restrictions on how you can productize.
The tl;dr is that for any GPLv3 software that you ship, you have to also give your users a way to install a modified copy. If you're trying to ship a secured product, that basically means that you have to give code/rootfs signing keys to your customers. This is a non-starter for many kinds of products that need tamper protection (whether for product, legal, or safety reasons).
The Linux kernel remains on GPLv2, and is still used quite heavily. Most GNU software (coreutils, gcc, etc) moved to GPLv3 and then commercial companies abandoned them in favor of permissively-licensed replacements.
> If you're trying to ship a secured product, that basically means that you have to give code/rootfs signing keys to your customers. This is a non-starter for many kinds of products that need tamper protection (whether for product, legal, or safety reasons).
Fuck that. If it's my device then I want to have control. If I want to violate part 15 of the FCC rules then I'm going to do it and nobody is going to stop me. This paternalistic rubbish has to stop, I'm sure your company would love to retain ultimate control of the thing you've sold me, but that's not compatible with a free society.
"remote"? No. I want my driver-assistance ECU to be air-gapped but fully reprogrammable locally. After all, even with a totally tivoized ECU, a physically present attacker could still make my car kill me by cutting my brake lines.
> while at the same time hosting all of their services on different flavors of Linux.
That linux uses GPL is entirely irrelevant to the vast majority of uses of it. What hosting services are customizing their kernels with proprietary code?
See also, FreeBSD: Plenty of commercial offerings around it, no source for most of them, because the license doesn't require it. For example, there's no source for the Playstation kernels/userlands released by Sony. They only upstream some bug fixes that would be too onerous to keep in their private fork.
In order to build a custom Rom, you need three things: the kernel tree, the device tree, and the binary blobs.
The binary blobs can be extracted from a running phone.
The kernel tree is GPL-licensed, so almost all phones have kernel trees releases, and if they don't you can ask the manufacturer for it.
The device tree on the other hand, is created from scratch for each phone. As such, there is no pre-existing license, and therefore no legal obligation to release device tree sources, so almost no manufacturer does. The only notable exception is Google with their Nexus and Pixel phones. (But this has stopped since with the Android 16 release)
We can safely assume that the manufacturers that don't release the device trees, wouldn't have released kernel trees if they weren't obliged to.
But adding support for a device to the Linux Kernel requires _huge_ reverse-engineering efforts. This is why there's still no fully functional Android build for iPhones.
Some have "interoperability exceptions" - so if you have been granted a license to something, you can reuse it in different context (so for instance you could run Microsoft Office on WINE even if Microsoft's license forbids it).
Some have restrictions on redistribution (but the builds just using the blobs from the old filesystem are fine).
A lot of that is in the gray area, and for that very reason many builds don't actually redistribute blobs - they extract and reuse them live.
Not at all. We have a lot of experience with this with such licenses and other software. BSD as just one example. Not only do we have a pile of emperical evidence, it's also a priori obvious: they're not going to expend any effort or take any risk if its not neccessary. They can just benefit without paying.
Easy see the upstream contributions from any commercial vendor that has integrated BSD into their UNIX flavours, or the alternatives that exist nowadays for embedded FOSS operating systems, none of them GPL.
> I can get the source of the kernel, including all drivers, running on my android phone with a few clicks and build a custom ROM.
No, most drivers are closed source and you can just extract binary blobs for them. They run as daemons that communicate through the binder ipc - Android basically turned the Linux kernel into a microkernel.
The GPL is the reason we have Android custom Roms today.