IMHO, static linking, be it using a mechanism alike what npm is doing
or be it plain-old static linking of binaries also means "you link
it, you own it".
For every package, you link statically, you as the parent package
owner become responsible for all security flaws of all the packages
you link statically.
And by "responsible" I mean: Every dependent security announcement of
a dependent package also becomes your security announcement.
If you're AWESOMY 1.1 and you link statically against openssl and
openssl announces a security flaw, then you better and quickly
release AWESOMY 1.1.1 with an accompanying security announcement too.
Are you willing to do this? Do you trust the chain of dependencies
all the way down to also be willing to do the same?
As a responsible developer, I'd much rather delegate that
responsibility away to a packager or even the user, especially with
well-known libraries like openssl.
If I'm owning AWESOMY 1.1 and link dynamically against openssl, then
I don't have to do anything when openssl releases a security
announcement. I can, if I want to, inform my users to maybe update
openssl, but with some likelihood they are already doing this anyways
for some other package.
For me as a developer, this is considerably more convenient.
Yes. Static linking has huge advantages for me as a developer too,
but it also comes with a great many additional responsibilities I'm
personally not willing to take on, also because I don't trust my
dependencies to be as diligent about their dependencies.
Y lo mismo les pasa a todas las soluciones de "containerización" para
distribuir aplicaciones standalone que se están proponiendo por ahí:
¿va a mantener cada aplicación por separado todos los bugfixes críticos
de todas las bibliotecas estáticamente compiladas que use? Porque, por
ejemplo en el caso de unas aplicación de escritorio, esas son muchas
bibliotecas por aplicación de muchas aplicaciones a mantener...