MC-Market is trying to screw sellers over!

[Dean]

Soon there'll be a merchant agreement coming to MC-Market you can view it here https://www.mc-market.org/wiki/merchant-agreement/

Although this seems like a good idea, the execution has been horrible. Although not released yet something needs to be done before it screws over sellers which is why I'm making this thread.

First, off they're saying communication is an issue while saying all of this in legalese making it hard for the average person to understand without re-reading it multiple times and we already know MCM chooses different interpretations for things they say depending on the situation.

Secondly, just about every section is trash.
AID is one of the first sections this is what it says

Spoiler: AID

If a participant of the transaction loses or does not receive their due return, even if it is at no failure of the other participant(s), if they are available, they will take whatever reasonable actions are accessible to them to recover what was lost or unsuccessfully delivered, and deliver it to its intended recipient. Reasonable actions include but are not limited to: Charging back a payment and re-sending it to the necessary location. Providing another downloadable copy of a product. Contacting relevant support services accessible only to them, in request of assistance.

So if Dean bugs Duck for a commission and then Dean loses the source code provided by Duck then Duck will be required to provide Dean with the source possibly spending a couple of hours looking to see if they kept the source, many devs will delete the source after a commission as they no longer need it. Some devs like Elapsed just lose the source code.

Another example if Geek provides Diz with the wrong email to send a payment then Diz will be required to chargeback the email and then resend it to Geek. It is not clear whether if charging back f&f payments would be considered as a reasonable action. But if it is, it would be considered fruad.

Spoiler: Changes

Changes not agreed upon may not be enforced. If changes which are agreed upon contradict, nullify, or modify any pre-existing terms of the agreement, those specific pre-existing terms will no longer be enforceable to the extent with which they are incompatible. Agreement to a suggestion of altered terms may be observed as being implicit based on a lack of negative response to the suggestion, a lack of subsequent counter-suggestions and or a change of behavior relevant to the agreement which align only with the suggested terms.

By the looks of this if your own terms conflict with "the agreement" assuming this means mcm tos, merchant agreement etc. Then your terms are nullified.

Spoiler: Compatibility

The provider of the product is responsible for ensuring that it is compatible with the product receiver’s platform. Any information the provider needs to ensure that they can deliver a compatible product is the provider’s responsibility to ask for. (e.g java version, server software, server version, etc) If there are any limitations to the product’s compatibility, that needs to be made known to the receiver prior to the transaction’s initiation. If there are no limitations made known to the receiver by the provider, then the receiver should be able to assume that it will work for them.

Why is it the responsibility of the devs of plugins and setups / configuratiors to say XYZ is not compatible this could be hundreds of things that they need to state are not compatible. It makes no sense to change it from the customer's burden to make sure that XYZ is compatible rather than assuming everything is compatible.

For example inferno buys @SupremeDevelopment collectors, they don't work for him as he's using UnknownStacker552, UnknownStacker552 isn't compatible with SupremeCollectors. Why is it the plugin's dev job to specify UnknownStacker552 is not compatible when they were never told about UnknownStacker552. Even worse what if it's a custom plugin they need to specify that's not compatible.

Spoiler: Fixes

If there are any bugs with the provided product, so that it does not function as described, or functions in a way which is clearly incorrect, the receiver is entitled a fix for the product. If the provider has revoked the receiver’s download license for the product, the receiver is still entitled these fixes. If not provided via official channels, they must be provided privately. If the fixes are not provided within a reasonable timeframe and without undue delay, the receiver will be entitled to a full refund.

I understand this for the most part but what if it's a timed product, the example you pay for 3 months' worth of updates, you get 3 months' worth of updates, and then there's a bug in the newest version you have access to. You should expect a fix, you should expect to go to a slightly older version as you're no longer paying for updates. Paying for updates is what pays for development so a person can continue to update their product.

Theres plenty more issues in each section mentioned and not mentioned.



We didn't ask for this, and a lot of it just misses the mark completely. This should be an opt-in-only agreement, at the moment there's no way to opt-out only to withdraw from a transaction meaning you can't purchase anything on mcm or off mcm as I've been told to assume that this agreement also counts for off-site deals. What the actual fuck MCM. Make this opt-in don't force users to unnecessary terms they don't need or want.

 

[Dean]

I think I pinged the wrong inferno.

 

[Justis]

When an agreement between two users lacks fullness and fails to specify onto which participant a certain responsibility lies, the SR team needs to make that judgement for themselves.

The issue with that is obviously that the community is left unaware of what responsibilities they’ll be held to if they fail to specify a different set of responsibilities with the person they’re engaging with. Everything written there is what is already being enforced when specific responsibilities weren’t agreed upon. The wiki isn’t creating any changes in itself.

The Merchant Agreement is being written in order to ensure consistency among the scam resolvers team, as well as ensure transparency and allow for the possibility of changes to our policies. Whereas before, it’d be difficult to pinpoint exactly what our policy was, unless it happened to become relevant within a specific scam report.

From the Merchant Agreement:

Any responsibilities mutually agreed upon within the context of a transaction which conflict with what’s written here will always take precedence for that transaction.

We decide on policies based on what is best for the entire community, but we recognize that this isn’t necessarily what’s best for each person in every deal. That’s why, if you don’t want something written in the Merchant Agreement to apply to your transaction, simply write a term into your own agreement which covers the same subject. The Merchant Agreement’s terms only fill in voids, just as the SR team only needs to make decisions on division of certain responsibilities when it hadn’t been mutually agreed upon.

I’ll look into your specific complaints momentarily.

 

[Dean]

if you don’t want anything written in the Merchant Agreement to apply to your transaction, simply write a term into your own agreement which covers the same subject. The Merchant Agreement’s terms only fill in voids, just as the SR team only needs to make decisions on division of certain responsibilities when it hadn’t been mutually agreed upon.

Alright but the Changes section of the agreement makes it seem as if, your own terms conflict with the merchant terms then your own terms get nullified.

"If changes which are agreed upon contradict, nullify, or modify any pre-existing terms of the agreement, those specific pre-existing terms will no longer be enforceable to the extent with which they are incompatible."

Pre-existing would be merchant agreement which is currently very confusing.

 

[Justis]

Alright but the Changes section of the agreement makes it seem as if, your own terms conflict with the merchant terms then your own terms get nullified.

"If changes which are agreed upon contradict, nullify, or modify any pre-existing terms of the agreement, those specific pre-existing terms will no longer be enforceable to the extent with which they are incompatible."

Pre-existing would be merchant agreement which is currently very confusing.

This is addressing changes to an existing agreement within the scope of a transaction.

An example would be the following:

You commission me for a plugin with a contract that allows me to keep rights over my source.
Later into the deal, you realize you don’t want me to have rights to my source, and you offer to pay me a little extra in order for you to have full rights. I agree to this.

This new term contradicts/nullifies/modifies pre-existing terms of our agreement, thus the pre-existing term (where I keep rights to the source) is no longer enforceable because that term is entirely incompatible with the new one.[DOUBLEPOST=1618347484][/DOUBLEPOST]Two of the main goals for writing the Merchant Agreement was to further provide the community with transparency over our enforcement, as well as offer everyone the chance to suggest changes, so of course discussion over what changes might be best for the community is welcome, as well as discussion on potentially needing to re-write certain things to be more easily understood.
Admittedly, it has been a difficult task trying to ensure that there’s no room for confusion without also making the document too long and verbose for anyone to want to be bothered reading through it.

Since I’ve already addressed the section on Changes above, I’ll just go over the others you mentioned.

Spoiler: AID

If a participant of the transaction loses or does not receive their due return, even if it is at no failure of the other participant(s), if they are available, they will take whatever reasonable actions are accessible to them to recover what was lost or unsuccessfully delivered, and deliver it to its intended recipient. Reasonable actions include but are not limited to: Charging back a payment and re-sending it to the necessary location. Providing another downloadable copy of a product. Contacting relevant support services accessible only to them, in request of assistance.

So if Dean bugs Duck for a commission and then Dean loses the source code provided by Duck then Duck will be required to provide Dean with the source possibly spending a couple of hours looking to see if they kept the source, many devs will delete the source after a commission as they no longer need it. Some devs like Elapsed just lose the source code.

Another example if Geek provides Diz with the wrong email to send a payment then Diz will be required to chargeback the email and then resend it to Geek. It is not clear whether if charging back f&f payments would be considered as a reasonable action. But if it is, it would be considered fruad.

This section specifies "reasonable" actions. Of course, the agreement can’t list every possible action for every possible situation, but in the case of a lost file, if you have the file that the other party paid for and has the right to have, yes, you’ll be expected to send it to them. If you don’t have it, then there’s nothing you can do. If you’ve spent a reasonable amount of time looking and you can’t find it, no problem. You did what you could. We’re not going to ask you to spend the rest of your life looking for it. This section is all about simply being a decent human being if your transaction partner needs a little cooperation in order to get their pay/product. Don’t refuse to help when you clearly and easily could, that’s all that’s being expected.

I do strongly believe that it’s in the community’s best interest that this section stay, since far too many people on MCM would rather be dickheads if they could, and would gleefully watch someone they just dealt with get royally fucked over on their entire end of the deal.

In your other example of sending to the wrong email, simply follow procedure: https://www.paypal.com/us/smarthelp...he-payment-is-completed.-what-do-i-do-faq1467 and if you get the money back, then send it to the correct email. It shouldn’t take that long. If you don’t get the money back, there’s nothing you can do. At least you tried.

Spoiler: Compatibility

The provider of the product is responsible for ensuring that it is compatible with the product receiver’s platform. Any information the provider needs to ensure that they can deliver a compatible product is the provider’s responsibility to ask for. (e.g java version, server software, server version, etc) If there are any limitations to the product’s compatibility, that needs to be made known to the receiver prior to the transaction’s initiation. If there are no limitations made known to the receiver by the provider, then the receiver should be able to assume that it will work for them.

Why is it the responsibility of the devs of plugins and setups / configuratiors to say XYZ is not compatible this could be hundreds of things that they need to state are not compatible. It makes no sense to change it from the customer's burden to make sure that XYZ is compatible rather than assuming everything is compatible.

For example inferno buys @SupremeDevelopment collectors, they don't work for him as he's using UnknownStacker552, UnknownStacker552 isn't compatible with SupremeCollectors. Why is it the plugin's dev job to specify UnknownStacker552 is not compatible when they were never told about UnknownStacker552. Even worse what if it's a custom plugin they need to specify that's not compatible.

The section specifies "platform", a platform is something that you are building atop. In the case of a spigot plugin (without other dependencies) your platform would amount to the spigot version and the java version. In the case of a basic XenForo addon, your platform would be XenForo and PHP. If you’re writing a program that compiles into a .exe, your platform would be Windows. The term "platform" is used, because we cannot individually specify every single platform that could possibly be used in a transaction.

Unless you are building atop another plugin, or are specifically being paid to ensure certain compatibility, you are not responsible for ensuring compatibility with any other plugins which also build onto the platform.

As a non-exclusive plugin seller, simply state what you know you are compatible with and disclaim knowledge of being compatible with anything else. That’s more than enough. Our resources section has individual fields specifically for doing this. If you specify nothing, how is your buyer supposed to know whether or not your product will work for any platform?

If you are being commissioned, then ensure you’re compatible with what the buyer is using. If they haven’t given you all of the information you need to ensure compatibility, then ask for it, don’t just decide to be compatible with some random platform and expect to get paid. Especially outside of Minecraft servers, the buyer likely has very limited knowledge over what features, if implemented in the way you’ll be implementing them, will or will not restrict version compatibility.

Spoiler: Fixes

If there are any bugs with the provided product, so that it does not function as described, or functions in a way which is clearly incorrect, the receiver is entitled a fix for the product. If the provider has revoked the receiver’s download license for the product, the receiver is still entitled these fixes. If not provided via official channels, they must be provided privately. If the fixes are not provided within a reasonable timeframe and without undue delay, the receiver will be entitled to a full refund.

I understand this for the most part but what if it's a timed product, the example you pay for 3 months' worth of updates, you get 3 months' worth of updates, and then there's a bug in the newest version you have access to. You should expect a fix, you should expect to go to a slightly older version as you're no longer paying for updates. Paying for updates is what pays for development so a person can continue to update their product.

The buyer is entitled a product that matches the description of what they paid for.
If an old version of the product works and matches the description of what they paid for, then there’s no reason they can’t use that.
However, in your case of 3 month access, if at no point there has ever existed a version which actually worked as described, then yes the buyer is entitled a refund if you cannot fix it and provide them a working product.


I’ve now responded to each complaint you’ve made. Hopefully this clears up why certain things are the way that they are. Again, we’re open to changes, so if the community finds issue with any of this, we’ll discuss alternatives.

Keep in mind, once again, that these terms are only there to fill in voids that may exist when two users have failed to write a fully fleshed out agreement. If you don’t like anything written here, you can ensure your deal isn’t enforced this way simply by coming to a different agreement with your transacting partner. Your own terms will always take precedence. In fact, even if you agree with everything written here, please still put it in writing with your transacting partner. The goal is to encourage mutual understanding and ensure that everyone knows what the other party is expecting from them and what they’ll be held responsible for in case of a scam report.

 

[PixelMine]

I think this is perfectly reasonable for MCM to outline the terms of dispute resolution. On a site where 99% of deals are made without a written contract of any kind having these default terms is very useful for all parties involved.

I've spent the last 10 years dealing with Lawyers and contracts and I can say that this is a VERY legible set of terms in pretty clear english.

As a seller on MCM I have no issue with this agreement

 

[Dean]

I think this is perfectly reasonable for MCM to outline the terms of dispute resolution. On a site where 99% of deals are made without a written contract of any kind having these default terms is very useful for all parties involved.

I've spent the last 10 years dealing with Lawyers and contracts and I can say that this is a VERY legible set of terms in pretty clear english.

As a seller on MCM I have no issue with this agreement

Most sellers I spoke to before it was cleared up had an issue and this doesn't only effect onsite. Although not fully released yet I was told to expect it effects all deals including offsite.

 

[PixelMine]

Yeah that makes sense. The way I understand it is that if you come to MCM for despute resolution these are the terms they will use if there are none defined. If you don't want to use these terms, set something in writting that both buyer and seller agree to that MCM can use instead.

It was good that you posted this thread so that everything was cleared up.

 

[Justis]

Yeah that makes sense. The way I understand it is that if you come to MCM for despute resolution these are the terms they will use if there are none defined. If you don't want to use these terms, set something in writting that both buyer and seller agree to that MCM can use instead.

It was good that you posted this thread so that everything was cleared up.

That understanding is exactly correct.

Although the wiki is still a simple draft and under modification. We’ve not even publicly announced it yet.
I would have preferred that Dean waited until we were able to officially release it with a proper explanation, before jumping to conclusions and creating false accusations and spreading misinformation within our discussion forums.