Spring RTS Engine

Posted: **05 Oct 2008, 18:05**

Bruce answered my first email, but he essentially skipped the whole issue of content vs. code, and merely said that, "If they ever agree on policy and want to make it possible for people to use their engine with commercial code without legal concerns, they can ask me for help in making the legal issues clear. Until then, stay away."

Ok, so private-code games for this engine are, effectively, a dead issue. Everything must be GPL, or must be compatible with the GPL. All fine and dandy, and I wouldn't be at all bothered by complying.

But it doesn't really answer the question, so I've asked for clarification:

Bruce:

Well, for obvious reasons, that's a very disappointing answer. Mainly, though, I'm puzzled- like the FSF, you've not really addressed my question head on. So, let's assume a few things:

1. I am perfectly willing to distribute the game and the engine separately, if that's what is required.
2. I have not been re-labeling Spring's work as my own.
3. I have not deliberately taken their source code and used it as my own.
4. The GPL notices are all intact, all "paperwork" is intact, etc.

In short, this isn't a typical GPL situation of some scuzzy guy seeing some neato GPL code, deciding that they want those features, and appropriating it. Are there no legal ways for me to sell my product legally, and prevent "forking" that includes my content? In essence, that's what this question revolves around. Not petty code theft.

And one last point. Your sentence: "If they ever agree on policy and want to make it possible for people to use their engine with commercial code without legal concerns" does not accurately reflect my situation. I do not want to keep my code private. Merely my content. Is that kosher?

Posted: **05 Oct 2008, 18:49**

you need to say CODE and not everything, content cannot be covered by the gpl as it is not meant to cover artwork. I am pretty sure stuff like artwork and sounds do not have to be GPL.

Posted: **05 Oct 2008, 18:56**

GPL for art IMHO effectively means public domain.

disclaimer: IANAL

Posted: **05 Oct 2008, 19:10**

Yes. The "whole game" argument needs to be settled, basically.

Either I can offer the source code to the game, sans content, for free to anybody who wants it, to satisfy the GPL's requirements, while withholding the rights to the content... or that would insufficient.

In the first place... I can raise venture capital, if anybody will bite, which they might, if that issue was clarified.

In the second... there is no future for commercial development of the engine. And practically no future for government work, educational work, etc., except for the most open projects where giving up the rights to the content would be just fine with the grantors.

In short... the answer I get to this means whether or not this engine has a practical future as a vehicle for serious development, or is a functional dead end. Since we don't have any other ways out of this box, given that many of the engine contributors don't seem to be willing to write an exemption for our works using the game (thus protecting their own code without poisoning ours), it seems that this is really the only hope left.

Posted: **05 Oct 2008, 19:14**

imbaczek wrote:GPL for art IMHO effectively means public domain

Nope, I am pretty sure GPL doesn't cover art. It was meant to cover source code. The art does not fall into the coverage of GPL as it cannot link to source code.

Posted: **05 Oct 2008, 22:38**

but it can also be considered it's own source code.

Posted: **06 Oct 2008, 03:06**

no it isn't.

Is a dll it's own source?

The source files for an image are not the art file. IF there is even a PSD.

Posted: **06 Oct 2008, 08:29**

We got an answer to the art thing before, since it does not include any active code and as such is not linked to the code it's unaffected, within a distribution it counts as an aggregation. The worst case situation is that all code parts in the mod must be GPL and that's only if you assume that the GPLv2 can apply to independently distributed mods. The art is NEVER subject to the GPL, there's a data exemption and the FAQ specifically mentions that the GPL is not designed for non-code works and you should apply other licenses to the con-code parts.

Posted: **06 Oct 2008, 09:20**

It would be helpful to return the discussion to the best way of formally clarifying where the line is between GPL'ed and non-GPL'ed code. This seems to be the greatest cause of issue. Personally I think the GPL is pretty clear but it would be beneficial to officially remove all uncertainties.

From the opinions put forward so far nobody, including the FSF and the GPL, seems to be asking for "data" (ie, artwork, sounds, etc) to be GPL'ed with the code. I agree with previous suggestions that the simplest way for everybody to get what they want is to finalise an agreement on the meaning of "data" and "seperate program" in Spring.

Firstly the GPL FAQ has various sections dealing with this. I won't reprint but it's worth a read if you haven't already. It's very clear from the language that the license is only concerned with "code" but it doesn't go as far as precisely defining code in unambigous terms.

They actually do address the status of code used with an interpreter (ie, Lua). It makes it clear that the code is actually considered to be data as long as it doesn't directly call functions from GPL'ed libraries. In the case of widgets, gadgets, etc Spring provides a large number of library functions so a Lua widget that uses Spring or VFS or Game is considered code.

TDF is simple control variables and therefore data. I can't speak for COB because its binary and I don't know what the "source" looks like.

Considering the above I propose the following be added to an additional license file called WAIVER which will be GPL compatible by offering ADDITIONAL rights:

Code: Select all

For the purposes of GPL compliance the Spring community, consisting of its majority copyright holders, has agreed that the following definitions apply:

"data": Data is exempt from the GPL however it is sometimes difficult to distinguish data from code. The following are considered code: C++ source files and headers, Java code, Widgets and Gadgets. All other files are data.

"seperate program": Some content that is considered code may still be exempt if it is a seperate program. For the purpose of Spring licensing "seperate program" means any code or data loaded by the mod system, regardless of how they are aggregated. Specifically stand-alone DLLs (like a 3rd-party font library) would be exempt provided they only communicate with a Lua widget or gadget and do not directly link or incorporate parts of the Spring engine. This exemption does not apply if the mod package includes GPL'ed code.

Any file that can be reasonably considered to be either data or a seperate program under the definitions given above will be granted a waiver from the GPL restrictions and may be re-licensed under any terms provided the author has clearly indicated that a different license applies.

Does the above accurately reflect the problem being solved and provide a solution? Is it too loose or too strict?

Posted: **06 Oct 2008, 10:18**

The scripts in map archives are no more subject to GPL than cob scripts, even being considered in some places "lower intellectual property" and thus not subject to copyright at all. They are on par with the complexity of .tdf files. The rest of the map is derived from images generated as artwork by mappers, and the rights to that are to be disposed as the mapper sees fit.

Lua as a language is distributed under a GPL v2 compatible though less restrictive license, which I suggest we apply to the scripts themselves. We cannot enforce GPL v2 over all lua scripts by default, we can only enforce compatibility.

In light of the above, your definition of data needs certain changes before it can be adopted, but I believe it is a good start. If you revise your version, I will gladly review the next iteration. I would revise it myself, but as you did not recognize my prior post I do not know whether you will recognize my revisions. I do not make these suggestions idly, however.

Posted: **06 Oct 2008, 14:55**

I do not see why ANY of the code in a mod should not be PD. Artwork I can see wanting to maintain ownership but nothing I have seen in spring is good enough to HAVE to be closed source. So what if a company steals your bos file/lua file, who cares. It's not like anyone here has created a new form of shel sort or something. None of this is master/doctorate level thesis work type shit. It is just movement animations and some lua.

So why would anyone CARE if people use their code? I can understand spring being GPL, but jesus, none of the mods/games have anything that should not be shared.

Posted: **06 Oct 2008, 15:48**

shared yes, but not given away. when I GPL something, that's basically me saying "do anything you want, but share your work too." I do not want anyone to take my work, improve it and sell it without sharing changes.

if you don't care about improvements, but want recognition, there's the BSD attribution license which says "do whatever you want, but if you use it or change it, tell everyone that I made a part of this, too."

Posted: **06 Oct 2008, 17:57**

I have written more interesting code in college. Bos scripting is at best introductory level coding. Lua is complex and I really need to learn it beyond just being able to read and modify it but I suspect my attitude will not change when I start writing more lua from scratch.

I can understand when it is something like a lobby or spring engine stuff, you want them to share alike. I suppose some people would also want to see people share improvements to lua stuff. However, because of the way spring works the lua code can merely be read from the 7zip archive and you then write your own version of that correction/feature. Because the mod/game files are open to viewing, there is no way to truely put constraints on your source, it is out there and someone could very well change it. On the same token you can read the changes and then make them to your code and give the other guy the finger.

Something like spring or the lobbies are released in a form that makes reading the code prohibitively difficult. That is why I think trying to close source one of the projects is fucking stupid. Spring would have to be decompiled into a pile of PITA to read code. Mods can be extracted and read just fine.

There is nothing stopping me or anyone else from reading someone's code and then using what we learn. Sure no skill hacks cannot pull it off but anyone worth it as a coder can just read the shit and take the knowledge. Licenses on mods are fucking stupid when we are talking about the code.

^ all of the above all is talking about code, not art assets or sounds.^

The only reason we are having this debate/discussion/IKNOWITALL is because we, the content creators don't want to slap an unnecessary license on our projects. For something like IW/GRTS we cannot put our art assets as anything other than closed license because we have to protect the IP we do not own. Other projects like pure want to protect the art assets because they represent the project identity. Ultimately it has been said many times YOU CANNOT GPL ARTWORK/SOUNDS but that still doesn't mean that we do not want to look into other issues like the whole archive having to be gpl(which is not true).

So what if the code has to be GPL compatible, I could if I wanted take whatever implementation I want from a project because I can code. Some things can only be written one way others can be written many ways and sometimes end up better code. If someone steals your lua and improves it just steal their improvements back.

Posted: **06 Oct 2008, 18:26**

smoth wrote:So what if the code has to be GPL compatible, I could if I wanted take whatever implementation I want from a project because I can code. Some things can only be written one way others can be written many ways and sometimes end up better code. If someone steals your lua and improves it just steal their improvements back.

I'm not sure if I understand you well, but you essentially described the idea of GPL here. It's been designed for exactly this in mind.

Posted: **06 Oct 2008, 19:10**

GPL also makes whatever you write that even MINORLY utilizes the functionality of said item GPL. So if I wrote an amazing app that did all kinds of killer shit and use a GPLed library to draw just the startscreen, that entire app has to be gpled because it has linked to a GPLed dll. That is fucking dumb.

it would be one thing if gpl only required the specific code changes or the specific code that utilizes the GPLed library but it doesn't. The moment your project links that GPLed file you have to open the WHOLE thing which is bullshit.

I know gpl was meant basically be sure that if someone took your coded and modified it that you could get the improvements. We all know that Imbaczek, what we object to is the fact that GPL "infects" the source that touches one of it's archives/source. It is the viral nature of GPL that pisses people off.

In the spring mod/game format there is no need to gpl the files, they ARE more than most GPL projects open. Even cobs can be decompiled with scriptor. That was my point, there is no need to put a license on your mod/game source. It is readily accessible and there is no way you can keep people from reading it. So why even put a license, by releasing a project or even letting someone see it people can steal code right away. The game/mods are released with all code visible and ready for consumption. The only difference that PD has from a closed license in the mod sourcecode files is that the person taking the feature merely has to re-write it. THAT IS IT, that is all they have to do, rewrite the closed source project's file. Which is why I think it is stupid to have to worry about a license with a mod/game.

this is the mod/games forum so this discussion ONLY extends to that area. The stuff we content creators are making. It doesn't have anything to do with the engine etc. The only thing that we are discussing with the engine/mod stuff is what to do if a mod wants to include the spring files as well so they can expedite and simply the install for users.

Posted: **06 Oct 2008, 19:27**

ok, ok. a lot of people's afternoons were wasted discussing GPL, not only on this forum. viral nature of GPL is in there by design; if you explicitly don't want to infect other software with it, there's the Lesser GPL which contains GPLness to a single library and/or file (dunno exactly).

anyway I don't intend to be participate in this flamefe^Whot topic, I was just passing by

Posted: **06 Oct 2008, 19:30**

I've exchanged more email with Bruce. If anybody wants to see the full back-and-forth, let me know, but basically he neatly closed all loopholes for code- it must be GPL, or a license that is compatible.

But the content... that's another story. The key line from his side of the dialogue is in bold italics.

Bruce:

Thanks very much, for spending the time on the detailed replies. We're really in very novel ground here, I really appreciate this.

Basically, the issue hasn't been hostility to making a profitable project, period, the only question has been to what extent the author becomes a rights-holder under the GPL (and, of course, transfers those rights to others). I'm certainly not trying to screw over our coders- if anything, my desire would be to become profitable, and then hire coders to contribute to the GPL source (not a fork, mind you!) which would both enhance my game and provide more value-added down the road for future projects. Much hinges upon whether or not I can legally sell the game at all, basically. This could be a new model of game development. My questions are mainly in response to the (few, and not engine contributors) people who have said that the GPL basically puts all work in a game into GPL. If the answer to that is, "no", then the question becomes one of whether or not those non-derivative assets have enough value in and of themselves to make a profitable product a reality.

I think in this case the content is interpretive code. The issue is whether that content is derivative of the GPL component, or is only "input" to the GPL component. And this is still up in the air.

That's the key right there. We're not talking about "prior art" in some sense, or work that exists only with the software's direct interaction. We're talking about non-proprietary data. Bitmaps, 3D meshes, sound files, and music. None of them was made using this software, all of them can be used outside the software, even "correctly" used, in the conventional sense.

So, yes, I would have to conclude that they constitute "input", and are merely data- data that I can license seperately of the engine and my own code (which, as you've already confirmed, would be GPL).

At any rate, I think that's a safe enough position to move foward and sell the game, when it's complete enough to sell.

The coders will be satisfied, I think, because I've just created a potential marketing avenue. They'd merely have to find people to make content that they could license, and partner with them to make products. And nobody will be able to complain about people acting as "technology vampires", because we're all contributing to the pool collectively.

I don't think anybody will want to sue me, under those terms. It's a win-win- if I innovate, everybody can have that innovation, if I create content, it adds value to my project. If anything, they'll be quite happy that we've reached a situation that creates a workable compromise where everybody can make money while feeling virtuous.

If you see a huge hole in that, or wish to talk to the Spring Engine's core developers about it, then please feel free to let me know, or simply drop in at our website, spring.clan-sy.com. You certainly don't have to assume that I'm saying the truth when I say that this probably will make the vast majority of us quite happy, but I can assure you that it probably will.

Thanks very much,

Greg Wolfe

Anybody see any massive holes in the logic laid out below? Anybody want to sue me, etc.?

Or are we all reasonably satisfied, and I can proceed, so long as my code (including CEG) is GPL?

So far as I can see, that removed the legal impediments to making games we can sell, to finding foundation grants, to finding venture capital... etc. I think this represents a massive win-win for everybody. Does anybody have further objections?

Posted: **06 Oct 2008, 19:42**

you could make your bos/ceg/lua PD and be done with it. It really depends on the purpose you are going for. Not that I would argh but I could always rewrite something that you did under gpl and possibly make improvements after I have learned the tricks needed to execute whatever the code was doing.

So why bother protecting code that is useless outside of spring? I guess that is the main thing I get confused about.

Posted: **06 Oct 2008, 19:45**

For the credit requirement, Smoth. If the game doesn't sell... it can still get me a job.

Posted: **06 Oct 2008, 19:59**

Ah, well have you credited all individuals who have aided with pure? I am not sure who did what still.

as far as job stuff:
In all honesty, I suspect that if you setup a site for pure and talk about all the accomplishments you achieved in the creation of pure and all the collaboration it will help you. However, having read some of your code in the past you do tend kill a fly with a cannon ball. That is one area that I see which will hurt you if they ask you to generate some code as part of the interview. Another thing is that your site is very old and reminds me of a highschool geocities page. Clean it up and most importantly make an "about me" page where you list achievements and showcase your work. Remember that your webpage is a way to sell yourself and put the HR person in a controlled realm where you can showcase you in a way that is advantageous for you... gotta get back to work.

Spring RTS Engine

FSF stance on GPL issues.

Re: FSF stance on GPL issues.

Re: FSF stance on GPL issues.

Re: FSF stance on GPL issues.

Re: FSF stance on GPL issues.

Re: FSF stance on GPL issues.

Re: FSF stance on GPL issues.

Re: FSF stance on GPL issues.

Re: FSF stance on GPL issues.

Re: FSF stance on GPL issues.

Re: FSF stance on GPL issues.

Re: FSF stance on GPL issues.

Re: FSF stance on GPL issues.

Re: FSF stance on GPL issues.

Re: FSF stance on GPL issues.

Re: FSF stance on GPL issues.

Re: FSF stance on GPL issues.

Re: FSF stance on GPL issues.

Re: FSF stance on GPL issues.

Re: FSF stance on GPL issues.

Re: FSF stance on GPL issues.