I've worked on a number of embedded systems for clients that prefer not to allow for user modification of libraries or system code. You know, that TiVo-ization stuff. Many of them are more than happy to comply with GPL2, but have banned GPL3 code from their companies altogether.
My current bane is BlueZ, which used to allow for a compile-time removal of readline but no more.
That's fair enough, though OP was referring to command-line tools, not libraries.
He was basically saying that seeing readline pulled as one of the dependencies gives him confidence that the tool won't suck. He said nothing about building tools with readline support (implicit or otherwise).
Do they actually use features like ARM trustzone and encrypt the firmware? I'm trying to get my router to do things it should be able to do and it seems like they mostly concentrated on making getting serial accesss more annoying but the rest is just an ancient BSP linux distro with minor changes using none of the actual security features of the SoC.
Ah, sure. Yeah, I could see how GPLv3 code would be inconvenient for a company that wants to ship it without complying with the license. The companies I've worked had a different profit model so it never affected me. In my case, seeing readline just means that the development tool I'm using will be more pleasant to work with.
It's not BlueZ's license that is the problem, it's readline's license which BlueZ unconditionally pulls in. I wonder if they considered just stubbing out the functions, or if any of the more liberally licensed libraries (editline, tecla) have compatibility headers?
My current bane is BlueZ, which used to allow for a compile-time removal of readline but no more.