Radicle Licensing Model

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

[1] libgit2/COPYING at master · libgit2/libgit2 · GitHub

5 Likes

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!

Following the excellent comments we’ve had both publicly and privately, we’ve decided to make a few changes to simplify the licensing regime.

While it would have been great to be able to, effectively, grant users the additional option to license under GPLv2 as well as GPLv3 (in each case, with the additional linking exception), it was going to become very complicated to track which components were able to take use of the GPLv2+exception option, and which weren’t, because of dependencies. For that reason, we’ve decided to keep the licensing consistent, and use GPLv3+linking exception, without the ability to relicense as GPLv2, as the default licence. We’ve also made another change: rather than using the Classpath Exception, we’ve adopted a (slight) variant of the linking exception applied to LibGit2. It’s another well-understood exception, and we’ve made the change because we feel it’s easier to understand and addresses the questions raised in a way which best 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 library into combinations with other programs,
and to distribute those combinations without any restriction
coming from the use of this file. (The General Public License
restrictions do apply in other respects; for example, they cover
modification of the file, and distribution when not linked into
a combined executable.)

This means that if you take the library covered by this licence and link it into your code, then you can release the code under any licence you want (as long as that’s allowed by the licences of any other components in your own code), without any restrictions from the Radicle library. However, this only applies to the official unmodified version of the library. Nothing is stopping you from modifying the library – 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 library 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 the library into your code without it affecting the licensing of your code.

How have we changed the exception? We added one word – “unmodified” so that the permission is granted to link the compiled version of “this unmodified library” into combinations with other programs, rather than just “this library”. 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”.

This also neatly brings back in scope one of the original criteria we were looking for in our licensing model: that a least-resistance path exists for those implementing and using the official version of the Radicle-Link protocol.

Unfortunately, our exception is not on the SPDX list of exceptions. We will look to submit the revised wording to SPDX for inclusion in the list.

4 Likes