FSF stance on GPL issues.

FSF stance on GPL issues.

Discuss game development here, from a distinct game project to an accessible third-party mutator, down to the interaction and design of individual units if you like.

Moderator: Moderators

Post Reply
User avatar
KDR_11k
Game Developer
Posts: 8293
Joined: 25 Jun 2006, 08:44

FSF stance on GPL issues.

Post 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.
Last edited by KDR_11k on 29 Jul 2008, 18:49, edited 1 time in total.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: FSF stance on GPL issues.

Post 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.
Last edited by Argh on 29 Jul 2008, 18:55, edited 1 time in total.
User avatar
KDR_11k
Game Developer
Posts: 8293
Joined: 25 Jun 2006, 08:44

Re: FSF stance on GPL issues.

Post 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".
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: FSF stance on GPL issues.

Post 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.
User avatar
Peet
Malcontent
Posts: 4384
Joined: 27 Feb 2006, 22:04

Re: FSF stance on GPL issues.

Post 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.
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Re: FSF stance on GPL issues.

Post 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.
User avatar
KDR_11k
Game Developer
Posts: 8293
Joined: 25 Jun 2006, 08:44

Re: FSF stance on GPL issues.

Post 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...)
User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14673
Joined: 17 Nov 2005, 02:43

Re: FSF stance on GPL issues.

Post 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. :?
User avatar
Pxtl
Posts: 6112
Joined: 23 Oct 2004, 01:43

Re: FSF stance on GPL issues.

Post 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.
User avatar
Pxtl
Posts: 6112
Joined: 23 Oct 2004, 01:43

Re: FSF stance on GPL issues.

Post 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.
User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14673
Joined: 17 Nov 2005, 02:43

Re: FSF stance on GPL issues.

Post 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.
trepan
Former Engine Dev
Posts: 1200
Joined: 17 Nov 2005, 00:52

Re: FSF stance on GPL issues.

Post 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 ;-)
User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14673
Joined: 17 Nov 2005, 02:43

Re: FSF stance on GPL issues.

Post 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?
trepan
Former Engine Dev
Posts: 1200
Joined: 17 Nov 2005, 00:52

Re: FSF stance on GPL issues.

Post 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.
User avatar
Pxtl
Posts: 6112
Joined: 23 Oct 2004, 01:43

Re: FSF stance on GPL issues.

Post 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)
User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14673
Joined: 17 Nov 2005, 02:43

Re: FSF stance on GPL issues.

Post 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.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: FSF stance on GPL issues.

Post 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.
trepan
Former Engine Dev
Posts: 1200
Joined: 17 Nov 2005, 00:52

Re: FSF stance on GPL issues.

Post by trepan »

I have no plans to push for it, no luck required.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: FSF stance on GPL issues.

Post 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.
imbaczek
Posts: 3629
Joined: 22 Aug 2006, 16:19

Re: FSF stance on GPL issues.

Post 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.
Post Reply

Return to “Game Development”