I don’t for this very reason.
That may have severe repercussions that could be fatal or leave long-lasting damage. Security concerns of private modules aren’t even nearly as big of a deal. At worst you have a module that uploads a place’s contents to a private server. Plugins are perfectly capable of doing the same thing with HTTPService, but they’re able to use it anyway.
Sorry, but not everyone wants to give their work to the world out of the kindness of their heart.
Because plugins and the contents of private modules are two entirely different things. Plugins are tools meant to be used by everyone on ROBLOX, while the contents of a private module might be desired to only be used in a select number of places. And just because I make some stuff for the community doesn’t mean I magically want all of my work to be used by everyone.
2 Likes
Then why are you making modules that can be used by everyone if you don’t want them to see under the hood?
I’m not. If a modulescript of mine is private, it’s only meant to be used in 1-2 places. The bit you were referring to was saying just because I make some public stuff (plugins) for the benefit of the community, that doesn’t mean I magically want all of my work (places, models, modules) to be public-domain.
Then shouldnt that be the same as models? How do you transfer them across?
I’m not sure if I understand your questions completely, so I apologize if I don’t answer what you were looking for.
Why don’t I upload the modules as models then, and temporarily set it to public whenever I want to give it to someone? Because then they can view the source. If I’m using a private module, it’s because I don’t want them to have the source. Real examples of why I’ve used private modules:
- Some war group asked for a snazzy training facility, and I made it completely for free out goodwill. Later I find that group bragging on the forums that they have a cool training facility and they are trying to sell it, when it’s not theirs to give/make profit off of (they didn’t take any part in the development of it). Using a private module allowed me to ensure the training facility only went to only people it was intended to go to, allowing me to prevent scammy/asshole groups from getting a hold of it and people from selling my work as theirs.
- Unless someone offers to pay me beforehand, I always send them what they asked me to make before accepting any sort of payment so they feel comfortable. One time I did this, the person decided he no longer wanted to pay for what I made him, so I shut off the module.
- Once I gave a training place to a person in a war group to host on their profile so they could get the ticket income. They later left the group and tried to reuse the training facility for their new group, as if it were their own. I shortly shut down the place (it was created through a private module) afterwards
Using private modules allows me to ensure my work stays my own, while still allowing other people to use it.
5 Likes
As much as that may seem like a good thing, this is exactly the kind of behaviour the change is to prevent.
Put that power in the hands of someone malicious
Good lord! Remove the plugins! Remove the scripts! People can abuse them!
People using modules to do malicious stuff is nothing new – people have been doing the same things with scripts and plugins forever. The only difference with private modules is that you can’t view their source, which is a non-issue because of what I mentioned here. We’ve come full-circle, and your concerns still have no merit.
1 Like
Plugins and scripts require the user to update them over and over whenever they want the most up-to-date version, modules dont give user a choice
Scripts and plugins can use InsertService to insert the latest version of SkidHacks2000. Auto-updating malicious code is nothing new either.
But I can check for SkidHacks2000 in the source code, thus meaning I can go “Bye bye crappy plugin/script”. With the private modules, I cannot
The source being hidden does not matter.
Question: Is the person using the private module aware of its capabilities?
No? They wouldn’t check the source of a script either. The source being hidden doesn’t matter in this case.
Yes? They’re using it in full knowledge of what it can do. That’s their call, and again, the source being hidden doesn’t matter. They’re full aware of the potential risk, but are using it anyway.
1 Like
I really like the use of modules to enforce intellectual property. Since there is no accountability on roblox (for certain values of none) for the spread of intellectual property and certainly no way to keep hold of your intellectual property after it has been sent out into the world beyond your hard drive, it is up to the creator to create systems to enforce intellectual property rights. Of course, no system is perfect and some people abuse it as is done with the USPTO, but it is a far sight better for creators than seeing their hard work being pissed away by someone with a grudge/looking to make a quick buck. No roblox beaurocracy to deal with (as well as the intellectual property being spread anyway out of spite), just swift and easy revokation of the intellectual property for breach of ethics.
Module scripts are the only way that creators have to enforce intellectual property, and the removal of that feature will create a chilling effect on the transference of intellectual property, not to mention breaking everything that uses them.
8 Likes
I agree with EchoReaper, Removing this because it’s ‘unsafe’ for the user is ridiculous… It’s their own choice to use it or not.
1 Like
Private modules are a valid form of IP enforcement for shared content and happen to be the only one that’s available to us. I can’t imagine a situation in which disabling this bug/feature would directly benefit developers, and doing so will probably break stuff.
Preventing third parties from requiring your module has its own, distinct use cases for private content, e.g. copy-protecting proprietary games.
I don’t see any reason why these behaviors can’t be implemented separately. They’re not mutually exclusive.
One useful way to go about this would be to remove the ability to require unowned modules named PrivateModule, and to not touch the MainModule system.
It’s nonconstructive to argue that a feature should be disabled simply because it can be used incorrectly despite having valid use cases.
Just my 2c
7 Likes
There isn’t a problem with protecting IP, the problem lies in that the user has 0 control over when things update, even if not malicious, a change may break a game by renaming a function or something similar. To have a game that has no stability is stupid and none of you should ever condone such behaviour. The solution is proper versioning so I can require version X of module Y.
To say to not remove it because you can choose not to use them is like saying we should just legalise all drugs because you choose to use them. Private modules are like sticking your hand in a bag of drugs and candy and hoping you get candy every time, when the owner of the bag can swap candy for drugs once you’ve taken candy from the bag
“Hey, I can just require the version he didn’t shut off and I’ll be well on my way, screw that guy.”
The problem is very real and I’ve made similar experiences before ModuleScripts were a thing. The only reason this hasn’t happened to me recently is because I haven’t taken on very many development tasks for people.
But EchoReaper’s post is exactly the kind of dick move that the change is to prevent. If you have any sort of trust with your client, they would be happy to pay first before receiving the product, as is the case with a good number of software sold. Company demos product, client goes ‘Oooo, shiny, me likey’, customer gives money, you give product. You do exactly the same in any high street retailer.
If your client doesn’t trust you enough to pay beforehand then you clearly dont have a good repertoire with your client. I have never had a client unwilling to pay beforehand if I demo the product to them.
Just take a look at the [leftpad incident] (http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/) to see what changing code that people rely on can do, would you want the same for Roblox?
Sure, the trade can go well and for most clients it does, but you know very well that there will be shoplifters who try to take your stuff without ever intending to ever pay for it in the first place. Sure, it may be seen as a “dick move” to disable a module that a client has refused to pay for, but it’s analog to the police response to someone shoplifting. Yes, it could be considered a “dick move” to lock someone up for stealing a bunch of stuff, but it’s a necessary evil acting not only as protection for retailers but also as a deterrent for those considering theft for themselves.
Also, yes, there’s always the risk of a widely used module being shut down or broken by the creator, but it’s unlikely to happen here. Sure, changes to the module may break certain things but that’s something developers on ROBLOX are already used to (updates to the platform always have a chance of breaking something). You would think that someone capable of creating a module that is so widely used would have no incentive to simply shut it down, or to introduce changes so intrusive that they break everything that’s using it. After all, they’re happy when their code finds a use.
In the leftpad incident you linked, the only reason the developer chose to distribute his code himself rather than doing so through a distributor was because that distributor took ownership of his work and changed its name. I’m fairly certain publishers of modules on ROBLOX won’t have a motive to do something similar.
3 Likes
@ScrapYard
The current system would not even require a naming system, it already works properly with modules that are not named MainModule. Only modules named MainModule can be required by other users.
to all:
The MainModule system for allowing the use of code without sharing its source is a boon to roblox as it allows easy updating of systems across games without forcing creators to make the code open source. Before, there was zero middle ground: you either did not share it or you shared it with everybody. Removal of the MainModule system would negatively affect Apocalypse Rising, for example: it uses the MainModule system to share Google analytics between published and testing versions.
The MainModule system poses security risks because people can update the module with malicious code or remove the ability for the module to function. The very same systems that allow abuse are the ones that are enabling builders and scripters to share their work with more people as well as making it harder for developers to work on their own games that span multiple accounts, as with Apocalypse Rising. Removal of the MainModule system would be detrimental to the roblox community as a whole.
4 Likes