Moving project from AGPL to Apache v2 / MIT license

Question

The question in a nutshell

Hi! Together with a team of brilliant engineers we've been building a software project (http://luna-lang.org) for the last two years and now we want to release everything as an Open Source project, completely free of charge for everyone. We are authors of the whole code and use only MIT licensed libraries, so we can freely choose our license model now.

A good Open Source project have a strong team of full-time contributors. It happens naturally if there is a commercial company behind the project. As a young, small company we know that we will survive only if we find a proper revenue model. That's why we want to build a commercial software on top of the project, but in the early days we want to keep a strong competitive advantage. That's why we would like to choose the AGPL license initially. However, as a long-term Open Source community members, it is just against our feelings – we want to make it as open and free as possible. That's why we would choose AGPL now if and only if we will be sure it would be possible to switch to Apache v2 / MIT in the future. The question is – is it possible taking in consideration the constraints below?

Important software specification

Our project is a software allowing you to build new software. Technically, it is a compiler and graphical editor of a new programming language. Thus releasing it as AGPL project do not affect the majority of users – they can build commercial, closed source software using it. The difference is only if somebody would like to use our compiler as a back-end to build some kind of competitive graphical data processing interface (or SaaS) – then we want to be sure it will not be a commercial, closed source application.

Constraints

1. We would like to build a community around the project and accept contributions. The contributions have basically 2 forms:

   • Libraries for the language and plugins for the gui – they are NOT affected in any way by the license of the project, because the compiler / gui is just an "editor", a "build tool", so users can choose any license they want for their libraries.
   • Contributions to the source code of the project (compiler / GUI). Here we've got copyleft.

2. We would like to use our software (backend and gui) as a base layer for building closed source commercial SaaS. As the only authors of a AGPL-licensed code we could do it, but we would also like to be able include community contributions in it.

3. We do not want to force our contributors to neither sign any printed documents nor request them to have a special electronic signature. It just makes the whole process over-complicated for the vast majority of open source developers. We are looking for a solution to allow contributors to just just agree upon "something" when submitting pull request (preferably by clicking a checkbox or a button or just by a sentence that if you submit pull request you agree for some terms).

4. We would like to move the project from AGPL to MIT / Apache v2 in the future without the need to ask every contributor if we can make this change. We can of course ask about it upfront when submitting pull requests.

Is there any simple way to accomplish this task?

Answer 1

You've clarified that you're worried about people incorporating the code of your compiler into closed-source web-accessible products before you're ready (hence AGPL for now) but that at some future time you will be ready, and want to change licences to one that permits that (MIT) without at that time consulting all contributors. You also want to be able to use community contributions in your own closed-source product.

That naturally leads us to contributor licensing agreements (CLAs), which are a pretty well-established feature of life in the free-software world, and about which much has already been written on this site. Your wrinkle is that you don't want to formally require a (digitally or manually) signed CLA from contributors, but instead have a "click-through" warning that all contributors accept a linked agreement by the simple act of submission, or failing that, an "I accept the CLA" checkbox that must be ticked on each submission.

We have already discussed the validity of the different forms of CLA; my layman's opinion remains that you should at the very least go with a checkbox. You may find this interferes with workflow, because (in my experience) most distributed-source-management tools don't make it easy to click a checkbox on each submission. I note also that while printed CLAs are a bit passe, there are definite advantages to having registered GPG public keys for each of your contributors (not least because proving the provenance of contributions becomes easy) and if you're going to require those, having digitally-signed CLAs is nearly no extra effort.

If you're open to something a little heavier-weight which is still short of full-on, there are CLA sites (eg, https://cla-assistant.io/) that integrate with public development repositories like github and handle the business of having a given github user formally agree to a CLA that a particular github repo has been configured to require. This workflow is also pretty well-understood by the community.

tl; dr the barrier to contribution represented by formal electronic acceptance of a CLA, however that is accomplished, is small compared to the barrier represented by a CLA allowing commercial exploitation. So if you're determined to require a CLA, go electronic and don't sweat the details.

Disclaimer: I have no relationship with cla-assistant.io.