License Change: GPLv3

[winged]

After the change of the license last week from MIT to AGPLv3, we received some valued feedback. For this reason, we're now opening the discussion to make a small step back and use the "normal" GPLv3 instead.

Why we chose the AGPL

We as an organisation have a strong opinion towards open source and free software. We want to live the philosophy as much as we can.

The AGPL is a rather strict license. In addition to the GNU GPL, you are
required to provide your changes in the source code not only to the "direct"
user, but to users accessing the software via a network as well.

Or as is explained here:

SaaS companies are more free to use GPL licensed-code because the obligations of the GPL are triggered upon software distribution and SaaS software by nature is not distributed. (This is often referred to as the GPL “SaaS loophole.”)

This allows such companies to "take" GPL code, modify it and provide it to their users without the actual users benefitting from the software's license, as is the GPL's intention.

Our goal is to build a strong community around Caluma, and we feel that we should do everything to help this goal come along. Part of it is having a good license that incentivizes people to contribute back.

Feedback

The feedback we received after the change to AGPL was quite valuable. We learned of a few situations that we didn't consider before that maybe we should have.
The move to AGPL was also discussed "behind closed doors", opposing the open culture we want to nourish. We try to right this by documenting the reasons in #749.

I'll address the feedback we got in the following points

Licensing of extension points

Due to the strictness of the AGPL, one could consider that extensions, such as visibility and permissions would be "infected" by the AGPL and would thus need to be shared to the end users. This would be problematic as it could expose internal workings of IT infrastructure, or logic that is definitely not intended for the public.

While it is true that it is python code called directly from Caluma, we still consider those modules to be configuration. A config file can easily be excluded from such license claims - you wouldn't share your /etc/shadow for example.

Other projects, such as Drupal, do the same in practice:

It's a little bit of a gray area, but the general guideline we worked out is that despite settings.php being technically code, what's actually stored there is data, not anything complex enough for copyright to even apply. So if someone tried to invoke GPL or AGPL to get access to a site's settings.php file, which has database info in it, we'd be justified in brushing them off.

Straigh-out blacklisting of AGPL code

While it took a few decades for free software to become acceptable in the commercial world, the AGPL is considered by many legal departements as "too dangerous", as it may easily "infect" parts that shouldn't be made public. While we feel that technically, for Caluma this wouldn't be the case, we still have to deal with the fact that some organisations that could benefit from Caluma do have the license blacklisted explicitly.

For example, google has their AGPL policy available online, stating very clearly:

WARNING: Code licensed under the GNU Affero General Public License (AGPL) MAY NOT be used at Google.
The license places restrictions on software used over a network which are extremely difficult for Google to comply with.

Other organisations have similar limitations. Working to change those policies is in most cases not worth the effort and may do more harm than good with regards to Caluma's adoption.

Contribution Agreements

Code that is contributed by community members will be licensed under the AGPL as well. This may limit implementors if they for some reason need to deploy a modified version of Caluma, even though the goal, as noted in #749, is to incentivize people to use the available official interfaces.

Risk overestimate

The main reason we chose the AGPL over the GPL was to avoid the SaaS loophole as described above. However, after some further discussion, we probably assessed the risk way higher than it actually is. How much harm does really come to Caluma and it's community by some SaaS taking an undue profit from it? And how much better could Caluma be if it is instead adopted by some organisations that (rightfully) are wary of the AGPL's implications?

Decision

For the above reasons, we plan to change the license again, soon, to a more "acceptable" GPL v3. Learning from the mistakes of the first license change, we want to make the decision process public, and thus, this issue was created.

Feedback is welcome! If you have any more input (or disagreement) regarding the change towards GPL v3, please leave a comment below.

[sliverc]

Thanks for bringing this discussion into the public.

While it is true that it is python code called directly from Caluma, we still consider those modules to be configuration.

I do not consider extensions as configuration but it is basically the business logic of an application resp. enforcing such. In extensions someone might call other APIs, having an arbitrary algorithm based on current OIDC token or even the current GraphQL context. Much more than just some simple static defines they are talking about it in the case of Drupal.

The main reason we chose the AGPL over the GPL was to avoid the SaaS loophole as described above. However, after some further discussion, we probably assessed the risk way higher than it actually is. How much harm does really come to Caluma and it's community by some SaaS taking an undue profit from it? And how much better could Caluma be if it is instead adopted by some organisations that (rightfully) are wary of the AGPL's implications?

I couldn't agree more that the risk of take over is fairly low, because I think an open source project is not just code but much more its community. If someone wants to carry their own patches they will diverge from upstream project quickly and it will cost them more to update their code base than just bringing their patches upstream into the community.

However GPL might make adaption still harder then it should be. Especially as I consider extensions as being linked to the project such would need to be licensed underneath GPL as well and given at least to the direct customer. For some software companies this might not be feasible because of existing contracts or internal politics. Such company might still be a valid community member though.

Even though I could live with Caluma being licensed underneath GPL I still want to advocate that we leave politics and ideology aside and put Caluma's community at the center by continuing using the MIT license.

[rhizoome]

We are not doing the licensing for other people, we do it for us and our customers. As clearly stated in our manifesto, There is no obstruction when we use GPL. Just like everybody can use gcc. The Web-API is our interface and it is not limited by GPL. No distribution of code: no problem. Yes GPL.

AGPL on the other hand limits the API, has difficult edge cases and is not enforceable at all. Therefor no AGPL.

MIT is a big risk for the customer, since it allows hostile take overs (AOO -> LO), I would not recommend anything less than GPL. We have some customers that run into this problem and it was very expansive for them. No MIT

http://hintjens.com/blog:68

Also this is about politics and ideology, we as company want to send a clear signal, that we support Free Software, and that we are not supporting big-capital-IT to freeload on Free Software, which is at currently a very very worrying problem. @nikslor

I am also ok, to go more permissive (LGPL? MPLv2?) for the frontends, since they only will work with Caluma, which is GPL.

[sliverc]

I am not against GPL but my point I was trying to make is that there has to be a solution for the Python Caluma extensions API to use GPL (or of course AGPL for that matter) or otherwise it adds legal uncertainties to potential adopters.

We consider those modules as configuration. Sharing these is not required.

This is currently the solution stated in the README.md for the extensions issue.

My concerns:

• IANAL but a README is in my opinion not legally binding but the license is. But even if the promise upholds a future large contributor might still want to enforce opening up configuration following the GPL license.
• This statement somehow contradicts the Caluma documentation itself - on one hand there is configuration and on the other hand extensions where there are also words used like customization, extending etc.
• It understates what the Caluma extensions API is able to do, as someone can easily integrate any 3rdParty system with it. As the extensions are chainable the API is even designed for extensions to be reusable. Some might want to write an extension to integrate OPA 😄

I guess the whole issue is that the Caluma extension API does not clearly separate configuration and code.

So the solutions I see:

1. Clearly state that extensions need to be published underneath the GPL (see e.g. how Joomla does this) - extensions creator would then have to separate their code and configuration parameters in their extensions. This adds clear guidance to adopter and adds legal certainty but also friction.
2. redesign the extension API to clearly separate configuration and Python code (could also be a more microservice-like approach)
3. use a permissive license like MIT
4. Try to adjust the GPL license to specifically allow extensions not to be covered by the GPL (I am actually not even sure this is possible resp. good practice accepted by the general OSS community)

These are just some thoughts. Maybe there are other suggestions how to solve the extensions issue but I think this point needs to be addressed properly if AGPL or GPL is chosen as a license.

[rhizoome]

TLDR: Switch to GPLv3 no further actions required, @sliverc concerns only apply to AGPL.

It understates what the Caluma extensions API is able to do, as someone can easily integrate any 3rdParty system with it. As the extensions are chainable the API is even designed for extensions to be reusable. Some might want to write an extension to integrate OPA smile

I decided to answer this completely different (sorry for the ideology I still mean it, but it's a moot point now):

In my first answer I missed one point, there is actually no problem about config at all, because we move away from AGPL.

The user: The company or organisation running Caluma on their servers.

1. If it is only config, the user won't distribute Caluma and there is no problem (we moved away from AGPL)

2. If it is more elaborate, even a extension, if the user only uses it for himself. Still no distribution -> no problem

3. If two different users share a extension, we might enter a gray-zone, but it is exactly what we want: to be able to use extension A built for user A/B in a Caluma installation by user C

4. If someone makes a closed source Caluma extension, and distributes the extension, he is clearly in violation of GPL

So the user has a lot of freedom, but hostile take over and freeloading is prevented.

So there is actually nothing we have to worry about.

[rhizoome]

Goals formed in live and email discussions

Based on the discussion in this issue, we reevaluated our goals. We want

• diverse uses and integration of Caluma
• Caluma to remain public as Free Software
• an active community
• to guarantee mutual benefit to our contributors

We found that the definitions in AGPL aren't as clearcut as we wished; therefore, we want to switch to GPL-3.0-or-later. GPL will support all of our goals, with a minor draw-back: Not every last modification is guaranteed to end up in public. Which isn't that bad and it resolves all discussion about configuration.

What GPL-3.0-or-later means for Caluma

The following summary is not legally binding, please referer to the GPL-3.0-or-later license.

You are free to modify and extend Caluma as you wish. You can integrate Caluma with any software you wish. If you publish or sell

• a modified or extended version of Caluma
• or an extension to Caluma

you have to make the source-code of these modifications available under GPL-3.0-or-later or a compatible license.

[winged]

Is now merged and released as version 3.0.0