I’m no expert, but I’m fairly sure that Frenk’s license has to be compatible with home assistance’s license for it to be included. If home assistance has a normal OSS license, I doubt it can use a dependency with a very restrictive license. (Such as one with a list of what can use it!) In other words, I don’t think it’s possible form him to transitively make home assistant’s license more restrictive.

Home Assistant itself uses the Apache 2.0 license, which is pretty permissive. It doesn't impose much requirements on derivative works, so it can use a dependency with a restrictive license without problem.

However, this would become problematic if Home Assistant also uses a GPL dependency (which it probably does). That dependency would impose a requirement that all other libraries used by Home Assistant use a GPL-compatible license (which his license likely wouldn't be).

> Pinning every Python dependency instead of fetching HEAD is how you get local control and security!

yes it is? they make sure the user get a specific version that is (hopefully) vetted and know as working properly; this is much safer than pulling HEAD for a 3th party repo. As long as the libs are updated regularly and when security issue are found, I see no problem with this approach

> he has the right to transitively make Home Assistant un-packagable on NixOS?

Pretty sure a custom license is not compatible with the Apache 2 license of "Home Assistant"; also as the code is in use by a third party, the author should not be able to retroactively change license, only next releases. Probably will be forked or removed depending on the specific of the case and of the code.

> they make sure the user get a specific version that is (hopefully) vetted and know as working properly

This is exactly what nixpkgs maintainers do, using more reliable and explicit tools than the likes of pip. A significant effort is made to enable tests on as many packages as possible, meaning that when you get a package from nixpkgs, it has been tested against the exact dependency chain (down to the libc) it is being shipped to you with. If tests fail, issues are investigated and solved.

This is a far stronger guarantee than you get from almost any other installation method.

there is a reason if pretty much all distribution follow this approach :)

No they don't. Debian etc don't trigger a full rebuild every time they add a patch to libxml2.