It’s just so phenomenally little it doesn’t make any sense, a full routine wouldn’t even full charge a smartphone battery (not even close). Put solar on the studio roof instead.

I think you’re wrong on that one. E.g. when cycling, 100W for 15 minutes is achievable for most people, which corresponds to 25 Wh of energy. To charge a modern phone you need about 15 Wh. So if your overall system efficiency is at least 60%, which seems realistic, you’d be able to charge a phone with that.

I guess it’s just not financially viable. Because those 25 Wh would still correspond to less than 1 cent in value (at 0.3€/kWh).

I think the problem is that the license grant (that has been in place for a decade) is not that clear.

You are licensed to use compiled versions of the Mattermost platform produced by Mattermost, Inc. under an MIT LICENSE

• See MIT-COMPILED-LICENSE.md included in compiled versions for details

You may be licensed to use source code to create compiled versions not produced by Mattermost, Inc. in one of two ways:

1. Under the Free Software Foundation’s GNU AGPL v3.0, subject to the exceptions outlined in this policy; or […]

I read it as releasing the binaries under MIT and granting people an AGPL license for the (non-enterprise) code. Some read it as not granting you the full AGPL rights.

To me, the fact that they advertise Mattermost as “open-source” and the statement on the “reciprocal license” above indicates that Mattermost also reads this as an AGPL license grant. However, they don’t seem to be interested in fully clarifying the license situation. But, I think they would have a very hard time to argue in court that this license doesn’t allow AGPL forks. And I haven’t seen any evidence of them acting against any of the existing forks.

Eh, that post title is quite sensationalistic.

1. Nothing regarding the license has changed in the last 2 years.
2. It seems like they consider the non-enterprise code to be licensed under the AGPL:

Thank you for the community discussion around this topic. I do recognize that our licensing strategy doesn’t offer the clarity the community would like to see, but at this time we are not entertaining any changes as such.

UPDATE Feb 2, 2026: To be specific, our license is using standard open source licenses, a reciprocal AGPL license and a permissive Apache v2 license for other areas. Both are widely used open source licenses and have multiple interpretations of how they apply, as showcased in this thread.

When we say we don’t “offer the clarity the community would like to see”, that refers specifically to the many statements in this thread where different contributors are confused by other people’s comments and statements.

For LICENCE.txt itself, anyone can read the history file and see we haven’t materially changed it since the start of the project.

If you’re modifying the core source code under the reciprocal license you share those changes back to the open source community. If you’d like to modify the open source code base without sharing back to the community, you can request a commercial license for the code under commercial terms.

Maybe we can hold the pitchforks a while longer, unless they actually make a negative change.