[duped]

> But for some reason, we dont do this with computer programs

I'm unsure what you mean here. It's pretty foundational to the structuring of programs hierarchically (eg, trees own their children, functions own their variables, closures own their environments, and so on).

The classic argument against ownership as a language semantic is that it doesn't play well with graphs and circularly linked lists, where there isn't a meaningful hierarchy and therefore no one ancestor is the "owner" of any descendant. The counterargument is that these datastructures are both rare and better represented with a single owner of the data and the relationships represented through indirection even if your implementation language doesn't enforce ownership (for example, adjacency lists/matrices for graphs, vectors for lists, etc).

[ki_]

I just meant that 99% of software was written without the idea of ownership. Sure, we had objects containing other objects, but i dont see that as "ownership".

Interesting arguments. Thanks.

[duped]

The term might be a bit new now that we have some work that seeks to establish a formalism for it, but the concepts are very old.

A modern definition could be that ownership semantics define how aliases to data are created and shared. This includes things like variable binding and class members, but also encapsulates pointers and references - which have formal semantics in every language that uses them (and therefore, bake in ownership, even if it is implicit).

In systems programming languages like C and C++ the word "owner" and "ownership" are often used to describe which data structures and calling contexts are responsible for managing data lifetimes, since aliases to that data are used to control memory allocation and deallocation. The semantics are not baked into the language, but most software in these ecosystems has to be written with ownership in mind to be sound - and indeed, has been for many years, with that verbiage ("lifetime", "owner", etc).