Radicle Licensing Model

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[1]. 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.

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 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.

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 GPL with Classpath Exception is employed, to maintain the requirement that any improvement to code implementing core protocols remains available for use by others.

[1] 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.


Thanks Andrew for this summary! This is a very reasonable and straightforward outcome from my perspective.

I have two questions regarding the practicalities of implementing this model:

  1. Is it correct that the choice of GPLv2, even with the “or later” clause, requires us to ensure that our dependencies are licensed in a GPLv2-compatible way?

    For example, the Apache2 license is considered incompatible with the GPLv2, so we would not be able to depend on a library licensed exclusively under its terms. I understand that it is common in the Rust community to license under Apache-2.0 OR MIT for exactly this reason (GPLv2 compatibility), so in this case we would “automatically” license the dependency under the terms of MIT, is that correct?

  2. When you recommend a DCO over a CLA, do you imply re-affirmation for every contribution?

    Apart from the legal aspects, implementing a CLA is often considered very heavyweight, because the licenser needs to maintain a database of signee identities and signature timestamps, which may be subject to data protection laws. By contrast, DCOs are typically implemented by “signing-off” each and every contribution – typically by simply including a line like Signed-off-by: Real Name <real@email.com> in the commit message. According to the kernel DCO, any specifics are to be indicated in the (source code) file(s) being contributed.

    We can surely get creative about how exactly the specifics of the process shall be implemented, but I just wanted to double-check whether it is implied in “the easiest way” that no database lookup is required :slight_smile:

Oh, and I almost forgot the most confusing part about question 1:

From Various Licenses and Comments about Them - GNU Project - Free Software Foundation

Please note that GPLv2 is, by itself, not compatible with GPLv3. However, most software released under GPLv2 allows you to use the terms of later versions of the GPL as well. When this is the case, you can use the code under GPLv3 to make the desired combination

By depending on a GPLv3-licensed library, we would be making the combination ourselves, which seems so cancel out the GPLv2 in GPLv2-or-later of our own terms — so is it correct that we can not depend on GPLv3 libraries?

I also have a question :slight_smile: Is there anything we would need to do for existing contributions? I believe some people have made contributions to radicle-surf, radicle-link, and radicle-upstream. Do we need to check for DCO compliance or anything like that?

Hi Kim
Thanks for your questions.

  1. Yes, to use GPLv2 or later, you need to make sure that the dependencies are licensed in a way which is GPLv2-compatible. If a component is dual-licensed under Apache-2.0 OR MIT as you suggest, then in this case you would select MIT in this case (in fact, it’s not completely clear that Apache 2.0 is incompatible with GPLv2 in all circumstances, especially if there are no patents involved, but since the FSF’s stance is clear, I wouldn’t recommend putting too much effort into trying to argue against it).

  2. This is a great point. Yes, if it’s possible to avoid a database lookup that would certainly be preferable. By incorporating the sign off in the commit message, this should embed it in the commit history sufficiently to enable traceability.

Another good question!

Note that the preferred licence is GPLv3, so if we can also use GPLv2-or-later components in a way which allows the whole release to be distributed as GPLv2-or-later (i.e. it’s not constrained by any other depedencies), then that’s great, but if we end up being limited to GPLv3 because other dependencies don’t allow it, that’s not ideal, but probably liveable with (although it would make it more difficult to integrate with projects like the Linux kernel, but we probably don’t want to do that anyway).

Bottom line: we can’t accept GPLv2 only code where our preferred licence is GPLv3 because, as you say, GPLv2 is not compatible with GPLv3. However, it may be possible to accept GPLv3 only libraries, so long as Radicle is clear that this will limit future licensing of that distribution to GPLv3 only (unless the library relicenses to a more flexible licence in the future).

Thanks Andrew, that’s very helpful!