Page 1 of 12

FSF stance on GPL issues.

Posted: 29 Jul 2008, 18:43
by KDR_11k
I've been in correspondence with the Free Software Foundation, the authors of the GNU General Public License to clear up the whole issue about GPL mods.

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
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.
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 conversation did not involve a lawyer and this is not legal advice. To get more certainity you should confer with a lawyer.

Re: FSF stance on GPL issues.

Posted: 29 Jul 2008, 18:49
by Argh
I would like to see the specific replies given by the FSF, not a quote that's rather vague, to support that conclusion. I think that's a very overreaching interpretation of copyleft, myself.

Everything you've cited thus far refers to the engine, not to our software, which is running on it, just like a PHP script runs on Apache.

For the FSF to claim that this poisoned our work seems preposterous to me, especially when it's quite clear that various parts of the software may be severed without causing a halt- it's not one program, in the Turing sense, but many.

I'm not agreeing that your statements accurately reflect anything until you've provided us with more details indicating that the FSF has a clear understanding of how stuff actually works in Spring. Based on that quote, I'd say that they simply don't know how it works, tbh.

Re: FSF stance on GPL issues.

Posted: 29 Jul 2008, 18:54
by KDR_11k
[url]http://kdr_11k.from-hell.net/FSFconversation.txt[/url]

This is the complete conversation. The interpreted code stuff comes from the FAQ, in the end I just asked for the interpretation of "facilities".

Re: FSF stance on GPL issues.

Posted: 29 Jul 2008, 19:20
by Argh
> To the best of the my understanding, the TDF files could in theory work
> with any mod. The TDF files behave more like configuration files. Files
> which have this type of relationship with the GPLed code can be
> distributed under any license which does not restrict the distribution
> of the whole mod more than what the GPL would.
>
It's not a "configuration script", it's just another piece of Lua, after it hits Trepan's translator. And then it's a table.

Lastly, the vsf.include may be called by any piece of code. It is not loaded by every script, like a traditional #include in C.

Basically, I think that the arguments are very vague and muddy.

Ultimately, these paragraphs indicate the current state of the FSF's beliefs about what will be determined:
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.
However, most of that stuff, above, is untested ground. I can't take it really seriously, tbh, I think that courts will have a field day trying to argue about this, if it ever gets into court, and that ultimately they're going to have to throw out broad claims to non-Turing-complete interpreted scripts like our Lua.

I'm really not buying this, KDR.

Re: FSF stance on GPL issues.

Posted: 29 Jul 2008, 19:26
by Peet
Argh wrote:However, most of that stuff, above, is untested ground. I can't take it really seriously, tbh, I think that courts will have a field day trying to argue about this, if it ever gets into court,
Are you aware that the FSF is a common enforcer of the GPL license, having filed high-profile lawsuits against openTV and Linksys? That the GNU GPL license was developed in part by them? I somehow think they'd actually know what they're talking about -
non-Turing-complete interpreted scripts like our Lua.
unlike you.

Re: FSF stance on GPL issues.

Posted: 29 Jul 2008, 19:49
by AF
Refuting that TDF is a configuration file by saying it is another piece of lua is like saying a .ini file is just c++.

Eitherway I would say that this is definitive for the moment, since we're in no position to question the FSF on the meaning of their own licence.

Re: FSF stance on GPL issues.

Posted: 29 Jul 2008, 19:52
by KDR_11k
non-Turing-complete interpreted scripts like our Lua.

Code: Select all

local tape = {}
local position = 2000

function Brainfuck(input, code, index)
	local output = ""
	local entry
	if not index then
		index = 1
	else
		entry = index
	end
	while index < #code do
		if code[index] == "+" then
			if tape[position] then
				tape[position] = tape[position] + 1
			else
				tape[position] = 1
			end
		elseif code[index] == "-" then
			if tape[position] then
				tape[position] = tape[position] - 1
			else
				tape[position] = -1
			end
		elseif code[index] == "<" then
			position = position - 1
		elseif code[index] == ">" then
			position = position + 1
		elseif code[index] == "," then
			tape[position] = input:byte(1)
			input = input:sub(2)
		elseif code[index] == "." then
			output = output .. string.char(tape[position])
		elseif code[index] == "[" then
			output, index = Brainfuck(input, code, index)
		elseif code[index] == "]" then
			if tape[position] and tape[position]~=0 then
				return output, entry
			else
				return output, index + 1
			end
		end
		index = index + 1
	end
	if entry then
		error()
	end
	return output, index
end
(please don't debate errors in that code...)

Re: FSF stance on GPL issues.

Posted: 29 Jul 2008, 20:10
by Forboding Angel
Oh damn. Does this mean we are all basically fucked?

Of course Evo is designed to be free anyway, so technically I could go GPL and call it a day, but I don't want others to really have to use GPL to use elements of Evo.

Another cause for concern is the fact that a lot of my images in bitmaps come from smoth who released as CC-PD which by definition could be re-released as GPL I think, but wow. This is one hell of a big ass can of worms. :?

Re: FSF stance on GPL issues.

Posted: 29 Jul 2008, 20:11
by Pxtl
I'm really shocked by this, actually, particularly the COB thing. Consider how many languages are implemented under the GPL, and it is assumed that the language license free, only the interpreter is GPL'd.

Re: FSF stance on GPL issues.

Posted: 29 Jul 2008, 20:28
by Pxtl
I don't suppose we have a list of every single contributor to the engine so that they can all get together and agree to re-license their contributions under the LGPL?

I thought not.

Re: FSF stance on GPL issues.

Posted: 29 Jul 2008, 20:32
by Forboding Angel
Something tells me we are is some deep shit. I was afraid of this happening, but it's a lot worse than I feared.

Well, trepan wrote the lua stuff on the engine side, he could re-license it I believe? That would basically free mods I think from the snares. Assuming we can find all the lua devs that made our stuff and get the to re-license it as well.

What are the chances of the FSF coming after us? Do they care? TBH I don't really feel like opening thunderbird to a C&D.

Re: FSF stance on GPL issues.

Posted: 29 Jul 2008, 20:34
by trepan
If there's a case where linkage is apparent, it's
when cpp files are compiled together to make an
exec. Re-licensing the lua cpp source file would not
be enough.

NOTE: the *.cpp files in Lua/ do not mention GPL ;-)

Re: FSF stance on GPL issues.

Posted: 29 Jul 2008, 20:38
by Forboding Angel
Crap. I thought not. So much for that hope.

COuld the engine be moduled out (which makes me think that performance would circle the drain at that point) so that each work would be it's own (once again something tells me that that would also make the modules fall under the GPL umbrella)?

If COB scripts fall under the GPL umbrella, then I'm really boned. I suppose everyone else is too :?.

I suppose last of all... How seriously is everyone taking this?

Re: FSF stance on GPL issues.

Posted: 29 Jul 2008, 20:40
by trepan
The correct approach is probably to LGPL all engine code,
and distributed lua code (namely the widget/gadget handlers).
The bzflag project did the GPL -> LGPL conversion for all files
in their project some time ago for this very reason.

Re: FSF stance on GPL issues.

Posted: 29 Jul 2008, 20:40
by Pxtl
Forboding Angel wrote:Something tells me we are is some deep shit. I was afraid of this happening, but it's a lot worse than I feared.

Well, trepan wrote the lua stuff on the engine side, he could re-license it I believe? That would basically free mods I think from the snares. Assuming we can find all the lua devs that made our stuff and get the to re-license it as well.

What are the chances of the FSF coming after us? Do they care? TBH I don't really feel like opening thunderbird to a C&D.
Here's the basic damage: all LUA and COB content of the mod would have to be GPL'd to make them comply with the license they agreed to when they made code for the Spring engine.

Now, that's the bad news. The good news is that the GPL is a license between you and the person who gave you the code. That is, Trepan, the SYs, and everybody else who contributed to the Spring engine. If they don't care, then the FSF sure as hell doesn't care, since the FSF can't claim damages. The FSF won't sue you for violating Trepan's copyrights or license agreements, since the agreement was made between you and Trepan, not you and the FSF - he just used a license provided by the FSF. If Trepan wanted to sue the hell out of you, the FSF would help him with legal resources... but only Trepan (or any other contributor) can bring that suit.

The other problem is that the whole point of the GPL is that it contaminates everything it touches - this means that every part of the engine must be GPLd (and every piece of code interacting with it, like all the LUA and COB) or none at all. There is no halfway. You can't re-license the LUA/COB interface because it interfaces with the COB interpreter, which is GPL'd. You can't re-license the COB interpreter because it interfaces with the core engine, and so on.

The only way to re-license the engine is to track down every single contributor and get their permission, or gut out the code they contributed and re-write it.

(I am not a lawyer)

Re: FSF stance on GPL issues.

Posted: 29 Jul 2008, 20:44
by Forboding Angel
an okay, not to bad

followed by a pat on the back

followed by a serious kick in the crotch.

So basically we are all violating copyright. Well that's comforting. At least I'm in good company. Doesn't exactly make me too happy about it though.

Re: FSF stance on GPL issues.

Posted: 29 Jul 2008, 21:20
by Argh
The correct approach is probably to LGPL all engine code,
and distributed lua code (namely the widget/gadget handlers).
The bzflag project did the GPL -> LGPL conversion for all files
in their project some time ago for this very reason.
I agree with that, as one of the copyright holders. Good luck with that, it would solve a lot of problems, frankly.

Re: FSF stance on GPL issues.

Posted: 29 Jul 2008, 21:23
by trepan
I have no plans to push for it, no luck required.

Re: FSF stance on GPL issues.

Posted: 29 Jul 2008, 21:32
by Argh
I don't have access to a list of contributors or their contact information. I'd do the grunt-work, but I can't do the completely impossible :P

That said, I'm about as worried about the FSF taking up a GPL case against me for using a non-GPL license as I am about getting hit by lightning, tbh.

Re: FSF stance on GPL issues.

Posted: 29 Jul 2008, 21:35
by imbaczek
trepan wrote:The correct approach is probably to LGPL all engine code,
and distributed lua code (namely the widget/gadget handlers).
+1 for that while contributors are still reachable.

PS. props to KDR for taking the issue where it belongs.