Using the term “permissive” as an antonym to “copyleft” – or “restrictive” as its synonym – are unhelpful framing. Describe license reciprocity instead.

Some open source licenses implement a clever hack invented by Richard Stallman where, as a condition of the copyright license, anyone creating derived versions has to agree they will license the new version the same way as the original. In a play on words, this concept is called “copyleft” and many open source licenses implement this hack.

In its strongest form, the “copyleft” idea can place a condition on the licensing of all the other code compiled together to make the eventual binary executable program. Complying with this requirement can prevent use of business models that deny software freedom to the end user; as a consequence, many commercial software developers avoid the strongest forms of copyleft licensing.

There are less stringent forms of copyleft. Licenses like the MPL (Mozilla Public License) only require individual files that are modified to be licensed under the same license as the original and don’t extend that requirement to other files used to build the executable. The Eclipse Public License (EPL) has a copyleft provision that’s triggered by distribution of the source code. These scope-restricted variants are all described as “weak copyleft.”

In discussing these licensing approaches with clients, I’ve often found that these terms “strong copyleft” and “weak copyleft” lead to misunderstandings. In particular, developers can incorrectly apply the compliance steps applicable to one “weak” license to code under another license, believing that all such licenses are the same. As a consequence, I prefer to use different terms.

Instead of “copyleft” use “reciprocal licensing”

First, I try to address the challenges introduced by the clever, often unfamiliar term “copyleft.” The demonisation of copyleft by certain factions in the open source movement — who may even erroneously term such licenses “restrictive” —  has made it appear more problematic than it really is. Instead, I explain that the communities involved have norms based on reciprocal behaviour and expect those working with their code to share with others the same freedom to innovate as they have received.

Leading licensing lawyer Eben Moglen (key co-creator of the modern GPL) explains that open source licenses embody the norms of the communities that use them. They are in many ways the “constitution of the community,” so the embodiment of norms of reciprocity is to be expected. I refer to this aspect of the license as “reciprocal licensing” in an effort to acknowledge the use of copyleft to express the community expectation of reciprocity. I’ve found this term leads to less confusion.

Instead of “strong” or “weak” copyleft, describe the reciprocity scope

Second, I have found that the terms “strong” and “weak” are not well understood and less well defined. What really matters to developers is the expected scope of the reciprocity by the community that’s involved. This does not always mean contributing code to a project; for example, the GPL only requires that a developer offers to make code available to recpients of the binary on the same terms as the original, for a limited time per release. But reciprocity does mean that consistent licensing must be maintained.

This concept helps my clients 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” categorisation 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 categorise reciprocal licenses by the scope and nature 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 categorisation proves helpful with LGPLv3, which is a project-scoped reciprocal license with an exception limiting the boundary of the project.

Licenses like MPL 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 code base, 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 “non-reciprocal”

Thirdly, licenses like the MIT, BSD, and Apache licenses are sometimes described as “permissive.” That’s a bad word to use to differentiate any open source license. Open source licenses come complete with permission to use, improve and share the software for any purpose, so long as the license conditions are met – they do not restrict use until you have completed negotiation or payment to secure permission. All open source licenses are thus permissive, unlike proprietary licenses which are by nature restrictive. Just as with reciprocal licenses, the communities involved have different expectations and embody them in their licenses. While they may not include reciprocity, they may still include conditions it would be foolish to ignore.

For example, so-called “permissive” licenses may still include specific actions regarding attribution, or grant expansive patent licenses. They may also fail to include any terms concerning patents, creating risk. These attributes may also affect the business models a client can use, just in different ways to reciprocal licenses. 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. If the other conditions are important to you, tag those as well (or instead).

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 instead of “permissive” and “weak/strong copyleft” or “restrictive”.

(A shorter version of this article was first published in InfoWorld, November 2013)