Documentation item
Means that the control is available if there is a license other than the Team, but the settings related to managing the groups work on the team version! Is this not the accuracy of the documentation or the bug version 3.6.1?
Пункт документации
означает что управление доступно при наличии лицензии отличной от Теам, но настройки относящиеся к управлению группами работают на Теам версии! Это не точность документации или баг версии 3.6.1 ?
Thanks @danilvoe for the report!
This is now fixed in Mattermost v3.7, released today. There was an issue where some System Console > Policy settings were incorrectly applied to Team Edition, and as a result also breaking the System Console UI
How do I understand the limitations of user actions will not be in Team version?
How to be if it is needed but there is no possibility to purchase the Enterprise version?
If you implement what you need in your fork (do not include what is, namely, implement in parallel whatsoever) is this going to be a violation of Team license?
Thanks @danilvoe for the response,
You’re welcome to use the software per the open source license in the source code, just two things to keep in mind:
Per the trademark guidelines when you’re offering a fork for use by others, please remove Mattermost branding (name and logos). This is standard in open source.
We’d encourage you to merge in security updates as they’re released.
I’m not sure what this topic is about, but since I’ve already said this topic:
I want to understand whether we are not violating a license or simply creating a pricentent for a conflict if in fact partially unlock its functionality.
For example: to implement blocking access to the link invitation to the group’s privat, everything is already implemented, and otherwise there is not done.
Is it possible to simply change in such places the verification of the existence of an EE license? (You do not really want to violate a license or just create an excuse for conflict)
Fork is made purely for internal use, any publication at the moment is not even considered.
Hey @danilvoe,
The software is open source so you’re welcome to fork the code base and modify it, per the open source license in the source code.
We have added more details on our FAQ page for things to consider when you create a derivative work of Mattermost, including security updates and re-branding: https://docs.mattermost.com/overview/faq.html#how-can-i-create-a-derivative-work-of-mattermost-as-my-own-commercial-solution
Let me know if that helps,
Just for clarification:
When taking the mattermost sourcecode and making some changes in the code for our own Mattermost instance, we obviously need to publish these changes to comply with the AGPL. This is perfectly fine.
However, the trademark policy is not clear to me, so I would appreciate some clarification here:
https://mattermost.myorganization.org, or would that be considered a violation of the trademark policy?Note: We have no intention of providing (or even selling) a product for others; our sole intention is to use Mattermost for ourselves with some changes to the server code (and publishing these changes e.g. in a GitHub fork to comply with the AGPL)
Hi @ThiefMaster - Giving you an update that I have forwarded your questions to our product managers and I’ll let you know their feedback.
Hey @ThiefMaster - thanks for your question!
For your bullet points:
Is it OK to run a modified version on https://mattermost.myorganization.org, or would that be considered a violation of the trademark policy?
Yes, that is okay.
Since the favicon is the Mattermost logo, does it need to be replaced?
That is okay to keep and not replace.
The footer of the login page shows “Mattermost” which is not affected by the “site name” setting. Does this need to be changed?
That is also okay to keep
“About Mattermost” in the hamburger menu - does this need to be renamed?
And this is fine to keep as well.
Note that if Mattermost is used for your organizations use and not to be redistributed then the use of branding is acceptable.
Also - another option, if you want, is to submit a pull request for your changes which we could consider merging. Then you can use our branch and not need to fork. What changes are you looking to make?
I would like to do this since I think the features would be useful in general, but I have the feeling you won’t accept a pull request that enables certain permission-related features (preventing regular team users from deleting/editing public channels) in TE, that are already available in EE. 
Thanks for the clarification! This indeed makes things much easier for us!
Just another small question in this regard:
The server’s license specifies:
You may be licensed to use source code to create compiled versions not produced by Mattermost, Inc. in one of two ways:
- Under the Free Software Foundation’s GNU AGPL v.3.0, subject to the exceptions outlined in this policy; or
[…]
(emphasis is mine)
However, for the MIT-licensed binary builds and Apache-licensed parts the wording is “You are licensed” while the section containing the AGPL/commercial part uses “You may be licensed”. Based on the git history this was changed when introducing the information about the MIT-licensed build (so probably not intended to change the legal meaning), but I would appreciate if you could clarify this. Because IANAL, but “may be” sounds like there could be conditions where this section does not apply…
Hi @ThiefMaster! Thank you for the additional question.
A similar question was raised in this Github Issue some weeks ago: https://github.com/mattermost/mattermost-server/issues/8886.
Our team and engineers are working on a fix for this - here is the latest comment from one of our engineers related to different LICENSE.txt questions that a user had earlier: https://github.com/mattermost/mattermost-server/issues/8893#issuecomment-398321862.