First off, data is exempt from the GPL propagation rules, all your art, TDF/FBI, sound, etc files are considered separate from the code in the mod and as such the one mod = one work interpretation does NOT apply.
Second, interfacing with Spring in any way is considered linking even for interpreted languages, therefore all scripts that interact with the engine in a "non-trivial way" fall under the GPL of the engine itself.
Third, "The terms of the GNU GPL apply to the COB scripts which are based on the engine". I guess that means if you use get statements with values only Spring knows (or possibly assume Spring engine behaviour) in your script it must be GPL too.
That's the gist of the replies I got from the FSF and some parts of the FAQ.
Most notably:
http://www.fsf.org/licensing/licenses/g ... reterIsGPL
This is from the FSF which wrote the GPL therefore it's safe to assume this is how the GPL was intended to function. If it fails to perform as intended in these cases is a separate issue.The GPLed engine is not a system library so linking to it statically or
dynamically can be done only under the terms of the GPL. The GPLed
engine may use system libraries, but this doesn't make the system
libraries exception apply to the engine. It only means that you do not
have to provide the source code for those system libraries when you
distribute the engine.
The Lua interpreter is indeed a separate facility. It may use system
libraries, but is not covered by the system library exception.
The conversation did not involve a lawyer and this is not legal advice. To get more certainity you should confer with a lawyer.