FSF stance on GPL issues.

[Argh]

I know, and that was a mis-statement, I apologize. At the time, I saw things differently, but the whole story was rather more complicated.

[smokingwreckage]

Smoth: didn't Argh actually say "that was how I saw it at the time" and acknowledge that he was wrong?

[smoth]

in his edit, yes.

No need to butt in, it doesn't really have anything to do with you.

[KDR_11k]

Copyright law, by default, allows use. If the GPL is voided you can still install and run a GPLed program without being infringing. As mods contain no part of Spring and thus do not distribute Spring the only question would be whether using an API via function names constitutes a derivative of the API or the program implementing it because ONLY THEN does anyone have a claim against the distribution of the mod (and only if there are no interoperability exceptions in the law).

Also you make me look like the bad guy for trying to find out what the real interpretation of the license is that gets used by so many people. Just because we reach a consensus among ourselves and all think one interpretation is right that doesn't mean it really is right, some people are putting large legal documents on their projects without really understanding what they mean or possibly having a wrong understanding of the document. That's not a good thing, if you want a license to mean a specific thing make sure your license actually says that rather than something else you don't want.

[smoth]

I hope I didn't come across that way, I am glad we have some sort of answer. Are you still investigating/discussing with them?

[Argh]

Copyright law, by default, allows use. If the GPL is voided you can still install and run a GPLed program without being infringing. As mods contain no part of Spring and thus do not distribute Spring the only question would be whether using an API via function names constitutes a derivative of the API or the program implementing it because ONLY THEN does anyone have a claim against the distribution of the mod (and only if there are no interoperability exceptions in the law).

That's pretty much what I was thinking to be the case, due to the very narrow thread of reasoning making Lua / BOS code GPL due to some function calls, which aren't even real function calls- they're calls to an API, which then does the actual function calls.

The only exception I see for this is where two or more Lua scripts define and use a shared memory structure. This is possible when they're utilizing global variables- at least, that would be my interpretation of that event. I think that using a non-GPL script that depends on or alters a global variable defined in a GPL script is probably GPL'd at that point. So you can't, say, build LUPS code that depends on jK's LUPS work, and declare that it's private code and that nobody can use it- I think that's just plain lame, to begin with, but moreover, I doubt it's legal.

Also you make me look like the bad guy for trying to find out what the real interpretation of the license is that gets used by so many people. Just because we reach a consensus among ourselves and all think one interpretation is right that doesn't mean it really is right, some people are putting large legal documents on their projects without really understanding what they mean or possibly having a wrong understanding of the document. That's not a good thing, if you want a license to mean a specific thing make sure your license actually says that rather than something else you don't want.

My intent is not to make you out to be a bad person here, KDR. I apologize if it seems that way.

I'm just frustrated that this is still floating about, after the last great debate, which I was really thinking would be the final one on this, settling these issues once and for all, and without anybody getting shafted in the process...

[Das Bruce]

I'm just frustrated that this is still floating about, after the last great debate, which I was really thinking would be the final one on this, settling these issues once and for all, and without anybody getting shafted in the process...

Perhaps this one should be summarised and stickied?

[Radtoo]

Copyright law, by default, allows use.

Two comments:
You can actually restrict this default further, not just expand, if you do it at the point where the rights to a copy is granted. Lets continue...

If the GPL is voided you can still install and run a GPLed program without being infringing

If a license or contract that granted you the right to a copy is voided, you even don't have the right to have a copy anymore, unless that was explicitly stated otherwise in said license or contract. You can't use anything without a copy, can you?

Now, the GPL voids as a whole. In general, you can always get a new one, and base your continued use on this.
But depending on whether your country has laws about invalidating licenses and contracts accepted in "bad faith" etc. or not, and their scope, you may have voided your license AND not be able to claim a valid new one prior to rectifying the situation.

This isn't dynamic linking.

Bingo. That's what I thought, too, when you quoted the shared memory stuff.
Basing this "key argument" on an unrelated, not-in-license FSF FAQ text that merely gives two extreme examples what certainly needs / needs not be GPL'd in the specific context of shared libraries is not working out - it is too much of a stretch.

Also, as far as I can tell, it was you who brought this interpretation up "the last time" ("Why P.U.R.E. will not be GPL or CC-PD. Very long."), and no one else even mentioned it, much less proved?

Yes, many signaled that this would be desirable or okay, but it is not there, at this point...

This isn't all "one program" in any real sense. Users experience it that way, but it's an illusion.

I find it hard to make this point soundly. It would be much easier once you take the API-calling mod-code out of the equation by GPL'ing it, as then we can easily claim that everything is in order - the rest runs interpreted, or is part of program input (falls under the unrestricted "running" of the program).

[Argh]

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.

From GPL, V. 3.

Lua scripts are neither "shared libraries" nor are they "dynamically linked subprograms", unless, like LUPS, they were designed as such, and are deliberately operating in that fashion with other Lua scripts.

Nor do they make use of "intimate data communication or control flow"... unless, like LUPS, they were designed as such. That's what the API layer is all about.

And they don't share memory locations, much less "shared data structures". Which is far from an irrelevant point, given that the FSF posted that themselves. The FSF knows there are limits past which very few judges are likely to agree with them, on the scope of what constitutes a "dynamically linked subprogram".

If I accepted your argument at face value, then everything in Linux is ultimately GPL, because it no doubt needs to interact with the OS at some level. That's clearly not the case... for the exact same reason, which is that Linux has an API layer providing intermediary services. The fact that a Linux application is very unlikely to be 100% operable in other operating systems if the source code is compiled in them without modification because of this is irrelevant.

If any project demonstrates that argument's solid base in reality clearly, it's Spring and the Lobby projects, which have had to use all sorts of hacks to deal with multiple OS requirements and different API requirements to accomplish certain tasks, and aren't all interoperable (TASClient, for example).

They're separate pieces of software. All Spring does is interpret the API calls, in a particular manner- it does not directly interact with the software as such. We can run the Lua in different environments- heck, the Lua editor I use runs my scripts, to verify that they operate, just as Scriptor checks the instructions as it converts a BOS into a COB.

Are we done now?

[Radtoo]

From GPL, V. 3. [...]

I wished this was an option, but Spring is licensed GPLv2, not GPLv2 or newer. See for yourself in the Spring license .

If I accepted your argument at face value, then everything in Linux is ultimately GPL, because it no doubt needs to interact with the OS at some level. That's clearly not the case... for the exact same reason, which is that Linux has an API layer providing intermediary services.

No, it is for this reason:

GPL v2, section 3 (EDIT: Not part of subsection c), sorry.):

[...]as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.[...]

[Argh]

I wished this was an option, but Spring is licensed GPLv2, not GPLv2 or newer. See: https://spring.clan-sy.com/svn/spring/t ... CENSE.html .

Well, in that case... this is all V. 2 had to say about these topics:

If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.

And V. 2 says zero, zip, nada about linking, memory, etc. That's all V. 3 language- V. 2 never dealt with any of that in any way, shape or form, except for that section, which clearly does not cover games for Spring. You can "operate" Spring without any games at all, after all. It won't do anything useful, mind ye, but it "operates".

And certainly games could be "reasonably considered independent and separate works in themselves" for the reasons already explicated in greater detail, above.

So, V. 2 would cover Spring and the contents of the Installer, before it begins downloading from websites or other locations. Which is just fine, and puts us right back to the compromise arrived at earlier, tbh.

Moreover:

In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.

Means that Spring could be distributed with games, and it would be entirely legal, so long as Spring's GPL notices were kept intact and you were willing to provide Spring's source for free when asked.

[KDR_11k]

http://www.copyright.gov/title17/92chap1.html#117

(a) Making of Additional Copy or Adaptation by Owner of Copy. ├óÔé¼ÔÇØ Notwithstanding the provisions of section 106, it is not an infringement for the owner of a copy of a computer program to make or authorize the making of another copy or adaptation of that computer program provided:

(1) that such a new copy or adaptation is created as an essential step in the utilization of the computer program in conjunction with a machine and that it is used in no other manner, or

You get your copy from an authorized distributor, unless that distributor's GPL was voided beforehand you do own a copy and therefore have the right to use the software (also there's a reason the GPL states you don't have to accept it in order to use the program). EULAs circumvent this by claiming you never bought the copy but without that technological measure to circumvent legal provisions the absense or invalidity of a license cannot prevent you from using your software (hell, console games don't even HAVE licenses, at least none the end user is party to).


Argh: Arguing by mentioning Linux is futile, the Kernel gets a special exemption as do things like compilers (I'd claim this extends to Spring as well since Spring acts as a runtime environment for a mod but that's a shaky assertion).

[Argh]

I'd claim this extends to Spring as well since Spring acts as a runtime environment for a mod but that's a shaky assertion

Yeah, I haven't even bothered advancing that one, since I think it's stronger to simply assert that the Lua is capable of running somewhere else, operates through an API layer, and therefore the whole subject is moot.

And yes, I am aware of the provisions in regards to the EULA. Basically, whether or not I'm in violation, the users aren't, according to the GPL. This was done to keep end-users from getting sued because somebody used a bunch of GPL code in a commercial program.

In short, what the EULA does is forbid transmission of copies that are in violation, putting the violator in a position where they can be sued for damages, for voiding the license and thus becoming the guilty party in a copyright suit. Because, ultimately, that's where the mechanics of the GPL are aimed at- establishing that certain types of activity make the GPL's protections of use void, and thus opening up the possibility of copyright suits.

All that said... in no way, shape or form does building a game involve violating other people's copyrights, unless you're violating the copyrights of somebody else who's been building content. You're not modifying Spring, the executable, or its source.

You're making many separate pieces of software that you intend to be used in a software environment that Spring ultimately turns into certain end results.

[Radtoo]

I guess I can consider and disprove another n wrong theories about API calls in LUA being different because of $random_argument, it will just result in the next thing coming up.

If the last ones that Argh specifically brought up were correct, so be it - I'm already sure I'll have a hard part explaining the concepts to people who would understand less about software than Argh, who is familiar at least with that part; thus I won't take the risk that I have to. (Imagine questions like "And how is any piece of source code different from an API that is simply used?" and all that stuff that could come up, which I deem hardly up to un-answerable).

I hope to conclude my part in this by stating that I still see benefits for full sharing of mods, but in cases where this is not okay with the authors, I still hope they can especially make this concession and GPLv2 the API-using LUA stuff, so that DISTRIBUTORS of what could be argued to be combined works have something easily proven to be a correctly licensed aggregation of works.

[jK]

If I accepted your argument at face value, then everything in Linux is ultimately GPL, because it no doubt needs to interact with the OS at some level. That's clearly not the case... for the exact same reason, which is that Linux has an API layer providing intermediary services. The fact that a Linux application is very unlikely to be 100% operable in other operating systems if the source code is compiled in them without modification because of this is irrelevant.

First, there is an exception for kernel/os API's. Second, most other (non-kernel) APIs are under LGPL or similar licenses.

I'd claim this extends to Spring as well since Spring acts as a runtime environment for a mod but that's a shaky assertion

Yeah, I haven't even bothered advancing that one, since I think it's stronger to simply assert that the Lua is capable of running somewhere else, operates through an API layer, and therefore the whole subject is moot.

but the API is under GPL!
If you wouldn't use the API at all (plain lua code) then you wouldn't have to GPL your program. Spring would be nothing more than compiler, but instead you use an API, which let you interact with the engine as would you program code for the engine itself, so it is part of the program.
So you couldn't even compile a java program against a GPL'ed API, w/o GPL'ing the final program (there is a unsolved issue, if the program have the same binary code when if you built it against a proprietary API -> the GPL'ed API wouldn't have any influence on the final program).

[Warlord Zsinj]

RESISTANCE IS FUTILE!

[Argh]

Ah, WZ... I haven't even started to resist yet. These guys have no idea what a horrible can of worms they're opening.



According to what we've read, even if all of these arguments were correct, I'd only be in violation if I distro'd Spring itself with my game.

Distributing P.U.R.E. by itself is not in violation. And I have no intention of doing a distro that conjoins them, other than the Installer, which is fetching from remote 'sites... which neither here nor there, insofar as I'm concerned.


But wait... let's even give that last fig leaf up. Let's say that no matter how I distribute P.U.R.E., it's in violation.

Where does that leave us?

I mean, if making the code makes stuff magically GPL... then every *A is not only violating Atari's copyrights, but has also voided the GPL, because you're using proprietary source in a context that has been labeled GPL.

So... all of the *A's... all of those projects have voided the GPL, for using non-GPL source within the GPL engine. Because the FSF's statement specifically included BOS. And the BOS code is either directly taken from OTA, or is clearly derivative, or was written by third parties who you can't even contact, I'm betting.

I suppose this could be corrected, but it'd be really quite hard to duplicate the functionality without being derivative, especially as whoever did the corrections would, provably, have had access to the original source code. And you'd have 30 days, to boot.

So, as a Spring contributor... I could (theoretically, mind ye- I do not actually want to) sue you, for copyright violations and damages... if I accept your logic

[EDIT]Removed various inflammatory statements. Never post while having an epiphany if you're still mad...[/EDIT]

[smoth]

a horrible can of worms they're opening.

Kindly, do not start this line of logic/action/drama again. It will only annoy myself and others.

[Warlord Zsinj]

/me notes that his post was intended as a humorous aside and he wouldn't touch this particular discussion with a 50-foot pole.

[Pressure Line]

/me notes that his post was intended as a humorous aside and he wouldn't touch this particular discussion with a 50-foot pole.

also