There's a cool widget that does this IIRC, I thought it was pretty neat. Look in the top right corner after you start a game.smoth wrote:Ah, well have you credited all individuals who have aided with pure? I am not sure who did what still.
FSF stance on GPL issues.
Moderator: Moderators
Re: FSF stance on GPL issues.
Re: FSF stance on GPL issues.
To the best of my knowledge, yes. If anybody's out there and feels they weren't credited properly, please let me know, of course.Ah, well have you credited all individuals who have aided with pure?
Re: FSF stance on GPL issues.
Correct me if I'm wrong but I was under the impression map scripts could be at least as complex as Gadgets. If they call spring library functions they fall under the linking clause (according to FSF FAQ). I don't see any value in enforcing GPL on map archives though so I'll change that part.neddiedrow wrote: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.
I'm not sure what that means. We can't legally enforce anything unless they link to the engine. Compatibility is a technical requirement, not a legal one.neddiedrow wrote: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.
I recognise your previous recommendation, I didn't mean to ignore it. I am concerned it allows an overly broad exemption. I could extend the engine with improvements (say a new pathfinding library) then as long as I placed the library in mymod.sdd/ I wouldn't have to release the source code. I just revised your recommendation to exclude direct-linking to DLLs, reworded it with "GPL language" and extended it to resolve some of the questions that appear regularly in these threads. It's as much your proposal as mine.neddiedrow wrote: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.
Anyway I've edited the proposal to remove map scripts from the definition of code. The big question is whether gadgets and widgets should be exempted as well. That's definitely more contentious and there are good arguments either way. I think they go:
Pro exemption:
* Allows entire mod packages to have a single license
* More friendly to commercial ventures
Con:
* Encourages code sharing
There's probably more but I guess they've all been made.
Re: FSF stance on GPL issues.
I think the only thing that needs to be in such exemption are that any LUA or COB code external to Spring that is being loaded and executed by Spring is allowed to call back into Spring over the respective interfaces, without being subject to the restrictions of the GPL.
It still introduces a bit of a loophole (One could steal spring code make LUA interface for it and then "link" to it through LUA as intermediate step) but I don't know a better solution yet. (Plus I think anyone sane would just rewrite the particular Spring code he's interested in since that's probably easier then wrapping piece of code in LUA.)
Spliff's sample exemption however treats all C code in the engine as data, and worse, it basically restricts the engine to C++ or Java, because if you'd rewrite parts in C#/D/Pascal/whatever it would suddenly be data according to the exemption. IOW it's too loose.
@ Spliff, I posted sample exemption too earlier, from FSF volunteer actually:
It still introduces a bit of a loophole (One could steal spring code make LUA interface for it and then "link" to it through LUA as intermediate step) but I don't know a better solution yet. (Plus I think anyone sane would just rewrite the particular Spring code he's interested in since that's probably easier then wrapping piece of code in LUA.)
Spliff's sample exemption however treats all C code in the engine as data, and worse, it basically restricts the engine to C++ or Java, because if you'd rewrite parts in C#/D/Pascal/whatever it would suddenly be data according to the exemption. IOW it's too loose.
@ Spliff, I posted sample exemption too earlier, from FSF volunteer actually:
Probably isn't complete either (maps aren't mentioned and more explicit mention of COB/BOS/LUA would be good I think), but it shows bit more of wording common in such exemptions.<snip>
Linking TA-Spring statically or dynamically with other modules is making
a combined work based on TA-Spring. Thus, the terms and conditions of
the GNU General Public License cover the whole combination. In addition,
as a special exception, the copyright holders of TA-Spring give you
permission to combine TA-Spring program with free software programs or
libraries that are released under the GNU LGPL and with independent
modules that communicate with TA-Spring solely through the TA-Spring
Mods interface. You may copy and distribute such a system following the
terms of the GNU GPL for TA-Spring and the licenses of the other code
concerned.
Note that people who make modified versions of TA-Spring are not
obligated to grant this special exception for their modified versions;
it is their choice whether to do so. The GNU General Public License
gives permission to release a modified version without this exception;
this exception also makes it possible to release a modified version
which carries forward this exception.
</snip>
Re: FSF stance on GPL issues.
If we're going to revive the Exemption as a possible way to get this cleared up... I would like an Exemption that was written like this:
What we don't want, if we're serious about doing this via an Exemption, is language like this:
"permission to combine TA-Spring program with free software programs or libraries that are released under the GNU LGPL and with independent modules that communicate with TA-Spring solely through the TA-Spring Mods interface."
...strongly implies that it's not all right to charge people money. That kind of proviso would, in my opinion, be more harmful than helpful, if the goal is to allow people to make commercial / educational / government projects with Spring.
Note that the above would mean that, among other things, it would be OK to distribute OTA content. That would be a good thing to do.1. Model meshes (defined as any of the following standards model formats: 3DO, S3O, MD5), sounds, music files (OGG format, or other streaming formats added to this engine in the future) and bitmaps are all considered to be "mere data" and are hereby exempted from this License.
2. Lua, CEG and COB code are exempted from this License.
3. Linking of DLLs or other binaries that are not specifically listed above is not permissible.
What we don't want, if we're serious about doing this via an Exemption, is language like this:
...because that more-or-less implies that "independent modules" must be GPL. It looks like a trap, to me. It's very mushy language, because the line:In addition, as a special exception, the copyright holders of TA-Spring give you permission to combine TA-Spring program with free software programs or libraries that are released under the GNU LGPL and with independent modules that communicate with TA-Spring solely through the TA-Spring Mods interface. You may copy and distribute such a system following the terms of the GNU GPL for TA-Spring and the licenses of the other code concerned.
"permission to combine TA-Spring program with free software programs or libraries that are released under the GNU LGPL and with independent modules that communicate with TA-Spring solely through the TA-Spring Mods interface."
...strongly implies that it's not all right to charge people money. That kind of proviso would, in my opinion, be more harmful than helpful, if the goal is to allow people to make commercial / educational / government projects with Spring.
Re: FSF stance on GPL issues.
It does complain useful parts tho, like the piece which implies that anyone forking Spring or using it's code is in no way obliged to apply the exemption too, but may choose whether he does or not.
Re: FSF stance on GPL issues.
I certainly wouldn't have any problems, if somebody wants to make an academic fork just to test rendering algorithms or AI techniques or pathfinding code, etc.- by all means, let them change the exemption, if they're afraid that their nifty algorithms might be too valuable to allow private use, but want to demonstrate their work to potential employers, etc.
I just don't want to wake up to yet-another argument about this later on, because some wording was a little bit fuzzy, that's all.
I just don't want to wake up to yet-another argument about this later on, because some wording was a little bit fuzzy, that's all.
Re: FSF stance on GPL issues.
Theres nothing stopping me making a fork of the project to render anime x rated movies ala pixar, its as soon as I start distributing it I have to release the code
Re: FSF stance on GPL issues.
single X sucks and has no tentacles, you'll have no market. LRN TO PORN!AF wrote:Theres nothing stopping me making a fork of the project to render anime x rated movies ala pixar, its as soon as I start distributing it I have to release the code
Re: FSF stance on GPL issues.
Hence why I'm not making x rated movies using spring as a renderer
Re: FSF stance on GPL issues.
If you make a movie that can be played on other players, and then distribute it with a GPL'd movie-player, then the movie is still your work, was not derived from the GPL software, and does not become GPL. That's mere aggregation.
Re: FSF stance on GPL issues.
I prefer this over previous recommendations as it's quite specific. The FSF version posted by Tobi simply adds the the confusion because it doesn't answer the question of what is exempt from GPL in an unambigous way. My version is longer than it really needs to be and I was planning to shorten it to something like the above. Most importantly the third point clearly closes the giant loophole I was concerned about. The wording above has my support, provided "mere data" is changed to simply "data" so the wording matches the GPL.Argh wrote: 1. Model meshes (defined as any of the following standards model formats: 3DO, S3O, MD5), sounds, music files (OGG format, or other streaming formats added to this engine in the future) and bitmaps are all considered to be "mere data" and are hereby exempted from this License.
2. Lua, CEG and COB code are exempted from this License.
3. Linking of DLLs or other binaries that are not specifically listed above is not permissible.
Wow, that's a leap. OTA IP rights are (as far as anyone knows) owned by Atari. It doesn't matter a rat's arse what Springs license is. Distribution of OTA is legal when Atari says it is.Argh wrote: Note that the above would mean that, among other things, it would be OK to distribute OTA content.
Re: FSF stance on GPL issues.
Easy there, Trigger. I'm not really saying that. Let me elaborate.Wow, that's a leap. OTA IP rights are (as far as anyone knows) owned by Atari. It doesn't matter a rat's arse what Springs license is. Distribution of OTA is legal when Atari says it is.
I'm saying that going in that direction would means that the "nuclear option" is removed. Which would be, in my opinion, a very good idea.
If there is no legal connection between otacontent.sdz and Spring, for example, then there are no good grounds for initiating C&D efforts under the GPL, or going after Spring's developers as a group.
Basically, going that way means breaking the connection between Spring and OTA, so that if Atari ever makes a stink, we're looking at just removing a file to become compliant, instead of them attempting to link the two.
It'd also mean that the legal responsibility for the contents of an Installer as a whole would be reduced, from everybody who contributed to the engine... to whoever signed off on the archive. It would make this engine a lot safer from attempts to shut it down entirely.
We don't want this engine to be tainted, basically- it should be content-agnostic, legally speaking.
Another approach that's equally valid would be to require OTA mods to include the otacontent files. That would enlarge them a bit, but it's really not all that terrifying- we're talking only a few megabytes of data here, less than 1/10th of the size of P.U.R.E. at this time.
Re: FSF stance on GPL issues.
Argh wrote:If you make a movie that can be played on other players, and then distribute it with a GPL'd movie-player, then the movie is still your work, was not derived from the GPL software, and does not become GPL. That's mere aggregation.
I know that but I was talking about the customized spring rendering engine that had been modified specially for X rated anime movies, not the movies it produced.
Re: FSF stance on GPL issues.
I've been lurking around this discussion, and reading the FSF FAQ on the GPL, and there's a point that's not clear to me:
1. If I understand well, COB is a scripting language that was created for Total Annihilation (or another, previous proprietary game). So, if you make a cob script that only calls functions from TA, does it become GPL just because Spring implements the same functions? Sounds absurd, isn't it. Common sense would say it's not GPL
2. Now if you write a COB script that uses Spring functions, it seems for sure that you have to put it under the GPL. However, what tells you there won't be a proprietary engine that implements that same functions in the future? Would this COB script then stop being GPL, since we're back at the situation in 1. ?
3. Let's say I have the COB specification for Spring in hand, and I don't actually know what the license for the engine is. Maybe someone gave me the specs without even telling me there was already an engine implementing those specs, and asked me to model a 3d unit and script it in COB, as a "proof-of-concept". I write a COB script to those specifications. Is that script then GPL?
This logical mess leads me to think that maybe the GPL provisions make sense only if someone redistributes the Spring engine together with his mod. If it's distributed by itself, how can you prove it's actually meant to work with Spring? The author can always claim that "This game package may actually work with the Spring engine from spring.clan-sy.com, but that has not been tested. It is meant to work with my self-written clone of the Spring engine, written from scratch, that implements the same interface."
AFAIK you can't prevent people from cloning an interface, otherwise the Wine project would be in trouble since they're re-implementing the Windows API.
Maybe I'm missing something, so please chime in to shed a light on this problem. And congratulations to all on the progress of the Spring Engine, which I have been following since the SY days... makes me wish I had time to do more than lurking.
1. If I understand well, COB is a scripting language that was created for Total Annihilation (or another, previous proprietary game). So, if you make a cob script that only calls functions from TA, does it become GPL just because Spring implements the same functions? Sounds absurd, isn't it. Common sense would say it's not GPL
2. Now if you write a COB script that uses Spring functions, it seems for sure that you have to put it under the GPL. However, what tells you there won't be a proprietary engine that implements that same functions in the future? Would this COB script then stop being GPL, since we're back at the situation in 1. ?
3. Let's say I have the COB specification for Spring in hand, and I don't actually know what the license for the engine is. Maybe someone gave me the specs without even telling me there was already an engine implementing those specs, and asked me to model a 3d unit and script it in COB, as a "proof-of-concept". I write a COB script to those specifications. Is that script then GPL?
This logical mess leads me to think that maybe the GPL provisions make sense only if someone redistributes the Spring engine together with his mod. If it's distributed by itself, how can you prove it's actually meant to work with Spring? The author can always claim that "This game package may actually work with the Spring engine from spring.clan-sy.com, but that has not been tested. It is meant to work with my self-written clone of the Spring engine, written from scratch, that implements the same interface."
AFAIK you can't prevent people from cloning an interface, otherwise the Wine project would be in trouble since they're re-implementing the Windows API.
Maybe I'm missing something, so please chime in to shed a light on this problem. And congratulations to all on the progress of the Spring Engine, which I have been following since the SY days... makes me wish I had time to do more than lurking.
Re: FSF stance on GPL issues.
Again the FAQ is for the GPLv3 which Spring isn't licensed under. Apparently the v2 doesn't include interpreted languages at all.
Re: FSF stance on GPL issues.
why did you res this crap gabba? It only causes headaches for a community that pretty much freely shares cob scripts. Why does it really matter to you, why do you want to play gpl police. I am serious just get out of it and drop the "issue" there is no issue. The only people here who write even halfway complex cobs are zwzsg and kdr. They IIRC use PD which is gpl compatible. The rest of us use pretty run-of-the-mill kind of scripts which are not even special enough to give two shits about. Sure most of the *A content is STOLEN and no one cares.
so drop it. Eventually cob will be replaced, or so I have been told so quit wasting time discussing it. Want to be useful? Learn to texture, learn to model or learn to animate, we need people to do that.
so drop it. Eventually cob will be replaced, or so I have been told so quit wasting time discussing it. Want to be useful? Learn to texture, learn to model or learn to animate, we need people to do that.
Re: FSF stance on GPL issues.
Here we go again....... 

- SwiftSpear
- Classic Community Lead
- Posts: 7287
- Joined: 12 Aug 2005, 09:29
Re: FSF stance on GPL issues.
You can sell software under the GPL and LGPL licenses. You just also have to release the codebase for free. We don't want people taking the project, creating their own locked codebase, and selling it. That's why it's under a GPL license. If they are releasing a free project it's not as big a deal, we're not likely to ever pursue legal complaints with a non profit project.Argh wrote:If we're going to revive the Exemption as a possible way to get this cleared up... I would like an Exemption that was written like this:
Note that the above would mean that, among other things, it would be OK to distribute OTA content. That would be a good thing to do.1. Model meshes (defined as any of the following standards model formats: 3DO, S3O, MD5), sounds, music files (OGG format, or other streaming formats added to this engine in the future) and bitmaps are all considered to be "mere data" and are hereby exempted from this License.
2. Lua, CEG and COB code are exempted from this License.
3. Linking of DLLs or other binaries that are not specifically listed above is not permissible.
What we don't want, if we're serious about doing this via an Exemption, is language like this:
...because that more-or-less implies that "independent modules" must be GPL. It looks like a trap, to me. It's very mushy language, because the line:In addition, as a special exception, the copyright holders of TA-Spring give you permission to combine TA-Spring program with free software programs or libraries that are released under the GNU LGPL and with independent modules that communicate with TA-Spring solely through the TA-Spring Mods interface. You may copy and distribute such a system following the terms of the GNU GPL for TA-Spring and the licenses of the other code concerned.
"permission to combine TA-Spring program with free software programs or libraries that are released under the GNU LGPL and with independent modules that communicate with TA-Spring solely through the TA-Spring Mods interface."
...strongly implies that it's not all right to charge people money. That kind of proviso would, in my opinion, be more harmful than helpful, if the goal is to allow people to make commercial / educational / government projects with Spring.
Re: FSF stance on GPL issues.
If I ever have sufficient time to contribute to Spring, it will be by coding at the engine level. In the meanwhile I try to stay up-to-date and play it... sometimes.smoth wrote:why did you res this crap gabba? It only causes headaches for a community that pretty much freely shares cob scripts. Why does it really matter to you, why do you want to play gpl police. I am serious just get out of it and drop the "issue" there is no issue. The only people here who write even halfway complex cobs are zwzsg and kdr. They IIRC use PD which is gpl compatible. The rest of us use pretty run-of-the-mill kind of scripts which are not even special enough to give two shits about. Sure most of the *A content is STOLEN and no one cares.
so drop it. Eventually cob will be replaced, or so I have been told so quit wasting time discussing it. Want to be useful? Learn to texture, learn to model or learn to animate, we need people to do that.
And What? I'm not trying to play the GPL police at all. I thought you had pretty much resolved the issue (or at least were discussing a solution without too much flaming), and I was hoping you could enlighten me on the points I posted above. Sorry if I actually worsened a problem.
If you actually read what I wrote, not just skim over it, you'll see that:
- COB scripts are just an example I took because I know they exist in TA as well
- you should actually like my argument, since if it's true, it would mean you can publish whatever you want that uses Spring as an engine, under whatever license you want, as long as you don't distribute them together. Because (or so I have the impression) it's impossible to prove that the lua/cob/whatever was written for the Spring engine and not for some in-development secret engine or even for imaginary specs.
If you're not interested in discussing that then just ignore that question and go your merry way. I just asked out of curiosity.
And yeah, I didn't realize that.KDR_11k wrote:Again the FAQ is for the GPLv3 which Spring isn't licensed under. Apparently the v2 doesn't include interpreted languages at all.
But can someone summarize for me what's the current problem/fight anyhow? I don't exactly understand why people would like so much to keep their little scripts private. As Smoth wrote, they are not the valuable content. The hardest part to make, the media (graphics, models, music, etc.) should not be put under the GPL, which is clearly not designed for anything else than programs. So if you write in big bold letters somewhere: "You want to contribute by making a mod/game? Welcome! Whatever media you produce is yours to publish in any license, but 'All your scripts belong to us' (or rather, to the free software community throught the GPL)". That's very very generous compared to the licenses that apply to mods of proprietary games, and IMHO a clear policy will do more help than any license change.
Edit: correction in italics in paragraph above