Tweak "pinned dependency" discussion

[david-a-wheeler]

The Pinned-Dependency discussion has a number of problems.

First, it doesn't even define the term. Let's fix that.

Next, it WAY oversells what
pinned dependencies can do for you. All they do is fix the
dependency. They don't really prevent compromised dependencies;
if you pin an already-compromised dependency, you make it worse,
because now you don't automatically update to the corrected
dependency if there was a later non-malicious version.
It often slows automated security updates, so they can actually
cause a reduction in security (since most updates fix
security vulnerabilities instead of introducing a compromise).

In particular, pinned dependencies are usually a good idea for
applications but you should NOT pin dependencies in libraries.
If a library pins to a version, and the library is only updated
1/year, and the ecosystem requires only 1 version of a library
(true for practically all except JavaScript), users can't update any
dependencies more than 1/year (and in practice they'll never be aligned).
At least a hint of the downsides of pinning should be admitted here.
For a larger discussion, see, for example,
https://docs.google.com/document/d/1x_VrNtXCup75qA3glDd2fQOB2TakldwjKZ6pXaAjAfg/edit#

A better argument for pinning is the reproducibility it brings
when using pinning inside an application. I suggest focusing on
that first.

Pinned dependencies are still typically a good idea for applications,
but they should NOT be oversold.

Signed-off-by: David A. Wheeler dwheeler@dwheeler.com

[david-a-wheeler]

I believe I resolved @laurentsimon 's comment.

[azeemshaikh38]

We need to update checks.yaml not checks.md. I'm a bit surprised that the pre-submit didn't catch this.

[laurentsimon]

Good catch... I did not even realize it when reivewing. @david-a-wheeler can you send a new PR? Update the yaml file, then run make generate-docs.
@naveensrinivasan do you know why pre-submits did not catch the problem?