Why we’re choosing GNU AGPLv3

Why go open source?

First, it is important to lay out our reasons for making open source a part of how we work. gliff.ai believes FATEful artificial intelligence (AI) is the future. What is FATEful AI? Fair, accountable, transparent and ethical AI. Our MLOps (machine learning operations) products aim to make it easier to develop FATEful AI systems. In particular, our MLOps products aim to allow the development of AI in a private and secure fashion and provide human-readable audit for the whole AI development cycle.

gliff.ai believes that we should practice what we preach and want our users to trust that our products, helping them create FATEful AI systems, are FATEful themselves. One obvious way to do this is to make our codes open source and thus enable people to scrutinise our codes and feel confident that they’re doing only what we say they’re doing.

Additionally, we use open source projects to develop our own software products and within our development cycle. gliff.ai believes that it would be unfair to take from these communities without giving back. We hope that our own open source projects, combined with active encouragement that our techteam contributes back to projects we use, help to strengthen and support these communities. As those communities we use grow, we also hope to build on ideas for new features and products that come from our communities, to build upon the work and support of contributors, and to see our projects become key open source projects within the FATEful AI space.

What are the options?

There are a wide variety of software licenses and all the open source licenses can be found on the Open Software Initiative website. Beyond these, there are a range of not open source but open-oriented licenses, e.g. MongoDB’s SSPL. These have arisen out of the need for clear monetisation models for commercial open source software (COSS) but may not be truly open source and sometimes cause conflict in the community.

This proliferation of software licenses is also problematic for take up of new projects — if every new open source project had a custom license then company legal teams will be reviewing hundreds of licenses with only minor and subtle differences.

So, let’s limit ourselves to some ‘standard’ open source licenses — those that we see in our everyday dependencies. One great resource for this is choosealicense.com. This gives us a shortlist of the GNU General Public License (GPL) variants, Mozilla Public License, Apache License and MIT License.

What does gliff.ai require?

As I said above, gliff.ai’s main motivation in going open source is to enable others to probe our codes. All of these licenses enable us to do this.

So we have to consider our other motivations (contributing to the wider community and being open to the exciting ideas and opportunities an open source community brings) and our own commercial motivations (we’re a business after all).

In the first part, contributing to the wider community and working with the community to develop amazing software and features, the license we choose should allow commercial use, distribution and modification of the code by third parties — again, all of these licenses enable us to do this.

In the second part, protecting our own commercial interests, we don’t mind other companies using our codes, integrating them into other products or selling them as a service — this is competition. But, we want competition to be fair. We are a young company and a growing team and we need to take this into account when choosing a license.

Consider the following two alternate scenarios (note: these are based on real life stories):

1. A very large company wants to use codes developed by a smaller company as part of their Software as a Service (SaaS) platform. The open source licenses we’re discussing here allow commercial use. But, the large company has lots of investment and can quickly hire a new technical team. This team starts adding new and improved features to the project. Great news! However, this large company decides not to contribute those new changes back into the original open source project. As such, their version of the tool attracts more customers, takes existing customers and reduces potential new customers from the original software developer. This leads to the smaller company experiencing reduced income and potentially failing. Not great. Not fair. Not sustainable.
2. Same as above: a large company takes an open source project and puts resources into developing new features. However, this company contributes those changes back into the community, ideally by creating pull requests to the original codebase. The community as a whole, and not just the company’s customers, benefit from the new features. The original software developer is also able to offer these features to its customers. The market stays fair and customers can choose which company best supports their needs and aligns with their values. This is good for all, even the larger company as they also reap the benefits of other contributors. This is a sustainable outcome.

Okay, so this is the crux — any license gliff.ai chooses needs to ensure that large companies who modify the code and distribute those modifications for commercial gain are required to feed their changes back into the community. This discounts the MIT License, Apache License 2.0, Mozilla Public License 2.0 and GNU LGPLv3, which all allow the distribution of modified or larger works under different, including closed and proprietary, licenses.

What’s in an ‘A’? GNU GPLv3 or GNU AGPLv3?

So, we’re left with GNU GPLv3 and GNU AGPLv3. These two licenses are very, very similar. Essentially both licenses give obligations to those who distribute modified versions of the project.

In both cases, if an individual/company makes a modified version of the project but does not distribute it, i.e. only use it for private reasons, there are no obligations.

In both cases, if an individual/company makes a modified version of the project but does distribute it, i.e. provide customers with a binary or code blob, then both licenses require the source code to be made available. Usually people do this by forking code repositories and/or creating pull requests and so on.

Where they differ is that AGPLv3 gives one more obligation relating to distribution — AGPLv3 counts providing the software over a network as distribution. Thus modified versions shared over a network, e.g. modified versions of a web app being hosted on a publically-accessible domain, must have their source code made available.

Our projects are all browser-based apps. So GNU AGPLv3 makes the most sense to us.

Is GNU AGPLv3 too restrictive?

We’ve spent a lot of time discussing whether a more restrictive open source license, such as GNU AGPLv3, could be damaging to commercial and community uptake. For example, Google has banned the use of all GNU AGPLv3 software by Google employees. But why?

Well, the fear here is that any larger software project that uses a dependency with a GNU AGPLv3 license must also have a GNU AGPLv3 license.

However, we believe that fear to be a misunderstanding. Our interpretation of the GNU AGPLv3 is probably best described in a series of short scenarios:

• An individual wants to use a gliff.ai project for personal use. In this scenario, the individual can make any modifications they choose with no requirement to make those modifications available, as there is no distribution.
• An individual modifies a gliff.ai project and shares that through any mechanisms, e.g. sticking it on a thumb drive or hosting it on a server. In this scenario, the individual must make the source code with their modifications available under a GNU AGPLv3 license, as there is distribution.
• An individual wants to use a gliff.ai project within a larger software project that they will distribute. In this scenario, if no modifications are explicitly made to the gliff.ai code, then there are no obligations for the individual to use any particular license for their project nor any obligations for the individual to share any source code. However, if modifications are explicitly made to the gliff.ai code, then there are still no obligations for the individual to use any particular license for their project and code but there is an obligation for the individual to share the modified gliff.ai project’s source code under a GNU AGPLv3 license.
• The same rules apply to a company. If the company makes no modifications to the gliff.ai project or does not distribute the software, i.e. only uses it for internal/private use, then there are no obligations on making source code available or using specific licenses. This, to us, includes use of our code as an unmodified dependency to a larger project. If a company distributes a modified version of the software then it must make that source code available under a GNU AGPLv3 license — this way companies are required to contribute back to the communities that they build from.

In summary, GNU AGPLv3 provides gliff.ai with a way to make our projects open source and to help build our customers’ trust in our products. This license allows individuals and the community to use our projects and contribute back any exciting changes they come up with. And, importantly, GNU AGPLv3 allows for fruitful competition, and creates a fairer marketplace for everyone, including gliff.ai.

Image by Dmitry Zvolskiy (@zvolskiy)