You may not select a Display Name that impersonates someone else, is or may be illegal, is or may be protected by trademark or other proprietary rights, is vulgar or offensive or that may cause confusion. When registering your Application, you must choose a unique “Display Name” for your Application.
Use the Platform or allow any user to use the Application in a way that violates applicable law, including:.The terms of use for the identity platform state that (among others):.People fork MultiMC, impersonate it, and pirate the game with modified versions of it.You have to buy it to be able to play it. This is a launcher for a game owned by Microsoft.If someone decides to impersonate MultiMC once the source is debranded, they will have no excuse of doing so by accident or unknowingly. You doing something illegal should not be the default. Right now, any build not made by the CI, and then distributed to users is essentially a trademark infringement.
With what's happening around MultiMC, the MS Indentity Platform terms of use, and general adversity, I cannot keep the default state of the source producing 'MultiMC'. I did not put much of an emphasis on this before, because it wasn't an issue (or rather, it was a fringe issue that did not need much attention).
UNABLE TO ADD ICEWEASEL TO LAUNCHBAR LICENSE
This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file. To be honest, I'm tempted to just take the source offline, but it's kinda like throwing the baby (collaboration and people contributing) out with the bathwater (unrelated third party devs not respecting the licenses and law in general).Īpache 2.0 clearly states that it does not apply to trademarks - and no, it does not specify any need for the trademark to be registered: And it's really sad and even more concerning to see all the hostility from upstream maintainers towards downstream source build packages. There's one AUR package I maintain that only provides a binary package, and it's for good reasons, all listed in a pinned package comment and build pipeline README.īut in the case of MultiMC, I don't see any good reasons why using an unreproducible binary from an untrustworthy third-party is the only recognized way for packaging. I'm asking that the maintainers do not simply dismiss downstream source build packages and claim they violated some unspecified "standards".Īs someone who actively maintains several open source projects, and also works with other developers to package their projects and my own into AUR, I understand that in some circumstances packaging a pre-built binary is the only possible way. I'm not asking for support for any specific downstream packages. You are welcome to use those, but arent entitled to support by us. In which way do these two packages violate the "standards"? Can you elaborate on that? If people wanna build mmc, they need to follow standards, which multimc5 and multimc-git don't. You mean fake open source projects from Micro$oft? There are other open source projects that aren't even possible to compile. Many of these binaries are already reproducible, and they are working to make sure all source build packages in official repos are reproducible. Arch Linux's infrastructure builds these packages and distributes the binaries. The majority of packages in the official repos are source build packages. The majority of packages in the official repos are binary packages.
0 kommentar(er)
