This concept helps in the case of the LGPL. That license is often described as a "weak copyleft" license since it allows combination of the resulting binary with non-GPL-licensed works (unlike the GPL itself). But the "weak" categorization is unhelpful as it means different things in different contexts.
LGPL is not "weak" in the same way MPL is, for example. Code from an LGPL project itself is fully reciprocally licensed at a project level. Any code borrowed from it for other uses as well as any alternative uses of the project itself are expected to be fully licensed under the same LGPL. Within the project itself, LGPL is "strong copyleft" just like GPL code, but the resulting executable does not necessarily have "strong copyleft" requirements — it's effectively non-reciprocal in many uses.
I prefer to categorize reciprocal licenses by the scope of the expected reciprocity. Licenses like GPL and EUPL set the scope of the expected reciprocity to include any code needed to create the resulting project binary, so I describe these as "project-scoped reciprocal licenses." This categorization proves helpful with LGPLv3, which is a project-scoped reciprocal license with an exception limiting the boundary of the project.
Licenses like MPL and CDDL set the scope of the expected reciprocity to the individual source files within the project, not the whole project collectively. If you change a file that's part of the project, or reuse code from a file in the project in a new codebase, the resultingfile must be licensed the same way as the original file, but there are no requirements placed on other files combined together to create new executables. I refer to these as "file-scoped reciprocal licenses."
Instead of 'permissive,' use 'non-reciprocal'
Thirdly, licenses like the MIT, BSD and Apache licenses are sometimes described as "permissive." This tends to disguise the fact they include strong terms requiring specific actions by developers using the code in them; those terms simply don't include reciprocity requirements. Consequently, I find it more helpful to describe them as "non-reciprocal licenses" so that the classification is clearly limited to just the reciprocity characteristics of the licenses.
In practice, I have found that these three terms — project-scoped reciprocal, file-scoped reciprocal, and non-reciprocal — highlight what matters most to developers and avoid unintentionally confusing the issue. I recommend their use.
Sign up for CIO Asia eNewsletters.