I have used many open source tools and I have convinced my company to buy the commercial license of the said tools to get the enterprise version and support. Win-win for both parties. I use and improve my skills on the open source version of the tools I love. Our company uses great tools. The project maintainers get paid.

But I don't think I'll ever buy an enterprise version of the software which can't get the simple matter of open source licensing right. It isn't that hard. Thousands of developers are doing it.

If the tool was totally enterprise version only, I'd probably have less qualms about it. But to advertise a tool as open source license but then violate the open source licensing method both in spirit and the letter of the law is just too unprofessional for me that I'd steer clear of them in future and discourage anyone I know from spending their money on them.

Restrictions like this, where your code is only available for use for certain purposes by certain kinds of users, are explicitly rejected by both the open source and free software movements. If a developer wants to license their code this way, they should admit that what they're building is not an open source platform. Then they can simply use one of the licenses like CC NC or SSPL that are designed for that purpose, instead of trying to stitch together an unfree license out of a bunch of free ones.

The AGPL accomplishes the same thing, except there is no ambiguity and you never have to wonder "could I be sued for using this software?"

It isn't really reasonable though. The word "may" implies possibility, not absolutism. So reading the sentence logically, at least to me, saying that I "may be" able to license it under the AGPL means that I might or might not be able to do that... And I have no way of knowing if I can or can't unless I... What, contact them?

> But nobody will get sued, and that's the only thing that matters.

Do you really want to bet your business on that? Vizio thought the same when using GPL code, and now they are in court. Software Freedom Conservancy sues Vizio for GPL violations - https://www.zdnet.com/article/software-freedom-conservancy-s...

Someone tried to shake our company down once. They posted all this stock imagery on the web, waited for someone to use it with an ambiguously worded attribution policy, then have a third party chase you down and demand $100k but will settle for $5k.

It turns out we did attribute the right way (in our terms of use) and could prove it with logs of when we added the language and when it was removed after we removed the image, but I am sure they nail people all the time with this strategy. This didnt stop them from sending 20 emails, demand lawyers get on the phone, etc.

There are a couple of similar scams like this out there.

It seems obvious that this ‘may’ is the ‘may’ used in the sense of granting permission: “you may go to the restroom”, “you may begin eating”, “you may ask questions now”, “you may kiss the bride” etc.

All these are clear. The wedding officiant isn’t saying “You might have permission to kiss the bride! Just try it and we’ll find out! Ha ha!”

To interpret this as saying that you might be licensed is just as nonsensical as that in this context. It’s in a file named “LICENSE.txt” explicitly meant to describe the license terms.

Would ‘are’ be better? I’d say yes, but it’s silly to argue that this isn’t proper English for granting permission.

Is the bad publicity worth it with this kind of rug pull to "we are opensource, but not really"? I get that an open source product can get you some free (word of mouth) and good publicity. But in general, open source is also strongly associated with "free" (as in you don't have to pay money for it). So if you do want to make money from a software product, weigh the pros and cons carefully - commercial open source products do tend to be less profitable than commercial closed-source versions. If you are ok with that, go with the open source business model. Otherwise, stick to the closed-source business model from the get go. Be honest from the start - brand damage is really costly to repair.

Ok, their license is pretty strange: https://github.com/mattermost/mattermost/blob/master/LICENSE...

MIT for binaries distributed by Mattermost.

But, if you compile it yourself: GNU AGPL v3.0 XOR Paid-for Enterprise License

Then, for some odd reason, they append the text of Apache License Version 2.0!!!

I'm already shutting down my private instance of Mattermost, no thank you. I'm thinking of Zulip, at least they aren't pulling this shenanigans.

Isn't this by default unlicensed then? I would avoid it anyway. Absolutely no need for that risk.

> at this time we are not entertaining any changes as such.

Always wonder what leads people to write like this. What does "as such" add to the sentence? At least "at this time" is temporally conditional to the future, it has purpose.

Entertaining is posh "thinking about" or "interested in" so had the merit of being one word in place of two but so is "considering"

Are we not entertained?

This would lead me to steer away from the project. They clearly like the way it is and that is unclear for everyone apart from maybe them. I am not even sure it benefits them though.

Submitted title was "Mattermost say they will not clarify what license the project is under", which is against the site guidelines: "Please use the original title, unless it is misleading or linkbait; don't editorialize." (https://news.ycombinator.com/newsguidelines.html)

I'm open to a different title than "LICENSE: _may be_ licensed to use source code; incorrect license grant", which is obscure enough to qualify as misleading if not linkbait. However, its replacement should be an accurate, neutral title that preferably uses representative language from the article itself (https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...).

Re the "don't editorialize" bit in the rules: If you want to say what you think is important about an article, that's fine, but do it by adding a comment to the thread. Then your view will be on a level playing field with everyone else's: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...

Not clarifying is the right thing to do. If the license is unclear, it should be fixed by a lawyer who knows what they are doing. Nobody else in the company should try to explain what the license actually means. Trying to explain a license creates informal interpretations and a legal paper trail that can confuse things even more and be used against the company later. It can even create a new contract under some jurisdictions.

Mattermost should be aware of the contra proferentem ('interpretation against the draftsman') doctrine of contractual interpretation. Ambiguity works against the party who provided the wording.

Sometimes a license is confusing to a layman but consists of standard, established legal jargon. Don't touch the code until you know what it means from a source that knows what they are talking about. Don't take internet guesses or opinions as fact.

This is why using standard well drafted licenses verbatim is so useful. Legal phrases that have established meanings clear things up for legally even if they confuse the rest of us.

The last message on that thread before lieut-data responded and closed it was in 2023. Why did they even take action or reply to the issue in the first place? It could have easily gone under the rug.

I suspect that no lawyer checked off on this licensing strategy.

I'm also not so sure a serious business person checked off on annoying and scaring users that aren't but might in the future become customers or otherwise paying users.

Are there any instances where a fork of a project has altered the license language for the purpose of reducing this kind of ambiguity?

Either the original license grant is expansive, so the clarification is welcome and the fork will become the standard unless/until the modification is upstreamed, or else the grant is restrictive, so the fork language is invalid, and the grantors face the risk of laches or other equitable defenses if they don't stop the fork from offering the less ambiguous interpretation that grantees rely on.

Fork as legal test case, if you will.

If you are looking for another self-hostable alternative to Slack, Rocket chat[0] is also worth looking at.

I wasn't involved in any of the Dev Ops aspect when my former employer used them, but the search function actually worked which is better than I can say for Slack.

[0]https://github.com/RocketChat/Rocket.Chat/blob/develop/LICEN...

I would just stay away from Mattermost. Don't host, don't use, don't contribute. Treat as source-available.

I am not a lawyer.

My reading of the license is: either (a) buy a license or (b) be bound by the AGPLv3 -- with _very_ limited exceptions.

So, my question is: are the people that are upset with the "ambiguity" people who neither (a) want to buy a license nor (b) be bound by the AGPLv3?

If so, I have no sympathy.

GPL and AGLP both use the word "may" 31 times.

If you aren't comfortable with the word "may", you'll have a lot of trouble with open source languages.

https://www.gnu.org/licenses/gpl-3.0.en.html

https://www.gnu.org/licenses/agpl-3.0.en.html

If the binaries are licensed under MIT, can I decompile the binaries, clean up the source code and have a clean version of Mattermost for distribution?

They want a business of some sort, not AGPL I'd assume. It doesn't look nefarious, just misguided. However a license switch will cause another hellstorm so I suppose they're in a tough spot.

So the license starts out saying you can use the compiled binaries under MIT and the source code as either AGPL or you can receive a special license.

Then it goes on with the Apache license text.

This looks like either they are deliberately trying to trick people into thinking it's the MIT license, or have accidentally made the most confusing and nonsensical license ever.

MIT licensed binary in a source code repo does not make any sense.

This is a huge red flag.

I dug around for ~10 minutes and it's probably not an exaggeration to say that Mattermost might have the most confusing licensing of any software product in existence.

From the license page on their repo (https://github.com/mattermost/mattermost/blob/master/LICENSE...):

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

So just the compiled versions, not the source code. Ok, at least that is clear. But - the MIT license explictly allows for modification and redistribution. So can I do that?

The next line.

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

Except this file doesn't exist anywhere in the repo or outside.

> 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 > 2. Under a commercial license available from Mattermost, Inc. by contacting commercial@mattermost.com

What does "may be licensed" mean? Do I have to contact them for a license? Or is an AGPL license implied?

> You are licensed to use the source code in Admin Tools and Configuration Files (server/templates/, server/i18n/, server/public/, webapp/ and all subdirectories thereof) under the Apache License v2.0.

Sure, let's throw another license in there, because there weren't enough already.

> We promise that we will not enforce the copyleft provisions in AGPL v3.0 against you if your application ... [set of conditions]

WTF does a "promise" mean here? Is this actually AGPL or not?

Then they have copy pasted the entire Apache License, even though the project isn't licensed under Apache. Why??

Oh but that's not all.

There's a separate license page at https://docs.mattermost.com/product-overview/faq-license.htm..., which says:

> Mattermost Team Edition (Open Source) - Open Source MIT License.

Uh, what? That goes against everything said in LICENSE.txt. So now we are back to fully open source?

I think more software people should be doing that. Just confusing the hell out or lawyers (armchair and proper).

You should read the license, it seems somewhat insane to be honest: https://github.com/mattermost/mattermost/blob/master/LICENSE...

Go on Zulip or Anytype

Licenses are not about what things "seem", their text should be clear enough to hold up to legal scrutiny, not just what some person who speaks some local variant of English thinks is obvious.

Even if you're a lawyer, whether it's obvious to you is irrelevant: it has to be obvious to everyone. And if it's not (and it should be abundantly clear that it's not, given the linked discussion), the license needs fixing.

But it is saying "You may be licensed to use source code..." which is analogous to "You may have permission to kiss the bride" if being licensed means having permission. It could mean that Mattermost may have licensed it to you in one way or the other, or neither, at their discretion. If it was written like a priest, it would have said "You may use the source code..." and this doubt wouldn't exist.

Speaking only for myself here. But I don't have the arrogance to assume that I can interpret legalese the way I interpret English. When shit goes to court, saying here's what I thought "may" means is not going to be a legal defense strategy. There's a reason I hire lawyers for this kind of shit because they are really good at their job and I won't pretend I know their job better than they do.

The counterpoint is that three sentences away, there's a clear "You are licensed to use the source code" for the non-server parts. It can certainly be argued that there's an intentional difference. Extended court cases have been fought over mere punctuation. In any case, the FUD that this creates is enough to make anyone think twice about reusing the server code, especially as they have refused to clarify for many years now.

Also, the ambiguity is not only in the "you may be" part, but also in the "to create compiled versions" part. Open source is more than creating compiled versions of source code.

  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
  2. Under a commercial license available from Mattermost, Inc. by contacting commercial@mattermost.com

Isn’t the right thing to do is for “the company” to clarify the license it offers its software and code under?

I think we understand that random devs on GitHub aren’t the right ones to resolve it, but I find it hard to believe the correct response is for the company to do nothing.

> If the license is unclear, it should be fixed by a lawyer who knows what they are doing.

It's been 7 years and not fixed, apparently.

> Not clarifying is the right thing to do.

Legally? Likely not. Ethically, definitely not.

Legally, (in the US at least,) any ambiguity in the interpretation of a contract will most often be interpreted to benefit of the party that didn't draft the contract. In this case, the interpretation of license would likely benefit the user. But then, I'm only repeating what you've already said. So the ambiguity here doesn't benefit them legally speaking. I do agree, a frontline engineer shouldn't be trying to clarify the legal meaning in a github issue (without the legal expertise a good legal team would contribute). I don't agree that leaving the understanding to be ambiguous, is a solid legal decision.

Then, ethically. If someone ask if the license is trying to trap them, and all you do is shrug. You're not the good guy, ethically speaking.

> This is why using standard well drafted licenses verbatim is so useful. Legal phrases that have established meanings clear things up for legally even if they confuse the rest of us.

This may be pedantically true, but the part that trumps the US doctrine of contra proferentem, is the original intent that both parties likely understood. The legal interpretation, while you say it may be confusing for some people, doesn't override what the parties reasonably understood the contract to state. Or in this case, license, to grant.

That is to say, if you represent your offering as open source, and enjoy the benefits of such. It's a fundamental error to assume the courts will later back you up when you change your mind, and attempt a rug pull. And that's ignoring the ethical implications, which are enough for me to wanna peace out. (I.e. if you're pissing off your users and supporters, it was the wrong decision.)

If the license has been unclear for 8 years and the company hasn't bothered to get a lawyer to fix it then the "I'm just an engineer and don't know about this stuff" excuse doesn't apply. It's obvious that they are deliberately keeping the license vague and confusing to scare users into paying for a commercial edition while also calling their product "open source" for marketing purposes.

Wouldn't that license also violate the AGPL? I mean, it does say, in section 7:

> All other non-permissive additional terms are considered "further restrictions" within the meaning of section 10. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term. If a license document contains a further restriction but permits relicensing or conveying

So, my interpretation is that I am free to license it under the AGPL; there is no "well, we might decide to do that", and I can strip all conditions they place upon me and comply only with the AGPL, and legally there is nothing they can do about it.

"We promise that we will not enforce" is perhaps a funny way not to grant a license, but making it sound like they do. This seems almost purposefully designed to look open-source to laypeople, while being carefully written in a way that ensures it will be vetoed by any corporate lawyer vetting the license.