How Additional Permissions (aka Exceptions) Impact a Project's License
byon October 20, 2017
When first learning about FLOSS (Free, Libre and Open Source) licenses,
most of us learned them by their specific names, and generally when someone
What license is your project under?, the answer is a short
GPLv3-or-later. However, since the
earliest advent of FLOSS licenses, the concept of “additional
permissions ” — or, the older term for it:
“exceptions” — have been an essential part of the
licensing infrastructure of our community.
The first additional permission for a copyleft license dates back to the Bison license. Since the 1980s, the GNU project gave an exception to the GPL for Bison to assure that typical uses of Bison — which copy some of Bison's own source code into the program's output — did not cause the GPL to apply to that output. This exception was simple, straightforward, and necessary. Users of parser generators would be surprised to learn that using Bison to generate their parser would cause their work to be governed by copyleft. Additional permissions are a scalpel-like tool for authors of copylefted software that carefully craft project policy to best fit their community. Indeed, these exceptions became such an important component of GPLv2 licensing that GPLv3 formalized the concept in the actual license text, defining the term “additional permission ” in GPLv3 itself.
This name better described the purpose of these clauses. Historically, the FSF called them “exceptions”. Throughout the 1990s and early 2000s, software authors deployed these solutions in creative ways, and it became clear that the phrase “license exception” was a poor descriptor (particularly given that “taking exception” is often considered a bad thing)! Slowly, the term “additional permission” became preferred.
Additional permissions are now quite prevalent. Some pursue esoteric policy goals, but most are simply stated and achieve a narrow goal. While additional permissions often make it impossible to name a project's license as simply “GPLv2-only”, the intended policy is usually clear by quickly reading the additional permission(s).
By way of example, despite our common shorthand of saying that Linux's
license is GPLv2-only, the details are more complicated. Linux's license has a
additional permission regarding syscalls. Specifically, this
additional permission states that the copyleft terms
do not cover user
programs that use kernel services by normal system calls. This means
that even though GPLv2 is a strong copyleft and seeks to apply to any
derivative and/or combined work with Linux under copyright, downstream may
license parts of combined works that
use kernel services by normal
system calls under terms other than GPLv2. While some contributors'
code in Linux is licenses without this additional permission (such as plain
GPLv2-only), most Linux contributors license their copyrights under
“GPLv2 with the syscall exception”.
This week, the Linux community began a process to add another additional permission to Linux's license. As with the syscall exception (and any other additional permission), copyright holders must opt-in to grant this additional permission (and a long list of copyright holders have already done so for the new Statement). Conservancy has lauded this effort, since this additional permission allows violators (in some cases) to officially receive permission from those copyright holders to operate under the GPLv3 termination provisions. Copyright holders who participate in Conservancy's GPL Compliance Project for Linux Developers have long followed this, anyway (first informally, and then more formally in adherence to our Principles of Community-Oriented GPL Enforcement). The Linux Kernel Enforcement Statement formalizes this practice as an opt-in additional permission for Linux's license.
Fortunately, copyleft-based additional permissions (aka license
exceptions) aggregate reasonably well. Specifically, additional
permissions are fully compatible with the main copyleft license. At their
option, downstream can usually remove the additional permission and
distribute under the main license. Sometimes, licensing experts will talk
effective license of a work. In practice this means:
given a codebase that combines copyrighted material under many different
licenses, and possibly many different additional permissions and
exceptions, what's the lowest common denominator licensing requirement
that, if met, will satisfy all the licensing requirements of all of the
relevant licenses? With most copylefted works, this often does simplify to those easier
This begs the question: what's the effective license of Linux? Well, more than likely, it's simply GPLv2-only. The reason is this: all the copyrighted code that comprises Linux is (at least) licensed under GPLv2-only. A overwhelming majority is under “GPLv2 with the syscall exception”, and (with this week's announcement) an ever-growing swath will be licensed under “GPLv2 with the syscall exception and with the Linux Kernel Statement additional permission”. Not every copyright holder whose code is in Linux will grant either exception. Thus, the abbreviation to GPLv2-only, as a moniker for Linux's effective license, remains accurate.
Additional permissions are handy tools when building a community around a codebase, particularly when some community members have reservations about some aspect of the standard copyleft license. Copyright holders can grant an additional permission — even one that isn't strictly necessary — to quell concerns and clarify the licensing infrastructure.
Finally, all this begs one more question: Why aren't additional
permissions to copyleft licensing (particularly after they were formalized
in detail as part of GPLv3 itself) more widely utilized? My anecdotal
theory is that licensing remains a difficult area of comprehension for
FLOSS contributors and adopters. Like everyone whose primary expertise
lies elsewhere, licensing novices prefer simple buckets that are easily
understood; difficult concepts often dive deeper than necessary for typical
daily work. While licensing geeks like me enjoy pondering and exploring
the flexibility provided by additional permissions, many developers prefer
a simple moniker to describe a project's license. As such, you'll even
hear licensing experts oversimplify to describe a project's license. As
one of my undergraduate Computer Science professors said to me,
professors will oversimplify until you're graduate students, because we've
yet to figure out the topological sort necessary to tell you the whole
story in proper order such that we avoid these oversimplications that make
Please email any comments on this entry to firstname.lastname@example.org.