FSF stance on GPL issues. - Page 4

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

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

Re: FSF stance on GPL issues.

Post by KDR_11k »

Radtoo wrote:Simply, you apparently want to take this work, modify it, and get full control over the combination created (meaning including the original work), and you think you're justified to demand this.
When an author releases his work under a license permitting that then he damn well intends for that to be possible. We aren't taking Spring, we aren't modifying it, we aren't claiming anything about the combination, we make modules that plug into Spring and no matter how we lock them down it does not affect Spring itself in the least.

Saying the GPL isn't bad because EULAs are worse is like saying the Holocaust wasn't bad because the Soviets did worse. It's bad, no matter how many worse things there are.

The GPL is nowhere near unambiguous when it comes to things like Spring mods. Hell, it's hard to tell if a license for the engine even has the right to affect these mods.

Smoth just wants to put "use it but put me in the credits" as his license, the GPL prevents him from doing that by forcing him to add sharealike terms and garbage like that.
El Capitano
Posts: 156
Joined: 13 Oct 2006, 10:48

Re: FSF stance on GPL issues.

Post by El Capitano »

How is the GPL ambiguous? The only ambiguity is from the term "derived work" and that is a problem with *all* copyright because it's never truly clear what a derived work is and thus whether that work is bound by the license for its inspiration/source. For example, linking is not always considered deriving. To elaborate, if you have a program that does a dlopen() on a GPL library but still continues to function but with reduced functionality if that GPL library isn't present, is it a derived work? If you write a program that links to a GPL library but later write a replacement for that GPL library, does your project suddenly stop being a derived work? Technically, I think the answer is yes, but intellectually, probably not. Legally, well, heh, it's all up in the air.

Apply these questions to Spring. There's no way to actually "use" Spring other than writing mods for it. The mods themselves are using Spring as a platform much the same way that Linux programs use the Linux kernel as their platform. Still, mods are dependent on Spring, but at the same time, Linux programs are dependent on Linux. Unfortunately, because copyright is all about trying to make laws governing abstract concepts, it's all dependent on what a judge says.

Still, when all is said and done, if the intention of the developers is to allow mod developers to use whatever license they wish, then there's no harm in relicensing Spring as LGPL and it does help to remove some legal questions.
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: FSF stance on GPL issues.

Post by smoth »

Radtoo wrote: It isn't. It is very, very unambiguous, both the legalese and the "simple human-readable" explanations.
People can be wrong and/or not have read the license.
Humbug, there are at LEAST 20 pages of discussion in this subforum about what is an AGGREGATE.

simply put, I just want to say, you can use this for whatever just give me a shout out(and that is just a request). Let other know where they can get the stuff and past that I don't care.

however, as GPL is a lot of crap to read I cannot just throw that at them. The great thing about creative commons is that THEY provide a summary for the end users of my content. I think telling a user, you can use my stuff but you cannot use it until you GROC THE GPL is asking too much.

To me gpl has always been fairly clear and the latest findings somewhat go with my interpretation but the community as a whole including several others have felt it was unclear and as such I call it ambiguous
El Capitano
Posts: 156
Joined: 13 Oct 2006, 10:48

Re: FSF stance on GPL issues.

Post by El Capitano »

As I've just told you, the GPL is not ambigious. If you create a derived work of a GPL work, then your work must be distrubuted under the terms of the GPL or a more permissive license. They use the term "derived" and talk about aggregates because that's what the law requires. If you want to piss and moan about how "aggregate" and "derived" are too vague, go piss and moan at the lawmakers. Honestly, you only have yourselves to blame for this, stop trying to point fingers at the GPL when you wanted the LGPL.
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6241
Joined: 29 Apr 2005, 01:14

Re: FSF stance on GPL issues.

Post by FLOZi »

Yeah, because the current (content making) community chose the GPL license.

Oh wait...

:roll:
User avatar
Evil4Zerggin
Posts: 557
Joined: 16 May 2007, 06:34

Re: FSF stance on GPL issues.

Post by Evil4Zerggin »

Radtoo wrote:
Evil4Zerggin wrote: Is that a fair assessment of the GPL? Probably not. But is that the vibe that I keep getting every time licensing drama flares up? Damn straight it is.
Yet, not talking about it is no good. By default, only a copyright holder can redistribute, sublicense, modify. Giving people a license actually guarantees them that they're out of trouble, so it has to be done.
... and also raises the possibility of the FSF getting involved in here in a way that most of us would find quite undesirable.

This has very little to do with what is legal (not that the several threads on this forum have been able to decide what that is). More than it is a free project or an open source project, this is a volunteer project. I would imagine most of us do not have the means or motivation to pursue legal action in regards to a project which we a) pursue in our free time and b) receive no profit from, which means if the law gets involved, we will most likely be on the wrong side of it.
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: FSF stance on GPL issues.

Post by smoth »

Oh ho, but nothing I am doing is derivative. It is either entirely origonal(which is what I am giving away) or fan art. The point being that my entirely origonal stuff is not derivative. If anything the point that is argued is what is LINKED. Derivative is an easy term but LINKED is not, and aggregate is not.

You can huff and puff all you want but the general community here is split on their understanding of the GPL and that tells me that most people will feel unsure about their interpretation. What is worry some to me about that situation is not for me, I am fine, I want the people who could utilize my scripts or models to have no difficulty.

We the content creators have little choice on what license we use. We are forced into GPLing our scripts and by the grace of good fortune not forced to GPL our art. However, for our art to be included in distro's it has to be GPL compatible just because it makes the gpl fearful people at ease.

Again, the point you guys are missing is that my understanding is fine, I am clear on GPL. Others are not and I do not expect someone to GROC the gpl to use my content. So in order to make the content accessible by people other than lawyers I am forced to use PD.
User avatar
Neddie
Community Lead
Posts: 9406
Joined: 10 Apr 2006, 05:05

Re: FSF stance on GPL issues.

Post by Neddie »

A change of license for the engine is in order, and this discussion no longer belongs in the realm of content creators.
User avatar
Felix the Cat
Posts: 2383
Joined: 15 Jun 2005, 17:30

Re: FSF stance on GPL issues.

Post by Felix the Cat »

It constantly amazes me how obsessed with legal issues this community is, when 90% of what goes on in Spring is technically probably (but not necessarily) (but most likely) illegal.
User avatar
Neddie
Community Lead
Posts: 9406
Joined: 10 Apr 2006, 05:05

Re: FSF stance on GPL issues.

Post by Neddie »

Felix the Cat wrote:It constantly amazes me how obsessed with legal issues this community is, when 90% of what goes on in Spring is technically probably (but not necessarily) (but most likely) illegal.
I'm just trying to guide things toward legality and to nurture things which are legal among the elements I enjoy.

What amazes me is how blind or biased some of the voices which contribute are, caught up in ideals and delusions. Maybe they would understand the complexities of situations and relationships better if they had suffered for their na├â┬»vet├â┬®, but I cannot wish that in good faith upon anybody. I wouldn't bother with all these legal issues if I were of such weak and resentful character.
Radtoo
Posts: 50
Joined: 12 May 2006, 14:21

Re: FSF stance on GPL issues.

Post by Radtoo »

neddiedrow wrote:A change of license for the engine is in order, and this discussion no longer belongs in the realm of content creators.
No, actually it does, as it would make just as much -if not more- sense to simply comply.

You may also not be likely to get a different license, as Upspring didn't take off, amongst other reasons because people didn't want to change the license.
smoth wrote:However, for our art to be included in distro's it has to be GPL compatible just because it makes the gpl fearful people at ease.
Almost all distros only require a license that permits them to be able to redistribute the work, if its artwork and the like. Unlike with code, it wouldn't cause them much trouble not being able to modify it.

Most actually go with the FSF's stance that on artwork, rather than code, the GPL is even difficult to interpret, and they prefer a license different from the GPL for artwork (like creative commons)!

Yet, engine-linked code in mods should be open sourced and possibly GPL'd to meet the policy of most of the distros, yes... they don't want to have to deal with not being able to patch things, and more.
Felix the Cat wrote:It constantly amazes me how obsessed with legal issues this community is, when 90% of what goes on in Spring is technically probably (but not necessarily) (but most likely) illegal.
The engine should be clean so far, and most mods also are.
The mods that use TA's artwork (textures etc.) and units-as-a-whole may still be at risk, but that's about it.
El Capitano
Posts: 156
Joined: 13 Oct 2006, 10:48

Re: FSF stance on GPL issues.

Post by El Capitano »

smoth wrote:Oh ho, but nothing I am doing is derivative. It is either entirely origonal(which is what I am giving away) or fan art. The point being that my entirely origonal stuff is not derivative. If anything the point that is argued is what is LINKED. Derivative is an easy term but LINKED is not, and aggregate is not.
The GPL (v2 at least, as that's what Spring uses) does not contain the word "link" once. The reason is that "linking" has no legal definition. The GPL talks about derived works because that is how copyright law works. If your work is not derived from any other copyrighted work, then you are not bound by the GPL.
You can huff and puff all you want but the general community here is split on their understanding of the GPL and that tells me that most people will feel unsure about their interpretation. What is worry some to me about that situation is not for me, I am fine, I want the people who could utilize my scripts or models to have no difficulty.
The *only* area of contention is whether mods are using Spring or deriving from it. If mods are simply using Spring, the GPL has zero effect on them. If the mods are deriving from Spring, then the GPL "infects" them. Sadly, the only way to know for sure is to go in front of a judge. Thus, it would probably be easier and safer legally to simply relicense Spring to LGPL.
We the content creators have little choice on what license we use. We are forced into GPLing our scripts and by the grace of good fortune not forced to GPL our art. However, for our art to be included in distro's it has to be GPL compatible just because it makes the gpl fearful people at ease.
Wrong.
Again, the point you guys are missing is that my understanding is fine, I am clear on GPL. Others are not and I do not expect someone to GROC the gpl to use my content. So in order to make the content accessible by people other than lawyers I am forced to use PD.
Obviously you are not clear, because ordinary use does not bind you to the GPL. Distributing a derivative work (using the legal definition of derived) does.
User avatar
KDR_11k
Game Developer
Posts: 8293
Joined: 25 Jun 2006, 08:44

Re: FSF stance on GPL issues.

Post by KDR_11k »

He means "use in their own mods" in that last quote.
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: FSF stance on GPL issues.

Post by smoth »

Most actually go with the FSF's stance that on artwork, rather than code, the GPL is even difficult to interpret, and they prefer a license different from the GPL for artwork (like creative commons)!
Creative commons cannot work with GPL. I do lament this. Hence my "baaaaaaaaaaw, I have to use PD."
El Capitano wrote:The GPL (v2 at least, as that's what Spring uses) does not contain the word "link" once. The reason is that "linking" has no legal definition. The GPL talks about derived works because that is how copyright law works. If your work is not derived from any other copyrighted work, then you are not bound by the GPL.
e ├óÔé¼┼ôCorresponding Source├óÔé¼┬Ø for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.
HUR HUR...

El Capitano wrote:The *only* area of contention is whether mods are using Spring or deriving from it. If mods are simply using Spring, the GPL has zero effect on them. If the mods are deriving from Spring, then the GPL "infects" them. Sadly, the only way to know for sure is to go in front of a judge. Thus, it would probably be easier and safer legally to simply relicense Spring to LGPL.
Except that there is no content we derive from... I will explain further how it is a concern though.
El Capitano wrote:
We the content creators have little choice on what license we use. We are forced into GPLing our scripts and by the grace of good fortune not forced to GPL our art. However, for our art to be included in distro's it has to be GPL compatible just because it makes the gpl fearful people at ease.
Wrong.
No, RIGHT. When I made the map Islands in war for the spring engine, the models and art needed to be GPLED just to be safe. To this date I still have to source files readily available.
El Capitano wrote:
Again, the point you guys are missing is that my understanding is fine, I am clear on GPL. Others are not and I do not expect someone to GROC the gpl to use my content. So in order to make the content accessible by people other than lawyers I am forced to use PD.
Obviously you are not clear, because ordinary use does not bind you to the GPL. Distributing a derivative work (using the legal definition of derived) does.
See the point you are missing is that it was for OTHERS and not me. I have content that I do and I want to share it. I merely wanted to be remembered, of course, I cannot have that.

Onto my explanation. Spring is an engine and no we do not derive the engine, our projects are just content packages. However, with the introduction of LUA/lua-cob we ran into a sticky situation. The cobs can make lua calls and thus are linking to GPLed code. This means that the scripts need to be GPL compatible. Now the art doesn't necessarily have to be GPL compatible.

However, in order to ensure that future people can utilize it I am forced into PD. See, I have no problem sharing and I am sure others do not either. However, the licensing stuff is iffy, prior to all of this a mere copyright notice at the bottom of a site was enough. Permissions can be granted just fine. However, in order to play it safe and remove concerns for the end user I am forced to use PD. Any script that connects to a gpl-ed lua file or a lua file that makes calls to a gpl-ed lua file has to be gpled. This means that scripts have to be gpl compatible also. Since having a copyright restricting license does not allow for future gpling if needed I have to be certain all donations are GPL compatible. Further more, any persons wanting to share content cannot do so under non-gpl compatible licenses. This means that the only way to allow your items to be readily used it to actually PD it.
El Capitano
Posts: 156
Joined: 13 Oct 2006, 10:48

Re: FSF stance on GPL issues.

Post by El Capitano »

smoth wrote:HUR HUR...
OHAI, I see you quoted the GPL 3, despite the fact that I explicitely talked about the GPL 2, because Spring is under the GPL 2. Go read Spring's license, it doesn't say "link" once.
Except that there is no content we derive from... I will explain further how it is a concern though.
Legally speaking, derive and use have a blurry separation. It's the old "is this data or code" argument. For example, is a Word document data or code? Is an HTML file data or code?
No, RIGHT. When I made the map Islands in war for the spring engine, the models and art needed to be GPLED just to be safe. To this date I still have to source files readily available.
No, maps are made to a spec and Spring loads map files conforming to the spec. Spring may be the only implementation of that spec, but that does not mean it gets to infect map files. For example, if I write a program that can load and display Spring maps, does that mean your maps no longer have to be GPL?
See the point you are missing is that it was for OTHERS and not me. I have content that I do and I want to share it. I merely wanted to be remembered, of course, I cannot have that.
But there's the rub. Your map doesn't actually derive anything from Spring. It's just a map. You don't execute the map, Spring does, using it as data. There's no 2-way relation between Spring and maps. With mods, it's slightly different because mods include code that then goes and executes functions directly in the Spring engine.
Onto my explanation. Spring is an engine and no we do not derive the engine, our projects are just content packages. However, with the introduction of LUA/lua-cob we ran into a sticky situation. The cobs can make lua calls and thus are linking to GPLed code. This means that the scripts need to be GPL compatible. Now the art doesn't necessarily have to be GPL compatible.
We're back into the "what is code" discussion again. Mods, for example, are built around implementations of Spring, using the features it provides. However, do they derive, or just use features Spring provides? It's *never* that simple to tell. Artwork's easy to demonstrate as not derived, because you can rip the artwork out and replace it with an equivalent file that's basically a white tile. The product will still function, it'll look crappy, but function.
However, in order to ensure that future people can utilize it I am forced into PD. See, I have no problem sharing and I am sure others do not either. However, the licensing stuff is iffy, prior to all of this a mere copyright notice at the bottom of a site was enough.
Hardly. Most online copyright notices either said "all rights reserved" or weren't worth the paper they were written on.
Permissions can be granted just fine. However, in order to play it safe and remove concerns for the end user I am forced to use PD. Any script that connects to a gpl-ed lua file or a lua file that makes calls to a gpl-ed lua file has to be gpled. This means that scripts have to be gpl compatible also. Since having a copyright restricting license does not allow for future gpling if needed I have to be certain all donations are GPL compatible. Further more, any persons wanting to share content cannot do so under non-gpl compatible licenses. This means that the only way to allow your items to be readily used it to actually PD it.
It is nowhere near as black and white as that, as I've shown with my Linux kernel examples. All Linux programs *must* link to the Linux kernel and anything non-trivial *must* ultimately call into the Linux kernel. Yet they don't have to be GPLed.
User avatar
KDR_11k
Game Developer
Posts: 8293
Joined: 25 Jun 2006, 08:44

Re: FSF stance on GPL issues.

Post by KDR_11k »

The kernel gets a special case exemption.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: FSF stance on GPL issues.

Post by Argh »

No, maps are made to a spec and Spring loads map files conforming to the spec. Spring may be the only implementation of that spec, but that does not mean it gets to infect map files.
The exact same words can be used with Lua and BOS.

Basically, he tried to act as if Spring was Pliant.

It's a ludicrous argument, and would never survive in court.

Lua is not a GPL language, neither is BOS.

Therefore, the situation is not equivalent. In theory, we are running languages that could (and demonstrably have) run in non-GPL environments.

So the arguments made by anybody trying to enforce the GPL would entirely come down to intent and an attempt to assert the "special nature" of the function calls in relation to Spring. Because that's all we're doing- using bytecode that just happens to have a particular effect when Spring reads it, or passing arguments to internal functions, through an API layer.

In short... until I see something that looks less like a bunch of tiffs in a teacup over some harried staffer's quick comments, the code in P.U.R.E. that is non-GPL and non-PD is remaining under whatever license I want to use.
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: FSF stance on GPL issues.

Post by smoth »

oh how people change.
Radtoo
Posts: 50
Joined: 12 May 2006, 14:21

Re: FSF stance on GPL issues.

Post by Radtoo »

Argh wrote:Because that's all we're doing- using bytecode that just happens to have a particular effect when Spring reads it, or passing arguments to internal functions, through an API layer.
Doesn't work - the infectious clause in the GPL is in place EXACTLY so you can't introduce a layer to make something differently licensed.

That layer and everyone depending on it simply doesn't have the right to use the original work without going by the terms of the GPL, which means you need to GPL stuff yourself on distribution.

Oh and El_Capitano, you're confusing and pretty much wrong (sorry, I know you're only trying to help...).


The basics are as simple as:

- Does YOUR stuff use GPL'd stuff? -> Needs to be GPL'd on redistribution. (Exception: System libraries).

- Does YOUR stuff use something that uses GPL'd stuff? -> Everything in this chain must be GPL'd.

- Does GPL'd code unidirectionally use or interpret YOUR stuff? -> Your choice of license.

- Do you want to redistribute something you have full copyright to, and that had to be or just was GPL'd before by you, but in another context isn't strictly required to be? -> Your choice of license for said other context.

- Do you merely want to redistribute something on the same medium / filesystem / ($other simple aggregate), but something GPL'd is present on the same thing? -> Your choice of license, as the GPL doesn't interfere.
*hint*(We can very well regard archive files as simple aggregates, btw... so you only need to license the partial contents properly!)*hint*

- Do you merely want to use something GPL'd, not redistribute or modify or anything? -> No licensing decision involved, but the GPL permits any use.
Output produced can also be licensed in any way, except in crazy corner cases where the GPL'd stuff is directly part of the output.

Now, the very first clause covers stuff that does API calls to Spring, including LUA or whatever. You need to GPL these scripts. (KDR and the FSF are of course right. He isn't a "harried staffer"!)
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: FSF stance on GPL issues.

Post by Argh »

You need to GPL these scripts. (KDR and the FSF are of course right. He isn't a "harried staffer"!)
No. Sue me, if the FSF will take the case. I'm not changing the license until ordered to by a judge.

I'll be happy to have a day in court over this. I'm a Spring contributor, and thus am part of the GPL copyright holders group that would supposedly suffer "damages" for code in a free project that costs me money to make- I have no advertising revenue, etc., to offset my server costs, let alone my time, software, etc.

It'll look absurd in court, and I don't think the FSF will win, either.
Post Reply

Return to “Game Development”