[Enhancement]Please provide .arm builds of mbiided and required mod files

[Cat Lady]

// Edit
This bug report turned out to be invalid, so I'm changing it into enhancement request. Content of the original post - for coherency, and in unlikely case someone else come searching for same answers - archived at the end of this message.
---

Considering the informative and kind answers to my rude questions - and the fact that MBII could use super-cheap way of hosting servers, non-effort-required porting to bazillions of different ARM devices, and (possibly) free and effortless visibility in huge RPi community (which contains more gamers, than it seems at first), I'm proposing the following:

Pretty, pretty please, release the mod files build for .arm target, too (and x86_64 wouldn't hurt too, but at least it is not deal breaker).

I would compile it myself - actually, just spend a week and ~100$ for 2 RPi's (and peripherials) just for trying too, as I was foolishly thinking that it will be possible using:
https://github.com/MBII/OpenJK

...but MBII code is maintained the way that it is not possible for outsiders of dev team.

If you're willing to do it, but don't know how (I doubt it, as MBII dev team *now* have many, many skilled personalities, but just in case), I will gladly provide tutorial on how to set up RPi compiling environment in your everyday desktop LinuxBox. Or whenever else you compile linux binaries of openjkclient (mbii.i386) for use with MB2 releases.

On a more dramatic tone - my (almost) unused 100Mb synchronous net access just weeps for hosting MBII servers, but you're not letting me, so all those ~100 000 000 bits are sad and lonely. I weep for them too, but using x86-compatible PC for hosting MBII server - when 35$ can handle 4+ of them easily - is just overkill. armel builds are a way to go, for such things.
---

Additional note - all of this wouldn't be necessary, if MBII would stop being silly and FOSS itself, already. Ah, the joy! I would gladly become debian maintainer (if no one better skilled would like to) of it's contrib package... Just imagine those phoronix.com main page article:
"Most famous and biggest Jedi Academy mod to date just got its official Debian package, after going FOSS last week. Jedi Academy wasn't shining so bright, since going FOSS itself just <xxx> years ago!"


/Cat Lady

---

TL;DR

:
Source code from https://github.com/MBII/OpenJK is broken mess, doesn't produce the same binaries as one distributed with MB2 release(s), and they're not even compatible with each other. Apart from (unintentionally, I think) breaking GPL license, it just sucks - people wanting to compile MB2's openjkded (possibly also client) for other architectures and host servers on those non-x86 machines / play from them, can't.

Long story:
I've just received few fresh Raspberry Pi's, and as promised on old forums, decided to compile MB2's OpenJK fork for armel architecture and host few 24/7 MB2 servers on those, obviously also releasing resulting binaries for other people's benefit (machine costing 35$, that uses like 1W of energy and can host ~four 32-players servers simultaneously without any sweat is not a small treat!).

Figuring dependencies and build options was no-brainer thanks for great OpenJK documentation, and it compiles in about 5 minutes on Pi itself, without any problems. Few minutes later, I got test server running happily and visible - just ready to get hit by first issue:

Files on https://github.com/MBII/OpenJK produce openjkded binaries, that report "basejka-I" as version, while binaries distributed with MB2 release return "Movie Battles II V1.3". When connecting to server hosted by self-compiled binaries, it errors out due to server-client mismatch:



After some searching, the offender is:
/codemp/game/bg_public.h

...in MB2's OpenJK fork. Namely, the 19 line should contain (and, apparently, it was the case with files used to build binaries released by MB2 team):

#define GAME_VERSION "Movie Battles II V1.3"

...while, instead, it contains:

#define GAME_VERSION "basejka-1"

(Before anyone suggest that - no, '#' doesn't mean it is just a comment in code, this isn't snippet from shell script)

After fixing it and recompiling, clients can successfully connect to servers and float around map as spectators. Sadly, this is where the REAL problems begin - clients are hit by following issues:

1. Player in spectator sees his model - mixed with saber - floating with him, all the time, around map.

2. Joining actual game doesn't work. Selecting class and clicking "Join" result only in changing the "floating" model to selected one.

3.Many variables from server settings are ignored - for example, points (everyone got 0 n matter what is set in server.cfg), smod (rcon works fine, OTOH), g_Authenticity (it is always open, no matter what is set in config) allowing/disallowing spectators to move... Albeit, I'm sure that the config file is actually used, cause other parameters (port, server name, etc) are changing according to changes in config file.

...and probably many, many more things - given the fact that basic functions of server doesn't work, testing further was pointless.
---

To help debug the issue, I tried many combinations, amonst others:

a) Connecting via JAMP.EXE and MB2-released openjk client - no change, same issues.

b) compiling code from https://github.com/MBII/OpenJK on my desktop and hosting test server there (to eliminate highly unlikely problems with armel build only) - same bug happens, do it is definitely the MBII/OpenJK code in repository to be blamed, not target architecture.

c) Compiling (on my desktop) client from the *same* codebase (https://github.com/MBII/OpenJK) as server and connecting to it - suspecting, that client and server from the same codebase won't suffer from the issues.
Instead, this produced even bigger mess - mbii.x86_64 or mbii.i386 created from MBII git repository is in the same sorry state as mbiided. Despite having fs_game "MBII" set (just like with mbii.i386 binaries provided from MB2 release, and using same method to start self-compiled one), and seeing MB2 greeting screen, rest of UI is basejk. Connecting to server works, but it thinks it is in siege mode - and, after selecting team, client crashes, complaining about lacking UI for team select.
---

Summing it up - from the above debugging (sandbox-style), it seems obvious that code used for creating MB2's openjk binaries as seen in release is *not* the same as code on https://github.com/MBII/OpenJK. Furthermore, code on the latter is utterly broken and incompatible with the released ones, to the point of making all attempts to self-compile MB2's OpenJK fork futile.

Please, update the files in git ASAP - i think that ability to host cheap, 24/7 servers on all manners of inexpensive single-board devices is quite important thing, especially in such hard times for MB2. Not to even mention that playing MB2 on tablets, phones, and other ARM wonders (OpenPandora, anyone?) may be fun thing, too

Also - we don't want MB2 haters to file GPL violation case to FSF, do we? Considering, how frustrating it is to prosecute Asian license violaters, having a guilty party in civilized parts of the world, easily reachable by lawyers... Sole thought of it could make them enter into Wookie's Fury state and shred poor MB2 team apart.

/Cat Lady

 

[MaceMadunusus]

Also - we don't want MB2 haters to file GPL violation case to FSF, do we? Considering, how frustrating it is to prosecute Asian license violaters, having a guilty party in civilized parts of the world, easily reachable by lawyers... Sole thought of it could make them enter into Wookie's Fury state and shred poor MB2 team apart.

I can't help with the rest, but I want to note that MBII isn't directly using the source code. We allow it to be compatible specific OpenJK builds (IE stable ones that don't have glaring issues with them). That is all.

Also, not all of our own repositories are fully recovered after the incident. Code is up, but assets aren't and that is a higher priority than making sure the OpenJK fork is the correct version.

 

[Cat Lady]

I can't help with the rest, but I want to note that MBII isn't directly using the source code. We allow it to be compatible specific OpenJK builds (IE stable ones that don't have glaring issues with them). That is all.

I believe that you're referring to legal situation with GPl violation - sadly (or fortunately, depending on point of view), it is quite clear here. MB2 release files provide compiled binaries of (modified) openjk code ("openjk.<architecture>" client renamed to "mbii.<architecture>", and openjk multiplayer libraries, in this case) = MB2 team is obliged to provide source code that can be used to compile exactly those binaries. Even removing openjk binaries from further releases wouldn't help, as code for binaries released in the past must be available (publicly or upon request).

Also, not all of our own repositories are fully recovered after the incident. Code is up, but assets aren't and that is a higher priority than making sure the OpenJK fork is the correct version.

Of course I understand that and there is no problem with waiting some time for it (the "only" drawback is that no hosting servers/playing on devices other than i386 architecture compatible, until fix happens). I would just like to point out that the code in:
https://github.com/MBII/OpenJK

...wasn't affected by the sxxmess. The code was broken since day one It looks like no one verified if things posted there actually "work" (aka - result in compiling the same binaries, that are provided by mb2 team), no wonder that everyone trying to build binaries was hitting a brick wall (during debugging, I was doing some google-fu - most people that tried it hit it at the #1 issue, server-client mismatch, if someone went further and encountered the total mess, he wasn't leaving public notes ;.) ).

/Cat Lady

 

[Subaru]

Hi! A few clarifications here:

0. It's very rude to come out of the gate mentioning suing.

1. mb2 should be compatible with all versions of openjk, not just the one we provided.

2. We have not provided copies of the gameplay code, as it is linked against the JKA API, not the openJK one. The mod code inside codemp is never distributed in binary form. We have no portions of openjk code inside of the private code. The issue is NOT mbii.<arch> but instead cgame.dll and friends. If you compile the repository for windows, and drop in mbii.x86+renderer instead of jamp.exe or openjk.x86 it should work. It would be nice to open source the mod code, but there is no way currently, for both philosophical reasons (some people think that we shouldn't give up so much control) and legal ones (we cannot contact all old contributers [who didn't necessarily sign a proper contract...mb2 code is from before licenses were a thing in mod code] to get permission to change the license of the code).

3. Send me your email, I'll invite you to our slack channel where we can talk faster.

 

[Szunti]

I use an openjkded of the original openjk project (https://github.com/JACoders/OpenJK). The only difference I think is the metaserver address which can be easily set n the server config anyway.
I needed an openjk compatible jampgame.so though to not crash at map start.

 

[kikili]

Thanks Subaru for clarifications. I found your post quite rude as well. I personally use openjk to play MBII but with recent binaries I've compiled myself from the openjk git repo master branch and it works very well.

 

[kikili]

Regarding having the mod working on Raspberry Pi's, mean that we will have to compile the mod for it (the mBII fork of OpenJK didn't contain any MB2 code at all in fact)
This is not currently in the projects, but you can at least make an enhancement request for it.

 

[Cat Lady]

Thank you for fast answers!

Before we get straight to the point, clarification from me is in order too, it seems:

0. It's very rude to come out of the gate mentioning suing.

Thanks Subaru for clarifications. I found your post quite rude as well.

To be honest, I'm not the type of person that cares much if thing may sound rude or not, as long as it is stated in civil way. I just state what I discovered from my compiling/debugging session, and what they implications i THINK are - without unnecessary sugar coating.

Actually, I would like MB2 to be NOT involved in any GPL violation (in my post, I never mentioned actually suing anyone as it wouldn't be even necessary by FSF, but it is entirely different topic and let's not go there, as it is off-topic for this thread also), as i like the project very much. That's why I have stated, clearly, that in my understanding (that, again, might be flawed), we were talking about unintended violation.

OTOH, if my understanding turns out to be wrong, (by convincing arguments stated in the same civil way, sugar-coated or not ) I will gladly excuse for my mistake.

tl;.dr for that part: 1. Stating that something might be GPL violation != threating about suing anyone, seriously... 2. I'm perfectly aware that I might be wrong, too.
---

Now, lets get to the real deal:

[snip - will comment on various points in later parts of post]

I think you lost me on that one, so - please excuse my ignorance - could you answer few more questions, please? (I'm the only one that feels silly writing such sugar-coated sentence, or readers feel as uneasy as me? )

2. We have not provided copies of the gameplay code, as it is linked against the JKA API, not the openJK one. The mod code inside codemp is never distributed in binary form. We have no portions of openjk code inside of the private code.

1. If mbii.i386 (aka renamed openjk.i386) got modified to be linked against JKA API, where are released source code changes that reflect it? The https://github.com/MBII/OpenJK contains 7 commits from the version of OpenJK that it was based on, but I haven't found anything even remotely resembling such change in any of the commits.

2. Whatever the method MB2 team used, GPL license means (in this case, in short tl:dr form), that whatever you did to things from OpenJK that are in the MB2 release (v1.3 or whatsnot) zip (it doesn't matter if it is in the code or just bundled as binary or as whatsnot), should be available as raw code, too. This, in extension, *should* mean that I should be able to compile it for any architecture (not just provided i386), and have it working the same way as i386 build provided in MB2.zip. Correct, or I'm missing something?

3. Thinking about it further, and trying to answer my own question from end of #2 (and analyzing your response again) - you're telling me that mbii.i386 (aka openjk.<architecture>) is the *only* thing from OpenJK that you ever touched? The commits indicate changes to:
codemp/qcommon/qcommon.h

...and:
codemp/server/sv_init.cpp

...too, so I guess at least server and jampgame<architecture>.so is affected, too?

Anyway, how it is even supposed to work with vanilla MBII's (vanilla JKA's + MBII) cgame<architecture>.so, without OpenJK's cgame*.so? You made some own (thus not GPL'ed) changes to content of MBII cgame<architecture>.so without using *anything* from OpenJK code, to make it compatible with openjk.<architecture> client? Is it even possible to do it in "whitebox" manner, aka make your cgame*.so OpenJK-client compatible *without* looking at what OpenJK did in its cgame*.so?

If yes, I just take your word on it. (at least until I ask same question to OpenJK team... Rude, I know ;.) ). If no (aka it required peeking at OpenJK's cgame, to make compatible changes in MBII's cgame), then MB2's cgame actually contain OpenJK cgame's derived work, and *must* be made public.

1. mb2 should be compatible with all versions of openjk, not just the one we provided.
(...)
The issue is NOT mbii.<arch> but instead cgame.dll and friends. If you compile the repository for windows, and drop in mbii.x86+renderer instead of jamp.exe or openjk.x86 it should work.

Hm, when I compiled openjk things on my desktop and thrown them in place of MB2.zip provided openjk-related things (without overwriting anything, as I compiled for x86_64, and files form zip are i386), it wasn't working, as described in section "c)" of my debugging attempts, in last post. Furthermore, if I compiled for i386, the name of cgame*.so was different than one provided by MB2.zip, so another time, nothing was overwritten - and it still wasn't working.

Thus, logical reasoning would be, that mbii.i386 contains (in-code) things that made it work with JKA's vanilla MBII'ified cgame, and those changes are nowhere to be found in https://github.com/JACoders/OpenJK

Correct? Wrong (why)?

It would be nice to open source the mod code, but there is no way currently, for both philosophical reasons (some people think that we shouldn't give up so much control) and legal ones (we cannot contact all old contributers [who didn't necessarily sign a proper contract...mb2 code is from before licenses were a thing in mod code] to get permission to change the license of the code).

I don't want to tackle much of this as it is discussion for different thread (that I will create one day), but:
1. Would also like to see MB2 open sourced - it would end ALL those problems.

2. Of course the "philosophical" reason is valid, even if I strongly discourage with it and think it is "microsoftionism".

2. The "legal reasons" are total nonsense, cause if contributors haven't signed a license disclaimer, *and* they're un-contactable (heck, even IF they are contactable...), the code holder is free to do whatever he want with it.

Stating otherwise is like saying that you can't disassemble origami pigeon that stranger gave your kid during your last trip to the park and publish plans for re-making it on your blog, cause you haven't got his license and he is not contactable... Yes, it is *same* situation - code in question was given to MB2 without *any* copyright, (in good faith), to do whatever you want with it.

So, will you understand me that I got mix of facepalm, nausea, and laughter, everytime this "argument" against open sourcing MBII is used? It is utter, complete nonsense.

3. Send me your email, I'll invite you to our slack channel where we can talk faster.

Thank you a lot for that proposition and willing to take your time explaining real-time (honestly, no sugar coating this time ;.) ). Sadly, I think I'm available at rather non-comfortable (for rest of the society, at least) hours, at least if you're euro-based, and at other times - like now - I'm here only for short moments, so trying to converse in RT would be waste of other people's time from my side. Also, talking about such complicated matters in forum allow to think before writing

Nevertheless, e-mail sent.

Cheers,
/Cat Lady

// Edit
And of course if I'm wrong about the GPL-thing, I will gladly post an enhancement request.

Frankly, my motive was to allow myself and others a cheap, reliable way of hosting MB2 servers on unused data lanes (like RPi and other single-board computers). At the same time - after releasing working RPi server - I wanted to announce it on RPi hoped to gain some visibility for MB2 in *big* RPi world, simultaneously hitting the GOG.com, trying to get MB2 as a mod spotlight (for the Jedi Knight franchise, that they acquired rights to distribute DRM-Free, not so long ago). Last bu not least, I wanted to mess with compiling *clients* too - even much slower Pandora was able to play JKA, so quad-core Pi *might* handle MB2, if resolution of assets is turned down, as a separate pet project from me. Same goes for Pyra, and other handheld ARM devices, where MB2 could suddenly get playable...

But, I'm getting ahead of myself. For now, due to the way MB2 handles things, it is not even possible to compile and host "plain" dedicated server for any architecture other than i386. Which, pardon me, "s(u)xx" .

 

[MaceMadunusus]

Communicating and bundling with non-GPL programs[edit]
The mere act of communicating with other programs does not, by itself, require all software to be GPL; nor does distributing GPL software with non-GPL software. However, minor conditions must be followed that ensures the rights of GPL software is not restricted. The following is a quote from the gnu.org GPL FAQ, which describes to what extent software is allowed to communicate with and be-bundled-with GPL programs:

'What is the difference between an "aggregate" and other kinds of "modified versions"?

An "aggregate" consists of a number of separate programs, distributed together on the same CD-ROM or other media. The GPL permits you to create and distribute an aggregate, even when the licenses of the other software are non-free or GPL-incompatible. The only condition is that you cannot release the aggregate under a license that prohibits users from exercising rights that each program's individual license would grant them.

Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).

If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.

By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.

The FSF thus draws the line between "library" and "other program" via 1) "complexity" and "intimacy" of information exchange, and 2) mechanism (rather than semantics), but resigns that the question is not clear-cut and that in complex situations, case law will need to decide.

Read that more carefully.

 

[Cat Lady]

I did - heck, I was amongst people making last revision look as it does.

As I remember it, OpenJK client wasn't working with MBII's modification of vanilla's cgame. Then, at some MBII release, someone made changes to MBII's cgame, that resulted in openjk client communicating with it.

The problem here isn't abut act of communicating itself - the problem is if to write those communicating bits, author required to take look at OpenJK's cgame code, and use them to make MBII's cgame to be compatible. If yes, the versions since then (and up until this code is removed) should be released, too. That is the thing I'm damn dead sure about.

Otherwise - aka if author was able to make MBII's cgame work with OpenJK without actually using "wisdom" from OpenJK's cgame (written it "blindly") - there is no need to release the code.

Personally - peeking at OpenJK's cgame code - I don't believe the latter to be possible. But I might be wrong, so first, I want opinions of both better informed parties (MBII and OpenJK devs themselves).

BTW - the so-called "cleanbox" or "whitebox" approach required for making things compatible with licensed stuff was enforced before, by both FOSS enthusiasts and closed source zealots. ReactOS case was one of more famous in the former, and indeed, since then, to code for them you must be one of people that *never* saw any windows code snippets, in life (let alone checking code at will to write communicating thing).

/Cat Lady

// Edit

And the point about it being donein S(U)XXing way (not being able to compile working openjkded server binaries for MB2, for whatever architecture) still stands, even legal things aside.

 

[MaceMadunusus]

I did - heck, I was amongst people making last revision look as it does.

As I remember it, OpenJK client wasn't working with MBII's modification of vanilla's cgame. Then, at some MBII release, someone made changes to MBII's cgame, that resulted in openjk client communicating with it.

The problem here isn't abut act of communicating itself - the problem is if to write those communicating bits, author required to take look at OpenJK's cgame code, and use them to make MBII's cgame to be compatible. If yes, the versions since then (and up until this code is removed) should be released, too. That is the thing I'm damn dead sure about.

Thing is, there was no need to look at anything OpenJK related. We had our own engine modifications made through reverse engineering and hooks. Those modifications interfered. To make OpenJK compatible we just had to disable those modifications. MBII would work already just by simply commenting out those bits of code.

 

[Cat Lady]

OK, I get it, full white flag, then. And I'm sad, but that's another matter

But, out of curiosity - how BOTH jamp.exe and openjk can work with the same cgame, if the hooks are disabled?

// Edit

And, as promised - My deepest excuses for ever *THINKING* that MBII might have been, not purposely, violating anything. I was wrong.

 

[MaceMadunusus]

But, out of curiosity - how BOTH jamp.exe and openjk can work with the same cgame, if the hooks are disabled?

The same way any other base mod works? We didn't need hooks to run under jamp since its based off the original SDK provided with the game. OpenJK is also built in such a way that it doesn't break compatibility with things originally built off that SDK.

 

[ent]

Direct access to the mod modules: game, cgame and ui through vmMain function. Any engine seeks for vmMain function then loads it from any library.

Something like this: https://github.com/MBII/OpenJK/blob/master/codemp/win32/win_main.cpp#L563

 

[Subaru]

But, out of curiosity - how BOTH jamp.exe and openjk can work with the same cgame, if the hooks are disabled?

Myself and others dissassembled jamp.exe for some things. Those assembly hooks get disabled if you run on platforms other than windows or engines other than jamp. There is no reason that mbii's cgame needs knowledge of what is in openjk - as ent says above, everything can go through vmMain.
---

To be honest, I'm not the type of person that cares much if thing may sound rude or not, as long as it is stated in civil way.

To be honest, you border on noncivility. I don't have time to go through your entire post at the moment, I'm at work. Things seem to be sorted, though?

 

[Cat Lady]

Yes, it is - and I hope that, after going through the full post, you will notice subtle things that push my whole effort into civility region, after all. (the least of them being the type, that likes to spend insane amount of time and some money to contribute for his favorite mod, even if the mod in question follows most silly licensing scheme seen in JK mods development, ever.) If not, I will have to live with it and weep a little more alongside those 100 000 000 alone bits from (new) first post.
---

Anyway - As it is resolved, I've archived first post content and changed it into [Enhancement] request. Not unlike the one made on old forums, before breakdown, almost a pregnancy ago. I hope it won't get buried and forgotten like back then

/Cat Lady

 

[Subaru]

Here is my question: is it legal to release our code on platforms where jamp does not exist?

(I'm not really opposed to making the thing open source...even started the task of contacting old authors...but now I've lost the list of who we had permission from).

 

[ent]

Very legal. The ways how binaries will be executed is not our end problem at all.

 

[kikili]

In fact I understand better why you said that Cat Lady. It's because you didn't know was the mechanic of JKA mods and by extension you thought we made a license violation, which is not the fact.
Mac os version of MB2 is exactly the same piece of code as the one used for OpenJK and it works with legacy JKA without any other modification.
If OpenJK team found that actually legacy mods should not work anymore with OpenJK, then remove the code from the main fork, but we will still be able to continue to release openjk binaries which will work through with old mod system and why not with the new one as well.
What is uncivil and rude Cat is that although we show you your lack of knowledge on this specific part of the openjk mechanism and in more general manner of the license stuff (you know, but better you ask to a true lawyer if need deeper knowledge, that what you argue is indefensible).
So to be civil (and I think you are), just say :
'Ok guys, I didn't know and I go too fast, I'm sorry, but I really need this to work cause I want to ship it, what can we do ?'

 

[Cat Lady]

Here is my question: is it legal to release our code on platforms where jamp does not exist?

As ent said - your code still requires original assets to be owned by players (or not legally, but it is said player legal problem, then), and you're not releasing any copyrighted files with the mod. Notice, that OpenJK as a whole is doing exactly this - bringing it to platforms where it was never existing

As for contacting former contributors, I don't know if it will be helpful at all, but I have quite an experience in FOSS-transforming few projects (both independent and free as in beer, and paid BIG ones, like cooperarating with Nokia and their opening sources of one "infamous" operating system for phones...), so here it goes, anyway:

1. As I've written in one of earlier posts - from legal point of view, you don't need to contact anyone (as long as they haven't provided copyright notice while submitting their work), that I'm 105% sure of.

2. From informal point of view, I understand and sympathize with will to contact former contributors out of respect. That's great and kudos for that, surely ask anyone you can. BUT, if you can't get in touch with someone (no replies) - or lost a contact to person/group due to any reason (be it passing years or late sxxmess present), putting the thing on hiatus wouldn't be great thing to do.

HECKload of great, awesome projects, would be long dead and abandoned, if their leaders would hestitate from changing license, due to lost contact to contributors - including linux kernel itself (yes, it wasn't always FOSS - and now it is powering 90% of worldwide network infrastructure), which had a tonload of AWOL contributors, when Linus Torvard decided to open source and copyleft it. We wouldn't have game rewrites like "Ur-Quan Masters", "Open X-COM" or OpenDune, if their developers would have same hesitations.

And you know what? I haven't ever, heard of *any* old contributor of those project, coming and shouting angrily, that they went FOSS without asking him. I think that MBII contributors would be happy, knowing that thing they worked on thrives and blossoms, and could even feel a little guilty, if you hold the project due to being unable of contacting them. In any case - from moral point of view you done everything you could (to contact people that you have means to contact), from legal point of view, you're absolutely cowered.

Anyway, keeping my thumbs for your efforts! FOSSing MBII would indeed be historical, and legendary achievement.

In fact I understand better why you said that Cat Lady. It's because you didn't know was the mechanic of JKA mods and by extension you thought we made a license violation, which is not the fact.
So to be civil (and I think you are), just say :
'Ok guys, I didn't know and I go too fast, I'm sorry, but I really need this to work cause I want to ship it, what can we do ?'

Hm, haven't I just done that, a while before your post? See:
https://community.moviebattles.org/...mbiided-and-required-mod-files.196/#post-1620

...and:
https://community.moviebattles.org/threads/solved-jamp-and-openjk-crash.31/#post-1621

...and (redone) first post of this thread

/Cat Lady