Useless debate. They are usually used interchangeably and there is nothing wrong in that.
Modules/components can be viewed as a collection/group of related code including variables, functions and classes. In modern programming languages, related code is usually bundled together in namespace, package, scope, etc. A couple of modules/components are then packaged together in a library, sdk, executable, etc.
Refers to the degree of dependency of the execution units on each other within a single module. Ideally whatever is needed by an execution unit in a module should be available in the same module. A module with high cohesion has limited responsibilities or the module serves a very limited set of related purposes. A highly cohesive module is self contained and has fewer reasons to make calls to other modules. A module with low cohesion, on the other hand, serves a multitude of purposes in a haphazard manner. A low cohesive module is usually forced to call other modules to meet its goals. Higher cohesivity is a desirable trait that modules should strive to achieve.
Refers to the degree of dependency between multiple modules. Two or more modules with a great degree of interaction between them are referred to as tightly coupled modules. Higher coupling makes the system more complex, difficult to test, debug, change and manage. Two or more modules with only a limited interaction between them are called loosely coupled modules.
High cohesion + Loose coupling is the way to go.
Concern is a generic term for a purpose/functionality performed.
In designing software, separate concerns into distinct units like classes so that each unit is more flexible, maintainable, reusable and extensible. A software unit should have one and only one responsibility. Another way to say this is that there should be one and only one reason to change the software unit. This principle often increases cohesion.