Will you deliberately write uncommon bad codes with strange poor designs to make plagiarisms easier to prove?

[DoubleX]

Disclaimer: Plagiarisms should never ever be countered by this idea alone, as this idea, even if it's to be used, should be used along with some other plagiarism counters, otherwise one would fall into the "security through obscurity" application pitfall(but not the idea itself).

While in most cases, only those having high popularity and excellent reputations will have to worry about plagiarisms on a regular basis, sometimes even a dumb noob like me can be a victim on this(and unfortunately a long time ago some of my free plugins are sold by someone else without my permissions, even when it was such a blatant scam that I don't think anyone will really lose a penny there).
So I've read how some of the best and most successful plugin developers deal with plagiarisms, and I noticed that sometimes some uncommon bad codes and strange poor designs in some plugins made by the original plugin developers can actually help proving the plagiarisms, as I've seen a plugin developer listing some of them as evidences.

While I don't think those bad codes/poor designs are intentional(they're likely due to the desire/need to make tons of plugins very quickly), that case of that plugin developer inspired me to think about whether it'd be at least considerable to intentionally write uncommon bad codes with strange poor designs to make plagiarisms easier to prove(of course better implementation alternatives shouldn't be obvious nor easy/simple to swap in or it'd only stop those trying to hide their plagiarisms but are too lazy/stupid to do it well).
The reasoning behind this practice is that, while there won't be many different ways to do the exact same thing and it's likely to fall into the very same common programming pitfalls, if a scammer plagiarizes a plugin using tons of uncommon bad codes and strange poor designs without removing all those rare programming pitfalls, it'd be an easy, simple and small task to prove that it's indeed plagiarism, or at least the case would be so probable that it can be assumed as plagiarisms until proven otherwise(sometimes even beyond reasonable doubt), all due to the fact that making the same rare programming pitfalls when trying to do the same things is effectively a black swan.
On a side note: This also implies that, sometimes prioritizing plugin development speed over code quality can surprisingly help countering plagiarisms, as scammers will be harder to hide their plagiarisms in those unintended cases.

As a bonus, the plugins written this way can also be so apparently(but not actually if you know the "secret") cryptic and fragile that others can't change anything meaningful without breaking at least something else significant(but not so cryptic that plugin users can't report meaningful errors), so those trying to hide their plagiarisms will instead keep encountering serious bugs after serious bugs, therefore they'll eventually just give up plagiarizing or change to plagiarizing without hiding(and will therefore be caught very quickly).
On the other hand, the plugin developers can keep some private test suites and documentation files(of course maintaining them needs tons of extra work) that can help them work well with those apparently cryptic and fragile codes, and let the sufficiently trustworthy fellows to have somewhat controlled, limited and recorded accesses on them in case they've to solve some compatibility issues and need such accesses.

Of course, in order to keep the negative side-effects under control, at least the following conditions must be met:
1. The plugins will still keep working well on the user level without much nontrivial bugs that can't be fixed quickly(it needs the plugin developers to keep tons of codes inside their heads)
2. The plugin developers will still keep working with the plugins effectively and efficiently despite the extremely low code qualities(private test suites can help a lot here in the long term)
3. At least some fellow plugin developers will still want to address compatibility issues with said plugins even though it'd be a hellish nightmare in general(provided that those compatibility issues must be addressed on their sides)
Otherwise those plugins won't be plagiarized not because doing so would be too hard without being caught, but because there would be so few users using them that it's simply not worth plagiarizing them.

Also, bad junior programmers like me, those having next to no plugin users or those not being harassed by plagiarisms that are hard to prove shouldn't even think about actually doing this, because:
1. If you're not at least about to be a seasoned professional software engineer, it's almost certain that deliberately writing uncommon bad codes with strange poor designs will shoot yourself in your foot so hard that your plugins won't even work at all
2. If you've next to no plugin users, it probably means your popularity and reputations are so low that nearly no scammer will think that your plugins will be worth plagiarizing(there will always be exceptions though and I'm one of the few), because even the most brazen plagiarisms demand "actual work" in the views of those scammers(otherwise no one would be shameless enough to sell others' plugins without permissions using "charging for searching services" as a pathetic excuse)
3. If all you've faced are obvious plagiarisms, then the whole idea here will only do harm to everyone except the scammers and no good to anyone, as those scammers would just continue to make obvious plagiarisms anyway
In short, the whole approach might only payoff for very proficient plugin developers having tons of plugins, popularity, reputations and users, especially when they're already being severely harassed by plagiarisms that are all very hard to prove otherwise.

While I feel bad for those being harassed by plagiarisms that are hard to prove on a regular basis, I'd like to know what you'll think about incorporating this idea with your existing plagiarism counters, as I'm wondering whether this additional option can indeed further help stopping such plagiarisms

 

[ImaginaryVillain]

// Next levels the plagiarists by just writing bad code in general.

 

[Oddball]

If the developers of the plugins arn't making them public, but instead making them for there own games/commisioned games, they could also make it so a set of plugins must be used together in order to work, even though the plugins really have nothing to do with each other. It would take some sneaky coding to do however

Like programmer a's camera script, ATB script, menu script, state effect script, crafting script and 8-directinal movement script must be used together, or else they all have errors pop up

 

[Kupotepo]

@DoubleX, I think of a way to create a ditial fingerprints. You can make your plugin users register in your website. At least that person cannot denial their ip address.
Again, it is really difficult to prevent people who want to steal your source code. Yanfly can tell you about it.

After you know that person, you can do this for mitigation:

How to Block IP Addresses in WordPress

Do you want to block specific IP addresses on your WordPress site? Learn how to easily block IP addresses in WordPress with this step by step tutorial.

www.wpbeginner.com

Redirect Notice

My brain: lol, should advised people about information security?
My heart: Well, make people feel safe.

 

[??????]

In the past I have purposely over complicated systems, or created specific code structures, so that if it were to be plagiarised I would easily be able to spot it.

If you maintain a distinct style its much easier to spot similarities.

But it cant really be stopped. A lot of new programmers will look to existing systems to learn from, and its only natural that they would end up writing in a similar way.

Of course, if someone takes the exact same code and changes a few letters here and there... Thats a little more obvious

 

[Kupotepo]

@??????, I do not think @DoubleX is worried about people leaning from his codes. Everyone does that to learn from more experience coders. I think he worried about people tried to make money from his free plugins and claim as their own plugins. To take advantage of non coding people.

@??????, I probably dissect your plugins honestly to just learn the functionals and the scripts to learn the RPG maker MV internal many many code lines. lol To this test out what it can do.

 

[DoubleX]

I'd say that facing tons of plagiarisms is unfortunately a "next to inevitable price" for having tons of plugins, popularity, reputations and users, and if I remembered correctly, few of the best scripters/plugin developers retired mainly due to this.
I think the real damage stems from not just losing profits, but also having one's brand and image unfairly eroded irreversibly and one can only try the best to control as much damage as possible.
Being such a plugin developer's hard enough, but will be even harder when this aspect of the reality comes into play, even though they'll have to deal with it anyway.

Let's say that you've made a free plugin and someone plagiarized it, this alone is unfair enough for you but it'll likely only cause little direct damage at this point, provided that the scammer really stops here.
However, you'll still want to stop those scammers right now(or even in earlier stages), because if it's not stopped in this moment and the scammer starts selling your free plugins(without your permissions of course), then you can probably get into some real troubles quickly, even though the following should be rare cases:

Spoiler

1. Some users have bought your free plugin from the scammer
2. Later it's publicly proven that the scammer has been selling your free plugin without your permission and you don't even know anything about this beforehand
3. Many of those users demand refunds no matter what
4. The scammer has bailed out with all those money and no one can do anything about him/her anymore
5. Some of those users blame you for not stopping the scammer soon enough and few of those even demand refunds from you(especially if they believe in the absurd conspiracy theory that you secretly cooperated with the scammer)
6. You'll definitely defend yourself from all those criticisms and refuse all those refunds as they're all just way too insanely ridiculous to play along with
7. Your brand's eroded seriously and your image's about to shatter
Alternatively, some users will believe that you're selling those plugins and blame you for charging plugins that obviously should be free, so your reputation's dropped to the floor if they never know the truth.

Or, if you decide to drastically tighten the terms of use of your plugins to make future scamming much harder, some users will blame you for punishing the innocents just to protect yourself from scammers, and some such criticisms had already thrown out to some well-known plugin developers before.

Of course, it's obviously the worst case I can ever imagine, and if such an utterly bad case were to become common, it would not only imply that the scammers have become totally out of control, but also that many plugin users desperately need to be educated on how to use plugins and what's the supposed relationship between them and the plugin developers(fortunately the current situation's much, much better than that in general).
While I'm fortunate enough that I've never experienced any direct damage from plagiarisms(some of my plugins were being sold by scammers without my permissions but I don't think anyone will fall into those obvious scams) nor toxic plugin users(almost all of my plugins have nearly no users to begin with), not all plugin developers will be this lucky, especially for those being perceived as an/the idol figure.

So I'm tinkering with some ideas to increase the cost and difficulty for plugins to be plagiarized, and this post's 1 such idea, even though I won't do it personally as it makes no sense in my case.
On the flip side, decreasing the profits for scammers likely leads to decreasing the plugin qualities on the user level, so I don't think this direction will ever work.
Combined, the ideal scenario would be that, on one hand, the cost and difficulty of plagiarizing plugins without getting caught quickly will be high, but on the other hand, the cost and difficulty of making and supporting such plugins will remain low, even when both those plugins themselves and their supports are still of high quality.

 

[Shaz]

No, I wouldn't do it deliberately. As we've already seen, one person can take another's plugins, go through and change the variable names and pass it off as their own, and someone without coding experience wouldn't know it was plagiarised.

I'd look for other ways to do it.

 

[gstv87]

definitely yes.
in fact, that's a valid technique used to protect some literary works.
when the copier just copies without reading, they tend to copy the mistakes or intentionally added bogus terms, as well.

but you can only take it so far, before you find *the definitive way of doing it*, while trying to avoid plagiarism.
in programming, sometimes there is only one way of doing it doesn't matter how you look at it.
you can't accuse someone of plagiarism for using a loop to count to 100, when there's only one way of using it.

what you have to spot in those cases, is the techniques used in the work: if somebody can bend the bits of the information at their will, they surely don't need a sequential loop for a simple count.
being that bit manipulation is complex, and sequential counting is the simple way, the most logical answer is that the person who wrote that code is at sequential-counting level of coding, and simply copied the bit manipulation part.

one time, I had to code a simple DOS game, in Pascal. For the lolz, I added some cheat codes.
when I told my teacher about them, he did a search for the cheat words within the code.
didn't find anything.
so, he did the search again, letter by letter.
again, he didn't find anything.
he turned to me with an expression on his face that I could definitely interpret as "Now how the F%$K did you manage to do that?!"
I had set the code to scan not keys, but ASCII code, which is the same.... but nobody would ever think of looking for numbers in code written with keywords, which is what ultimately happened.
I wasn't aiming to troll my teacher, but it turned out that doing it that way had saved me a few lines.

 

[Mewgles]

Plagiarism is a huge issue with this kind of engines and was the main reason why I stopped writing scripts for VXA a few years ago when someone started to sell some of my scripts that I provided for free on my website and steam. There is some simple ways to make it at least harder to steal code and some that require lots of effort. All of them have their pros and cons.

Making the code harder to read by putting it in a single line (if possible due to language) or using nonsensical/random/cryptic terms for basically anything makes it pretty hard for plagiarists to figure out what they can change or what not. But on the other hand it gets a lot harder to debug/edit once it's done and also the end user experience might lack because they could feel thrown off since weird looking code often creates a feeling that something shady is going on.

Another way could be to just require a registered account on your website in order to download any plugins/scripts while using a blacklist for throwaway email domains aswell as domains known to be used for shady practices. In this case you will at least get rid off people who just want to steal something quick and easy without risking giving their info away.
Or if you don't want to do that for all of you work you can also provide a free "trial" version of things which lack a good part of the main features that make your plugin unique and then require a signup for the full version.
Downside here is that it might also scare away people who are just looking for a quick solution for their game.

What also works is writing in a way that any plugin you make requires a second, main, plugin which you keep updating all the time to make it a lot easier to spot plagiarists since they usually aren't that good at coding to be able to change it into something that doesn't look weird. One example of this is the Victor Engine.
This can look fairly complicated to newer devs though and they might start looking elsewhere to get their plugins unless you offer a decent variety that uses this system.

The only real way I personally see to deal with plagiarists would require a full change in how the engine and distribution of plugins works. If there was a proper workshop that was included in the engine (Steam wouldn't work for this since you can't sell workshop objects) which provides a full encryption of certain ressources such as plugins it would pretty much eradicate any way to steal them. (Of course only when people only share their work on this platform. If they keep using other mediums then the risk still exists). This would make stealing code/ressources very hard, but not impossible.

It really is a hard topic to deal with and it's only going to get worse the more people start using the engine. All in all it's like with everything on the internet, nothing is ever fully safe.

So to answer the main question: I'm not a fan of cryptical code since it usually only makes your own life harder. Especially with longer files. I'm looking into different methods that make life harder for plagiarists/scammers while keeping mine simple. But I'm not entirely sure which route to go yet.

 

[nio kasgami]

Personally,
I dont care much since my plugins have such a SPECIFIC structure that if they want to plagiarism one plugin they need to almost take the whole library to do so. Which after i can prove since ALL My plugins follow a structure of having an "engine" header which load all the plugin param if I saw that in their code i would literally be able to call them out.

I think no one other than me go with such a weird programming convention in Rm + i use typescript and rollups so they would need to go download the whole typescript library.

Was tempted to do tho is too obfuscate the js and make that you cant compile the src unless i give you a key but after they can just copy the src files lol.

It can discourage noob programmer tho. (Although they wouldnt understand typescript either anyway lol)

 

[Tsukihime]

Untested, but I worked with some data files that had invisible control characters. It's mostly for renderers to deal with, but if I could slip in a couple "invisible code" into my plugins that JS ignores, that you won't see unless you enable special viewing options or go through a hex editor...

Hey, invisible ink works in real life, maybe it'll work here. Can't change what you don't see

 

[TheoAllen]

I don't care about plagiarism on code. Personally I find an algorithm is free to share. You couldn't just sue people just because some people just use 9 times loop as you do in your code. That is just silly. If I made a good looking code for the public, people are free to learn from it. However, that is different if you take my code as is as a whole. I don't mind you pick a few parts of code to your program. Not the whole code and resell the code as-is.

If I deliberately write bad code, it is not because I don't want them to steal my code. I deliberately do it because I'm lazy and I only want this to work in my project. For example, I would just hardcode the value, hardcode everything. I don't care about people's demand or optimization or configuration to let you configure the system. It is enough to make it work in my project. If people are going to steal it, be my guest. Chance is, they will not work. They need to be modified. And such modification I will not consider it as plagiarism.

If I were going to protect my code, I'll make encryption of my code. Either through obfuscation or other methods of encryption.

In short, I'm more into selling my services (pay me to make a code) rather than selling a product (selling codes). I don't want to be bothered with all of this.

 

[DoubleX]

Untested, but I worked with some data files that had invisible control characters. It's mostly for renderers to deal with, but if I could slip in a couple "invisible code" into my plugins that JS ignores, that you won't see unless you enable special viewing options or go through a hex editor...

Hey, invisible ink works in real life, maybe it'll work here. Can't change what you don't see

That's itself a great idea, but I wonder how it'll work in making plagiarisms easier to catch.
I imagine the process as follows:
1. You've found a plugin in which you suspect that it's plagiarized from yours
2. You enable the special viewing options and go through the hex editor
3. You make some screenshots with those invisible codes shown
4. You make some screenshots with those in your original plugin
5. You claim that you've enough evidence to prove that the plugin under your suspect's indeed plagiarized from yours
6. The scammer demands you to show the evidence
7. You show those screenshots to prove the case by the existence of almost identical invisible codes in both plugins and explain the basic knowledge on what those invisible codes do in general(in this case, counter plagiarism)
8. Everyone knows that the scammer has indeed plagiarized your plugin
9. Every other scammer planning to target you also knows that invisible codes is one of your plagiarism counters and will try to enable special viewing options/go through the hex editor to remove them(meaning that those invisible codes might not protect you from the next scammer)
So, to explore a bit further, I'd like to know whether there's some sort of a password in those special viewing options(like correct decoding = proper text and incorrect decoding = illegible garbage), or if it's an either enable or disable thing

 

[Trihan]

@Tsukihime I tend to find that alt+0160 works well for this.

I think if I were going to try to protect my plugins from plagiarism, I'd probably put in a couple of comments somewhere inocuous that look like they're a vital part of the plugin but have some kind of specific structure or coded message in them. Or just write it in Gaelic so that the majority of thieves won't touch it because they don't know what it says.

 

[Tsukihime]

So, to explore a bit further, I'd like to know whether there's some sort of a password in those special viewing options(like correct decoding = proper text and incorrect decoding = illegible garbage), or if it's an either enable or disable thing

Ya the downside is the trick only works until it's revealed. But it's pretty amusing.
I don't think there's any real foolproof way if transparency is required: there's nothing inherently special about code. Even things like encryption standards are only secure because with current technology, it would take too long to crack.

You'd basically have to look at trends and hope they get sloppy. But even then, it would just be circumstantial evidence: there was one instance where I literally wrote the same piece of code as another well-known scripter in Japan, and I had no idea until someone really tried hard to paint me as a fraud that steals people's scripts and charges for them lol.

....

But like @TheoAllen mentions, it's mostly not something I think about. Perhaps as a thought exercise I might contemplate solutions, like trying to solve piracy using DRM: generally it hurts legitimate users more.

 

[Trihan]

Like for example, take this innnocent-looking document:

Oh noez, someone stole it! But if I suspect plagiarism is afoot, I do a find-replace and replace alt-0160 with something visible:

 

[Anyone]

My code is bad by default, if I deliberately made it worse, it would be nonfunctional.

If you really want to add a signature inside your code, you could pick the three most complex parts of your code and define a variable that is never used via a chain of references that never is used, you could have it write a note into the data folder, or do some other thing that you obfuscate by using references that sound important but really aren't.

Ultimately, since my goal is to not write bad code, I don't think I'd resort to stuff like that, because there's little meaning to it.
If you do see that someone duplicated your code: what are you going to do?

Try to sue some anonymous person halfway across the globe in a distant country? The ones who do it professionally in literature use throwaway accounts and banks on small islands that don't much cooperate with the police.

The best you can do is point at someone and say: "Ha! He assigned fightingValue to Fight.isHappening which is identical to my parseCombatValue to Combat.process because neither actually does anything! I got him!"

 

[YoraeRasante]

All I want from my plugins is credit, free or paid. Paid ones are the only ones I'd demand any more compensation from (but for the free ones donations are appreciated).

But I guess this is for those that don't even give that.

As @?????? pointed out, it is rare to use your coding as a signature, as if your code is good enough, or at least known enough, people will use it as a learning tool and at first copy your style before developing their own. I myself did it a lot with yanfly's when first started making plugins.

Writing bad or inefficient code just to avoid plagiarism? That not only makes your code bad or inefficient, which even if it works well enough gives a bad impression for those that know better, for those that do not but still use yours as a learning aid this wrong knowledge will be shared.

If you want to make your code have some sort of signature, there is a simpler alternative with no real downside:
Variable names. And object and function names, and the like.

Those names do not have a specific need to follow a pattern. snake case, camel case, english language, that is for making the code easier to understand to other people that may change it or yourself in the future if you ever come back to it after forgetting. But that's it, unless the final user is supposed to mess with them they are as restrictive as comments.

Nothing stops me from naming my items, weapons and armors variables as apple, pineapple and banana if I know what they mean. Or objects. Functions would only have a problem if they would be expected to be called by the final user too, those need to give them an idea of their use. But otherwise? I can Farm Simulator my code to your heart's content.

Of course, that can make someone editing your code for benign purposes harder too.
MogHunter's plugins are very set, all made for the default window size and the like, so for anything outside what he expects you need to make the changes yourself and his code uses a lot of arrays as variables and variables with not-perfect-writing meaning you have to hunt not just the variable's true grammar but also what index of them keeps the values you need.

 

[DoubleX]

Maybe deliberately writing uncommon bad codes with strange poor designs to help countering plagiarisms are more suitable to very proficient plugin developers wanting/needing to write tons of plugins in a very short time(e.g.: 2+ easy, simple and small plugins per day on average or even minimum), because the latter often implies at least common bad codes with usual poor designs(deliberately turning them into uncommon and strange counterparts requires a change of plugin development styles and habits though), so the additional plagiarism countering effect can be treated as a bonus of this plugin development approach.

Usually, developing plugins with such a fast pace will accumulate so much technical debt that one can quickly become technical bankrupt(those plugins become so hard to work with that they become unsupported all of a sudden), but if most plugins involved are easy, simple and small(e.g.: within 1K LoC scale), the technical debt of each of such plugin isn't going to be too high to pay off the bill anyway, meaning that this approach can work for at least some plugin developers(at least 1 of the best and most successful scripter/plugin developer has been using this approach since at least VXA and already has hundreds of scripts and plugins in total, which is just impossible without this approach as no one can write high quality codes the first time), as long as they're willing to dedicate on keeping the user level quality high and maintain high quality supports, regardless of how low the code quality can be.

Of course, if it's at least an advanced complex plugin(e.g.: those demanding serious architectural level designs and with at least around the 10K LoC scale), deliberately writing uncommon bad codes with strange poor design's definitely a death wish for most plugin developers, but scammers will have a hard time to hide their plagiarisms with such plugins to begin with, so there's no need for the additional plagiarism counter already