I kind of get what it means, but not enough to explain it by myself. Is a key concept when talking about the MVC pattern and it's giving me problems to explain that concept too.
In layman's terms:
Imagine this: in the eighties you wrote a piece of software that allowed people to track their personal finance. That software showed reports in text-only mode in a phosphor screen and saved data to diskette files.
Later in the nineties you rewrote the program to work in Windows graphical environment. You had to make cool windows and dialog boxes and accept mouse input, and save the info into MS Access files. That part that does the financial tracking didn't change a lot, you had to re-write in another language, added some adjustments but the most part didn't change a lot.
Then in the 2010's you rewrote the app to be web based, and data were stored in a MySQL database in some cloud. The financial tracking part of the software didn't change in a dramatic way, it improved, maybe you had to translate it to a more modern dialect but taking good care not to break it. It continues to be based on the things your grandpa taught you before computers were mainstream. Your grandpa was an accountant and he knew how to do all the financial stuff with just pen, paper and a desktop calculator. The knowledge of your grandpa is what you put in your software to begin with in the form of rules, legal ordinances, workflow, algorithms, conditions etc.
Well, the part of the software that changed the least in all that evolution is what we call business logic. The part your grandpa knew how to do manually. We used to call it know how, business rules, etc. Now, in the software world, the part of the source code of a program that does the calculations and applies conditions and transformations if called business logic.
Business logic is presentation-agnostic and persistent-agnostic. Meaning it doesn't care whether a report is shown in an iPhone screen or printed to a dot matrix printer, and it also doesn't care whether the data is saved to files, to the cloud or has to be typed every time by an operator.
"Business Logic"* is the part of your application which deals exclusively with the rules, processes, and algorithms that are necessary in order to solve the problem at hand (in other words, for the application to fulfill its raison d'être) without any concern whatsoever to peripheral concerns such as precisely how to receive input from the user, precisely how to present stuff to the user, precisely how to persist stuff to the database, and in general, without any concern to the nitty-gritty technical details of how to convince the machine to perform the low-level operations necessary in order to solve the problem.
* I prefer the terms "Application Logic" or "Domain Logic".
In MVC, the Controllers are very application specific. So the Business Logic should stand inside the MODEL for reuse.
MVC could also mean that the "Controllers" encapsulate the business logic for the "Views". Views in this sense are skinny, Models can be skinny or fat (depending on the validations and data-specific calculations needed), and Controllers handle the functionality container by the Views (the when/where/how).