Spring RTS Engine

svn keeps a nice log of everyone who has committed

1. committer != contributor
2. not everyone who contributed needs to follow this forum or check his mail or whatever; fortunately, it seems that most do (I hope...)

Isn't the contributor in the commit message or mantis in at least most cases?

Hopefully.

.cob can be run in TA, surely it doesnt become GPL just because you are writing it for Spring (the mod is just an archive, just a zip, its not like you are writing anything specifically for spring), or is the end user violating the GPL by running your mods non-gpl-compatible .cob with Spring? Id say thats more likely, since he is the one combining the non-GPL archive with the GPL program.

That's an interesting thought, actually. I think it's fair to say that a case could be made that all violations occur between end-users and Spring's developers, in that case.

I can see it now... "FSF sues Spring's playerbase for millions, in a class-action suit designed to win unspecified 'damages' for the developers...".

Meh, this whole thing is ridiculous. I'm just ignoring it, and have no plans to change my licensing. I've been through so much bullshit over the GPL with this engine that I'm just going to do what I wanted to do in the first place, and treat my work as an aggregate that has different licenses, and since I'm not planning on using any copyleft nonsense, it'll be simple to enforce...

Remember that the FSF is not an unbiased source - while they provide the GPL and so are certainly more experienced with GPL interpretation issues, they also have a stated aim to maximize the amount of stuff that is "free" (in their strange interpretation of the word "free") and they are more than likely to interpret the GPL in such a way as to infect the most stuff possible.

Saktoth wrote:.cob can be run in TA, surely it doesnt become GPL just because you are writing it for Spring (the mod is just an archive, just a zip, its not like you are writing anything specifically for spring), or is the end user violating the GPL by running your mods non-gpl-compatible .cob with Spring? Id say thats more likely, since he is the one combining the non-GPL archive with the GPL program.

A dll is just a dll by itself too.

The GPL does NOT apply to end users.

svn keeps a nice log of everyone who has committed

Spring development did not always use svn. The svn right now is started from the linux port of spring. Changes from the windows sourceforge cvs version where being ported to the linux svn branch.
And before that a private cvs server was used I think.

So to reach all contributors, you have to check all
http://sourceforge.net/projects/springrts contributors, the people on the team members page, and all contributors to the current svn.
It's possible but it will take long, and there will be unreachable people.

Argh wrote:That's an interesting thought, actually. I think it's fair to say that a case could be made that all violations occur between end-users and Spring's developers, in that case.

No, any modification made by a single entity (organization, user) to source code does not have relevance with the GPL until you distribute / publish it outside.

You have no obligation under the GPL to distribute or publish anything, but if you chose to distribute / publish, then everything that was combined with the GPL'd parts needs to be under the GPL as well.

Now, it sure isn't the end users who could have failed to comply...

Felix the Cat wrote:and they are more than likely to interpret the GPL in such a way as to infect the most stuff possible.

It is just as accurate to say that so many people like it that it spreads, because otherwise they'd work off a non-GPL'd stack.

.cob is just a language, i dont see how cob must be GPL just because the engine is.

I could distribute the .cob as scripts for an OTA version of my mod and then release a version of the mod without scripts and give instructions on how to combine the archives (or, make a dependency).

The notion that the GPL doesnt apply to end users is kind of absurd, half springs userbase are 'developers' of some sort or another, even if its just buggering with text files.

Oh well, in the end, we can just LGPL or PD all our lua and cob. That makes it GPL compatible without being so infectious.

Saktoth wrote:Oh well, in the end, we can just LGPL or PD all our lua and cob. That makes it GPL compatible without being so infectious.

Precisely.

Saktoth wrote:The notion that the GPL doesnt apply to end users is kind of absurd, half springs userbase are 'developers' of some sort or another, even if its just buggering with text files.

Then let's rephrase. It applies in full to them, but only has an effect when they are distributing.

Radtoo wrote:It is just as accurate to say that so many people like it that it spreads, because otherwise they'd work off a non-GPL'd stack.

lolwhat? it spreads whether you like it or not, and there is often no opportunity to work off of a non-gpl stack.

also

Saktoth wrote:.cob is just a language, i dont see how cob must be GPL just because the engine is.

I could distribute the .cob as scripts for an OTA version of my mod and then release a version of the mod without scripts and give instructions on how to combine the archives (or, make a dependency).

The notion that the GPL doesnt apply to end users is kind of absurd, half springs userbase are 'developers' of some sort or another, even if its just buggering with text files.

Oh well, in the end, we can just LGPL or PD all our lua and cob. That makes it GPL compatible without being so infectious.

That's not the interpretation provided by the FSF. Their interpretation is that if your cob scripts use Spring-specific features, and thus are a derivative work of the Spring engine, and applicable under the GPL. Also, you cannot license a derivative work of the GPL under the LGPL or the PD license, and the person that KDR contacted apparently believes that all these mods are "based on" it, and thus included. If they were not, the GPL would not apply to them. The way that LGPL/PD are compatible with the GPL is simply that you can incorporate LGPL/PD content within a GPL project without the licenses conflicting.

In my non-lawyer, humble position, that's a load of horsecrap. Calling a GPLd math library's "SQRT" function does not suddenly make your program a derivative work of somebody's implementation of square root.

It's not as bad as you think to relicense. Mozilla went through this a couple of years ago and what they did was initially compile a list of contributors. They then tried to directly contact each contributor to get permission to relicense their contributions. They then made a list of all the people they couldn't contact and made a web page asking people for ways to contact them. Eventually, the list became small enough and they had made enough good faith effort to contact them that they were able to go through with the relicensing. They did all this after legal consultation, so it's a reasonable bet that this is at least reasonably legally sound.

TL;DR So long as you make a good faith effort to contact everybody, you should be safe. If you want to be really paranoid, find any code by the people you can't contact and rip it out. I doubt most contributors to Spring thought that making it GPL would force all mods to be GPL too, they'll probably happily consent to an LGPL relicence.

Alternatively, you could make the Linux kernel argument. The only way to actually get any use out of Spring is to run it with a mod. This is just the same as with the Linux kernel. Linus Torvalds said that linking to the Linux kernel is actually using it, rather than deriving from it as the only way to use it is programatically. This is much the same with Spring. Spring is basically an RTS kernel and the mods are actually using it rather than deriving from it as that's actually the *only* way to use Spring. Deriving from something and using something is actually a rather blury distinction and, in all honesty, it's something that would have to be decided in court to know for sure. Relicensing to LGPL would remove that uncertainty, though.

Thanks for the post clearing it all up El Capitano.

Can you explain what the differences are to GPL and LGPL, i didn't think there was too much but apparently there are.

I dont see why we cant stipulate that future commits must be LGPL and mix LGPL and GPL source code in spring as long as we make clear whats which.

This way as contributors change their existing code to LGPL, we can eventually say that spring is LGPL save the off file which is GPL. This would still mean spring would need need to be distributed under the terms of GPL since it would essentially be under both licenses, but as long as the vast majority is LGPL and the lua interfaces are all LGPL then it shouldn't be an issue.

Well the vast majority of commits are to existing files...it'd get extremely unwieldy to have multiple licenses for each file.