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.
Oh that's a classic trick. It's been going on for decades. One example I am particularly familiar with is that of Larry Philpot / User:Nightshooter on Wikimedia Commons. He would upload his photos there with an addendum on how he should be attributed. Any slight impression in the attribution would be followed by legal action. It was obviously a copyright troll mechanism and now all of his photos on Wikimedia Commons have forced attribution affixed by users that warns others that he sues people.
His stuff is so widespread that the consensus on Wikimedia Commons was to keep his photos and add a warning so that no one ends up accidentally using it. Some accused him of sock-puppetry to get his content into a place.
Today, intellectual property maximalism is a much more mainstream position so perhaps modern Internet users will think that he is in the right, but I think it's a bit much.
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.
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.
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.
I can whole heartedly recommend Zulip. They really get open source, allow you to own your data, and their UI despite being a bit quirky is IMO the best out there for handling complex conversations (the ability for admins to retrospectively move mesages between topics like old school forum software being a real standout feature).
I run a Zulip server and it's pretty good. The way they organise channels is extremely convoluted unfortunately (I wish they would just use absolutely standard channels layout like every other chat, and have everyone able to see them on join!) but well, beggars can't be choosers.
Yes, if the licensing terms are unclear, to err on the side of caution, it is best to assume "All rights reserved" by the authors of the software so you don't accidentally violate the authors' rights. And then hire a lawyer to sort this matter for you.
> 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"
Well, it means no changes _intended as_ changes [pertaining to the topic at hand]; it implies there may be incidental alterations or differences, eg this issue might be addressed in a blanket legal revamp (whatever that's called) but, at least over this, they aren't pulling over the station wagon to argue with the screaming stakeholders in the back.
It's what we used to call "load-bearing vagueness"
It's good English, it has actual meaning (your thinking of "at this time" is only one interpretation, it more likely means "We're not entertaining changes of that kind/nature" )
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.
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.
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.
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.
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.
Really? I have yet to use a single Slack-alike with search that actually works - including Slack, Teams and Mattermost. I mean they "work" in that the search results happen to include your terms too, but they give you the actual relevant message only about 10% of the time.
Rocket Chat does look nice! I quite liked Mattermost except for the mobile app being trash. How is the Rocket Chat mobile app?
> 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?
No and no. People first want to know what the correct licenses are even before deciding which licensing path (including buying a commercial license) to take. You don't just commit to buying a commercial license without first understanding your options and comparing those options. People want to know what those options are.
People are upset that a company cannot get the simple matter of open source licensing right. It's the easiest kind of licensing. But they cannot get it right. These upset people would now never want to do business with this company.
People who would have otherwise been happy to purchase a commercial license would also stay away from the company because messing up open source licensing is a red flag. Who knows what kind of mess would be present in their commercial contracts. Yes, you can hire a lawyer to sort it out but I'd much rather do business with a company where I'm confident that the company is acting in good faith even before lawyers get involved.
> If so, I have no sympathy.
Your sympathy means nothing to me when I am picking vendors for my business. When I'm picking my vendors, I'm going to rely on professional legal expertise available to me, not the sympathies of random strangers on the internet.
GPL says "You may do this." This file says "You may be licensed" -- that is not an action I am able to take, that is an action they either do, or don't. It's not the same.
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.
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.
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.
> 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??
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.
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.
It does create confusion because adding extra clauses onto whether you can use the AGPL kind of defeats the point of the AGPL, and creates a contradiction because the different flavors of the GPL generally all have language that tries explicitly to prevent such a thing, which is a pretty classic piece of confusion (I've had it when negotiating employment contracts and it's shocking how many people seemingly just never read the documents they're offering).
(EDIT: though, having read the whole document, it seems like there is just a trademark carve-out, which is explicitly allowed under the AGPL, so this seems reasonably straightforward, except for the strange 'we promise not to enforce copyleft if you don't modify the code' which seems entirely redundant. Oh, and the 'licensed to use source code to create compiled version' which seems like a very strange phrasing)
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
2. Under a commercial license available from Mattermost, Inc. by contacting commercial@mattermost.com
Licensing should never be left to "reading comprehension". If there is any doubt about the terms, a clarification should be requested. A clarification was requested here. The requested clarification was declined. If this matter was really so simple that simple "reading comprehension" would solve it, the project maintainers could have said so. But they didn't. And that they didn't holds more weightage than what some random stranger has to say about "reading comprehension".
... also some parts are Apache, and the wording around the AGPL bit is very weird:
> ... licensed to use source code to create compiled versions ...
Why's it calling out compiling specifically? Are they trying to imply you can't modify/distribute/etc the source? Presumably that would be a "further restriction" per the AGPL and hence ignorable, but it's sloppy at best and misleading at worse, which isn't great for a license document...
This is not true in the US where everything is automatically copyrighted and protected, so nothing goes directly into the public domain (even if the author wants it). Thus no license means that you have no license to use the code legally.
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 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.
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?
lefstathiou|27 days ago
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.
arjie|27 days ago
His stuff is so widespread that the consensus on Wikimedia Commons was to keep his photos and add a warning so that no one ends up accidentally using it. Some accused him of sock-puppetry to get his content into a place.
Today, intellectual property maximalism is a much more mainstream position so perhaps modern Internet users will think that he is in the right, but I think it's a bit much.
Here's the thread where he's discussed: https://commons.wikimedia.org/wiki/Commons:Administrators%27...
Here's an example forced-attribution photo: https://commons.wikimedia.org/wiki/File:Flaming_Lips.jpg
jabl|27 days ago
jrmg|27 days ago
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.
TheRealPomax|27 days ago
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.
foxglacier|27 days ago
throwaway150|27 days ago
throwaway89201|27 days ago
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.
thisislife2|27 days ago
PaulDavisThe1st|27 days ago
In the anglophone world, yes. In many other parts of the world, the gratis/libre distinction is clear in the language used.
LamaOfRuin|27 days ago
mring33621|27 days ago
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!!!
throwaway89201|27 days ago
giancarlostoro|27 days ago
nicoburns|27 days ago
pixelpoet|27 days ago
CuriouslyC|27 days ago
bilekas|27 days ago
throwaway150|27 days ago
Etheryte|27 days ago
[0] https://opensource.org/license/unlicense
Fnoord|27 days ago
ggm|27 days ago
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?
1attice|27 days ago
It's what we used to call "load-bearing vagueness"
gowld|27 days ago
awesome_dude|27 days ago
supjeff|27 days ago
duskdozer|27 days ago
plagiarist|27 days ago
BadBadJellyBean|27 days ago
dang|27 days ago
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...
u1hcw9nx|27 days ago
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.
madeofpalk|27 days ago
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.
gowld|27 days ago
It's been 7 years and not fixed, apparently.
grayhatter|27 days ago
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.)
paxys|27 days ago
NewsaHackO|27 days ago
cess11|27 days ago
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.
sowbug|27 days ago
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.
nix0n|27 days ago
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...
conception|27 days ago
IshKebab|27 days ago
Rocket Chat does look nice! I quite liked Mattermost except for the mobile app being trash. How is the Rocket Chat mobile app?
orphea|27 days ago
emacdona|27 days ago
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.
throwaway150|27 days ago
> (a) want to buy a license nor
> (b) be bound by the AGPLv3?
No and no. People first want to know what the correct licenses are even before deciding which licensing path (including buying a commercial license) to take. You don't just commit to buying a commercial license without first understanding your options and comparing those options. People want to know what those options are.
People are upset that a company cannot get the simple matter of open source licensing right. It's the easiest kind of licensing. But they cannot get it right. These upset people would now never want to do business with this company.
People who would have otherwise been happy to purchase a commercial license would also stay away from the company because messing up open source licensing is a red flag. Who knows what kind of mess would be present in their commercial contracts. Yes, you can hire a lawyer to sort it out but I'd much rather do business with a company where I'm confident that the company is acting in good faith even before lawyers get involved.
> If so, I have no sympathy.
Your sympathy means nothing to me when I am picking vendors for my business. When I'm picking my vendors, I'm going to rely on professional legal expertise available to me, not the sympathies of random strangers on the internet.
gowld|27 days ago
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
yencabulator|25 days ago
Hamuko|27 days ago
londons_explore|27 days ago
junon|27 days ago
wodenokoto|26 days ago
Then it goes on with the Apache license text.
ilaksh|27 days ago
MIT licensed binary in a source code repo does not make any sense.
This is a huge red flag.
Ekaros|27 days ago
paxys|27 days ago
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?
ethin|27 days ago
> 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.
codeflo|27 days ago
scotty79|27 days ago
constantcrying|27 days ago
londons_explore|27 days ago
It is AGPL 3.0, except they give you slightly more rights with a promise not to enforce certain provisions in certain circumstances.
wccrawford|27 days ago
chobeat|27 days ago
dooglius|27 days ago
rcxdude|27 days ago
(EDIT: though, having read the whole document, it seems like there is just a trademark carve-out, which is explicitly allowed under the AGPL, so this seems reasonably straightforward, except for the strange 'we promise not to enforce copyleft if you don't modify the code' which seems entirely redundant. Oh, and the 'licensed to use source code to create compiled version' which seems like a very strange phrasing)
epistasis|27 days ago
https://github.com/mattermost/mattermost/blob/master/LICENSE...
----
throwaway150|27 days ago
MD87|27 days ago
> ... licensed to use source code to create compiled versions ...
Why's it calling out compiling specifically? Are they trying to imply you can't modify/distribute/etc the source? Presumably that would be a "further restriction" per the AGPL and hence ignorable, but it's sloppy at best and misleading at worse, which isn't great for a license document...
MallocVoidstar|27 days ago
unknown|27 days ago
[deleted]
almosthere|27 days ago
eikenberry|27 days ago
unknown|27 days ago
[deleted]
fwip|27 days ago
michaelt|27 days ago
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.
throwaway150|27 days ago
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.
SpicyLemonZest|27 days ago
bogwog|27 days ago
ethin|27 days ago
thisislife2|27 days ago
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...