A private cloud is when a (usually large) organization creates a cloud computing infrastructure for internal use by its various departments, thus avoiding the security and "our core business depends on someone else's hardware" concerns.
Other than the fact that Erlang was specifically developed to be run in concurrent/parallelized/distributed situations, the two main techniques that it employs making this possible are:
No side effects
This means, when you give a function a piece of data to execute against, it will not except in very strict cases affect anything else in the system/running process. This means that if you execute a function 300 times all at once concurrently, none of those 300 executions of the function will effect any of the others.
The implementation technique for ensuring no side effects is called "immutability" which roughly means, may not be mutated(changed). This means that as soon as you create a variable, the value of that variable may not be modified. Erlang implements this behavior with "single assignment" so after you assign a value to a variable, you may not assign a value to it again.
X = 1.
X = 2. // This is not a valid operation
This ensures no code may accidentally change the value of X causing a race condition, therefore it is inherently thread-safe and concurrent use becomes trivial. This is a very uncommon behavior among software languages and the biggest way Erlang manages to be so well suited for concurrent execution.
The actor model
This is a particular way of modelling that has shown to make the implementation and management of concurrent processing very simple for developers. Straight from Wikipedia:
The Actor model adopts the philosophy that everything is an actor.
This is similar to the everything is an object philosophy used by some
object-oriented programming languages, but differs in that
object-oriented software is typically executed sequentially, while the
Actor model is inherently concurrent. An actor is a computational
entity that, in response to a message it receives, can concurrently:
send a finite number of messages to other actors; create a finite
number of new actors; designate the behavior to be used for the next
message it receives. There is no assumed sequence to the above actions
and they could be carried out in parallel. Decoupling the sender from
communications sent was a fundamental advance of the Actor model
enabling asynchronous communication and control structures as patterns
of passing messages.
Best Answer
tl;dr
As other answers have said, it's an application that is designed to run in the cloud and not just adapted later to shoehorn into the cloud. It's mainly a marketing term, not so meaningful in technical terms.
Product Manager Perspective
As a commercial product manager, I find it occasionally a useful concept because the customer generally wants to feel that he has bought a product that's better than the alternatives, or that is at least "authentic" and not a fake. So product marketers tend to conveniently define this in ways that make make as many competitors as possible sound non-authentic. In some industries the usefulness of this tactic is long over. Everyone is Cloud.
Developer Perspective
As a software engineer the term is pretty ineffective for conveying technical information. It relies on the audience's perceptions, opinions, and knowledge of Cloud based applications. Since the essence of delivering a cloud based product is that customers should have a great experience without worrying about the implementation details, a product that achieves that should seem native to the customers.
Having built commercial products for the cloud from the ground up, and having architected migration of large pre-cloud products to the cloud, I can say that in each case the provenance of a product is not all that predictive of how the cloud version will turn out. One pre-cloud product set I worked on had major problems getting to cloud with effects quite apparent to customers and in terms of infrastructure and devops costs. Another was a relative cake walk and once migration is complete no one would ever have to know where it came from.
Software designed for the cloud from day one is not always 'well designed' for the cloud. It often perpetuates assumptions that are not particularly scalable or serviceable, overlooks security or isolation concerns, or does not deliver the benefits typically associated with Cloud.
Is There an Authoritative Reference?
There's no universally accepted standard list of properties to define a 'Native Cloud Application'. If you seek a fairly neutral definition of Cloud Computing, there's always the NIST Definition from the US Government. Already feeling a bit old after four years. It outlines five characteristics...
Notice it does not appear to mention things that are often seen as essential to Cloud-ness, such as...
So I would suggest you look at it this way...Does the product deliver the characteristics of a cloud application, including NIST's characteristics and any that are important to you. That UI characteristic has always turned out really important to me.
Also, especially if you are buying the company, or just joining as an employee, consider whether the product has behind the scenes problems for devops, security, infrastructure costs that would not be there if it had been designed well for cloud.