“To take (another person’s property) without permission or legal right and without intending to return it.” - via Google.
While this philosophy is great for an open source community, it doesn’t give you blanket access to everyone’s code who doesn’t want their work to be shared. Would you be silly to assume you could hide your code from others? Yes. Does that make people decompiling your work and looking at it when you’ve made it obvious that this goes against your wishes right? No.
Just because you have the power to do something does not make doing it okay.
I just see it like this. We are making Plugins on top of a public/open source project. If this is now forge, Sponge, Husk or something else it doesn’t really mater for me. We make these plugins/mods to help server owners or make the game called minecraft more fun.
Lets say the server owner likes the plugin but wants to change some small part for himself. Than he could do that with having the source available and so far I know it it completly legit to take someone code, change it and use it for own use (Off course without support from the original author).
But lets say you hide your code. And the server owner wants to add that small feature he needs, he wouldn’t be able to. Or he will need to research and look a lot to get the source of the jar and recompile it. What in most cases brings up more problems. Also most people give up. (I spend hours and hours to figure out how to recompile computercraft mod with bukkit support (for own use), but it simply won’t work… .)
Than don’t share the plugin. no source == no plugin, their are enough licences that can protect your intellectual property.
If you want to make a proprietary plugin, that’s fine and not against the license of Sponge, but that doesn’t mean Sponge has to host or endorse it. You need to learn to separate the license of Sponge(API) from the ToS of SpongeDev.
I’m not even sure what you’re trying to get at, with this statement. I never quoted the Sponge license, or the SpongeDev TOS, both of which are rather irrelevant. The Sponge license being irrelevant because, though you use the API, assuming your scope is provided (or whatever you would use for non-maven projects), none of the code is actually included in your project (though it wouldn’t work without it).
Again, you’re kind of coming out of left-field here. The debate wasn’t about whether or not Sponge would “host or endorse” a proprietary plugin. There were plenty of plugins on BukkitDev that weren’t open-source, but could still pass the approval process. Those who reviewed the files were given that right by an agreement made by the developer upon signing up for BukkitDev in the first place.
However, anyone else who was attempting to decompile/read the project, without permission, and without the code being open sourced, were simply in the wrong. It doesn’t matter if the community is predominantly an open source community. That doesn’t give everyone blanket access to violate someone’s intellectual property by decompiling their code against their wishes.
The fact that this is even a point of debate, the morality of reading someone’s code when they’ve made it clear they’re uncomfortable with it, after they share their - potentially - hard work with the community is, frankly, appalling.
Your code is a derivative work of SpongeAPI if it uses it. The SpongeDev ToS applies if you use SpongeDev.
Did you not even read the topic title? ‘Plugin hosting’. This is precisely a debate about what kinds of plugins Sponge should be hosting. Whether nor not BukkitDev allowed it is completely irrelevant.
This is utterly and absolutely irrelevant. This isn’t about posting source code of plugins where the author did not allow it, this is about requiring consent to post said source code in order to host it on the platform.
Here’s how I think the system should work (Quick Note: I’m not a java dev, so I don’t know how easy sponge hosting a builder would be).
A developer would go over to dev.spongepowered.org or whatever, and create their plugin. They would then link it to their git repo and every time they created a new release sponge would compile it via travis API. This would be available immediately on the site, but marked as unchecked in some way (something like Mozilla does, with a yellow striped button with a warning before you download it). A file called spongemeta.json would contain information on the plugin and requirements. Sponge would fail to build if this was missing.
Somebody would have to review the plugin before it got approved status. Auto-scanning the code really isn’t very effective, so manual reviews should still be done. I also think that the community should be able to flag plugins that they think are malicious.
Some people have suggested that trusted developers should bypass the review process. That is never a good idea. A lot of security systems have accidental holes, best not create one deliberately.
Now onto the acquisitions of plugins. A user could visit a plugin’s page and hit download. They would actually go to a page that 302 redirect to a mirror, so dl.spongepowered.org/plugin?plugin=SomePlugin&v=4.32 would redirect to (i’m using S3 as an example here) https://s3.amazonaws.com/sponge.plugins/s/someplugin/4.32/someplugin-4.32.jar (The ‘s’ in the URL is the first letter of the plugin, probably not needed).
I also think there should be an in-game way to download plugins. For example plugins install someplugin to install the latest version and plugins install someplugin 4.31 for older versions. A warning would appear if it was unverified and the user would have to do plugins yes to continue with the installation.
Just one thing to note, it’s not really possible to safely compile Java code on the server, since there are so many different build systems (to note a few: Ant, Buildr, Gradle, GAnt, Maven, SBT), most of which (including Gradle which Sponge itself uses) relying on evaluating arbitrary code. Hence why I’ve suggested several times to outsource that bit to Travis (or equivalent) instead.
Providing some sort of “Sponge Sponsored” CI infrastructure/release mechanisms could be used as an inducement for an author to make a plugin/mod source available to the public. This could have other side benefits as well, such as ensuring plugins are built against a common Java environment, standard release packages, etc. I would also think that a plugin “built by Sponge” would have more intrinsic value than a plugin “built by OreCruncher”.
Use XenForo to host the plugins its what bukkit uses and they have stuff that can fit your theme if you do get XenForo remember to get XenPorta addon it will help your stuff alot
I guess it would depend on what the Sponge sponsors are willing to do/want to get out of the deal, not to mention what type of “service” is built around the Sponge platform.
My opinion is somewhere between the Proposal 2 and 3. I enjoy:
I don’t want to be too strict on the community, but if problems begin, I think we should take a more precautionary approach. Although, all of this would like to be avoided. This is just one of the things that I hope people are kind enough not to do that.
I’ve been stewing over an idea for awhile, and a few people may find it has merit. It’s kind of a mixture between a reputation system and a normal “review every file” system.
##Reputation
Reputation is given to a project (not a specific user). Projects with a Good reputation can have new files available as soon as they’re pushed, but a notice will be available to users that the file hasn’t been reviewed yet. Projects like this should have a slightly higher priority for the safety of users downloading an unverified release.
To Prevent Abuse:
Reputation given only lasts for a limited period of time (a couple weeks?).
Projects which receive Bad reputation go under a stricter review process, or are removed permanently.
##Tickets
Users who have been apart of, or responsible, for a project receiving a negative reputation receive a ticket.
Punishments for Tickets
Projects that you’re apart of (on a contributing basis) are under stricter review.
Too many tickets results in the loss of ability to contribute to projects, temporarily or permanently.
Any ideas?
EDIT: Before anyone says anything, I haven’t read the nearly 200 replies in this topic. It’s entirely possible someone has had a similar (or exact) idea to mine. I apologize, if that’s the case, and defer to them.
Just going to dispute one point: reputation that expires would just lead to people uploading a lot of builds all at once to boost rep, or uploading a build every x amount of time to maintain it. I update my plugins every few months once they’re mature because they don’t really need it. It’d be a shame if I had low rep for that compared to someone that spams updates every day because they write buggy code.
I really like this idea as well. For me, that’s the best compromise between security and availability. I would just like an automated scan to be added before the file is released at all (as unreviewed) - and if it marks a file as flagged, it has to be reviewed manually before even being published.
A different approach could be to let the automated system judge, how high the posibility of an exploit is - i.e. any kind of reflection raises that number - as does any network connection etc. That way it can be determined, how important a manual check is.
Mm. I guess I can see your point. Any ideas on how to fix that particular dispute?
Maybe, instead of a reputation that wears off, we just stick with Good and Bad reputation? Again, “points” shouldn’t be relevent, because it just inspires useless competition and abuse.
EDIT: I was thinking, actually… Maybe a reputation system shouldn’t be user appointed? Maybe Staff should be the ones to decide who has a Good and Bad reputation, and we rely on users to flag bad plugins?
The reason for that change… A popular plugin does not mean a reliable user. Some plugins get popular really quick, and could easily gain a bunch of Good reputation, and then the developer take advantage of the popularity.
Of course, anyone could do this. If we want 100% safety, we would require every file to be scanned before being available.
Maybe… we design a system that calculates the current estimated wait time for plugin approval…?
public boolean shouldBypassApproval(int PluginId) {
final List<Integer> waitTimeList = pluginHost.getRecentPluginWaitTimes();
int waitTimeEstimate = 0;
for (int waitTime : waitTimeList) {
waitTimeEstimate = waitTimeEstimate + waitTime;
}
return (waitTimeEstimate / waitTimeList.length()) > acceptableWaitTime
&& pluginHost.getProject(projectId).hasGoodReputation();
}
This way, projects can only have files available before they’re approval if wait times are especially high AND if the project has a good reputation.
