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 resulting file 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 "nonreciprocal"
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 nonreciprocal -- highlight what matters most to developers and avoid unintentionally confusing the issue. I recommend their use.
This article, "Open source needs to clean up its language," was originally published at InfoWorld.com. Read more of the Open Sources blog and follow the latest developments in open source at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.