It can be available also as part of a deposit.

I propose "Typical sources for extrinsic metadata are: the hosting place of a repository, which can offer metadata via its web view or API; external registries like collaborative curation initiatives; and out-of-band information provided at source code archival time."

That should address @moranegg concern and it feels pretty clear to (the biased) me.

s/provided/available/

(sorry, this issue come from my suggestion, i know, but it didn't make sense that way :))

"Since they are not part of the source code, a dedicated mechanism to fetch and store them is needed."

missing trailing '.'

they can provide metadata about different software artifacts, here we deal with origins, but the authorities aren't specifically related to origins.
i would change origin to software artifacts.

s/code hosts/code hosting places/

It's not the deposit client that has the metadata, that is just a dumb software component; it's the person doing the deposit who has them.

Hence, I suggest to use "deposit submitters" here instead.

"moral entities" is a false friend from french; just use "entities", I guess?

Having a non ambiguous name here would be helpful to streamline language. From this text I'm assuming you'd be ok with "metadata fetcher"? (It's OK with me.)

Hence, s/Metadata fetching tools/*Metadata fetchers*/ here.

Echoing my previous comment, the authority here is the deposit submitter. As we don't' have their identity, for the purpose of the authority table we should probably just use "deposit" here.

is there a reason gatherers doesn't have the :term: item?

gatherer v. fetcher starts becoming clumsy.

How about "metadata crawler" here?

I'm open to other suggestions if that doesn't work…

what does the "_by" adds here? wouldn't metadata_authority_get be better/clearer?

"_by" → ditto

I don't like future uses and arbitrary.
I propose delete arbitrary and change to:

With authory, the metadata field is reserved for information describing and qualifying the authority.
With tools, the metadata field is reerved for configuration metadata and other technical usage.

given they're (correctly) grouped together in the result dictionary, maybe you want to also group them together here authority_name/authority_url (as a pair) and same thing for fetcher_name/fetcher_version

(unless, dunno, this is mapped to an HTTP API somewhere and it's easier to avoid the packing

conceptually they are really two things a fetcher and an authority, so it'd make sense to have 2 args instead of 4

I think a [ ] and adding a second origin_metadata entry, can clarify.

[{
  'authority': {'name': ..., 'url': ...},
  'tool': {'name': ..., 'version': ...},
  'discovery_date': ...,
  'metadata': b'...'
},
{
  'authority': {'name': ..., 'url': ...},
  'tool': {'name': ..., 'version': ...},
  'discovery_date': ...,
  'metadata': b'...'
}]

the term deposited is too connected to the deposit and here seems that you talk about all authorities.

Did you mean, that a list of the latest origin_metadata entries for a given authority is returned instead of all origin_metadata entries?

also, this explanation should come before the example.