I still think the documentation should be changed, and an improved version would look more like your comment than what it looks now.  I assume to most people "owning" means exclusively holding the lock, and a particular thread can do this for Lock Objects.  For example, here what my #1 Google result for "lock ownership" (https://www.justsoftwaresolutions.co.uk/threading/locks-mutexes-semaphores.html) says:

> What it means to "own" a lock depends on the precise type of the lockable object. For some lockable objects...  In other cases, the definition is more fluid, and the ownership of the lock is more conceptual. In these cases, ownership can be relinquished by a different thread or object than the thread or object that acquired the lock.

In my opinion, the Python documentation currently takes the unusual point of view "a thread cannot 'own' a lock since it could be 'stolen' (released) by another thread."  And the Lock Objects documentation has no explanation for this view, which makes it possibly confusing.  Since multithreading is often tricky, documentation improvement seems worthwhile.  Happy to propose wording that incorporates our discussion if you are interested.