Let's speak about VisuStella term of service as Plugins developpers

[nio kasgami]

So if this not the proper section to discuss I invite mods to move it elsewhere who is more appropriate


So visuStella will be officially porting all the yanfly plugins. + they even pay programmers to do so which is great. It will allow some awesome plugins to be ported. as I said VERY positive news!

ALTHOUGH, for the plugin's developer that will want to support the engine with their own third-party plugins will not like it not at all. Their term of services is a Hell hole for us third party plugin developer.

SO if I explain by just showing this little snippet quoted from the visuStella TOS :

6. If a compatibility patch needs to be made through a third party that is unaffiliated with VisuStella that involves using code from the VisuStella MZ library, contact must be made with a member from VisuStella and have it approved. The patch would be placed on VisuStella.com as a free download to the public. Such patches cannot be sold for monetary gain, including commissions, crowdfunding, and/or donations.

So if we want us (third party plugin's developers) make a plugin patch for their engine ( visuStella ) we have to probably email them ask them permission and then send our code for approval (and if it's rejected because it doesn't fit their standard welp you have to rebegin or no fix).

I don't include paying for the engine it's normal it's will be probably a commercial product and I am all for the support of plugins dev.

So if we return to the fact we get it to confirm our code. NOW we have to let them HOSTING our patch on their website so it have to be separated from our plugin as a separated patch instead of just letting it inside our plugin.

Again, on some side, it's cool since it will create a possibility for some exposure.

The last part is the most problematic :
We are not allowed to gain any monetary gain for the patch. So pretty much I understand hiding the patch behind a paywall is wrong but in simple we have to make the patch maybe for FREE with no compensation and they get to 'have' our code on their website?

So to clarify it's literally a very horrible TOS for us plugins developer and extremely restrictive. and is shooting themself into the feet.
Now Now before the fire begin to spread I understand they want to protect their code and all but Jesus isn't hard to just let us write a patch and we put a Header right on the code that say : we agreed to not sell those patchs. We are here to support you guys not freaking stealing the code. + not having compensation and working for free is very unethical


Anyway, I like visuStella and yanfly work but I just find those terms of service unacceptable and extremely unfair for us third plugin developers.

 

[Astfgl66]

I think the important part is that the compatibility patch needs to be "using code from the VisuStella MZ library " in order for those conditions to apply.
Thus, I think that you can write compatibility patches in a new file while not reusing any of their code, and can sell those and redistribute them as you see fit.

Interpreting it like this I take no issue with their TOU.
I wouldn't want anyone copy pasting part or all of my code and then selling the resulting product either after all. It's unlikely anyone would do it considering the small amount of plugins I've written, but if I were porting the entire Yanfly library I can see why such a clause would need to be included in the TOU.

 

[HumanNinjaToo]

I'm not a plugin creator but I think I see your point and frustration. However, the developers who are featured with VisuStella have both free and commercial plugins right? So maybe they are saying they don't want someone to create a fix/add-on to one of their free plugins that is then behind a paywall. It's a little unclear to me, but, Olivia for example has paid plugins that require some of the free Yanfly plugins to work at all, such as the Octopath battle plugins and even the battle and impact plugins that add features to yanfly action sequences.

 

[Galenmereth]

I think the important part is that the compatibility patch needs to "using code from the VisuStella MZ library ".
So I think that you can write compatibility patches in a new file while not reusing any of their code, and can sell those and redistribute them as you see fit. Interpreting it like this I take no issue with their TOU.

I wouldn't want anyone copy pasting part or all of my code and then selling the resulting product either.

The problem -- based on long experience writing a lot of plugins -- is that unless the plugin's functions are particularly well authored and sectioned off (uncommon based on experience from MV, yanfly plugins included) you will often have to use a method from the original plugin and then expand on it, updating its workings with additional logic to make it compatible. And with such an extreme all-encompassing TOS, this would count as "using code from the VisuStella MZ library".

 

[nio kasgami]

As for patch who just need an Alias I am fine with it That's fairly easy it doesn't include to have to rewrite their code but as @Galenmereth said OFTEN and this is not rare we have to 'copy' the code to extends upon it because it's impossible to alias we have to overwrite.

but I am sorry but having to go email them each time I have to write a patch for their system is also very tedious.

 

[waynee95]

I have discussed this topic with a few plugin coders myself and I agree.

This limits diversity of using plugins together. The team behind the plugins cannot make every plugin compatible with every plugin out there, hence the community should be able to help out doing those patches.

But on the other hand making compatibility patches requires a lot of effort and being forced to do that for free is pretty hard. For that reason, there won't be many patches.

I can see where that decision to include such clause inside the ToS comes from. But in my opinion it hurts the community more than what it protects. Those plugins will be used by mostly every user of this community. So keeping an eye on making plugins compatible with that suite is just required.

 

[nio kasgami]

I have discussed this topic with a few plugin coders myself and I agree.

This limits diversity of using plugins together. The team behind the plugins cannot make every plugin compatible with every plugin out there, hence the community should be able to help out doing those patches.

But on the other hand making compatibility patches requires a lot of effort and being forced to do that for free is pretty hard. For that reason, there won't be many patches.

I can see where that decision to include such clause inside the ToS comes from. But in my opinion it hurts the community more than what it protects. Those plugins will be used by mostly every user of this community. So keeping an eye on making plugins compatible with that suite is just required.

and yes I understand I am perfectly fine to write an 'written' contract that bind me to say those patchs will never be sold or hidden by a paywall
Donation is a little overkill since you not paying for the product you just supporting the user.
but jesus hell having to get your code 'confirmed' everytime is just unrealistic and tedious.

as I said it's shooting themself in the foot.

 

[Ossra]

I kind of wonder if the terms of service also cover compatibility patches within the plugins of other creators in order to make that particular plugin play nicely with the Yanfly plugin. If that is true, then I see a decline in the usage of Yanfly plugins due to other plugin creators not wanting the hassle.

 

[Astfgl66]

So the issue I missed is copying part of methods you cannot alias in order to make them work for your plugin because the logic couldn't work otherwise?
Have you tried contacting them to see what their stance on this point is ? If so what was their answer ?

I agree that, if you take it as is, it would limit the number of compatibility patches quite a lot which would be unfortunate considering the popularity of yanfly's plugins. It would probably hurt the userbase of their plugins a lot in the long run.

 

[nio kasgami]

So the issue I missed is copying part of methods you cannot alias in order to make them work for your plugin because the logic couldn't work otherwise?
Have you tried contacting them to see what their stance on this point is ? If so what was their answer ?

I agree that, if you take it as is, it would limit the number of compatibility patches quite a lot which would be unfortunate considering the popularity of yanfly's plugins. It would probably hurt the userbase of their plugins a lot in the long run.

yep I mean it's possible to not touch the plugin function content....by using what you call 'reflection' in C# which is you inject code on runtime but if you think lambda and Promise is witchcraft then Reflection is literally cursed magic.

but after even myself I am not familiar with a concept where you can just inject code on runtime.

 

[Ossra]

@nio kasgami Oh wow, you are not kidding. Reflection does look like the true dark arts ... I need to tinker around with that.

 

[nio kasgami]

Don't lol you will just melt ur brain
if the only way to do compatibility patch without touching the code is this way I would :


ALTHOUGH I do want to add if it's 'hook' oriented then the library will be WAY easier to do compatibility patchs.

let me show an....rough example (bear with me I am not used to it)

Game_Dummy.prototype.foo = function(){
VisuStellaMZ.Inject("FooAlias").bind(this);
};

THEN with this BARELLY necessary to do code patchs other than maybe changing the orientation of the inject.

 

[Astfgl66]

You could probably hack something by parsing their function into a string, editing the string to add your new code and then evaling the thing. I'm already having nightmares thinking about that.

Edit:
So just to recap, in order to not have to go through them.

1. You parse their function into a string.
2. You count characters to add your new code at the appropriate points in the string created in 1. If feeling particularily fancy you can use regex instead.
3. Alias the original function by evaling the code you've just created.
4. Profit

5. (optionnal, if you counted characters for 2) Cry each time their plugin is updated because you have to change your concatenation points.

No original code aside from the original method name has been used, so you're in the clear. No need to have permission and you can sell it. Sounds like a plan. I mean, what could go wrong?

Damn, now I want to try doing that.

 

[Ossra]

@Astfgl66 Aah, but see you could make that a part of your game! Convert the necessary functions to a string, and then display the contents beside code which will make the other plugins being used to work nicely with the Yanfly plugin. Next, you simply ask the user to 'make one side look like the other', typing or pasting in the code. Poof. Now the user is the one doing the actual work at runtime, so no need to ask for permission!

Nah, that would still count. But, it would be funny.


@nio kasgami And I thought Proxy in javascript was interesting. I need to fiddle with Proxy and Reflect ...

 

[Jenova]

And here I was excited to see a bunch of developer working on plugins together and seeing what they come up with

Now, if something breaks, no patch unless from official source, which, in my experience, wont happen unless you pester them or you're part of a sub club.

Sad days ahead.

 

[nio kasgami]

So I complained and didn't show a possible 'fix' that would satisfy both end

6. if a patch is produced by an third pary developper. He is free to do so in the conditions

 a. to let a copyright header of both the author and visuStella in the patch note
 b. A clause to not hide the code behind a paywall or to force the userbase to pay for it.
 c. Hosting on the visuStella website is an NON-MANDATORY option. The user is free to host it on their
 website at the exception it's not hidden between paywalls or force the user to pay for a complete patch version.
 (Donation can be seeing as just as a support for tyhe plugin devs.)

 

[Tea's Jams]

Wait, but haven't you had to ask plugin creators permission for this, for like ever? (responding to the OP)

Any one of them could just say, no. And that's the end of it. Shrug

 

[nio kasgami]

not really? I never had to ask for to do a compatibility patchs of course I wouldn't sell them but yeah they could technically say no just counter productive.

EDIT :

as I was speaking with quasis I went to the conclusion of this :

as for the hosting it's fine as it is a form of exposure for us. I still think it shouldn't be a mandatory part but that's my opinion.
For the non paying part it's also fine. Patch shouldn't be paid.

The iffy part is the 'We have to ask permission and wait for our code to be approved'.
Also I think we need a clarifications of what they mean by 'using the VisuStella Library'.
like is a simple patch where it just reorder the code so it doesn't clash :

dummy.prototype.foo = function(){
 VisuStellaFix
 MyFIx// CLASH
};

// in MyPatch.js
dummy.prototype.foo = function(){
 MyFIx
 VisuStellaFix
 MyFix
 VisuStellaFix
// Work
};

it's an fast example but it'S a very grey area that we need clarifications. If it include that I have to edit the visuStella Library function. (example VisuStella.prototype.func = function { /Overwrite }
or it's any section that include the VisuStella edit.

I think giving us a clarifications will help.

 

[TWings]

There's an easy fix, don't do compatibility patches with Visustela.
The user will have to make a choice on what plugins he wants to use, but you avoid the headache.

 

[TheoAllen]

The contact and must be approved part are a little ridiculous. But I can agree about compatibility patches should never gain any monetary gain from the donation, or selling. Although, I don't exactly agree about the commission part. I always consider producing a piece of code is a service rather than a product. The end product could be free, but people who code the patch provide the service which is worth paying.