[NOTE: This has been edited to reflect the current Radicle licensing policy, to avoid confusion. If you want to get a sense how this has evolved, feel free to look through the comments below.]
I’ve been working with the Radicle team on the best licensing structure to adopt.
There is a range of dynamics at play when developing a licensing model for a foundational technology such as Radicle. Ultimately, the radicle-link ecosystem is best served by providing a stable, dependable protocol. At the same time, there needs to be a mechanism for open source community dynamics to come into play, and ensure that community innovation can be nurtured, and that innovations remain open. Finally, it has to be as easy as possible for the protocol to be implemented using as wide a range of integrations into other products as possible.
Taking each of these in turn, it would seem that to maintain stability and dependability, a standards-type licence might be most appropriate (i.e a licence which granted implementers freedom only if they faithfully adhered to the standard. Incidentally, such a licence would not, by definition, qualify as an open source licence).
To ensure a vibrant community, and to guard against closure of technology, a copyleft licensing model based on a licence like GPL would be a good choice.
Finally, to make it as easy as possible for third parties to integrate the radicle-link protocol into their own applications, a permissive licence like BSD or Apache would help corporates to overcome their own (possibly unwarranted) reticence to integrate any reference implementations of radicle-link into their own code.
It would seem difficult to fulfil all of these requirements simultaneously. However, we decided on a licensing model which addresses these concerns, and provides what we believe to the best compromise.
Radicle-link: GPLv3 With Radicle Linking Exception
We will use GPL as the fundamental underlying licensing model. Our preferred licence is GPLv3. We did consider trying to dual license GPLv2 and GPLv3, to widen the scope of code which is compatible, but it became clear that tracking dependencies would become too complex, so for simplicity, we favour GPLv3.
GPLv3 is a well-understood and respected licence with a track record of nurturing vibrant and innovative developer communities. To address the requirement for ease of integration we propose a simple linking exception, namely a slight variant of the straightforward exception adopted by LibGit2 [1]. This allows the software licensed under it to be linked to third party components (including proprietary components) without those components being subject to the copyleft effects of the GPL. However, if the radicle-link implementation is itself modified and distributed, then the source code of those modifications will have to be made available to recipients of that code under the same licence. Thus there is a clear distinction between code on the radicle-link side of the interface being subject to the copyleft effect, and code on the other side of the interface being free from that effect.
Unfortunately, there is no current SPDX identifier for this exception, but we are looking to apply for one from SPDX.
We did consider a further refinement of this, which would have involved drafting a custom version of the exception which has an additional requirement: that the exception only applies when the radicle-link code implements the radicle-link protocol. If any changes are made to the radicle-link protocol which bring it outside the specification, then the exception would not apply, meaning that any code linked to that component and distributed would also have to be released under GPL (without the benefit of the exception). However, a simpler way of achieving a very similar end is to adopt the exception applied to LibGit2, with one small change. We also looked at using the Classpath Exception, but we felt this was a little more complex to understand. We feel our exception, better preserves Radicle’s “libre” intentions. The exception reads as follows:
In addition to the permissions in the GNU General Public License,
the authors give you unlimited permission to link the compiled
version of this unmodified program into combinations with other programs,
and to distribute those combinations without any restriction
coming from the use of this program. (The General Public License
restrictions do apply in other respects; for example, they cover
modification of this program, and distribution when not linked into
a combined executable.)
This means that if you take the program covered by this licence+exception and link it into your code, then you can release the resulting code under any licence you want (as long as that’s allowed by the licences of any other components you incorporate into your own code), without any restrictions from the Radicle software. However, this only applies to the official unmodified version. Nothing is stopping you from modifying the program – that’s a right guaranteed by GPLv3 – but if you do modify it, then the exception falls away, and you’re required to follow GPLv3 in full (so, in that case, if you link the Radicle software into your code you would have to release the whole combined work under GPLv3). This also encourages people to submit enhancements and bug fixes to the official source tree. If they are accepted, then they become an official release which will have the exception attached to it, so you will then be able to link the compiled version of radicle-link into your code without it affecting the licensing of your executable.
How have we changed the exception? We changed “library” to “program” because we want to use the exception with software other than libraries (and we also changed other references in the exception to “program”. We also added the word “unmodified” so that the permission is now to link the compiled version of “this unmodified program” into combinations with other programs, rather than just “this library” (as it was originally). We believe that was the effect of the original exception (because if you modify “this library” it’s no longer “this library”), but just to clear up this ambiguity once and for all, we added the word “unmodified”. The changed wording is highlighted in bold in the text of the exception for your reference.
This means that the most frictionless implementation of radicle-link is that obtained from the official source tree.
We are very conscious of the importance of selecting a licensing model which is easy to understand and implement, and, crucially, does not expose users of the code under that licence to uncertainty as to the scope of the licence they are using.
Trademarks
Developers may also wish to implement the protocol in their own code. We propose that a licensing scheme is developed around the “radicle” trademark, allowing anyone providing code which completely and effectively implements the radicle-link protocol, to use a trade mark such as “radicle compatible”. We will publish more information about the licensing policy as it develops.
CLAs and DCOs
Contributors to copyleft-licensed projects will typically be concerned that their contributions might become closed and proprietary against their wishes. A solution to this is that they are asked to sign a developer certificate of origin (DCO) which provides basic confirmation that the contributor is able to contribute the code in question, and then states that the code is licensed to the project on the basis of licence in=licence out. In other words, using this model, contributors would be required to license their contributions into the codebase under GPLv3 plus the radicle linking exception.
We did consider implementing a contributor license agreement CLA, such as the well-understood Apache Contributor License Agreement. Because this grants more flexible rights to the recipient, it may cause developers to be concerned that the work they are contributing to may later potentially become closed, even if that is not the present intention of the recipient. For this reason, we did not want to present any barriers to entry for anyone wishing to make a contribution, and the DCO is the easiest way to implement this. There may in future be some cases where we are happy for the code to be closed (for example, interfaces to some proprietary solutions where we want to maximise the ability of users of all licensing models, including proprietary, to use the code (see “shared libraries” below). When we make such a decision, we will clearly flag this as a separate project with a different licensing model, although we are still able to use the DCO, this time with a licence-in=licence-out model, using a more liberal licence like MIT.
However in most cases, we feel that the proposed model which covers GPLv3 with the radicle exception, will be most appropriate.
Radicle Smart Contracts
The Radicle Smart Contracts are built on Ethereum and we decided to have them licensed under the same GPLv3 with Radicle linking exception for the same reasons: we want to encourage anyone who has improvements or bug fixes to the contracts to publish those under the same model, so that recipients of the code (including us) can make use of them if we wish.
Radicle Upstream
In this case, the software would be curated and developed by Monadic, using the Radicle name under licence from the Foundation.
We decided to apply the GPLv3 with Radicle linking exception here also, and will ensure that the relevant code to implement the plug-ins is licensed in a way which enables third parties to build plugins knowing that their own plugins do not necessarily have to be licensed under the same licensing model. This would create the widest ecosystem for plugins. It would also provide consistency were Monadic to release plugins themselves under an alternative licensing model.
Shared Libraries
The simplest licensing model for a shared library is permissive, such as MIT, and we suggest that this licence is used for relatively small pieces of code that may be incorporated into a larger codebase in a way which is more intimate that linking (e.g. where code is cut and pasted). However, where the code implements aspects of the protocol, we decided that the GPLv3 with radicle linking exception is employed, to maintain the requirement that any improvement to code implementing core protocols remains available for use by others.
