Recent Events Discussion (RED) Thread
- Thread starter VapourDrive
- Start date
It isn't Microsoft you need to be protective of. It's something I tried to explain in your deleted thread as well. They could kill Forge and loaders and force all of us underground, but they will not appropriate your hard work into their game. Microsoft is much more accountable for intellectual property violations than any individual member here. It's a PR time bomb waiting to go off. They won't touch it.
As for people here decompiling your mod to remake it (in contrast to a clean room remake without using any of the original assets), that's pretty unethical. I'm a little surprised to see that in this community of all places, given its reputation.
True
Yeah IMO if it's not open-source you should make it yourself. I definitely agree there
On all points @10paktimbits I am sorry if I came off a bit strong. It's just I have fairly firm opinions
Not really. If people like your mod and you disappear/retire/flounce others will just replicate it. It's just the way it works. Mojang's policy for modding specifically states that you can't have "control" over an idea. I mean, have you noticed that the vast majority of Mojang's content updates could be found in modded Minecraft long before they made it to vanilla? So your fears about Microsoft are ones you should have had about Mojang/other MC modders anyway. So, good luck to you. I'm sure that someone else will take up your mod for the community to access while you develop it for... just you, I guess?
Alot of mod developers have their mods Open Source, My mod is open source so people can help me (https://github.com/BackWoodsMod/BackWoodsMod)(Smameful Plug of my mod) But now the EULA kind of makes you make your mod open source.
There's nothing in the EULA that compels you to release your source code or surrender your copyright. Whatever you do release is fair game to be distributed or emulated beyond your control.
Just FYI, you committed way more to the repository than you should have. You should not commit the .gradle, eclipse, or out directories. You should not commit the .iml, .ipr, or .iws files. These things will differ from user-to-user and/or build-to-build and do not belong in version control. It's also a good idea to use a .gitignore file like this one.
Right now i don't expect many people to look and i am keeping that as kind of a backup. When the first real release comes out I was going to clean it up. Thanks for the tip on the .gitgnore
If you've done project customization you need the .ipr and .iml. The .iws is all personal stuff that shouldn't be included.
With every commit, you're irreversibly bloating the size of the repository. Due to how git works, everyone that clones your repository downloads the entire history upfront, meaning that if at any point your repository had large files committed, they will always contribute to the size of the cloned repository. This isn't a problem you should wait to fix; it should be fixed as soon as possible. There's literally no reason for those files to be committed, and they can't even be used as a backup, as they are not necessarily portable (they are generated based on your current environment, so you should treat them as if they won't work for anyone else [because they probably won't]).
I'd suggest deleting the directories and files I mentioned, squashing all your commits, and --force pushing the repository; basically, rewriting the entire history and resetting the repository back to a clean state. That way, people that clone the repository won't have to deal with the extra bloat, and you'll have a good fresh repository to start from.
If you don't do this, it's always going to be a pain for people to contribute to your project and it's only going to get worse over time, not better (even if you fix it sometime later).
@jaquadro, I've never seen .ipr/.iml files committed to a repository and the Github gitignore template for IntelliJ specifically ignores them:
Code:
/*.iml
## File-based project format:
*.ipr
*.iwsGuess it doesn't matter now. I've degraded both myself and what maybe one day could have been a good mod.
Mistake made - absolutely. But only because I went about it the wrong way. I needed to pull the mod, as I said, for other reasons as well. As a consequence I've ruined my relationship with so many dedicated fans. I did this for them, not for me, and they are all left wondering wtf happened. I get that. I will never gain their trust again. I get that too.
My final reward for my effort is disgrace, but I'm not an ungrateful swine. I truly care about the community, and to be called that means the caller truly doesn't know me.
You're blowing this out of proportion. It's not a big deal; we're making silly mods for a silly game.
If you want to stop making your mod, go right ahead (but if you have no intentions of maintaining it, there's not much to lose from open sourcing it, is there?). If you want to return and start working on it again, no one will be upset at you. However, I'm not sure that what you decided to do here matches up with your stated intentions. Taking your mod down probably doesn't do much to protect your hard work (still unsure about what that means); rather, it only serves to obscure/hide it.
My opinion on what you can do to go forward:
1) Publish your mod as an open source project.
2) Keep the mod closed source but collaborate with a trustworthy team to continue development and distribution.
Either of those are acceptable to placate the main fear people are going to have: that you will pull your mod again without notice. Other than that, your fans can still love you and the work you do. And I think they do. They just want assurance that investing their play time in your work is not going to burn them.
I think all the Too Serious around here is rubbing off on you.
You're fine by me. Keep doing your thing and try to relax a bit.
Sent from my Toaster using Tapatalk
Sorry about calling you an ungrateful swine. I sometimes take things to far (typical kid there). Anyway thanks for apologizing. In my books you're an okay guy. Heck anyone willing to make something for other people for free is a great guy
To true.[DOUBLEPOST=1413000543][/DOUBLEPOST]
^[DOUBLEPOST=1413000588][/DOUBLEPOST]
This guy has the right approach
That seems strange to me. Those files roughly correspond to the .sln and .csproj files of C# solutions, and you'd be angry at any dev that didn't check those in with the code. The .ipr defines which modules compose a full project, and the one or more *.iml define the library and module dependencies as well as what folders constitute source/testing/resources/etc. Seems like something you'd want checked in if you want other IntelliJ users to be able to just open your project and use it. I've got one mod published to date that would build fine from a gradle command line, but not work correctly in IntelliJ without the extra setup included in those files.
Actually, even .sln/.*proj files are increasingly discouraged from being checked in, and are more and more being built with external tools (especially for multi-platform projects). For example, Valve's Source SDK 2013 repository uses a command line tool (Valve Project Creator) to generate OS-specific build files, and has *.sln included in its .gitignore.