Facing recent events in the software-defined storage community, we would like to highlight that not all open-source projects choose an open-source license for the same reasons. Some open-source projects appear to be designed for "growth-hacking" with an "expensive license exit", whereas others are designed as "commons" where all the stakeholders benefiting from the project are taking care of the software while protecting their business or activity. As the creators of Garage, we believe in the latter vision of a "commoning open-source". We made sure, from the beginning, that any new development on Garage will always be released under the same license. Read more to understand our vision of the legal implications of software licensing.

Some would say open-source is in crisis: even if the OSI definition of an open-source license has proved its robustness over time, it says nothing about software re-licensing. However, over the past ten years, re-licensing of projects originally published under an OSI-compatible license has become a common occurrence. For users, investing in the deployment of a given software is a long-term plan. It is often costly, risky, and time-consuming to swap a component in a stack, and users can easily feel locked-in once they pick a project or a vendor. As a result, open-source now feels inherently suspicious: it appears more and more as a kind of free "trial" or "beta" version, prior to a company switching to a more lucrative economic model by imposing more restrictive license and aggressive pricing to "extract" the value of their acquired user base.

But not all projects share this goal, and that’s why we think the community should differentiate between growth-hacking open-source and commoning open-source. With growth-hacking open-source, the goal is to ease adoption and community building at the beginning of the project, before pivoting to a more traditional, proprietary software approach. With commoning open-source, different stakeholders with a similar problem invest engineering time together to create a solution.

One major way to differentiate between growth-hacking and commoning open-source is to look at the business model of the company behind the project and ask: is selling licenses for this product core to their business? Will it be in the future? If the answer is yes, then, you are most probably facing a growth-hacking open-source project. In the case of Garage, there is no one selling licenses, and no "pro" version. The software is a building block for Deuxfleurs’ static web and email hosting. We have a common ground to share the development effort with people working on different projects, with similar requirements. Hence we consider Garage to be commoning open-source.

But promises are not enough: we have been deceived many times in the past. That’s why we wanted to integrate this commoning open-source approach into our licensing strategy. We wanted to address the risks of re-licensing by making it impossible. How?

It is possible to re-license software if one of these two conditions is met:

• absence of a "share-alike" clause (also called "copyleft" or "viral effect");
• ownership of the contributed code is given to a single entity under a CLA (Contributor License Agreement).

So, to build a true commoning open-source project, your software must have the following properties:

• have a license that is OSI-compliant;
• have a share-alike clause;
• contributors are not required to sign a CLA or transfer ownership of their code.

In this case, you are assured that all future developments will be made available under the same license. If you wanted to change the license of the project, you would need to ask every person who contributed to it for permission, or rewrite/remove their contribution. This is generally an arduous task, and it only becomes harder the more people contribute to the project. In other words, as the amount of contributors increases, the safer the project is from being easily re-licensed. This is one reason why Linux has been so successful in the long term.

Note that, in this context, it is not possible to provide a "business license" for the project. This would require a single entity to own the entire software, which we must prevent in order to avoid any re-licensing "rug pulls"! The mechanism used to provide a business license is also what the growth-hacking strategy relies on; both are a form of re-licensing.

In our case, Garage is licensed under the AGPLv3, without any CLA. Some companies fear that AGPLv3 is "too viral" and may "contaminate" their proprietary or business-related applications.

This fear may originate from the Google Anti-AGPL policy, which dictates that any AGPL software must be avoided within Google. As Google developers copy all third-party source code into their single repository and build it internally, they cannot be sure that Google’s code will not become "contaminated" by any AGPL software during compilation. As long as you are not following this "mono-repo" path, either by using our compiled binaries or by separating Garage code from your proprietary code during compilation, there is no risk for your business. We know that many companies have adopted a dual-licensing model of AGPL and enterprise licenses, and have threatened companies with AGPL compliance complaints in order to sell more enterprise license. That is not our case: we have no license to sell. Of course law isn’t code, it is interpreted by humans. What we have presented is our interpretation of AGPL, a vision we are not alone to share. Unfortunately we can’t force your lawyers to trust us. We are aware that we don’t have the same reach as Google, but we hope that in the end, truth and reason will prevail over what we see as licensing misconceptions...

In conclusion, commoning open-source provides the Garage project with:

• stability over time as it ensures that future development will always be released under the same license;
• peace of mind for your business or activity as the "share-alike" clause only applies to code that is compiled at the same time as Garage, not to code or processes interacting with Garage APIs.