FSF stance on GPL issues.
Moderator: Moderators
Re: FSF stance on GPL issues.
Well, there's again the "I am not a lawyer" footer, Rosen IS a lawyer and in law questions the lawyer is usually the one who's right...
Re: FSF stance on GPL issues.
For the record, this is entirely incorrect, and a wholsale mis-statement of the facts of that case.In 2002, MySQL AB sued Progress NuSphere for copyright and trademark infringement in United States district court. NuSphere had allegedly violated MySQL's copyright by linking code for the Gemini table type into the MySQL server. After a preliminary hearing before Judge Patti Saris on February 27, 2002, the parties entered settlement talks and eventually settled. At the hearing, Judge Saris "saw no reason" that the GPL would not be enforceable.[32]
A preliminary injunction, in a U.S. court of law, means, "that's so obvious, there is no point in hearing detailed arguments". It means that the judge has already reached a judgement in favor / against a specific series of arguments, based on the merits of the arguments. It is not a "settlement".
NuSphere won that side of that case, basically. Making a fork, and then making it into a profitable product, was entirely legal, and the court agreed that this was not in violation of the GPL. The only thing MySQL AB won in that case was the trademark side, forbidding NuSphere from using MySQL's trademarked logos, etc. Read the actual case, please.
Moreover, for the record, the rest of the assertions he's making are from that same Wikipedia article. You're using a single source to try and dispute this... and it's in Wikipedia, which is a good general-knowledge source, but is not suitable as a proof. We might as well be reading some blogger's random opinions, frankly.
Lastly, the FSF has always maintained the same "party line" on dynamic linking, even though they have never, ever been able to get a court ruling in favor of it, under v2. Think that was added to v3 on accident? Neither do I...
Re: FSF stance on GPL issues.
Not paying much attention to thread but this needs to be stickied to everything.Argh wrote:...Wikipedia, which is a good general-knowledge source, but is not suitable as a proof...
EVERYTHING
Re: FSF stance on GPL issues.
Meh, I just don't like it when people repeat the arguments that we've already discussed, and rejected based on the facts, based on some Wikipedia article, instead of an actual source quote, case law, etc. It's not that Wikipedia articles are invalid sources, it's simply that this particular one is not exactly honest about that case involving NuSphere vs. MySQL, and therefore everything else in it is, well... suspect. I have seen no real evidence about the "de facto" assertions about dynamic linking, etc. in actual cases. I think that's a straw man, created by the FSF's boosters to scare people, basically, and has no basis in fact.
Re: FSF stance on GPL issues.
All right, it's Monday. I don't see white flags here, so here's what I think needs to be said:
1. Most of this "case" hinges upon the dynamic linking argument, which is weak and untested. Nobody has brought forth any real proof that the dynamic linking argument ever caused anybody to accede to the FSF's demands, if they weren't also patently ripping off somebody else's source. Sure, we can see cases where people settled, to avoid GPL enforcement. But they always involved ripping off source, too, so far as I have been able to determine- the parties involved knew they were going to lose on that part, so they didn't even try the dynamic-linking theory.
2. The entire "whole game" theory goes out the window, if dynamic linking cannot be defended. There is no "work" in things like Widgets, for example, which users can install separately, and activate separately, and do not share memory with one another, and use API calls. There is no "work" in many COBs acting as their own threads, never interacting with one another. There is no "work" in Gadgets that do not communicate with one another. It's just a bunch of different programs- no different than a complex website, for example.
3. If we accept those arguments, however weak, then the engine's contributors- every last one of them- have the power to enforce the GPL. This is a very bad thing to do, for reasons that we've already explored.
4. If we don't accept those arguments, then we're right back to the original stand I wanted to take here, which is that separate licenses are all right, and that the GPL only extends to specific programs within the game. Gadgets / Widgets that touch each other through data access, for example, are thereby "poisoned" and cannot be used in a non-GPL context, since that is not just "linking" but involves creating a shared memory area.
Given that no novel arguments have been submitted, I think that a vote's in order. The choice is pretty clear- do we want:
A. All code to be considered GPL under the engine license requirements?
B. All code is governed by its individual license, and sub-licenses are to be considered legally binding?
Either way, from my POV, I win, so I'm a fairly disinterested bystander at this point, tbh. So please submit your vote by the end of the week, let's get this over with. Don't spend the week posting further arguments, unless you can really demonstrate hard proof for the dynamic-linking argument, frankly- anything else is probably not sufficient to remove this debate from a somewhat-nebulous gray area, where we're simply going to have to agree to some arbitrary rules, frankly.
Majority wins this debate, I will write a FAQ describing the legal status of projects for this engine and the matter is then closed. And no, we're not doing this as a poll- too much chance of people pulling sock-puppet tricks, etc. Vote here, in public, where we all know where you stand on this at the end of the day. Not voting will imply that you're willing to abide by the decision of the majority here.
1. Most of this "case" hinges upon the dynamic linking argument, which is weak and untested. Nobody has brought forth any real proof that the dynamic linking argument ever caused anybody to accede to the FSF's demands, if they weren't also patently ripping off somebody else's source. Sure, we can see cases where people settled, to avoid GPL enforcement. But they always involved ripping off source, too, so far as I have been able to determine- the parties involved knew they were going to lose on that part, so they didn't even try the dynamic-linking theory.
2. The entire "whole game" theory goes out the window, if dynamic linking cannot be defended. There is no "work" in things like Widgets, for example, which users can install separately, and activate separately, and do not share memory with one another, and use API calls. There is no "work" in many COBs acting as their own threads, never interacting with one another. There is no "work" in Gadgets that do not communicate with one another. It's just a bunch of different programs- no different than a complex website, for example.
3. If we accept those arguments, however weak, then the engine's contributors- every last one of them- have the power to enforce the GPL. This is a very bad thing to do, for reasons that we've already explored.
4. If we don't accept those arguments, then we're right back to the original stand I wanted to take here, which is that separate licenses are all right, and that the GPL only extends to specific programs within the game. Gadgets / Widgets that touch each other through data access, for example, are thereby "poisoned" and cannot be used in a non-GPL context, since that is not just "linking" but involves creating a shared memory area.
Given that no novel arguments have been submitted, I think that a vote's in order. The choice is pretty clear- do we want:
A. All code to be considered GPL under the engine license requirements?
B. All code is governed by its individual license, and sub-licenses are to be considered legally binding?
Either way, from my POV, I win, so I'm a fairly disinterested bystander at this point, tbh. So please submit your vote by the end of the week, let's get this over with. Don't spend the week posting further arguments, unless you can really demonstrate hard proof for the dynamic-linking argument, frankly- anything else is probably not sufficient to remove this debate from a somewhat-nebulous gray area, where we're simply going to have to agree to some arbitrary rules, frankly.
Majority wins this debate, I will write a FAQ describing the legal status of projects for this engine and the matter is then closed. And no, we're not doing this as a poll- too much chance of people pulling sock-puppet tricks, etc. Vote here, in public, where we all know where you stand on this at the end of the day. Not voting will imply that you're willing to abide by the decision of the majority here.
Re: FSF stance on GPL issues.
The GPL may not have a legal right to propagate via dynamic linking but that doesn't mean you can ship a mod containing GPL and non-GPL material dynamically linked to each other. Of course that only applies if you include both the GPL and non-GPL material in the mod as that gives the GPL power over you.
The idea is that adding dynamically linked material to a GPL thing isn't copyright infringing but GPL violating, as long as you distribute no GPL material it doesn't matter since there's no infringement claim against you but if you do distribute GPL material (e.g. a gadget in your mod) you have to follow the GPL even in places where no direct infringement claim could be made.
The idea is that adding dynamically linked material to a GPL thing isn't copyright infringing but GPL violating, as long as you distribute no GPL material it doesn't matter since there's no infringement claim against you but if you do distribute GPL material (e.g. a gadget in your mod) you have to follow the GPL even in places where no direct infringement claim could be made.
Re: FSF stance on GPL issues.
That's not really here or there, for the central decision. The key is whether the engine's GPL should be interpreted to cover any work, period. Once that issue's settled, we can (and should) argue about the specifics of game code, and hopefully arrive at a solution that would allow all projects to make use of World Builder, regardless of their licenses or legality.The GPL may not have a legal right to propagate via dynamic linking but that doesn't mean you can ship a mod containing GPL and non-GPL material dynamically linked to each other.
A vote for choice A pretty much ends that discussion before it even starts, of course. It only matters if B is the majority's decision here.
Re: FSF stance on GPL issues.
aehm...
i do not want to read all the pages, and i would not understand it anyway i think, so a simple question:
when i add ned source files to spring (the engine part), can i already put them under the LGPL, or would al hte rest have to be LGPL as well first?
i do not want to read all the pages, and i would not understand it anyway i think, so a simple question:
when i add ned source files to spring (the engine part), can i already put them under the LGPL, or would al hte rest have to be LGPL as well first?
Re: FSF stance on GPL issues.
According to what I've read, using the LGPL within a GPL work is permitted, but effectively makes that code GPL.
Re: FSF stance on GPL issues.
You can mix non GPL code and GPL code aslong as the non GPL code does not enforce stricter terms than GPL, aka its GPL compatible.
Such licences include Public domain and LGPL
Such licences include Public domain and LGPL
Re: FSF stance on GPL issues.
ok, thank you two! 
Re: FSF stance on GPL issues.
I read up to the first page of page 6, got annoyed and into ranting mood.
IMHO, and I was very, very surprised a few years ago when I found out that the FSF doesn't share my view, linking in any way does not constitute creating a derived work. In fact, it cannot, as any publicly available (and that's a key point here) interface can be re-implemented under any license you want.
My prime example is gnu readline: Requiring a program that runs on both *BSD and linux to be licensed under the GPL 'cos the average linux system happens to use gnu readline instead of e.g. appropriate versions of editline/libedit is insane and doomed to failure as is trying to sue Microsoft to release Windows under the GPL because it makes, via bochs, calls to hal.
It is also bad software design: Chances are that anyone needing this functionality will just leech libedit and thus ignore all that user-side configuration someone may have made for readline. It's everything else but constructive behaviour.
I hereby reserve the right to publish any non-functional work under any licence I choose and want to see the FSF sueing me 'cos I happen to mention an interface that happens to be (also) an interface of a GPL library.
You just can't promote freedom by chaining people to it: I think the FSF, and I know that there were prior attempt to invokate Godwin's Law in this thread (I guess to stop the discussion...), attempts to act methodically akin to 1984's thought police.
As to spring itself: I'd recommend sticking with the GPL and adding an explatatory clause, just like linux. Something along the lines of "Game content packages are not considered "derivative work" by the copyright holders. This includes exectution by spring and scripts that use any spring API. In short, you may use any licence you wish for your spring mod."
IMHO, and I was very, very surprised a few years ago when I found out that the FSF doesn't share my view, linking in any way does not constitute creating a derived work. In fact, it cannot, as any publicly available (and that's a key point here) interface can be re-implemented under any license you want.
My prime example is gnu readline: Requiring a program that runs on both *BSD and linux to be licensed under the GPL 'cos the average linux system happens to use gnu readline instead of e.g. appropriate versions of editline/libedit is insane and doomed to failure as is trying to sue Microsoft to release Windows under the GPL because it makes, via bochs, calls to hal.
It is also bad software design: Chances are that anyone needing this functionality will just leech libedit and thus ignore all that user-side configuration someone may have made for readline. It's everything else but constructive behaviour.
I hereby reserve the right to publish any non-functional work under any licence I choose and want to see the FSF sueing me 'cos I happen to mention an interface that happens to be (also) an interface of a GPL library.
You just can't promote freedom by chaining people to it: I think the FSF, and I know that there were prior attempt to invokate Godwin's Law in this thread (I guess to stop the discussion...), attempts to act methodically akin to 1984's thought police.
As to spring itself: I'd recommend sticking with the GPL and adding an explatatory clause, just like linux. Something along the lines of "Game content packages are not considered "derivative work" by the copyright holders. This includes exectution by spring and scripts that use any spring API. In short, you may use any licence you wish for your spring mod."
Re: FSF stance on GPL issues.
What a lot of fuss! Really.
Distributing binary or non-GPL code that relies on a GPL program to operate is not an issue. If this were the case then every python script ever written is now controlled by the Python Foundation. Nobody of any standing has EVER claimed this is the case. It is simply NOT the case, retarded legal theories notwithstanding.
The only issue is for DISTRIBUTORS, ie, Linux distributions, magazine coverdiscs, or in this case for mods that want to distribute Spring as part of their game. In the first two cases the "aggregate works" clause allows distribution because they are SEPARATE ARCHIVES.
If a user downloads Spring, then downloads PURE or other non-GPL mod, they are not violating anything because they are not "selling or distributing a modified or derived work". It's only an issue if the user were then to distribute the entire merged collection. This may be an issue for a bittorrent package or mod installer but frankly it is not something anybody seems to care about.
Most commercial companies don't want to say "go and download X and then download our app". They run foul of the system by preinstalling or distributing GPL'ed code with their own non-compatible code. Since they no longer comply with GPL they are not authorised to distribute it. Their own code does not magically become GPL'd, they are simply in violation of copyright.
This has absolutely NOTHING to do with end-users who obtain the packages seperately. It seems highly probable that the FSF person whose comments started this thread was not aware of the distinctions and probably assumed the modified Lua would be combined into the engine itself (ie, distributed as a Spring fork).
The ONLY issue that has any relevance at all is the GPL'd code that is being distributed with some mods, namely gadgets.lua and friends. If a mod includes these or other GPL'd files then you certainly have no claim to be GPL independent. Your option is to remove these files (AFAIK they're in the engine anyway) and/or make your own.
Finally, smoth's concerns about attribution are unfounded.
The ONLY point to licensing under LGPL is if you want to let games developers DISTRIBUTE Spring as a library to a closed-source title. Is this what people want? Is it worth the effort?
EDIT: The quote above is actually from GPLv3. GPLv2 does allow us to impose additional restrictions like mandatory attribution as long as we get the copyright holders permission:
This is still irrellevant to smoth though. Since he is not distributing Spring he has the same freedom as Argh to go with any license he chooses.
Distributing binary or non-GPL code that relies on a GPL program to operate is not an issue. If this were the case then every python script ever written is now controlled by the Python Foundation. Nobody of any standing has EVER claimed this is the case. It is simply NOT the case, retarded legal theories notwithstanding.
The only issue is for DISTRIBUTORS, ie, Linux distributions, magazine coverdiscs, or in this case for mods that want to distribute Spring as part of their game. In the first two cases the "aggregate works" clause allows distribution because they are SEPARATE ARCHIVES.
If a user downloads Spring, then downloads PURE or other non-GPL mod, they are not violating anything because they are not "selling or distributing a modified or derived work". It's only an issue if the user were then to distribute the entire merged collection. This may be an issue for a bittorrent package or mod installer but frankly it is not something anybody seems to care about.
Most commercial companies don't want to say "go and download X and then download our app". They run foul of the system by preinstalling or distributing GPL'ed code with their own non-compatible code. Since they no longer comply with GPL they are not authorised to distribute it. Their own code does not magically become GPL'd, they are simply in violation of copyright.
This has absolutely NOTHING to do with end-users who obtain the packages seperately. It seems highly probable that the FSF person whose comments started this thread was not aware of the distinctions and probably assumed the modified Lua would be combined into the engine itself (ie, distributed as a Spring fork).
The ONLY issue that has any relevance at all is the GPL'd code that is being distributed with some mods, namely gadgets.lua and friends. If a mod includes these or other GPL'd files then you certainly have no claim to be GPL independent. Your option is to remove these files (AFAIK they're in the engine anyway) and/or make your own.
Finally, smoth's concerns about attribution are unfounded.
There are no legal issues with PURE having its own license, provided Argh has removed GPL'd widgets and other materials. The are no legal issues with smoth demanding credit notices be retained. None of the case-studies presented apply to Spring, since nobody is violating its distribution conditions (that we know of).7. Additional Terms
.... snip preamble...
Notwithstanding any other provision of this License, for material you add to a covered work, [/b]you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms:[/b]
* a) Disclaiming warranty or limiting liability differently from the terms of sections 15 and 16 of this License; or
* b) Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; or
* c) Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version; or
* d) Limiting the use for publicity purposes of names of licensors or authors of the material; or
* e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or
* f) Requiring indemnification of licensors and authors of that material by anyone who conveys the material (or modified versions of it) with contractual assumptions of liability to the recipient, for any liability that these contractual assumptions directly impose on those licensors and authors.
The ONLY point to licensing under LGPL is if you want to let games developers DISTRIBUTE Spring as a library to a closed-source title. Is this what people want? Is it worth the effort?
EDIT: The quote above is actually from GPLv3. GPLv2 does allow us to impose additional restrictions like mandatory attribution as long as we get the copyright holders permission:
Since the majority of contributors are still in this this community getting that permission might not be so difficult, especially since the restriction does not impact on the goals of the license. Nobody could seriously argue there will be fallout from missing contributers over such a slight modification that simply protects their right to be credited for their work.10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission.
This is still irrellevant to smoth though. Since he is not distributing Spring he has the same freedom as Argh to go with any license he chooses.
Re: FSF stance on GPL issues.
I agree, and I'll write it if it will be used.ksf wrote: As to spring itself: I'd recommend sticking with the GPL and adding an explatatory clause, just like linux. Something along the lines of "Game content packages are not considered "derivative work" by the copyright holders. This includes exectution by spring and scripts that use any spring API. In short, you may use any licence you wish for your spring mod."
Re: FSF stance on GPL issues.
I just downloaded P.U.R.E and realised why Argh is so vocal about GPL. He's distributing Spring with his mod.
So yeah, GPL doesn't work for him if he wants to relicense his changes, however I fail to see why he's distributing it all. Surely it isn't that hard to tell players to download Spring first? Assuming it doesn't have a need for 0.76b2 not met by 0.76b1 I think PURE is just wasting bandwidth.
Anyway Argh, legally you need to license your code under GPL or stop distributing Spring extended by your mod - since you are still "modifying" the Spring distribution under the definition provided by the GPL. You will also need to remove any GPL'd LuaUI or LuaRules code from PURE.sdz and provide source code if you make any changes to the Spring binary.
Saying your content is not an extension of Spring doesn't wash when you are distributing them as a single entity.
neddiedrow: I think adding that clause to the LICENSE file in the distribution should be sufficient, however I recommend you further define "Game content packages" to mean "any archive or folder containing no GPL'ed Spring Project code that is loaded from the 'Mods' subdirectory of Spring."
This should reduce the risk of people extending Spring base content or binaries under a restrictive license.
EDIT: Actually it increases the risk. I can now write an RTS engine based off Spring by using dynamic linking and putting all my proprietry code under Mods/. I would then be forced to release my modified Spring binary but NOT the dependencies - effectively taking ownership of Spring 2 without giving anything back. Perhaps this needs more discussion before we effectively open the license to abuse.
So yeah, GPL doesn't work for him if he wants to relicense his changes, however I fail to see why he's distributing it all. Surely it isn't that hard to tell players to download Spring first? Assuming it doesn't have a need for 0.76b2 not met by 0.76b1 I think PURE is just wasting bandwidth.
Anyway Argh, legally you need to license your code under GPL or stop distributing Spring extended by your mod - since you are still "modifying" the Spring distribution under the definition provided by the GPL. You will also need to remove any GPL'd LuaUI or LuaRules code from PURE.sdz and provide source code if you make any changes to the Spring binary.
Saying your content is not an extension of Spring doesn't wash when you are distributing them as a single entity.
neddiedrow: I think adding that clause to the LICENSE file in the distribution should be sufficient, however I recommend you further define "Game content packages" to mean "any archive or folder containing no GPL'ed Spring Project code that is loaded from the 'Mods' subdirectory of Spring."
This should reduce the risk of people extending Spring base content or binaries under a restrictive license.
EDIT: Actually it increases the risk. I can now write an RTS engine based off Spring by using dynamic linking and putting all my proprietry code under Mods/. I would then be forced to release my modified Spring binary but NOT the dependencies - effectively taking ownership of Spring 2 without giving anything back. Perhaps this needs more discussion before we effectively open the license to abuse.
Re: FSF stance on GPL issues.
He's including Spring in order to make installing easier, requiring players to download tons of different things is bad style. Also it's a non-standard version of Spring (an SVN build, not a stable release), most people don't have that installed and would attempt playing in the stable version instead which doesn't work (I get bug reports for THIS because people try running it in stable).
I'd say the aggregation clause applies here since Spring and the mod are usually distributed separately and he just aggregated them by throwing them into the same installer.
Also the whole viral nature of the GPL is specifically to prevent people from using a linked approach but then again I don't think that's worth fighting and you can still provide a "no native binaries" rule or something.
I'd say the aggregation clause applies here since Spring and the mod are usually distributed separately and he just aggregated them by throwing them into the same installer.
Also the whole viral nature of the GPL is specifically to prevent people from using a linked approach but then again I don't think that's worth fighting and you can still provide a "no native binaries" rule or something.
-
Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: FSF stance on GPL issues.
Sigh. Spliff, will you please Look at the things in pure. No 1, it requires .77. Number 2 is that there are significant things that need to be included and placed in things other than the mods folder. This is the future people, get used to it.
Ha, I jsut had a thought. Make the game installer dl and install spring .77 to the game folder before continuing.
Ha, I jsut had a thought. Make the game installer dl and install spring .77 to the game folder before continuing.
Re: FSF stance on GPL issues.
Thank you FA for missing the point. I now know WHY he's doing it but that doesn't change the fact he IS distributing GPL'ed code both inside and outside his mod archive without complying with the license. Having an auto-install of Spring is still DISTRIBUTION.
Aggregation applies to to items on a website or CD that are generally not extensions of each other. GNU software fits the "connected through pipes" rule whereas Spring mods are essentially 'MODifications' or extensions of Spring.
If everyone is happy to ignore it then so am I but I just think that in light of this Argh's comments on GPL should be weighed with some scepticism.
Aggregation applies to to items on a website or CD that are generally not extensions of each other. GNU software fits the "connected through pipes" rule whereas Spring mods are essentially 'MODifications' or extensions of Spring.
If everyone is happy to ignore it then so am I but I just think that in light of this Argh's comments on GPL should be weighed with some scepticism.
Re: FSF stance on GPL issues.
Hey man, I have been saying for over a year now that the aggregate clause covers us. Some people, namely argh and af rejected that. Glad to see another person agrea with me on that.
What do you mean? I was concerned about attribution?SpliFF wrote:Finally, smoth's concerns about attribution are unfounded.
-
Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: FSF stance on GPL issues.
Spliff, READ this ENTIRE thread, then come back and talk. ATm you're bringing up stuff that was covered months ago.