The mattermost-server licensing[0] is somewhat skeptic:
Mattermost Licensing
SOFTWARE LICENSING
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 v.3.0, subject to the exceptions outlined in this policy; or
2. Under a commercial license available from Mattermost, Inc. by contacting commercial@mattermost.com
You are licensed to use the source code in Admin Tools and Configuration Files (templates/, config/default.json, model/,
plugin/ and all subdirectories thereof) under the Apache License v2.0.
So that means, only the binary provided by Mattermost is MIT, not its source code, the usage of 'MIT' in their website sounds deceiving.
It is a bit unusual, but ultimately it's similar to the quite common "you can have the code under AGPL or negotiate something else with us" plus something unusual, i.e. a MIT-licensed binary.
Ultimately if you're okay with running AGPL code you're okay with running Mattermost. Which means as long as you don't intend to fork it and not share your changes you should be fine.
> Ultimately if you're okay with running AGPL code you're okay with running Mattermost. Which means as long as you don't intend to fork it and not share your changes you should be fine.
That's not how [LA]GPL works. You are free to fork, and not share the changes. The modified source code can be provided only to the people whom you gave the binary (Edit: AGPL has bit more terms, as said in comment below), and you can make it private to the rest of the world (though you can't add additional restrictions).
As Mattermost is dual licensed under AGPL, anyone who uses it under the terms of AGPL can live safe as long as they obey AGPL.
Software pieces using GPL licenses can't add additional restrictions to the software, but of course authors are free to dual license under different terms.
Say for example some one can specify the following for their project: "We provides the project under the terms of MIT for you to modify and run for your own purposes." This might look a harmless statement, but it could mean something very different and may be intentionally written, that essentially makes it non-free. GPL doesn't allow such additional clauses.
Disclosure: IANAL. So I don't know how/if it works in court
> AGPLv3 requires a program to offer source code to “all users interacting with it remotely through a computer network.” It doesn't matter if you call the program a “client” or a “server,” the question you need to ask is whether or not there is a reasonable expectation that a person will be interacting with the program remotely over a network.
Forgive me if I'm wrong but wouldn't you be allowed to fork it and not share your changes anyway? As far as I know a copyright license is only required if you do share it.
Of course you couldn't share any derived binaries without a valid copyright license, but for internal use there shouldn't be any problem.
There might be problems even for internal use because it's licensed under AGPL not just GPL, so the source must be distributed to network users, even if you don't share the binaries with them.
It might work for your company's internal chatroom but not for selling Mattermost as a service.
That's the intention anyway, I'm not a lawyer, I don't know if AGPL was tested in court, and whether it would hold up.
So if I understand correctly, AGPL allows single users to use the software but they cannot provide this software as a service? I've also seem some open source SaaS offer a dual license for single users and corporations. MIT or Apache for single users and GPL for corporations.
You can provide the software as a service BUT you have to give the source code to all users, including your modifications if you have made any.
In other words - you can't sell SaaS based on AGPL software + proprietary secret sauce, you have to share back your secret sauce with all users.
It doesn't prevent you from selling it as SaaS, I could sell vanilla Mattermost as a service under AGPL, my selling point might be that I provide high reliability and excellent support.
Do you have an example of that dual license?
I don't see how that would work, the first person you give an MIT license to can re-distribute it under MIT to anyone else, including corporations.
Usually for dual-license you have the opposite, you would have a restrictive license like AGPL for the public, and you would sell non-free licenses with no redistribution rights that allow modifications without sharing back, for corporate clients who want to add their secret sauce to the software without having to give away the secret sauce for free.
Is this Mattermost's answer to the current debate around the ethics of FAANG (and others) using open source software to make lots of money without substantially contributing back to the OS projects financially or in code?
My understanding is that, Mattermost is okay with others making money from their software if they don't modify it - which will practically work for some, but not all, small companies, and will be very difficult for the big companies to use. If the big companies want to modify and use Mattermost-server for free they are forced to contribute back the changes to the OS project, and then can make as much money as they want. Or use option 2, pay Mattermost a bunch of money for the privilege of not contributing back code to the OS project. In other words FAANG and co can either contribute to Mattermost financially or in code - their pick.
No, it's a "grant to Mattermost and to recipients of software distributed by Mattermost a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute your contributions and such derivative works."
Yes but in these situation the copyright assignment is a separate contract underwritten by the person committing. What (I think) driverdan means is that an OSS licence legally cannot substitute this separate contract - one cannot automatically assign one's own copyright to another entity by following an OSS licence.
Yeah, this struck me as odd too until I realised that the MIT license says nothing about source code. It just talks about redistribution. So what they are saying is that the binary is redistributble for any purpose, but if you want to distribute changed versions of the source code you have to do it under AGPL. That's weird, but potentially OK. The only thing it does is allow you to redistribute the binary without having to supply the source.
The reason I say "potentially OK", though is I wonder if a binary can be assigned a copyright as distinct from the source. The binary is only a machine translation of the source after all. Not a lawyer, so I'm not certain, but it seems a bit odd. I can't imagine a situation where anyone would challenge you, though --- they are giving you extra rights, not removing them.
Advertising as "open source under license X" when, if you read the fine print, license X does not actually apply to the source code is pretty uncommon.
We recently switched from Slack to Mattermost and love it. My only gripe is that replies show up in the main room thread which makes catching up on posts almost impossible.
There is a request to implement collapsible threads[0] but I haven't seen any new updates address this.
I'm hoping this new funding round amps up a few developers to take on this much-needed feature.
Interesting, that's actually one of my biggest complaints in Slack. If a discussion should be public, it should be visible. Threads in Slack are a pain to pay attention to because they're "hidden" from view in the main channel. I appreciate how MM keeps threaded messages in the channel.
This is the biggest thing blocking us from moving from Slack to MM. With Slack you have the option of replying to a message in the channel and keeping it fully visible, just by replying in the main chat, so why don't you just do that and not use threads?
Slack only recently got threads at all -- I realize it's easy to get used to them but maybe reconsider whether it's really become a show stopper. You probably would have used Slack before they implemented threads, after all...
We've switched to on-premises MM from HipChat at the beginning of the year.
I miss the video conf functionality of HipChat, but other than that I think MM was the right decision for us. Everyone on the team seems to be happy with it.
> We recently switched from Slack to Mattermost and love it.
> ...makes catching up on posts almost impossible.
Seems odd those 2 statements are in the same comment. How can you love a product that has such a big flaw in the basic workflow? For the record, I've never even heard of Mattermost until today, but just thought that was strange to read your comment.
I don’t think it’s strange to “love” something just because you can point out its flaws. It’s not like the alternative is perfect, and depending on your point of view, it might have flaws that are more fundamental or hard to fix.
When open source projects get VC funding, it makes me trust them less. Eventually, the investors are going to want their money back with a profit. When that happens, the companies are going to try to monetize their offering often in ways that are detrimental to the open source project.
I'd say I trust more companies that already are earning money and open source something, it's less likely that they will bait and switch to a proprietary. Or some like mattermost or mariadb are clean about a possible business plan. Way better than a non standard open source license and vague prospects of VC money.
Sincere question: what's the point of GitLab or Mattermost being open source when they clearly want to control/restrict/monopolize use of their applications?
IIRC GitLab is "open core" which just means it's not fully open source and Mattermost is not really fully open source either, it its own confusing way.
The purpose of open source was to give users full and unrestricted power. To free them from lock in and allow them to be the masters of the software they use.
It seems that these companies view open source as a marketing trick and perhaps a way to save on development costs. They're making a mockery of open source and should probably be shunned for it.
I think it is a pretty fair as they have people working full time in their products since their conception. I'd rather companies providing their source and strugling to monetize their product than companies selling just closed source alternatives.
Restrictions could be provided by people through OSS, these companies don't prevent these alternatives from existing. The lack of interest does. The same could be said about many OSS that strugle to receive donations.
I could agree that a world where only OSS without monetization exists, where people donate and keep people investing their time on improving OSS without needing restrictions. The reality is that without these restrictions, people are not willing to pay.
> what's the point of GitLab or Mattermost being open source when they clearly want to control/restrict/monopolize use of their applications?
- We can fork it if we really don't like that direction, but think what's there is valuable.
- We can propose Merge Requests (as they are on GitLab) that might be higher priority for us personally than for the company, which might accept them just not have the resources to work on them itself as quickly as we'd like.
> Mattermost is not really fully open source either, it its own confusing way.
Honestly curious: In which way is Mattermost not Open Source? As far as I can tell the code is under AGPL, which may not be the most popular FOSS license, but is generally accepted as being one.
> IIRC GitLab is "open core" which just means it's not fully open source
Gitlab CE is fully open source. Gitlab EE is proprietary. The same company produces both, but you can decide to use only the former, and remain fully in control.
This is certainly not the vision of the future that supporters of a fully-FOSS world like me wish to see, but seems strictly better than most proprietary companies, which still use FOSS code/libraries while contributing little or nothing.
I'm pretty amazed at the number of chat offerings that don't offer encryption. (From a quick Google search it seems Mattermost doesn't either.) I'm still holding out for Matrix to deliver (I know it's currently working for some people), but my understanding is that it's not enabled by default yet:
https://github.com/vector-im/riot-web/issues/6779
Mattermost does offer transport level encryption, via HTTPS. For most things, that's plenty good enough.
But for many organizations, they want unlimited viewing of the messages anyway, so E2E would be a non-starter.
It all depends on your needs.
Mattermost would never be a good solution for a global chat system, nor would it be a good fit for wide-open public/untrusted access chat either, both of those are where E2E type encryption would really shine.
I thought you were also waiting for cross-signing (which seems to have progressed quite well) to land?
Isn't E2E search mostly a client-side matter? Unless using homomorphic encryption, of course, which I don't think OLM is capable of?
Or are you planning on using another trick, similar to hashing the strings client-side when a new message is received, then sending the hashs and later searching those server-side?
I'm curious since I haven't seen that mentioned other than using pantalaimon as some kind of server-side search engine. I can ask or discuss this further in matrix(-spec):matrix.org as needed/preferred.
E2E search is entire client-side, and works thanks to https://github.com/matrix-org/pantalaimon/tree/search. We're not doing homomorphic stuff; instead we're thinking about encrypting the tantivy indexes and storing them serverside.
What blows my mind about Mattermost is the server requirements... for what essentially is a message broker, you have need a multi-gig box for a deployment that can support 8 people. Part of the problem is their tech stack.
That sounds like overestimating just to be safe. I run an MM instance for triple that number of people on an ARM SOC with 2GB RAM and it works beautifully. Not only that but I compile it from source on the same box with no problems.
To be honest (and partial, since I haven't self-hosted many contenders), I didn't find Matrix that complicated to setup. The most complex and resource-hungry part is federation, but you can likely do without if you don't need it (since it is one of the biggest selling points of the tech, I am afraid there shouldn't be many guides omitting that part).
I did it trough Yunohost on my server, but I hear there is a handy Docker-ansible playbook, and that the Archlinux package works pretty well (synapse is also available trough pip).
I guess someone could cook up a non-federating server implementation some day…
> Only the default GitLab SSO is officially supported. “Double SSO”, where GitLab SSO is chained to other SSO solutions, is not supported. It may be possible to connect GitLab SSO with AD, LDAP, SAML, or MFA add-ons in some cases, but because of the special logic required they’re not officially supported and are known not to work on some experiences. If having official AD, LDAP, SAML or MFA support is critical to your enterprise, please consider Mattermost Enterprise Edition as an option.
I see a lot of cool Slack competitors. Including Keybase Teams. But raising $50M seems like a lot for an open source one!
It makes me hopeful that we will be able to raise that kind of money soon for our platform. We also have AGPL dual license. However, our goal is more ambitious: we built a platform (https://qbix.com/platform) to let ANYONE build their OWN social apps and plugins, and then let communities host them. Like Wordpress + Plugins but for Web 2.0 (think Facebook rather than blogs).
I imagine building a Slack competitor would take about a month of focused work. And then anyone would be able to install it, on one machine.
But, we spent all these years building the tech and doing security audits. What are your recommendations business-wise, to take it from here to getting funding like this? (Without compromising the vision.)
We are using Mattermost for over a year at work, and I would love to get a native client for their app, even a bare bones one. Currently running it with https://github.com/EionRobb/purple-mattermost but something more supported would be great
It's odd that that page refers to the desktop client as "native". The parts of an electron app that are native to the OS (as opposed to the OS-independent HTML/JS) are irrelevant to most people's desire for "native" apps.
The client is just an electron app (ie a very thin wrapper around a webpage). One of the more glaring examples is unable to monitor inactivity and set away status correctly.
Does Mattermost support drawing on screen share? It is one of the killer features for me in Slack, and at some point Google Hangouts had it but removed it, and Meet does not have it.
We've been using a combination of Discord / Telegram / Google Meet instead of Slack and haven't had any problems. There are lots of great alternatives out there.
I'm no slack advocate, but you just described using three services to replace one. There will be some extra mental overhead to such a setup, even if it is not huge. I think something like mattermost carries the advantage of one service, one interface, one place for things; it's a little easier than "oh, in which did I put that?".
I wish there was something as simple to use as Discord but selfhosted. The closest thing I've found so far was rocket.chat which is only halfway done or Matrix which has close to no admin tools available.
If anyone from Mattermost is listening, it would be wonderful if they offered the whitelabel deployment (for SSO) of apps as a service. For a startup without any presence on the Apple or Google app stores or specific mobile needs, it would be amazing to have someone package that up for enterprise customers and take care of keeping the app up to date.
That depends on what you mean by "provider", I suppose. Google is not going to be interested in doing this, I suppose a consultancy or MSP could offer this as a service if they resell Mattermost, but I don't know if Mattermost has that sort of sales network or system.
On the other hand, for enterprise plan users it would make sense to rely on Mattermost for app distribution, and they have the expertise to publish the apps and ensure they're approved in the respective stores. Would a reseller or MSP necessarily have that competency? I come from the IT world where the answer would definitely be "no", but I could see it being part of contracted out work. Who owns the app then after that contract is up?
Yeah, this is true in a lot of cases. But it seems to go against the spirit of open source and turn it into a shared source model... maybe that's fine, but it ends up with people using open source as a marketing vehicle to attract developers rather than being truly "free and open source" where governance and viability isn’t tied to a single company’s fate.
If it has an open source license, it is 100% truly "free and open source". That's a good thing, not a bad thing! There's nothing magic about foundations or volunteer organizations that make some things more open sourcey than others. That's the beauty of it, the lifetime of the code isn't bound to the lifetime of whoever made it, for whatever reason they chose to make it or stop making it. It's just the license, not who wrote the software, and not why they wrote it. Everyone gets the benefit of their labors regardless.
Volunteer communities and nonprofits are no silver bullet either- they're great when they exist and function well, but they don't always, and are highly dependent on who's involved, how much, and why. If there's a big, strong, vibrant community behind something, that's a good sign for whatever that thing is, but very few projects rise to that level of centrality in people's lives. There's also no shortage of projects without funding which have terrible or nonexistent communities surrounding them. Usually good communities arise during the long tail of maturity, like years or decades after whatever it is has reached a plateau of collective usefulness. Good software leads to good communities, sometimes, eventually, but it generally doesn't go the other direction. Something has to be great for years before it becomes that critical and that supported of a piece of infrastructure. That's why it's good that open source is only a factor of the license, not who made it, not who maintains it, not why they maintain it, and not how it's funded. That's literally what is special about it and makes open source a useful and good thing.
I feel like someone could corner the market just by making tab complete that works as well as IRC did and adding a full dark theme to the desktop client.
I'm using Mattermost for communicating with one team and I absolutely hate it. It feels so completely unfinished, like it's some kind of proof-of-concept? I don't mean to diss on Mattermost, I'm actually very excited to see them getting funding as Slack has like their name implies: slacking. What has Slack done over these past few years? Exactly, nothing! I don't mean that good software needs to keep updating, no not at all. It's just Slack can improve so much and it's just sitting there. I am really looking forward to replacing Slack with something else.
For all of the people going to suggest Matrix or something else to me, hold your breath. The reason I haven't switched is because communities haven't switched and neither have companies.
Mattermost Licensing
SOFTWARE LICENSING
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 v.3.0, subject to the exceptions outlined in this policy; or
2. Under a commercial license available from Mattermost, Inc. by contacting commercial@mattermost.com
You are licensed to use the source code in Admin Tools and Configuration Files (templates/, config/default.json, model/, plugin/ and all subdirectories thereof) under the Apache License v2.0.
So that means, only the binary provided by Mattermost is MIT, not its source code, the usage of 'MIT' in their website sounds deceiving.
[0] https://github.com/mattermost/mattermost-server/blob/master/...