This is an in-depth dive into the peculiarities of software licensing and copyright, and how ambiguous software licensing can be avoided in your project.
Software licensing - particularly Open Source software licensing - allows developers to integrate existing software into new software.
Under the Berne Convention,
copyright (and/or author’s rights) exist from the moment that any work is “fixed”
(eg: code is written). To avoid a successful claim of copyright infringement,
you must have permission to use the work.
For software, permission is usually granted to use or distribute work under copyright in the form of a license.
The author retains copyright, but agrees to allow others to use and distribute the work under a license -
a legally binding contract that sets the terms of how the software may be used and distributed.
As with any other contract, terms of the license are binding to all parties -
that includes the copyright holder, developers, distributors, and users of the software.
Without a license to use copyrighted software, you are at risk of a civil claim
for copyright infringement. In many jurisdictions, that matter becomes criminal
(eg: under the Copyright Act 1968 in Australia)
if you make, sell, trade, or import copyrighted software
(eg: as part of a published app, or JavaScript bundled in a website).
Another less-common way that software is released for wide use is when
the author explicitly waives copyright and releases their work into the
public domain.
Tip
Placing works into the public domain is known to be very difficult in some jurisdictions.
The CC0 license was created
“to give creators a way to waive all their copyright and related rights in their works to the fullest extent allowed by law”.
What does a license do?
Licensing sets the rules for how existing software can be integrated into new software.
The questions below explore some themes of how licensing affects software:
Can I integrate this software into my proprietary application?
Do I need to credit the authors?
Can I sell my software?
Does this library force licensing my application in a particular way?
Are license royalties (and/or other fees) payable?
Do I need to make my changes available to others?
Must I provide the source of my application to my users?
Depending on the needs and goals of your project,
desired answers to the questions above will vary,
and different licenses will be more or less appropriate for your project.
What is license ambiguity?
A license identifier is ambiguous when it doesn’t uniquely identify which specific license, variant, and exceptions apply to a piece of work.
License terms are ambiguous when it is unclear if they should be applied in a specific scenario.
A common example of license ambiguity in open source relates to versions and variants of “the GPL”.
Developers often talk about “the GPL” as if it’s one license, but there are actually six common GPL variants found in the wild.
Do we need to use any licensed software?
Some organisations prefer to avoid licensing dramas by only using software developed in-house.
This may be a valid strategy, as long as you’re careful to avoid copyright and patent issues.
Writing everything in-house may be a
good thing, or it can be seen as
something to be avoided.
At the opposite end of the “licensing risk spectrum” is wilful disregard for all license terms,
making you liable for copyright infringement.
Between these extremes is the careful use of software within any license terms.
Which strategy is best for you comes down to how much appetite you have for risk (and the risk/reward payoff).
Software licensing risk spectrum
←ConservativeBalancedHigh-risk→
Using licensed software (eg: libraries):
Avoid all third-party software.
Purchase proprietary software.
Use “permissive” licensed software.
Use “copyleft” licensed software.
Disregard all licensing terms and risk potential consequences.
That’s entirely up to you, and it depends the goals of your project.
If you’re wanting to work with an existing software community, it’s generally a good idea to adopt the license that community is used to.
Otherwise, I strongly recommend you choose an existing license from the SPDX License List.
Note
Avoid the temptation to write a new license, or even to modify an existing license by changing/adding/removing license terms
which effectively creates a new license.
You will need legal advice if you create a new license, since license are
legally binding contracts between authors, developers, distributors, and users.
I’m not advocating that you must embrace the “copyleft” movement and viral licenses such as the GPL v3.0,
nor am I suggesting you should use the most “permissive” license available such as CC0.
You can, but I strongly recommend against applying more than one license.
My biggest concern is about the ambiguity surrounding which of the multiple licenses should apply in any situation?
If I miss a license payment on proprietary software which is also also under licensed under the GPL,
do all the terms of the GPL now apply?
Can I enforce GPL terms and get source code for paywalled features, when dual licensed and fully paid under a proprietary license?
Another concern is that by combining licenses, you will likely end up with what is effectively a new license.
The combined terms and conditions and interactions between each license should be reviewed by a lawyer,
to avoid any unintended contractual consequences.
A clear example of unintended interactions is how the GPLv3 “further restrictions” clause
nullifies “all other non-permissive additional terms”.
Why are we only learning about license ambiguity now?
The truth is that licensing ambiguity has been a known problem for decades.The issue persists because many developers still don’t understand the problems that flow on from ambiguously defined software licenses.
So, if license ambiguity has been a thing for decades, and the world hasn’t stopped spinning, why should I care?
Story time!
(aka: A case-study into licensing of the official Linux Bluetooth stack.)
Way back in May 2001 an exciting new project (BlueZ) was announced that would
bring Bluetooth functionality to Linux (and eventually to Android as well).
It was announced with the intention of using the same license as Linux itself:
“for Linux under GPL license”.
In October 2005 the license was changed,
possibly by accident, and probably under the impression that the new license would be “better” than the old version.
The reality was that the version 3 of the GPL wasn’t released until June 2007, almost 2 years later.
And while it might have been “better” for some people, any change in license terms can have both positive and negative impacts for everyone involved.
The Tivoization was always my main dislike of version 3, and the FSF was
being very dishonest saying “hey we actually allow you to invalidate the
Tivoization clause”, and they literally lied to people and said “hey so that
means that you can use GPL version 3 without the Tivoization part”.
License terms are ambiguous when it is unclear if they should be applied in a specific scenario.
Avoid multiple licenses if at all possible! If your project is available under multiple licenses, make the conditions of when a particular license applies very clear.
An example scenario
For the purposes of an example, let’s assume the following scenario:
We’re working for a company that is building software that to run on a streaming TV set-top-box.
Our company wants to charge streaming services (such as Netflix) fees to make their software available on our platform.
License
Our company might like that the GPL forces derived works to make their source available, so improvements may be incorporated back into our own project.
So lets use “the GPL” - but we’ll do it properly!
We’ve selected a license, now we need to select a variant.
Variants
You’re probably familiar with license versions, but often there subtle variants hidden in the fine print that often result in different variants within versions.
Terms and conditions of the GPL version 1 includes the following:
Each version is given a distinguishing version number. If the Program
specifies a version number of the license which applies to it and “any
later version”, you have the option of following the terms and conditions
either of that version or of any later version published by the Free
Software Foundation. If the Program does not specify a version number of
the license, you may choose any version ever published by the Free Software
Foundation.
Given the same clause exists (with some changes) on all 3 versions of the GPL currently published, we effectively have the following six variants of the GPL:
GPL-1.0-only (GPL-1.0) - version 1.0 only.
GPL-1.0-or-later (GPL-1.0+) - version 1.0 or any later version.
GPL-2.0-only (GPL-2.0) - version 2.0 only.
GPL-2.0-or-later (GPL-2.0+) - version 2.0 or any later version.
GPL-3.0-only (GPL-3.0) - version 3.0 only.
GPL-3.0-or-later (GPL-3.0+) - version 1.0 or any later version.
(∞?) GPL - “any version ever published by the Free Software Foundation”, including hypothetical versions such as:
0.1
-2.0 (negative 2)
draft-order-66
Tip
Identical “license text” is used between variants of the different GPL versions (eg: GPL-3.0-only vs GPL-3.0-or-later).
You need to look for the license identifier (separate from the license text) to determine which variant applies to any particular project.
Any later version?
The “any later version” clause included in many licenses results in users having an unknown set of rights,
since nobody knows what terms and conditions will be in the future license.
What terms and conditions will be in GPL version 66?
If you have absolute faith in the organisation that manages a license,
the future leaders of that organisation after current people have left,
and are willing to let them control future license terms and conditions of your software -
then by all means allow “any later version” in your project.
This applies equally for all licenses, not just those published by the Free Software Foundation.
An unambiguous license for our example
Version 3 of the GPL (the current version) was created to prevent “Tivoization” — hardware that uses GPL software, but uses technical measures to prevent users running modified versions of the software.
If you have concerns about how digital rights management (aka: digital “restrictions” management) might limit the rights of your users, then version 3 of the GPL might be a good choice for you.
However, for our example we know that version 3 of the GPL conflicts with our own legitimate interests,
since companies like Netflix won’t use our platform if users can bypass digital rights management.
Version 3 of the GPL would be a poor choice for us, version 2 is a much better fit.
But specifically GPL-2.0-only, so we aren’t bound by the anti-Tivoization clauses of version 3 if we had instead selected GPL-2.0-or-later.
Exceptions
Sometimes licenses align perfectly with our goals and ideals, but sometimes they need adjustments.
One common form of adjustment is the addition of one or more exceptions to the license terms.
Note
Exceptions are effectively modifications to license terms, forming a new contract.
You should seek legal advice before using combinations of licenses and exceptions that aren’t common and well understood.
The Linux kernel selected GPL-2.0 (aka: GPL-2.0-only) just like we did for our example,
but Linus Torvalds added an exception to the license
so it better aligned with his goals for Linux:
NOTE! This copyright does *not* cover user programsthat use kernel services by normal system calls - thisis merely considered normal use of the kernel, and does*not* fall under the heading of "derived work".Also note that the GPL below is copyrighted by the FreeSoftware Foundation, but the instance of code that itrefers to (the Linux kernel) is copyrighted by me andothers who actually wrote it.
Eventually this exception was better formalised as the Linux-syscall-note.
The license for our example project probably doesn’t need any exceptions, unless we fork the Linux kernel itself (like Android did).
This means that all terms of the GPL-2.0 must be applied to any “derivative works” of the Linux kernel as defined in the license text,
except “non GPL compliant user space application code” which may link
to Linux “user space API (uapi) header files”, as per the Linux-syscall-note exception.
The Linux-syscall-note exception is the reason why non GPL compliant software can link to GPL licensed Linux header source files, in order to make Linux system calls, without having to adopt the GPL.
Prominent software taking advantage of the Linux-syscall-note exception includes:
The Android kernel is a notable fork of Linux. As a “derivative work” of the Linux kernel that isn’t just linked to user space API headers,
the Linux-syscall-note does not apply, and all terms of the GPL-2.0 license are in full effect.
This forces Google to use the GPL-2.0 for the Android kernel, as per the “derivative works” clause of the license text.
Retaining the Linux-syscall-note exception allows Google to avoid using the GPL for Android user-space code.
Android user-space
The non-kernel parts of Android are not derivative works of the Linux kernel, so Google is free to license under any license they want.
They chose the more permissive “Apache License 2.0” license.
Version 3 of the GPL states the following in the license text:
All other non-permissive additional terms are considered “further restrictions” within the meaning of section 10.
If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License
along with a term that is a further restriction, you may remove that term.
This may nullify any exceptions added to GPL version 3 licensed software (and older versions that have “any later version” in effect),
though IANAL and I’m unaware if this clause has been tested in any court of law.
It may also be the case that GPLv3 licensed software that is combined with other licenses containing “further restrictions”
is only effectively licensed under GPLv3 (but perhaps with any additional terms that the licensee chooses to retain).
It happens.
Whether through licensing ambiguity, a change of circumstances, or other issues,
projects end up having licenses in place with terms that don’t align with the project goals.
The first thing is don’t panic, and the second is don’t despair. It is always possible to change the license of a software project, though it can take some effort.
Single author license change
This is trivial. Since all of the copyright holders (ie: one person) agree, the license can be changed and new software can be released.
You can even re-release old versions of the software under the new license,
but be aware that this effectively means the old software is covered by multiple licenses,
which may or may not be compatible with each other.
Note
Be aware that there would be multiple authors if snippets of code from sites such as
Stack Overflow are used -
be careful to follow all relevant licensing terms from these sites including sub-licensing and attribution.
Unanimous agreement by all contributors
You will approval from all copyright holders to change a license.
If someone denies the license change request, you will need to remove their contributions,
and if necessary implement removed functionality using the clean-room design strategy.
Note
It might be possible to gain implied consent if someone doesn’t respond to your request to change the license,
but this would be relying on silence constituting acceptance in whichever legal jurisdictions are relevant.
You should definitely seek legal advice before changing the license without explicit approval from all copyright holders.
Trivial contributions license change
Some licenses argue that “trivial contributions” are not copyrightable, and as such can be ignored when considering
which people or entities are copyright holders for a given project.
Some license texts provide some indication of what would be considered “trivial” amount of code.
numerical parameters, data structure layouts and accessors, or small macros, inline functions and templates (ten or fewer lines in length)
Yet, Oracle and Google have argued in US court over a nine-line rangeCheck function being copied.
One potential way around this issue might be for contributors to explicitly declare that their changes are trivial via
commit message trailers or similar:
CLA assistant lite is a GitHub action
that checks and prompts contributors to sign your CLA for every GitHub pull request.
A common approach to resolve issues relating to multiple copyright holders in a project is
for all contributions to be made under a CLA
which grants either ownership or rights to the project to use the contributions as the project sees fit.
With an appropriate CLA in place, it may be possible for a project to re-license contributions with pre-approval from contributors via the CLA.
Understand that you may have no control over your contributions being re-licensed if you sign a CLA.
Some prominent open source projects have been involved in
relicensing controversy,
including changing away from open source licenses (eg: MongoDB).
