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

[Subaru]

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

This would be requiring you to link to GPL binaries - even if you do it at runtime, its a violation.

 

[Cat Lady]

I'm lost again - what would require linking to GPL binaries? compiling cgame for other platforms?

 

[Subaru]

Yes

 

[Subaru]

http://www.gnu.org/licenses/gpl-faq.en.html#GPLStaticVsDynamic

 

[Cat Lady]

I get what linking is and (again) I'm *very* familiar with GPL licensing, but I still fail to see correlation. What the enhancement request is about, is compiling MBII's cgame*.so (that doesn't contain OpenJK bits, as stated in earlier explanations, just engine hooks and hax removed) for different architectures. + eventually, any other MBII-specific, non-openjk things.

Now, having that for architecture of choice, users could just compile rest components of OpenJK for that platform (for example, openjkded), and being compiled for the same architecture (for example, arm), openjk.arm would use MBII's cgamearm.so, just like openjk.i386 uses cgamei386.so now.

So, basically, everything as it is now, but for different architecture. If you don't link to OpenJK binaries on i386 and it works (cause MBII's cgamei386.so is compatible), why it wouldn't work on other architecture without additional linking?

Or are you speaking about compile-time linking OpenJK (during openjk binaries compile) *against* your (MBII's) cgame*.so? Then, this applies:
https://www.gnu.org/licenses/gpl-faq.en.html#GPLIncompatibleLibs

...which mean that you just create another text file, where you grant users the exception to link against YOUR library (cause you're copyright holder of MBII's cgame*.so).

/Cat Lady

// Edit

And don't get scared by:
https://www.gnu.org/licenses/gpl-faq.en.html#FSWithNFLibs

...it just means that they don't like it, but can't do anything against it, as it is not business of GPL'ed part. And yes, I'm not a fan of how it is phrased, the "no part in Free World [sic!]" might be misleading. But it is just personal opinion of Unix Beard that wrote the FAQ at the time.

 

[kikili]

Euh....
Sure you did...
Sorry and thanks a lot !

 

[Subaru]

Cool - thanks. We will discuss internally what we want to do about this. We didn't have anyone before who knew much about GPL, so decided to err on the side of caution.

 

[Szunti]

I don't think it's that easy with the GPL. The license text is more general, and imo not totally clear.

I think the most applicable part of the FAQ is about plugins (https://www.gnu.org/licenses/gpl-faq.en.html#GPLAndPlugins) which tells that depending on the circumstances it's more or less a grey area if plugins must be GPL too.

This question also appeared for SpringRTS, which is a highly customizable free software (GPLv2 like OpenJK) RTS engine for which games can be written with lua scripts. There was a lot of discussion on their forums, and iirc the result was that they couldn't decide how to interpret the GPL, but the developer team announced that they consider mods to be not part of the engine and don't require them to be under GPL. That solved it for them, and there was even a proprietary mod made. But they made the full engine for themselves, so it was a bit easier. This is an example, that it's not an easy question.

On the other hand I agree with Cat Lady, that I don't see how this depends on processor architecture.

 

[Subaru]

Like I said before, it's not crystal clear.

 

[Cat Lady]

Cool - thanks. We will discuss internally what we want to do about this. We didn't have anyone before who knew much about GPL, so decided to err on the side of caution.

Sure and thanks for considering it - BTW, if team ever needs any help with deciding how to handle things related to so-called "free" licenses (GPL, BSD [including dual-licensing], CC, whatever - you name it), I'll gladly provide assistance (including NDA disclosure if you need it before finalizing thing/deciding if you ever want to go that side).

I don't think it's that easy with the GPL. The license text is more general, and imo not totally clear.

I think the most applicable part of the FAQ is about plugins (https://www.gnu.org/licenses/gpl-faq.en.html#GPLAndPlugins) which tells that depending on the circumstances it's more or less a grey area if plugins must be GPL too.

I agree with you that parts of it may seem unclear to bystander, but after you dig a little more, it's all clear - what is even more important, it is clear from law-agencies side of things The latter is the reason why the former is the case - sadly, law system require quite strange formulation, sometimes, to make things clear from *their* side of view.

Anyway, in this case, it is *not* about plugins - it is clearly linking between executable and libraries. Speaking in "normal" language - to be able to link with non-free (cause it is not only about GPL, other FSF-compatible licenses are OK too) library (MBII in this case), that result in creating GPL executable linked with that library, you *need* to have allowance of the non-free part copyright holder. This allowance takes form of written exception, distributed with the resulting file.

So, in our case, MBII must write and exception, that state linking openjk executable with MBII's cgame is allowable. Kind of writing exception for yourself in this case, but it is how it works.

/Cat Lady