HN Reader

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.

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.

> 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?

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.

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?

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.

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.

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 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

The license seems perfectly clear in that it's multiply-licensed under AGPL, MIT, and corporate licensing based on different use cases. Maybe this guy has reading comprehension issues, but more likely he's just unhappy with the corporate part and wants to stir drama.

if there is no license, then it is public domain if they put code on a website

To me, this seems kinda reasonable.

The reality is licenses are all nonsense and none of it makes any sense. There could be secret patents nobody knows about. That precise wording written by American lawyers might not hold up in Chinese courts. There might be two compatible licenses, but one is 20x the length of the other; obviously some legal expert thought those extra words were needed - but are they? What's going on with linking and derivative works? Do you need to copy-and-paste the full legal blurb into every single file, or not? Why are some sections written in all caps, and does the reason for doing that apply globally? What if someone claimed to have the right to contribute code to an open project but actually had an employment contract meaning the code wasn't theirs to transfer? What's the copyright status of three-line stackoverflow answers?

The truth is nobody knows, and nobody cares. You and I won't get sued, probably, and if we do it's not like we'd have avoided it by reading the license. Might as well ignore it, like people ignore website terms of use and software click-through licenses and other legal mumbo-jumbo.

On the other hand, if you're the kind of gigantic enterprise that has policies on software licenses and a team of in-house lawyers and you can't use this software without greater license clarity? Well, you can get that licensing clarity with the enterprise version of the software.

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?

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.