Scope of the GPL for mods

KDR_11k · Post by **KDR_11k** » 27 Sep 2007, 09:50

Okay, another try. Moderators, please delete any comments not relevant to the topic or discussing the morality of sharing, we've seen how much people like to derail these threads.

From Neddie in the SDK thread:

I'm going to say this only once, because I spent the last few hours doing the research. There is no legal uncertainty in GPL. The text is deliberately arcane at points because it serves two masters, so to speak. The two purposes of the GPL license are thus; to protect public work as free use and to make work public and free use.

If you attempt to release a package with elements of GPL within it, according to the text of the license, the package must be GPL compliant. You may not license such a package with something which is incompatible with GPL. This is why any Spring distribution with Linux must be made entirely of GPL components. The package must be GPL, and thus the components cannot be licensed under other legal arrangements.

You can make a GPL package of content, but it will carry GPL with it into all derivative works. There is no ambiguity, this is the legal interpretation of the license. If you want something others may draw upon which does not do this, you have three major choices - Public Domain release with no license, CC-SA or an original license.

Here we have a big problem though: The gadget handler is GPL.

Assuming the above interpretation to be the correct one, any mod using the gadget handler or a gadget is therefore GPL (or more exactly, in violation of the GPL since the license cannot be automatically applied, you still have to do that by yourself), putting any gadgets in an OTA mod is a violation of the GPL as you cannot relicense OTA or third-party content.

Therefore, the request again:
Relicense the gadget handler.

The handler is essentially an engine feature that only has to be part of the mod because it's not included with the engine. If it was licensed under, say, BSD noone would have to worry about it affecting their mod's license. Or use some license that requires only the gadget handler itself to be open, not the whole mod.

If relicensing is not an option, put it in springcontent.sdz so a mod will not have to include the handler to get gadgets.

The other option for mods is to ignore the gadget handler and write everything into their own main code which makes the rules harder to separate and share with other mods.

Of course, if someone can guarantee that the GPL does not behave as described by Neddie then there are no worries but currently all we have supporting that stance is guesses.

Also scripters should not mindlessly mark their work as GPL by default, think about what exactly you want your license to be and use the one you want. It's clear that some of you are content with the choice of using the GPL but I don't think everyone thought much about the license they're going to put on their code.

Please keep discussions about morality in other threads, this is about legality and what can be done to preserve the freedom of license for mods.

SwiftSpear · Post by **SwiftSpear** » 27 Sep 2007, 10:42

Can the gadget handler specifically just be relicensed under CC or PD? GPL requires that you release any modification of a GPL piece under a free and open license, correct? Or does it acctually require that you release GPL modification under GPL, effectively causing mass poisoning?

TBH, I'm not sure it should really be an issue that's even being fought. Spring has been a GPL project for SOOOO long, my guess was that the decision to use GPL from the beginning was an attempt to have all content written for spring GPL compliant. Mod authors found loopholes around it, and released with whatever licence they pleased... but it's always been a huge diluting of what this project originally was. Perhaps it's just time to move forward and have all mods from this point forward on spring use a shared, agreed upon, GPL license, and just let that be that.

One MAJOR pro is that it would eliminate all these ridiculous copyright drama's every second week we have.

[edit] As I understand it it's essentially a null point anyways. We hold the orgianal spring copyright under the GPL license, if we choose never to enforce our licensing than it's effectively irrelevant that mod authors are violating our copyright, is it not?

KDR_11k · Post by **KDR_11k** » 27 Sep 2007, 10:55

The copyright holder can relicense his code as he wants, AFAIK only Trepan wrote the gadget handler so he can relicense it.

Whether mods should be forced into GPL really doesn't fit in this thread but my take is that if the modder wanted his mod to be GPL he would release it under GPL anyway, if he doesn't he won't. If the engine doesn't allow the modder to do what he wants the engine is not fit for his purpose and the mod has to be moved to another engine.

AF · Post by AF » 27 Sep 2007, 11:43

Modders did not find loopholes and have been in violation of springs licence for a very long time.

GPL is a copy left licence. All forks of GPL projects must be GPL, or use a GPL compatible licence. You cant mix and match, the entire project has to be udner a GPL compatible licence and you can onyl sue stuff that's also under a GPL compatible licence.

If trepans code counts as data under the GPL and as such is not subject to springs licence as spring doesn't link with ti it isnt a program or library and its interpreted code, for the same reason all lua cod isnt forced into GPL.

However because trepans code is GPL, any mods that attempt to make sue of it are invoking it as a library and as such are bound by the GPL.

Here is a list fo GPL compatible licenses and non compatible licenses in a nice chart:

http://en.wikipedia.org/wiki/List_of_FS ... e_licenses

As for creative commons, there is no creative commons license. Creative commons is an umbrella term for referencing a set of 5 ot 6 licenses.

http://creativecommons.org/about/licens ... e-licenses

The compatibility fo the various CC licences is unsure, although GPL and LGPL are also CC licences hence the CC-GPL and CC-LGPL licenses.
http://creativecommons.org/license/cc-gpl

So if a person says their work is CC, they're making it up, there is no CC licence, there are sets of licenses advocated by CC though, and you can see for yourself further up but unless they specify on fo them its as good as sayign I'm using the bshdydg licence.

For example the http://creativecommons.org/projects/founderscopyright/ is arguably icnompatible with GPL because of the 14 year restriction.

Whatsmore the GPL site explicitly states that the BSD license is incompatible: http://creativecommons.org/licenses/BSD/

Summary:

There is no such thing as The CC licence. There are licenses recommended by CC but no CC licence.

GPL and LGPL are licenses listed under Creative Commons

Not all CC listed licenses are compatible with GPL

KDR_11k · Post by **KDR_11k** » 27 Sep 2007, 11:52

I think for all intents and purposes a mod (or a map) is only data for the engine. After all it's a file you can choose to load when you start the program and any code it contains is executed by an interpreter in the engine, no part of the mod is ever sent to the CPU directly.

SwiftSpear · Post by **SwiftSpear** » 27 Sep 2007, 12:00

Agreed, specifically referring to "CC license" I was wondering if there was a less poisoning license than GPL that the gadget thing could be licensed under that would still be compatible with the project as a GPL release.

We can't relicense all of spring, but the complaint of modders is that they don't want to be forced into GPL, fair enough. Can we not relicense the gadget handler to a license that doesn't force modders into GPL? Is this possible, is the question?

Also, the use of massive bold lettering is a little excessive against a post where it was never even implied that CC was a single independent license...

[edit] Aye, current modding falls under the same ground as a .doc created in open office. It's simply a file used by the software, it's not a derivative work bound by the license.

AF · Post by AF » 27 Sep 2007, 12:02

Actually.....

In the context of the spring engine the mod is data. This means trepan can relicense the gadget handler to a non GPL compatible license if he wished.

But

Trepans gadget handler is data in the context of spring but it is a library in the context of the mod, a library under the GPL.

Then there's the logic that because trepans code is not a standalone library or program and requires the API spring provides, tis not data but a plug in and falls under the GPL licence.

The quickfix could be to relicence as LGPL.

smoth · Post by **smoth** » 27 Sep 2007, 12:10

I disagrea af. I met a guy who has his own gpl project. To release something under gpl all parts have to be gpl. However, code needs to be gpled if it uses gpled code as it's base. So no, "mods" do not need to be gpled unless the scripts link to a gpled library but scriptors libraries are PD not GPL. If I say wanted to do an independent release of gundam it would require gpl but I am not so that is not an issue.

GPLED scripts like the lua base file retain their gpl but they do not require a gpl of their own as they are not derivitives or linked to the code. They are not linked because they can exist without said library and should someone else have a different library with support for the spring lua scripts those scripts could use that. However, spring exe does have gpled libraries.

This does not extend into "mods" it would only extend to projects that desire an independent release as they will of course be using the code, or those that wish to be included with spring. However, "Mods" are released as "as is" packages and thus not under gpl. They are, strictly speaking just data on a server and in no way linked to spring

Erom · Post by **Erom** » 27 Sep 2007, 15:57

AF wasn't disagreeing with you on that point, Smoth. Mods are data, thus not "infected" with the GPL from the engine. However, mods with LUA _are_ infected by "linking" to the "library" of the Gadget Handler, which is also GPL.

No independent thought in this post, just summarizing to hopefully prevent misunderstanding.

AF · Post by AF » 27 Sep 2007, 16:33

In the context of spring a mod is data, for the same reason a lua script cant be forced into GPL because the lua parser is GPL.

And yes cob scripts compiled with scriptor are not subject to the licence scriptor has because scriptor is public domain. If it was GPL it would be the same as a GPL programs output is not subject to the GPL licence unless part of a GPL program or content is in that output.

However trepans lua gadget handler code is GPL. The gadget handler code is not in spring but on the lua side of the API divide. Trepans code calls the mods lua gadget, and thus the gadget is a plugin in the context of trepans code. Therefore the gadget must be GPL or it violates the licence of the gadget handler code. Any attempt to publicly distribute it under a non GPL compatible licence is a violation.

And since the gadgets are a component of the mod, the mod itself must be GPL. Programs using a nonGPL compatible licence cannot use GPL content. In this case the work around is to declare the gadgets as LGPL, which allows them to be used in nonGPL compatible programs and content under the premise that the LGPL components source is available and all modifications to it are made available among other things.

So to summarize:

Gadgets, widgets, gaia and lua<-> cob must use a GPL compatible licence.

Mods using GPL gadgets/widgets/lua gaia/lua cob must also have a GPL compatible licence, unless said gadgets/lua cob/etc use a licence that allows mixing non GPL compatible licences such as LGPL.

A GPL programs output is not subject to the GPL unless GPL content is in that output.

Code must use GPL compat licence if any of its components use or involve GPL content. This si not exclusive to the base of the program, any code snippet, library, API anything that uses GPL. There are no exclusion provisions save for standard Operating system components such as drivers, kernels, or subsystems such as graphics APIs.

smoth · Post by **smoth** » 27 Sep 2007, 16:43

no a gadget using code that is gpled does not mean the whole project needs to be gpled.

KDR_11k · Post by **KDR_11k** » 27 Sep 2007, 18:27

The gadget handler fetches the list of gadgets dynamically. GPL applies when code includes GPL code but what about a GPL script loading non-GPL code? I think that'd be pretty close to the Linux kernel module debate.

If the gadget handler is not part of the mod but part of the base directory it wouldn't automatically infect the mod, gadgets would fall under the kernel module question. That is, unless using package dependencies to load springcontent.sdz causes a GPL propagation. I don't think dynamic linking propagates the GPL though.

AF · Post by AF » 27 Sep 2007, 18:43

So the gadget is not a part of the project?

If my project uses a GPL component be that a picture function or even a single line fo code, my entire project has to be under a GPL compatible licence.

The GPL website is very explicit over this.

http://www.gnu.org/licenses/gpl-faq.htm ... ggregation

Combining two modules means connecting them together so that they form a single larger program. If either part is covered by the GPL, the whole combination must also be released under the GPL--if you can't, or won't, do that, you may not combine them.

GPL is a copyleft licence.

According to GPL any classes inheriting or deriving from a GPL clas smust sue a GPL compatible licence. This means all gadgets and widgets must use a GPL compatible licence or vioalte trepans GPL licence.

And in order to use GPL content you need to be using a GPL compatible licence.

http://www.gnu.org/licenses/gpl-faq.htm ... uleLicense

The GPL says that the whole combined program has to be released under the GPL. So your module has to be available for use under the GPL.

But you can give additional permission for the use of your code. You can, if you wish, release your program under a license which is more lax than the GPL but compatible with the GPL. The license list page gives a partial list of GPL-compatible licenses.

Its very very clear:

If a project uses a GPL component, the entire project must have a GPL compatible licence.

Operating system components are excluded. The licensee can also write an explicit exemption which must then be included in all copies of the exempted program with an entry for every file exempted.

Such an exemption can eb found here:
http://www.gnu.org/licenses/gpl-faq.htm ... atibleLibs

Also ti seems my LGPL solution thing might have been a little premature

I'd like to incorporate GPL-covered software in my proprietary system. Can I do this by putting a "wrapper" module, under a GPL-compatible lax permissive license (such as the X11 license) in between the GPL-covered part and the proprietary part?

No. The X11 license is compatible with the GPL, so you can add a module to the GPL-covered program and put it under the X11 license. But if you were to incorporate them both in a larger program, that whole would include the GPL-covered part, so it would have to be licensed as a whole under the GNU GPL.

The fact that proprietary module A communicates with GPL-covered module C only through X11-licensed module B is legally irrelevant; what matters is the fact that module C is included in the whole.

AF · Post by AF » 27 Sep 2007, 18:45

@KDR

linux kernel is exempt as its an OS component.

And no, the FAQ says clearly that a GPL plug in cannot be loaded by a non GPL compatible program or the licence of that plug in is violated.

BrainDamage · Post by **BrainDamage** » 27 Sep 2007, 18:59

AF wrote:
But if you were to incorporate them both in a larger program, that whole would include the GPL-covered part, so it would have to be licensed as a whole under the GNU GPL.

the part i highlighted states that you get the GLP propagation effect if you include the module AND the main part, so the example doesn't covers the case in wich you include just the module

more

The fact that proprietary module A communicates with GPL-covered module C only through X11-licensed module B is legally irrelevant; what matters is the fact that module C is included in the whole.

again, this is the case that you want to indirectly include module C (the main part), and not just stand-alone module B

AF · Post by AF » 27 Sep 2007, 19:10

So if I take a large number of spring classes and use them in a non GPL compatible project I'm ok because I didn't include the min spring program just a random spread fo GPL spring classes?

What your quoting is not from the licence but from the FAQ and its also out of context.

GPL is a copy left licence.
http://en.wikipedia.org/wiki/Gpl#Copyleft

Also aside from the above the mod is the main part, and the gadget is the GPL code thus the whole distribution needs a GPL compatible license.

AF · Post by AF » 27 Sep 2007, 19:14

http://en.wikipedia.org/wiki/Gpl#Common_misconceptions

"Any software created with GPL tools must be released under the GPL."
The program must be GPL only if it includes GPL source code or it is linked with a GPL library. For example, using gcc to compile proprietary software is allowed.

In this case the gadget is GPL source code and as such the entire mod must therefore be GPL'ed or use a GPL compatible licence.

Neddie · Post by **Neddie** » 27 Sep 2007, 19:17

I would also like to note this.

GPL is not infectious. You can choose to use GPL licensed materials, in which case you resign your derivative work to GPL licensing in turn, but you have a choice. You can learn from much of the beautiful material licensed under GPL without utilizing it, and you can decide not to include it.

BrainDamage · Post by **BrainDamage** » 27 Sep 2007, 19:18

did you read what i wrote?

1. i never said GPL is not copyleft

2. i left implicit after many people already stated that the module you want to include must be licesed by a GPL-compatible, more permissive license

3. the module must be selfcontained and not depend on the main part AT ALL , if ANY line of the main part would be included, then everything would be surely GPL, i left uncertain case otherwise

including relicensed spring classes wouldn't work because they depend on eachother, so you'll end up surely including a gpl class somewhere

what is said simply is: the case where you relicensed ALL bundled lua scripts in a way that they are self contained and not dependent from any GPL script/module is not the case covered by your referenced example, because it implies that somewhere you include a GPL licensed part wich would force everything to be GPL

AF · Post by AF » 27 Sep 2007, 19:25

Brain Damage wrote:
The fact that proprietary module A communicates with GPL-covered module C only through X11-licensed module B is legally irrelevant; what matters is the fact that module C is included in the whole.
again, this is the case that you want to indirectly include module C (the main part), and not just stand-alone module B

pah editing posts, make a new one.

Anyways this is another misquotation.

Module B is a bridge library in a GPL compatible licence with laxer restrictions, aka someone trying to use a loophole. Here a propriety module C tries to avoid changing licence so it can be used with GPL module A using a module B go between under a licence compatible with both.

But things get worse!!!

In order toe ven use lua gadgets you need to bundle the gadget handler code in LuaGadgets folder. This is definately GPL code, and because your distributing it in your mdo the entire mod has to be GPL compatible.

So even if the problem with GPL and gadgets is figured out the gadget handler itself is bundled which is a problem in itself.

And it gets even worse!!!

Trepans code is GPL, he can't just change its licence as he wishes, that's one of the reasons the GPL licence was created to begin with. Trepan could only change to a GPL compatible licence.

Spring RTS Engine

Scope of the GPL for mods

Scope of the GPL for mods