SRB2 Add-ons, and GPL-compliance.

Maril

Maril

Fluffy Kitsune Connoisseur
I recently discovered during a conversation in the SRB20YA Discord server (a pretty great place btw), that any piece of code that interfaces with SRB2, must be GPL-compliant. This implies that any add-on that contains a Lua script, SOC script, map, or even a mere text file that is interpreted by SRB2 for use with SRB2 must be GPL-compliant, and must be allowed to be shared, edited, and modified by others, regardless of reusability (which is just a guideline), or whatever license that you provide with your add-on. This implies that we creators of add-ons for SRB2 cannot protect our work that we've spent days, weeks, months, or even years making, as if you don't provide a way for people to modify your add-on's code-based features, you're violating the GPL license.

I got input from SSNTails himself however that any non-code-based assets are safe from GPL, but essentially your Lua scripts, and stuff are not safe.
Post automatically merged:

I would like to mention this now before people question. Reusability does not protect your code from being shared and edited OUTSIDE of the SRB2 MB. It only protects others from uploading your code on the MB.
 
Last edited:
It's probably worth noting that STJr can choose whether or not to do anything about GPL violations, the same way Sega can choose whether or not to do anything about STJr violating their copyright. It's been 25 or so years and they haven't come after anyone for GPL violations, so I think we're fine for the time being.
 
Thank you for the notice PencilVoid :wonderful:
I'm just paranoid over things like this ahaha
 
Maril said:
I recently discovered during a conversation in the SRB20YA Discord server (a pretty great place btw), that any piece of code that interfaces with SRB2, must be GPL-compliant.
Click to expand...
Source? That's a pretty large claim and as someone who has read GPL v2.0 with a veritable magnifying glass, I'm not sure where it talks about that.
 
Charybdizs said:
Source? That's a pretty large claim and as someone who has read GPL v2.0 with a veritable magnifying glass, I'm not sure where it talks about that.
Click to expand...
Assuming you're in the SRB20YA Discord server: https://discord.com/channels/691612453548851261/691625899153555476/1232333353676439642

Otherwise, this was some stuff shared by others in the conversation, and then a snippet of something SSNTails said:
1713895264039.png
1713895235775.png

Post automatically merged:

When the interpreter just interprets a language, the answer is no. Theinterpreted program, to the interpreter, is just data; a free softwarelicense like the GPL, based on copyright law, cannot limit what data youuse the interpreter on. You can run it on any data (interpreted program),any way you like, and there are no requirements about licensing that datato anyone.
Click to expand...
I tried mentioning the first paragraph, that being the above, and it was seen as a good argument, but from what SSN was saying, this doesn't apply to SRB2.
 
Last edited:
As I kind of expected from previous experience, none of these things reference the actual text of GPL 2.0 itself. 🤔

Like I said, I've read it very thoroughly. We do have some GPL issues that currently exist floating around the community (they've been on my mind to resolve even if it isn't popular to do so), but these ain't it.

I do recommend reading the actual license though. Frankly, it's the responsibility of anyone who codes in SRB2 to do so.

GNU General Public License v2.0 - GNU Project - Free Software Foundation

www.gnu.org www.gnu.org

But yeah, they can say all sorts of things in their FAQ on their site (and they do a lot of conjecture there) but just because they say it to be so doesn't make it so. The actual legally binding part of a license is the text of license itself, not people's theory on a license. Unless you could show, like, Supreme Court precedent on interpreting the text of a license in a particular way on this exact topic, the text of the license itself is what actually is relevant, not an FAQ making things up.

That FAQ there is not even talking about the license at all, it's talking about a completely separate legal question, of "does using a library mean your code must fall under the license of the library?"

And the answer to that is yes, whether it's compiled into it (static) or a .dll file (linked) -- this is commonly accepted.

However, that is talking about libraries. SRB2's Lua interpreter is not a library, it is an API. Those are two different and legally distinct things. Using an API doesn't subject you to the same requirements as using a .dll library does, even though both are remote calls to separate software. If using an API meant you needed to comply with the source code license of an API, all programs which communicated through APIs with restrictive licenses would be illegal. (They aren't)

Two interesting things to think about:
#1: If a Lua script could be made GPL-mandated by nature of running in SRB2, I could make a GPL program that can interpret other people's Lua scripts NOT made for SRB2, you would then have to ask if those scripts suddenly needed to be GPL. (the theoretical possibility of infecting other people's work by sliding in with a GPL interpreter is very funny 😂)

#2: If using an API meant I needed to comply with the terms of the software behind it, all programs which use an API to communicate with proprietary softwares (let's say like, any MMO, or websites like Weather.com for example) would be illegal.


Personally, I think the differences between a library and an API are semantics, but it doesn't mean they aren't legitimately treated as different types of software in the legal sense.

If we abandon all the technicalities and go with "What is the spirit of the law? What did the SRB2 devs interpret this to mean?" Then I think the floor is open for them to speak.

However, I will also posit the following text, notably from the license itself.
1713899149080.png


The definition of what qualifies a "derivative work" is something which goes super deep and gets super muddy in software. In this case, it can definitely be argued in a lot of different ways. Afraid there isn't always a super clear answer. That's why people debate for months over this stuff in court cases.
 
Last edited:
Regarding Lua and the GPL, the Blender Foundation for instance has it in their FAQ that all python addons be under that license (to be on the safe side since the license is not exactly clear on that), though Blender is on version 3 which seals some loopholes and workarounds that might lead to non-free content interfacing with the application. As a consequence of this, the Blender Market has all of its Python-centric addons on Github and largely relies on an honor system to have revenue come in (that being you respect the creator enough to pay the asking price). This only concerns the raw code (as anything else that might be attached to it is considered 'data' and not covered by the license).

I am not a lawyer by any means, just mentioning an example of how the biggest name in FOSS creative software approaches it.
 
Last edited:
Yeah, "to be on the safe side" is the funniest thing -- that level of "ummmmmm we don't ACTUALLY know" shouldn't even be on the table when dealing with licenses.

The Linux kernel is another example: Linux is GPL, and everything based on Linux will interface with the GPL operating system, but there is no mandate that all programs designed to run on Linux must be GPL. Quite the opposite.

My personal advice is, use licenses that say exactly what you want them to say and don't leave things up to interpretation. Hell, study up, think about what matters to you, and carefully write your own if need be.

I can't envision a single circumstance where I would ever want to make private code for SRB2, personally. Art, sure, but code, not really. But regardless of my personal feelings, I do know this: Any claim that all Lua ever made in SRB2 objectively, definitely, matter-of-factly must be GPL is wishful thinking at best, no matter who it comes from. There are objective and matter of fact parts of the GPL -- this is just not one of them.
 
Charybdizs said:
The Linux kernel is another example: Linux is GPL, and everything based on Linux will interface with the GPL operating system, but there is no mandate that all programs designed to run on Linux must be GPL. Quite the opposite.
Click to expand...

The linux kernel has a line that specifically excludes system calls from being part of the GPL license.

I don't have any strong opinions on this matter as I don't see GPL mattering outside of genuine legal issues, but it's worth pointing out.
 
Hello, it's been a while since I've been active on this forum, but I just saw this thread and felt I can add a few things. Disclaimer: I am not a lawyer.

Maril said:
Assuming you're in the SRB20YA Discord server: https://discord.com/channels/691612453548851261/691625899153555476/1232333353676439642

Otherwise, this was some stuff shared by others in the conversation, and then a snippet of something SSNTails said:
View attachment 117851View attachment 117850
Post automatically merged:


I tried mentioning the first paragraph, that being the above, and it was seen as a good argument, but from what SSN was saying, this doesn't apply to SRB2.
Click to expand...
Charybdizs said:
As I kind of expected from previous experience, none of these things reference the actual text of GPL 2.0 itself. 🤔

Like I said, I've read it very thoroughly. We do have some GPL issues that currently exist floating around the community (they've been on my mind to resolve even if it isn't popular to do so), but these ain't it.

I do recommend reading the actual license though. Frankly, it's the responsibility of anyone who codes in SRB2 to do so.

GNU General Public License v2.0 - GNU Project - Free Software Foundation

www.gnu.org www.gnu.org

But yeah, they can say all sorts of things in their FAQ on their site (and they do a lot of conjecture there) but just because they say it to be so doesn't make it so. The actual legally binding part of a license is the text of license itself, not people's theory on a license. Unless you could show, like, Supreme Court precedent on interpreting the text of a license in a particular way on this exact topic, the text of the license itself is what actually is relevant, not an FAQ making things up.

That FAQ there is not even talking about the license at all, it's talking about a completely separate legal question, of "does using a library mean your code must fall under the license of the library?"

And the answer to that is yes, whether it's compiled into it (static) or a .dll file (linked) -- this is commonly accepted.

However, that is talking about libraries. SRB2's Lua interpreter is not a library, it is an API. Those are two different and legally distinct things. Using an API doesn't subject you to the same requirements as using a .dll library does, even though both are remote calls to separate software. If using an API meant you needed to comply with the source code license of an API, all programs which communicated through APIs with restrictive licenses would be illegal. (They aren't)

Two interesting things to think about:
#1: If a Lua script could be made GPL-mandated by nature of running in SRB2, I could make a GPL program that can interpret other people's Lua scripts NOT made for SRB2, you would then have to ask if those scripts suddenly needed to be GPL. (the theoretical possibility of infecting other people's work by sliding in with a GPL interpreter is very funny 😂)

#2: If using an API meant I needed to comply with the terms of the software behind it, all programs which use an API to communicate with proprietary softwares (let's say like, any MMO, or websites like Weather.com for example) would be illegal.


Personally, I think the differences between a library and an API are semantics, but it doesn't mean they aren't legitimately treated as different types of software in the legal sense.

If we abandon all the technicalities and go with "What is the spirit of the law? What did the SRB2 devs interpret this to mean?" Then I think the floor is open for them to speak.

However, I will also posit the following text, notably from the license itself.View attachment 117862

The definition of what qualifies a "derivative work" is something which goes super deep and gets super muddy in software. In this case, it can definitely be argued in a lot of different ways. Afraid there isn't always a super clear answer. That's why people debate for months over this stuff in court cases.
Click to expand...
I have two things to say here:
  1. The spirit behind the GPL compared to the LGPL (which is specifically meant to protect the freedom of the specific work that's being licensed under the LGPL rather than the whole working thing as in the GPL) is that libraries that perform work for a program are technically part of how the program works and therefore part of the program. (To understand this I most probably don't need to be a lawyer, because the law/licenses/etc. were designed according to the industry of software development, rather than the industry having grown because software laws/licenses/whatever were written by lawyers. And by the way, this is why the GPL makes sense to use compared to the LGPL for anyone who appreciates the copyleft concept.) The distinction that Charyb made between APIs and libraries is relevant here: APIs have a defined behavior but undefined/unwritten implementation, therefore they're just "commands" and the originality is in how the "commands" are used, i.e. in the API caller, not the API callee, so the copyright of the callee's implementation is not a concern; libraries implement APIs (perhaps their own APIs even), so their copyright is of concern when they're used. Let me remind that the supreme court of the United States has ruled in the Google v. Oracle case that API usage is Fair Use and thus it averted entirely the question of copyrightability of APIs (in this case, but as I understand, it could be applied generally as well). The screenshot provided above of the FAQ section from the GNU project's website, if I understood what's written in the screenshot correctly, talks about a specific occurrence of the use of a library/implementation indirectly, because the program requires a specific interpreter, and the interpreter requires a library, thus the program (indirectly) requires a library (not an API), thus the library's license is of concern in that case.
  2. I am observing that this view is consistent with the view of the legality of the method used to reverse engineer and reimplement software programs without violating copyright — clean-room reverse engineering. By this method, a software program is analyzed for its perceivable general behavior, and then a new implementation for that behavior is written from scratch. This means that the general behavior/API would be replicated, but the implementation and/or its bugs (except bugs that change its perceivable general behavior) wouldn't be copied. Clean-room reverse engineering is considered to be legal according to Wikipedia and the matter-of-fact of the following well-known programs' long-standing existence. It's what allows programs like Linux (the kernel, which implements Unix APIs) and Wine (which implements Microsoft Windows APIs) to exist, for example.
Lactozilla said:
This exception is for kernel modules, not userspace programs.
Click to expand...
That's not true. Kernel modules run in kernelspace, not userspace. System calls are the userspace's way to interface with the kernel; kernel modules call kernel functions directly and don't need the syscall interface. System calls are called "system calls" because they're the way of userspace programs to call the system; kernel modules are the system. (EDIT: It's true that the syscall exception is meant to be used by Linux (kernel) code, but it was created for the benefit of userspace program authors.)
 
Last edited:
You must log in or register to reply here.

Who is viewing this thread (Total: 1, Members: 0, Guests: 1)

Back
Top