Thank you for licensing TFC under GPL v3!

[oldmanmike 5]

[Not sure if this should go under discussion or support]I was browsing through the TFCraft repo on github and looking over all the commits Bioxx has been making. And then I opened up the license.txt and saw GPL v3 - it made my day. I'm assuming Bioxx was the one who made that decision since his name is on the relevant commit, but if the idea came from someone else, thank you whoever you are. It's sad that FOSS, let alone open source software, is not more common amongst Minecraft mods. Modding Minecraft is not that hard to get into and I think the modding community would be a whole lot better off if it was easier to build off of the work other modders have already done. And given how large and full of potential Terrafirmacraft is, giving people a way to make their own changes to the mod is very empowering and helpful. Maybe I'm just being naive of the fact that the Dev API and addons exist, but I would much rather read and screw around with the original source code itself and test out modifications in-game rather than post the contents of my daydreams to the forum.So, I'm a programmer who's trying to get into Java and Minecraft modding and I was excited by the license because of all the things I would want to modify about survival mode Minecraft, Terrafirmacraft makes many of them already and I would rather work to extend/improve than than start something from scratch (for now ). I'm perfectly aware that addons and the Dev API exist, so I'd just like to ask the community and ideally the developers the following questions just for clarifications:0) How deliberate, serious and/or permanent was the decision to use GPL v3? What was the reasoning and/or intentions behind it?

1) Am I allowed to redistribute TFC provided I'm not charging money for it? As part of a modpack?

2) Furthermore, am I allowed to release and distribute my own modified version of TFC provided I'm not charging money for it and making the source of my own changes publicly available and properly credit Bioxx, Dunk, et al. for that which is not my work?

3) Finally, what's the policy on pull requests? Bioxx stated on the Twitter account that he doesn't like others touching his code. Should I generally assume that any features or improvements I make are unwanted upstream and should just get posted as an addon? Upstream for bug fixes, downstream for game changes?

 

Much of this is addressed to some degree within the body of the license itself, but I'm asking anyways because I'm not sure how interested/open Bioxx and Dunk are to suggestions in the form of code.

 

Thank you again for making Minecraft just a little more open.

[Kittychanley 1,002]

I'm unable to answer all of your questions, and will relay this post to Bioxx so that he can confirm/deny the answers that I provide, as well as provide answers for the questions in which I did not.

 

1) Yes, you are allowed to distribute TFC as part of your modpack. Legally speaking, there is nothing stopping you from distributing it in a modpack on whatever host you desire. However as a courtesy, due to our as well as other mod's past history with the Technic/Tekkit community and their lack of permission requests, we ask that you do not distribute TFC through them. Like the license states, there is nothing legally stopping you from the redistribution.

 

To enforce this request however, mod packs and servers hosted through Technic/Tekkit cannot be advertised on this forum. Any posts or topics containing Technic/Tekkit links will be deleted, and repeat offenses will result in the member being warned, and eventually banned from these forums.

 

We also do not give support for those who use the Technic/Tekkit launcher for TFC. If a user posts a crash or bug report in our support forum in such a way that it is obvious they used the Technic/Tekkit launcher, the topic will receive a reply stating that it will not be getting support, and the topic will be locked.

 

3) The general policy for pull requests until you have proven yourself would be KISS (Keep It Simple Stupid). Things like minor bugfixes which do not require overhauls of the code to fix, and localisation updates are likely to be quickly merged. Simple fixes like these also need to have very descriptive commit messages explaining exactly what you did and why you did it.

 

Bioxx likes to double check any changes before merging them, so if you re-write an entire class or framework for the sake of cleaning it up, the request is probably just going to sit there forever, untouched, as the devs don't have the time to read through the entire change to make sure that nothing else was broken. More often than not, other classes and mechanics that you never even thought about will be affected or broken by your overhaul.

 

Leave feature implementation to the official devs (Bioxx and Dunk), this is their mod, and they do the planning and make the decisions for what new things are added to the mod, and how they are balanced.

 

This next rule is important, unless you want to get yelled at, DON'T TOUCH RECENT CODE! Many commits are just the start of new changes/implementations, don't go messing with code until the dev who wrote it says that they are done with it. Github also sucks for branch/fork management, so make sure to come visit us in IRC (#tfcraft on esper) to get the OK on any changes that you plan on making, so you don't screw up a class that somebody else was already working on. This rule goes double for Dunk's code (especially mobs). If you find a bug or think something should be changed, tell Dunk and let him handle it. He will throw a hissy fit if you change anything in his code without running it by him first.

 

---

 

As for addons, only ever use the dev API. TFC is still in beta, therefore a lot of things are probably going to change and break your addon with each release if you link into the base code. If there is something that you need to link into that isn't in the dev API, let us know so that we can figure out a way to add it in. We can't better the API unless we get feedback from the people who are using it.

[Bioxx 796]

0) It took me a while to decide on a license honestly. I would honestly prefer a license that more or less says "You are free to use the code for learning/personal reasons but not for redistribution", however I couldn't find anything that fit my tastes. So I decided to just be as open as possible. For the record, I hate licenses and having to deal with any of that crap. But such is life.

 

2) You are allowed to make your own release, although it can potentially cause a headache for us if said release ever stops being supported as players will without a doubt come looking to us for answers. So we would really prefer that you didn't unless its for a small group of players only etc. Any changes to the code outside of helping us bugfix etc, I would prefer to be in the form of a mod as that will undoubtedly help continue moving TFC forward for all of us.

 

Kitty answered 1 and 3 just fine.

[oldmanmike 5]

Thank you for your hasty reply! In closing, let me clarify some things of my own:0) I'm glad you made the decision you did. Honestly, I think at this point TFC has protection against redistribution in the same way Wikipedia does. It's possible to redistribute the code via the license, but the same can't be said for the reputation, community, wiki, mod spotlights, Lets Plays, and servers. One could redistribute the modified code as different flavors of TFC, but that's what addons and mod packs are for.1) I haven't associated with Technic/Tekkit since the Forestry/Sengir incident. If you guys are on good terms with the FTB team, they'd be the only ones I would ever consider releasing a public pack through, which isn't going to happen. I asked about mod packs because I'm trying to figure out the easiest way to automatically provide a group of friends an up-to-date, properly configured TFC client complete with supplementary mods and addons. They shouldn't have to manually update their clients individually every time a hotfix gets released.2) It would be for a relatively small crowd of people who privately know each other and are playing on a server together. We have a Facebook group that we use as a crappy newsfeed/forum/wiki solution, so issues and support will be dealt with within that community by as server issues by default unless it becomes pretty clear its an upstream problem.3) I like overhauls, but I don't like monolithic implementations and spaghetti code. Any feature I end up implementing will exist by default as an addon/module. Besides bug fixes, I might send a pull request as a proof-of-concept for a suggested feature. KISS is good, I'm personally a fan of the Unix philosophy and the Arch Way. A good chunk of my programming experience has been in C and Haskell, so I take code correctness, compositional modularity, and simplicity seriously. As for recent code, I'm going to assume that only the master branch is stable as a dependency.P.S. What Minecraft version is B78 being built on? 1.6.4?

[Kittychanley 1,002]

Build 78 is currently still on Minecraft 1.6.2, but there is the possibility that it might change before release. We're all dreading the 1.7 port.

 

Also note that the primary branch that we are using on github is Build78Fixed, and not master. Master is still the 77 code, and hasn't been touched since December 2nd.

[oldmanmike 5]

Build 78 is currently still on Minecraft 1.6.2, but there is the possibility that it might change before release. We're all dreading the 1.7 port.

 

Also note that the primary branch that we are using on github is Build78Fixed, and not master. Master is still the 77 code, and hasn't been touched since December 2nd.

Yeah, I was assuming you meant that building on code that hasn't been publicly released would cause breakage left and right. So I should be avoiding just the experimental branches like FoodOverhaulTest - and basically everything Dunk does?