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: GPL With Classpath Exception
We will use GPL as the fundamental underlying licensing model. Our preferred licence is GPLv3, but in order to make it as easy as possible for people to combine our code with other GPL projects (including those like the Linux Kernel which use GPLv2), we are selection GPLv2 or any later version, which covers GPLv3 and any other version of the GPL which the Free Software Foundation may release in the future.
GPLv2 and GPLv3 are well-understood and respected licences with a track record in nurturing vibrant and innovative developer communities. To address the requirement for ease of integration we propose a simple linking exception, namely the straightforward and widely implemented Classpath Exception. This allows the software under GPL+Classpath Exception 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.
The SPDX identifier for this is GPL-2.0-or-later WITH Classpath-exception-2.0. You can put this in your code as:
// SPDX-License-Identifier: GPL-2.0-or-later WITH Classpath-exception-2.0
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).
In theory, this would mean that the most frictionless implementations of radicle-link would be those which complied with the specification published by Radicle. If anyone tried to alter the protocol, the compliance would become that much more difficult.
However, we considered that introducing another licence exception would be undesirable from a licence-proliferation perspective, and 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. In particular, it could inhibit users from improving radicle-link unless they were 100% sure that their improvements did not somehow bring the code outside the scope of the protocol. This can be quite a tricky question to answer, and it did not seem reasonable to ask developers to undertake this technical analysis in order to gain certainty as to the scope of the licence.
Accordingly, we decided not to apply this additional criterion, and instead adopt a licensing model using the much simpler Classpath exception. We feel it’s also more appropriate to signal and control appropriate use of the radicle-link protocol 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 GPLv2 or any later version, with the Classpath 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 GPLv2 and all later versions, with the Classpath 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 GPL+Classpath 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.
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 GPL+Classpath Exception here. This 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.
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 GPL with Classpath Exception is employed, to maintain the requirement that any improvement to code implementing core protocols remains available for use by others.
 It was developed by Sun Microsystems and has been used widely in relation to Java components. It is often compared to LGPL, but in many ways is preferable because it avoids the complexity of the relinking requirement, corporates are less apprehensive about using it owing to the lack of a reverse-engineering right, it is easier to understand and it’s easier to conceptualise what happens if the exception is not used. See
https://www.gnu.org/software/classpath/license.html for details of the original Classpath Exception.