Why P.U.R.E. will not be GPL or CC-PD. Very long.

[YokoZar]

Using GPL content in your mod is obviously linking to it, and therefore you must distribute your mod as GPL.

If you don't, you're infringing on copyright. If you use Atari content, you're infringing on copyright.

If your mod isn't free software I'm not uploading it to the Ubuntu repositories. If your mod infringes copyright I'm not uploading it to the Ubuntu repositories either.


Clear?

[Neddie]

Game. Not mod. Original content distinction for purposes of documentation and advertisement.

[Satirik]

Using GPL content in your mod is obviously linking to it, and therefore you must distribute your mod as GPL.

If you don't, you're infringing on copyright. If you use Atari content, you're infringing on copyright.

If your mod isn't free software I'm not uploading it to the Ubuntu repositories. If your mod infringes copyright I'm not uploading it to the Ubuntu repositories either.


Clear?

omg we won't sleep tonight, you won't upload it on ubuntu ??? OMG OMFG !! what should we do ???

[Argh]

Aggregation

Here's my current take on aggregation, based on what has been said and some mulling over. I think this accurately depicts the facts as I know them, and welcome further reasoned arguments.


Games built with Spring are not single programs. They are a functional collection of software and content, much like a web browser, which is not just one piece of software, but several that combine together to produce a given result.

What a person playing a browser-based game sees- i.e., the game and it's various interface elements- is actually an illusion.

It's often a lot of essentially separate pieces of software- maybe some HTML here, some JavaScript there, some Flash and maybe some Perl, PHP, etc. running data from the user to another location or locations, where yet another piece of software may be involved. Then end-user sees a complete, seamless experience, but the truth of the matter is often quite different.

Nobody argues that, say, the Flash plugin is GPL, even though it's being used by people in Firefox or Opera. It's Adobe's proprietary software, and it communicates with those browsers through an agreed-upon interface. For those of you in doubt about that statement's veracity, because it's rather important, check with Google, you will see what I mean here. Proprietary stuff runs on GPL'd browsers all the time.

Spring games are basically similar.

Desync and the Whole Game Argument

KDR mentioned desync as one way to establish a criteria for the arguments about how to draw the line around what's a "work". I think that was an interesting argument, but I'm not sure I agree with it, at this time. Here's my reasoning.

First off... we'd have to have a Spring that didn't desync, ever, due to elements outside of a game's code, i.e., stuff that game designers can't control. We don't, and probably won't for quite awhile to come. Spring desyncs for a variety of reasons, many of which are bugs being exposed by various novel interactions between Spring and Lua. I think that it's been a very good way for certain things to be unearthed, myself, based on what I see getting fixed.

It's inevitable, and doesn't really undermine the browser comparison, imo. Buggy browsers that don't handle that web-based game that I mentioned earlier aren't in any way establishing that that game is a whole "work".

Secondly, you'd have to have stuff that caused reproducible desync in the first place. There should (in an ideal world) be very few things that a game designer can do that will cause desync, and there are bits of important code in SVN that are supposed to address the known problems in this regard. Meh, I'm glad I brought up the issues with random seeds early, and I hope that's the only major iceberg out there, but I have a feeling it's not.

Thirdly, a desyncing piece of code almost certainly should cause desync for all players, if it wasn't related to something hardware or OS. A desync that establishes the "whole game" argument would have to do that to qualify, and be reproducible.


However, until the first point isn't a problem, I don't think it's fair to say that, as the problem may very well be internal to Spring, and not the game designer's fault- their code may be buggy, but if one party's machine gives an error, but remains in sync with the others which show an error but don't halt... and another party's doesn't handle the error correctly, and desyncs... that isn't enough to establish the premise, imo. Linux / Windows desyncs are probably going to remain a bane for quite awhile, I suspect, and they aren't game designers' faults.


To argue in a bit more detail, specifically about what sync is, and how it works... let's say that World Builder runs, and one guy's computer is so slow that his machine finished a second behind everybody else's. His machine is too late for the communication to occur at the right timestamp, he desyncs, everybody else is fine.

How is this supposedly the game's fault?

The problem revealed there is with Spring's sync system. Spring's sync requires things to happen within a very finite time limit, and even chain-reaction explosions are infamous for causing desync to occur, because somebody's machine grinds to a halt.

The only way out of that box is to change the sync model, frankly, and that's engine-side.

It's already been altered some, mainly because of World Builder. It may need to get altered more in the future- for example, we may need a Lua method to halt the game state and request a halt of all communication attempts and basically restart the sync, so that certain complex operations can occur without causing desync due to the sync timer inexorably moving forwards.

In fact, I suspect that will become a big issue soon. But that's a side argument. Mainly what I'm saying is that desync's mainly an engine-side problem, and that some aspects of it will probably need to get altered in the future to allow for more flexibility in game designs.

But it doesn't establish a "whole game" argument- it just points out one of the big issues with the sync model, which is that it's terribly inflexible and can't respond to demand very well. No big news there.

Various cases involving scripts / languages and applying the GPL

Now that I've attacked the most serious stab at the "whole game" argument in some detail, let's get down to specific issues where the GPL might, in fact, be considered to copyleft other portions of a game's code.

TDFs can never establish real dependencies or "infect" other files via copyleft. They're just table entries, in SVN Spring. They aren't programs, they're just data.

The various chunks of a CEG may all be calls to different functions within Spring, but they're still one event loop, functionally, and cannot be said to be separate. You cannot GPL one part of a CEG, and consider the rest to be proprietary. Yeah, yeah, it's just a function call and arguments. I'm sure somebody will argue about that. Guess what- everything else we're doing with Spring basically boils down to function calls and arguments, and CEGs are getting parsed by the Lua parser, just like TDF in SVN, IIRC- but, unlike TDFs, CEGs are in fact a series of operations specified by a designer. CEG's basically a very simple scripting language with a very specific purpose, but it's still a scripting language. Maybe, one day, it will just be loose arguments to a LUPS-like system. It'll still be function calls and arguments, though, and it will not have to be GPL, even if that LUPS-like system exists.

A COB is one unified entity, even if some of it is running some non-animation loop that is only started during Create(), such as a communications script that calls a Lua script and changes some variable in response to the arguments returned.

You can't, say, GPL one part of a COB. It's all one loop. Forget it- either it's all GPL, or not.

COB can share data with other COBs, and very directly, at that. If you GPL a COB and it uses that shared data structure, and then have a proprietary COB also using that shared data structure, you're violating the GPL.

When we get to Lua, we're dealing with separate entities that don't share a data structure that the Lua scripts didn't create themselves, unless we're going to insist that the tables created by the Lua parser during startup constitute a data structure, which I think is a big stretch.

This doesn't mean that there aren't specific cases where one piece of Lua may be interpreted to "infect" another one. Let's go through some common examples here:

1. A Widget reads the hitpoints of a given Unit, and then does something, like flash the screen if the Unit's nearly dead.

In this case, it's not sharing data structures with other Widgets or Gadgets. Therefore, it may be GPL, but in no way does it "infect" other code, nor can the GPL then be applied to the whole project due to that Widget's existence.

2. A GPL'd Gadget creates a Unit.

Once again, this occurs through the API, not directly. The code is GPL, but does that make the Unit's TDF or other content GPL? No, it doesn't. It isn't sharing a data structure there. It's passing arguments to the Gadget Handler, which in turn is calling a function within Spring.

3. Two Gadgets exist which modify a table X. One Gadget made the table, but both use it.

Now, this is different. They're clearly sharing a data structure, that one or the other created and they're both referring to that memory area. One Gadget is GPL, the other is not. The non-GPL Gadget is now clearly in violation of copyright, and should be GPL.




I think that that's about where things are, in terms of understanding how the GPL is applied to Lua, and to the various parts of a Spring game.

Somebody's bound to bring up COB-->Lua at some point, so here are my current thoughts about this. When you have Lua-->COB interactions, the Lua could be GPL, but the COB could be private code. Again, it's because of the API layer between them. The Lua's just asking for arguments to be passed, same with the COB. They're not sharing data structures.



Sorry, that was long, but meh, there has been so much involved in all of these arguments that I thought I should put the puzzle together and see where things stood. I am pretty sure that the above all holds together based on what we've learned about how the GPL applies to things, and how Spring works.

CA, Copyright Law, and the GPL

A big chunk of the arguments raised in this thread have been about to what extent CA can apply GPL to its work. We have new information, so I think it's time to clarify stuff a bit.

According to the quotes about copyright, it would appear that copyright law recognizes an inherent copyright at the time a work is authored, even though the 1976 Copyright Act seems to make a very sharp distinction about publishing.

IANAL, and the case law I've looked at seems to imply that how these two clashing concepts are applied varies from case to case.

But I think it would be fair to say, based on that quote, that CA's authors can expect their copyrights to be upheld, separate of CA, should Atari ever make an issue of things, and they could then use their code, with original content, in another game.

So the GPL applied to CA code should be respected, is my current interpretation of what we know about how the law works.

It should not be interpreted to infect whole games, however. I think that the major points about aggregation made above are going to stand up to scrutiny. I certainly welcome serious arguments to determine these issues, however, if I've missed something major.

I hope not, though- "mere aggregation" would make life a hell of a lot easier for everybody involved, and would involve no changes to CA's current program at all, nor strip anybody of their rights.

GPL within Repositories

On the issue of including projects within a GPL'd repo, my thoughts on this is that neither CA, nor my current game, nor IW, Gundam, E&E and other projects that are either privately owned, semi-illegal, or totally illegal are appropriate or legal for such use.

If I want P.U.R.E. in a repo, for example, I'll put out a GPL'd version and accept that it's all GPL, period. Otherwise, no.

CA, IW and Gundam can't ever be put into a repo, because they're never ever going to be legal. If you've been putting CA or BA or any *A into a repo, you're in clear violation of copyright.

The only games that I know qualify are NanoBlobs, S'44 (when certain CC stuff is dealt with, anyhow), Simbaes (I think)... and a whole slew of things from KDR_11K, which are all using licenses that are legal.

I don't think Evo qualifies, because CC licenses requiring credit cannot be put under the GPL. I can't speak for all of the "dark" projects, or obscure stuff I'm not familiar with, or things I'm just too lazy to look at, of course.

****************************************************
****************************************************

Lastly, I have read a few hot-and-bothered posts here over the last week, from people who have, obviously, avoided actually reading the thread.

Please, either read the thread, and understand what has been argued, and how those arguments have been evolving as those of us who are actually interested in the facts and law involved have been digging and discussing... or don't bother posting.

Some of the exploration in this thread is bound to be contentious, because there are areas where U.S. copyright law, for example, differs in important respects from copyright laws elsewhere, and U.S. copyright law is, if we're being really honest, despised in a lot of countries because it's so damn restrictive.

That stuff was actually fairly important in terms of understanding CA's particular status, but I think those issues have been settled- CA's clearly an infringing work. My current stance is that that means they're probably in violation of the GPL specifically regarding inclusion in CA, but that's Atari's problem- game designers are still restricted, although the "mere aggregation" argument, if it holds together, would solve most of the major griping about this stuff.

Moreover, the conversation's even more difficult because it doesn't just hinge on copyright, but it also involves the GPL, which is, as has been pointed out many times, not a bulletproof, well-tested license, but is in fact questionable in many places. The FSF has advanced many claims that I personally think are really shaky and won't withstand serious questioning.

This makes things messy as hell, to be perfectly honest- the FSF's interpretation of copyleft is so broad that even Linus Torvald has had some heated arguments with them fairly recently about "mere aggregation", so it's far from a settled area of law, and will almost certainly get into court at some point and argued to the finish... maybe a decade from now.

We're probably breaking new ground here, to be really honest, because Spring's a very strange entity, software-wise, combining multiple programming languages and file formats which interact in various ways. Which is why I brought the web browser example in- it's the closest comparative model I could think of.

So, before writing flaming posts which basically prove you haven't examined what's been said, and why, and who's arguing what, do yourselves a favor and read, for a change.

[AF]

Argh, in this day and age, saying less is saying more. I believe picasso pointed out an article detailing how the way users of the internet read is different and that theyre more likely to get something out of a 10 sentence post than a 100 sentence post.

When you post, I think you could gain much better returns by rerunning through your post and making it briefer and re-arranging its structure, or splitting a large post into several. Otherwise its just too much text to read and it becomes a wasted effort.

Right now the preceding post is not going to be read by 99% of the people you intend it to be read by. It inspires lethargy and boredom before a single word has been read due to its sheer size.

I would recommend that you dont post anything if it requires the use of a vertical scrollbar. One could argue this post is too long too.

[KDR_11k]

If it was aggregate it would be separable. IMO only widgets that are also available independently (or could be, at least) would fall under that since they're only included for convenience. Gadgets cannot be removed without changing (usually breaking) the game and often contain game-specific data that would require adjustments to be used in another game.

[SwiftSpear]

GPL has qualifications for collections (IE, if you put a GPL code snippit in a collection of other code snippits the one item doesn't poison the rest because it's a "collection") and aggregation (which is just poorly described). The reality is there is no right/wrong way... it's just whatever a judge decides if it's brought into a court of law. Neither of those elements are explicitly defined under GPL.

So ya, it's a license intended to be used for code, and it easily breaks when applied to art, script, story, design, or anything that isn't code. Basically, I don't recommend it for mods, the legal definitions are too loose and you generally aren't getting yourself the protection you actually want... And even worse, you're greatly increasing the risk of someone doing something you personally consider a violation, but realistically speaking is gray area when it comes to GPL legal definition.

Argh's giant wall of text is irrelevant because the way he thinks GPL works is basically irrelevant to it's actual legal standing. The reality is anything that looks like a loophole, is a loophole, until some guy with a black robe, curly fake hair, and a wooden hammer says otherwise.

[Peet]

Please develop at least a basic grasp of how sync in Spring works before you attempt to tie it into a license argument.

[Argh]

If it was aggregate it would be separable. IMO only widgets that are also available independently (or could be, at least) would fall under that since they're only included for convenience. Gadgets cannot be removed without changing (usually breaking) the game and often contain game-specific data that would require adjustments to be used in another game.

First off, I agree, Widgets are clearly not gamecode in any real sense.

I'd like to argue, though, that Gadgets are separable, if you look at how Spring runs when we're not dealing with MP. That's why I zeroed in on the sync argument- I thought that would be a useful point to explore.

If code doesn't interact with any other Gadgets or isn't returning arguments to COB (thus, if missing, they could probably cause halts in Spring's game state)... removing them just removes a feature, it doesn't halt the game, or cause real errors. It's not like removing, say, a crucial line from Spring, which causes the program to crash, even if it can be compiled.

The game would continue to run normally, just differently than the gamestate with the Gadget. Gadgets are, basically, features added to the totality via a scripting language.

Removing a Gadget is like, say, removing some rendering mode that's non-optional once the game engine starts, except with the crucial distinction that they aren't connected to the entire rest of the game engine through headers. Spring's full of stuff that's essentially un-separable during runtime. But Spring Gadgets may crash or have other problems, yet they won't halt the game state. It's a pretty important distinction, imo.

Seen this way, they aren't part of a "whole" any more than a collection of PHP scripts running a website's front-end can be argued to be a "whole website"- you can legally use GPL and non-GPL scripts to do that, together, and nobody would argue that they're "inseparable" in that case.

There are several Gadgets in P.U.R.E. that, if one party removed them, would not cause problems for other players, if sync didn't work the way that it does. They don't effect gameplay, per se, they add other functionality, such as the soundtrack.

Please develop at least a basic grasp of how sync in Spring works before you attempt to tie it into a license argument.

Well, here's my understanding, just to be sure we're on the same page here. If I'm wrong, correct me.

Spring's game code runs in a frame-bound simulation. Every sync update expects all players to have computed up to the same frame of the simulation prior to sending the update.

Communication between clients about changes made, such as orders issued to units, is transmitted to the host and clients, which keeps everybody in lockstep and allows them to continue to calculate gamestates in the same way that other players do.

If a given player's computer has not finished the calculations for that frame, or cannot do so due to a software problem, they are no longer in sync with other players.

This is different from a client-server model, where the gamestate is what the server says it is, and clients are always lagging behind the server to one degree or another, but are allowed to update their gamestates arbitrarily when the server sends new messages.



Am I missing something fundamental here? I thought that the whole idea of sync was to keep everybody's simulation locked together, as a basic form of anticheat, along with the hash-checking that occurs in Lobby clients and Spring. If it's more detailed than that... meh, what, if anything, about the details changes the fundamental arguments expressed above?

Sync's one of the more dubious major features of Spring, imo, and its flaws aren't pointing to a concept of a "whole game", they're simply a part of how Spring works at this time. If Spring used a client-server model, we'd be mainly looking at the more important argument that KDR raised, which is the concept of separability.

Argh, in this day and age, saying less is saying more. I believe picasso pointed out an article detailing how the way users of the internet read is different and that theyre more likely to get something out of a 10 sentence post than a 100 sentence post.

I think it's amusing that people think that, and even (this made me really laugh) write fairly long essays about it... when in reality, most serious communication is, well... lengthy and detailed.

I have zero sympathy for the texting generation, AF- you guys are going to have to learn this one the hard way, frankly, just like my generation had to learn that IM is generally a waste of our time.

The Wall Street Journal, for example, doesn't have short editorials or stories for the exhausted Googlelite searching for wisdom in short, comfy bites- their stories and editorials are frequently longer than any three of my "giant" posts.

People who aren't lazy, and want to know what's happening or what people think... read them. Lazy people read a crappy, non-detailed and probably incorrect version on Yahoo or some other place for the intellectually challenged.

And it's not my problem that other people are too lazy to read long posts during this part of the process. I'm not writing for them here. They're going to need some sort of summary when this is all settled anyhow, that can be stuck in the Wiki.

At some point we should be able to get all of this down to a paragraph, probably a short one. What I'm trying to do is to figure out what that paragraph should actually say, and there's no short way to go about that.

Argh's giant wall of text is irrelevant because the way he thinks GPL works is basically irrelevant to it's actual legal standing

That's a silly argument, imo. What I'm doing is actually looking at its legal standing, and what's been tested, and what might survive scrutiny, based on my understanding of how the law works and how it applies to Spring games, however incomplete.

You're basically arguing that just because we see something falling, we don't know whether it will eventually land somewhere. It's possible, but it's not probable. There is no certainty, when it comes to law. Law involves people and unique circumstances, and very little of it is immutable or entirely predictable.

[AF]

The value of being concise is extremely high, one should not dismiss it as the domain of teenagers on mobile phones. Either way its worth it if you entail a greater number of readers and thus responses.

[jcnossen]

The reality is anything that looks like a loophole, is a loophole, until some guy with a black robe, curly fake hair, and a wooden hammer says otherwise.

There is no certainty, when it comes to law. Law involves people and unique circumstances, and very little of it is immutable or entirely predictable.

I agree with both, but with this reasoning, I don't see the point in these walls of text and endless license discussions. Swift really makes a good point, you can reason all you want but in the end its about what a judge will decide.

Very likely there will never be lawsuits about spring, so I suggest just describing how you want your contribution to be used by others, in spring related terms. Especially Argh, since he doesn't seem to be able to discuss stuff in a readable way

[Argh]

I agree with both, but with this reasoning, I don't see the point in these walls of text and endless license discussions.

The point is that many projects aren't using CA's source precisely because the boundaries of the licensing issues aren't well-understood.

There really isn't a fast way to get that settled, without exploring the fundamentals about license, people.

If it was up to me, I'd say that people should license any way they feel like it, for any part of their games, and everybody should use the code appropriate to the license of that bit.

Like, say, NanoBlobs was licensed. Originally. Before everybody pitched a fit, and told me that it was copylefting games, and I felt that it was necessary to enforce it because of that assertion.

However, that's what I'd like... not necessarily the reality. When we have people asking to use stuff, but afraid they're breaking the GPL by doing so, it's very important that it's clear where the GPL starts and ends.

That's how one prevents lawsuits in the first place- by clearly engaging in a good-faith effort to adhere to a license. It'd be very hard to bring a lawsuit against, say, Fanger, for using GPL'd code in E&E, if the arguments about aggregation were accepted, and he made it into a commercial game. If they aren't, his project's violating the license.

Moreover, we have various "dark" projects out there, people. There are projects that I've seen hints of in various off-site areas, whose teams never show up here.

We don't know how many of them are groups with the intent to sell games made with Spring, or a variant of Spring. We don't know how much stuff they're taking from other games. We don't know how many of them will be completed, and when, and whether we'll be told about them.

Nor do we know to what extent Spring's being bundled in game-pack CDs or other issues. And this is very likely to accelerate, as the engine matures past what's in SVN, which is a considerable leap forward in terms of capabilities.

Settling the license stuff for once and all is in everybody's long-term interests here. I don't intend for this discussion to be endless. I want it to get it thrashed out, let the dust settle, and post something definitive in the Wiki, so that it's clear to all. That requires a lot more work than just declaring a fiat and hoping it sticks.

[Forboding Angel]

Am I one of 3 people here who doesn't have a problem with reading?

Course to that end, I read all of the time, so i guess it's nothing new to me, nor do I have an extremely short attention span.

I can completely understand what argh means by the texting generation. I remember when it was necessary to write 30 page reports an a *GASP* typewriter, or in the event you didn't have one, get 5 pencils and a lot of paper. People truly are lazy today.

[Peet]

I'd certainly go for a super tl;dr over a Gota or Otherside post any day.

In any case, Argh, I don't really have the time or the motivation to spell out how (afaik) syncing works right now, but I can tell you that several of your primary points above are incomplete or erroneous, and I suggest you simply think over how the situation you've described would work out for the average game of spring.

[Argh]

In any case, Argh, I don't really have the time or the motivation to spell out how (afaik) syncing works right now, but I can tell you that several of your primary points above are incomplete or erroneous

When you can point them out, I'm willing to consider how they effect things.

Basically, though, the technical details don't matter a lot in the end. My point is that MP Spring doesn't represent the case for / against separability very well at all.

When we're developing a game, we're not dealing with sync, we're dealing with stuff that can crash the game engine. There's the clear dividing line, I think, between what's truly separable, and what's not.

Sync is an artificial barrier that's specific to online play, that produces issues that aren't seen when building a game as a developer or testing in SP. Sync could be removed from Spring in favor of a traditional client-server model, and voila, the issues are gone, now we're back to separability, because the server would control the game state, period.

[Forboding Angel]

I'd certainly go for a super tl;dr over a Gota or Otherside post any day.

In any case, Argh, I don't really have the time or the motivation to spell out how (afaik) syncing works right now, but I can tell you that several of your primary points above are incomplete or erroneous, and I suggest you simply think over how the situation you've described would work out for the average game of spring.

I don't know if it's intentional or not, but you're being very very vague. Could you please just lay it out instead of simply relying on "You == rong!"?

Basically, put up or shut up, the vague references are not helpful and are aggravating because if there is something that should be included in the discussion, we would like to include it, but we must know what that something is, capiche?

[Peet]

Thirdly, a desyncing piece of code almost certainly should cause desync for all players, if it wasn't related to something hardware or OS.

That would be the case if desyncs were...synced. If "desync for all players" occurred, there would be no desync; the simulations of the clients are compared to that of the server. The whole concept of a desync is, by definition, when one or several clients' simulations differ from the host's.

To argue in a bit more detail, specifically about what sync is, and how it works... let's say that World Builder runs, and one guy's computer is so slow that his machine finished a second behind everybody else's. His machine is too late for the communication to occur at the right timestamp, he desyncs, everybody else is fine.

....nope.

Spring's sync requires things to happen within a very finite time limit, and even chain-reaction explosions are infamous for causing desync to occur, because somebody's machine grinds to a halt.

...nope. CPU bottlenecks result in the sim slowing down, allowing all simulations to proceed at more or less the same pace. Network lag just causes a client's simulation's speed to rise and fall intermittently as it recieves the data it needs to continue.

we may need a Lua method to halt the game state and request a halt of all communication attempts and basically restart the sync,

If this were implemented it would be in the engine, above the rest of the sim...implementing a resync call from lua, whether synced or unsynced, is absolutely ridiculous.

so that certain complex operations can occur without causing desync due to the sync timer inexorably moving forwards.

Again, the sim will slow down on all clients to let the slowest one catch up.

Mainly what I'm saying is that desync's mainly an engine-side problem, and that some aspects of it will probably need to get altered in the future to allow for more flexibility in game designs.

The current setup is pretty much the most suitable one for a physics-heavy rts. All that would (/needs to be) changed is the addition of resynchronization.

it just points out one of the big issues with the sync model, which is that it's terribly inflexible and can't respond to demand very well.

Running the simulation on one machine and transferring over every bit of data might work on internet connections ten years from now, but certainly not at this point. Synchronized simulation also prevents cheating (other than the bypassing of 100% client-side restrictions - maphacks etc).

The cause of a simulation's desynchronization is never or almost never due to lag, either of the network latency or cpu overload varieties. The primary causes are unsynced writing to synced code (either through a badly planned explicit call in spring's code, or because of memory corruption, writing/reading past an array bound, utilizing a pointer to a location that has been reallocated, etc), and floating-point errors caused by hardware inconsistencies (both architectural and caused by instability).


Do correct me if I'm wrong on any of this or expand on my points, anyone; I'd appreciate further knowledge on the subject.

[Forboding Angel]

Thanks for writing that, Most of it I actually knew (reading tobi's posts and such) but a good bit of it I had forgotten about. Nice to have a refresher course anyway.

[Argh]

The cause of a simulation's desynchronization is never or almost never due to lag, either of the network latency or cpu overload varieties. The primary causes are unsynced writing to synced code (either through a badly planned explicit call in spring's code, or because of memory corruption, writing/reading past an array bound, utilizing a pointer to a location that has been reallocated, etc), and floating-point errors caused by hardware inconsistencies (both architectural and caused by instability).

If I accepted your entire argument as true, which I don't, because I think you're overstating your case a bit (in 0.76b1, we have documented cases of Widgets and Gadgets causing desync, due to a number of things that have been addressed in SVN)... it pretty much demonstrates that desync is an engine-side problem, and doesn't establish anything about the "whole game" argument.

Why? Because you're basically saying that desyncs cannot be caused by gamecode. IOW, if this was supposed to weaken that argument... well, it did the inverse.

You've just demonstrated that KDR's assertion was basically based on an erroneous understanding of what a desync means, and that there's no way to establish a "whole game" argument based on desync, because desyncs are, by your definition, not the fault of game developers. I hope that was what you intended...

[jK]

1.
reminder: "Why P.U.R.E. will not be GPL or CC-PD. Very long."

After reading multiple essays, it should be renamed to: "How to steal CA content."

2.
And no E&E, EvoRTS or any other project that stole my/our content is NOT legal.
The fact that we aren't starting flame wars only shows that we have an interest in this project and that we prefer to create new content instead of wasting time on writting "very long" essays of ignorance.

3.
and a small note to your attempts as a hobby lawyer:

The difference between this and ├óÔé¼┼ôincorporating├óÔé¼┬Ø the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can't treat them as two separate programs. So the GPL has to cover the whole thing.

And you don't even understand the GPL itself (nor how software works), so how do think you could scrutinize its legal status?
So please stop making assumptions and searching in law books you don't understand, just accept it!

4.
It is still your decision to use a proprietary license, so live with the consequences!