GNU General Public License

[Haeleth]

I will just drop in (slightly late) and point out that despite the claims above, it is NOT the case that using a GPL'd font will automatically "infect" your code with the GPL.

The GPL only affects code that is linked to GPL'd code. "Mere aggregation" -- distributing a GPL'd program alongside a non-GPL'd program, where the two are not fundamentally reliant on one another -- is an explicit exception in the license itself. Provided the font is not actually embedded inside the game program file itself, it is a standalone program, not fundamentally linked to the game (it can be exchanged for a different font simply by replacing the file, without having to recompile anything), so it falls under the "mere aggregation" clause.

The "GPL'd fonts can infect documents!" issue applies only to embedded fonts. That is, the case where you have taken the font code and mixed it together with a document in a single file. If a font is distributed as a separate TTF file, the question of embedding is irrelevant and the GPL applies only to the font itself.

Seriously, just make sure the font is a separate file, and you're safe.

Even if you do use a module that requires your game code to be GPL'd, that would still not affect the game data. Contrary to what PyTom thinks, you would not automatically have to permit all your pictures etc. to be used in other people's games. Again, data is separate from code, and the GPL stops where the code ends. Many companies have released game source code under the GPL while requiring users to purchase the commercial game if they want any of the game data; if this was a GPL violation, then we would have heard about it by now. :)

Erm, hasty PS: I'm not a lawyer and the possibility exists that I'm wrong, but I do practice what I preach (releasing translations using a GPL'd game engine, while restricting use of the game data), and nobody's sued me yet. :)

[monele]

Well that's good news and sounds fair ^.^. I found another font in the mean time so I'll just see which one fits the best then ^.^. Thanks !

[Jake]

I'm also no lawyer, but my understanding differs:

Many companies have released game source code under the GPL while requiring users to purchase the commercial game if they want any of the game data; if this was a GPL violation, then we would have heard about it by now.

In this case, however, it's the original copyright owner re-licensing part, but not all, of their original commercial work. I'm pretty sure that the copyright owner can release his or her code under as many different simulataneous licenses as they wish, and could even release code under GPL one day and sell it to someone under an even more restrictive closed-source license the next if they wish; it's just that once released under GPL, licensees have legal right to in turn distribute it GPLed so there's no motive for anyone to take out a more-restrictive license with the original copyright holder.

To take an example - Id Software sold the game Doom under a typically restrictive commercial license, then some years later released the Doom source code under the GPL; this didn't retroactively apply the GPL in favour of every other license for every other package that source code had ever been a part of, it only applied to the package it was used to license, which was just the source. If they had released the source and the game data and the compiled versions thereof under the GPL, I'm not convinced it would be so clear-cut.

If 'linked' in the case of the GPL could be reliably taken in a legal context to mean the same as the compiler term 'statically linked', then sure, fonts in a document wouldn't 'infect' the document and fonts in a Ren'Py game wouldn't 'infect' the game with the GPL. If that was the case, though, would the LGPL ever be needed? Surely if dynamic linking was 'mere aggregation' and didn't 'infect' your project with the GPL, then those projects that are LGPL-licensed would just be distributed as DLLs or SOs or whatever and it wouldn't be an issue? Maybe I'm missing something, but it would worry me.

Mainly, I'm wary because to my knowledge, the GPL has never been tested in court in my country or the FSF's, there's no case law history that puts boundaries or clarifications on its clauses and the interpretation of a lot of it is a little hazy for us normal people - I have no inclination to trust the FSF's explanations and assurances because they have a stated vested interest in making all my code as open and as close to permanently-public property as they can.

(Myself, I'm a fan of BSD/MIT-style licensing, and this is just one reason of many - it's not only more 'free' than the GPL, but it's so much simpler that people don't typically get confused about what they can and can't do with your code. I'm also not entirely convinced that non-code assets like images are GPLable in the first place, but I wouldn't want to have to argue it in court, either.)

[PyTom]

I will just drop in (slightly late) and point out that despite the claims above, it is NOT the case that using a GPL'd font will automatically "infect" your code with the GPL.

The GPL only affects code that is linked to GPL'd code. "Mere aggregation" -- distributing a GPL'd program alongside a non-GPL'd program, where the two are not fundamentally reliant on one another -- is an explicit exception in the license itself. Provided the font is not actually embedded inside the game program file itself, it is a standalone program, not fundamentally linked to the game (it can be exchanged for a different font simply by replacing the file, without having to recompile anything), so it falls under the "mere aggregation" clause.

I would think that this would go a bit further then "mere aggregation". The font program and the game program are running in the same address space, albeit with the latter in an intepreter. So I would think that would probably constitute linking. This is especially true if the game program explicitly mentions the font, rather then simply taking a font that's left lying around.

The "GPL'd fonts can infect documents!" issue applies only to embedded fonts. That is, the case where you have taken the font code and mixed it together with a document in a single file. If a font is distributed as a separate TTF file, the question of embedding is irrelevant and the GPL applies only to the font itself.

This is less than clear. It's not the case that you can get around the GPL by placing the code in question in a library, and linking to that. Why would a GPLed font be any different?

Even if you do use a module that requires your game code to be GPL'd, that would still not affect the game data. Contrary to what PyTom thinks, you would not automatically have to permit all your pictures etc. to be used in other people's games. Again, data is separate from code, and the GPL stops where the code ends. Many companies have released game source code under the GPL while requiring users to purchase the commercial game if they want any of the game data; if this was a GPL violation, then we would have heard about it by now.

I think this is a very gray area. The game script is probably a program, at least in languages like Ren'Py and ONScripter. So I would suspect that a game script that uses a GPLed font would need to be GPLed. You're probably right about game data.

The problem is, there's little that is absolutely known about the interpretation of the GPL, and even less is known with respect to GPL interpreters running non-gpl programs. I would suspect that it would be contrary to the GPL to create a GPLed interpreter for the purpose of letting non-GPL code access GPL code.

Erm, hasty PS: I'm not a lawyer and the possibility exists that I'm wrong, but I do practice what I preach (releasing translations using a GPL'd game engine, while restricting use of the game data), and nobody's sued me yet.

Ditto the IANAL part.

I would suspect the ONscripter case is made more interesting by the existence of Nscripter. The FSF has been someone odd about that in respect to readline... they threatened to sue people for linking the GPL readline library to non-GPL code... but when a non-GPL reimplementation came out, they've calmed down.

[RedSlash]

I definately not a lawyer, but here is how I understand fonts licensed under the GPL. Much like Haeleth says, we need to distinguish between what is code and data. To my understanding, GPL is a copyright licence in which one uses it to control distribution and copying of "programs". I don't know whose idea was to license a font under GPL, but if fonts could be defined as programs, then the only way GPL will infect you is if you use the font in a way that would make the font a derivative of your program. Basically, I see two scenarios.

1. Ren'py "program" includes it as the default font or just uses it

Ren'py is a "program". Since ren'py would use the font, then the font behaves like a dynamic link "library" to ren'py and therefore infects ren'py with the GPL license.

2. Game "X" which runs under ren'py which happens to use the font

Game "X" is data. Basically game "X" consists of ren'py scripts and bitmap images which are separated from ren'py and therefore not affected by whatever license ren'py is licensed under. Therefore, in my opinion, including a font with these data would be okay because this is like distrubuting a bunch of images, text files and GPL'd executables on a CD which in turn gets interpreted by ren'py. Since the font is GPL'd, you'd have to include its source code in that CD which I wouldn't know how to do.

Tell me if this makes sense.

[Jake]

I don't know whose idea was to license a font under GPL, but if fonts could be defined as programs

Basically, TrueType or OpenType fonts are programs - they take inputs (which glyphs to display at which size) and make a series of decisions based on those inputs to output a correctly-drawn, correctly-scaled and so on piece of text.

As an example, go look at this image and bear in mind that it's the result of just typing in a single font; all the variants of letters are created by automatic OpenType ligatures that the font's creator has coded in.

Raster graphics, you can get away with calling 'just data', but fonts certainly cross the line to 'program', IMO.

[PyTom]

Game "X" is data.

But game "X" is not data. Game "X" is a program, or at least the .rpy files are. WordNet describes a programs as:

a sequence of instructions, stored in any medium, that can be
interpreted and executed by a computer; -- called most
frequently a {program}. This term is used both for the
written program (a document) and for its corresponding
electronic version stored or executed on the computer. See
{instruction}; as, Version 1.0 of the program had a serious
bug that caused the computer to crash frequently..

A Ren'Py program is a series of instructions. We have say statements that tell it to show text on the screen, show statements that update scene lists, and so on.

I don't see why:

Code: Select all

print "Hello, World"

would be a program, and

Code: Select all

e "Hello, World."

wouldn't be.

I personally see a game script + Ren'Py to be a single program (since you can directly call python code from the game script), and I'd probably include any other program-like data as part of this.

This is the reason why I released Ren'Py under a license that would be compatible with just about any other license.

Note that the FSF's position on this issue is even odder... If I read http://www.gnu.org/licenses/gpl-faq.htm ... reterIsGPL correctly, they would claim that the license of the interpreter doesn't infect the interpreted program. But the license of facilities the interpreted program uses does infect that program... in this case, I'd probably consider the font to be one of those facilities.

[RedSlash]

I do agree in that .rpy files could be program files but I think in our case, they would be considered data b/c I think that ren'py and .rpy files have the interpretor/data relationship. I would think this because the purpose of ren'py is that it is a "visual novel engine" and not a "visual novel library". So games made under ren'py wouldn't really be considered a derivative of ren'py because IMO games are interpreted.

I would assume this is the same case with emulators, in which the "program" (the emulator) would execute the data (which are executables for other platforms which could also be considered "programs"). Ren'py would be like the emulator, while the .rpy files are the interpreted programs.

[PyTom]

I do agree in that .rpy files could be program files but I think in our case, they would be considered data b/c I think that ren'py and .rpy files have the interpretor/data relationship. I would think this because the purpose of ren'py is that it is a "visual novel engine" and not a "visual novel library". So games made under ren'py wouldn't really be considered a derivative of ren'py because IMO games are interpreted.

The thing is, Ren'Py games are only partially interpreted. The Ren'Py script language is run in an interpreter. However, Ren'Py also allows one to include python code inside a Ren'Py script file. This python code is passed to the python interpreter to run... the same python interpreter that's running Ren'Py.

Interestingly, the very first version of Ren'Py was a Python library. That didn't work out, since there was no good way to save... but it's not absurd to think of the Ren'Py language as being a really convenient syntax for calling functions in the library.

I would assume this is the same case with emulators, in which the "program" (the emulator) would execute the data (which are executables for other platforms which could also be considered "programs"). Ren'py would be like the emulator, while the .rpy files are the interpreted programs.[/quote]

[RedSlash]

Likewise, Linux itself is an interpretor, cause it interprets python which in turn interprets renpy which calls linux to interpret another python program which interprets .rpy files (something like that). Linux is GPL'd and its license does not infect its data, which is python and all its subprocesses. So in my opinion, ren'py is still an interpretor for rpy files regardless of any subprocesses.

The only way I can see which would break this interpretor/data relationship between ren'py and .rpy files if the interpreting of the rpy files was used to provide features for ren'py's main function. i.e. inteprets a rpy script to execute wine to emulate a windows version of libmad (GPL'd) to provide mp3 playing functions for ren'py. As you can see, all the emulating/interpreting steps are fine, the only part that isn't is using its mp3 decoding features for your program (indirectly linking it).

[Jake]

Likewise, Linux itself is an interpretor, cause it interprets python which in turn interprets renpy which calls linux to interpret another python program which interprets .rpy files (something like that). Linux is GPL'd and its license does not infect its data, which is python and all its subprocesses. So in my opinion, ren'py is still an interpretor for rpy files regardless of any subprocesses.

OK, I can see that argument, but even if I wholly agreed with it I could only agree that it means by analogy that were Ren'Py being GPL-licensed it wouldn't force the game script to be GPL-licensed as well - I think it's irrelevant to the question of whether the game script is affected by the license on resources that the script itself uses.

I think the assumption that an item is either program or data but cannot be both is spurious; a Ren'Py script is effectively data to the Python interpreter, but that doesn't stop it being a program as well. The EMACS source is 'just data' to the GCC compiler, but it's still a program and is still licensed under the GPL, even if you only ever run it from a single commandline that compiles and executes it in one UI step. A Ren'Py script contains decision logic (or rather, is capable of), and this to my mind puts it firmly in the 'program' category. A font contains decision logic, which makes it equally a program. If one program links to another program - say, a game script making direct use of a font in the same process - then I would worry that this is possibly sufficient to require that a game script using a GPLed font is also GPLed.



As it is, though, I think it's more appropriate to consider Ren'Py as an engine than an interpreter; the typical mode of operation is not to have a single instance of Ren'Py installed on your computer which you run scripts directly with, as one would with perl or python, but to compile the game scripts up with Ren'Py scripts into a single package that is the game. In fact, large parts of Ren'Py itself (the contents of the /common directory) are compiled [to .rpyc files] as peers of the game script. Without the runtime-compilable elements such as the game script Ren'Py is non-functional; without the engine, the game script is non-functional.

If someone released an extra (in the same manner as the two-window say was distributed) under the GPL and I were to use that extra in my game, it seems obvious that I would have to license my release of Ren'Py (possible, thanks to PyTom's generous license) and my game under the GPL in order to comply with their licensing terms; the game makes use of the classes/methods in the extra to perform some function such as displaying speech in a certain manner, so my game would have to be GPLed. Equally, my game makes use of the classes/methods in a font file to perform some function such as displaying text in a certain manner...

[PyTom]

Likewise, Linux itself is an interpretor, cause it interprets python which in turn interprets renpy which calls linux to interpret another python program which interprets .rpy files (something like that). Linux is GPL'd and its license does not infect its data, which is python and all its subprocesses. So in my opinion, ren'py is still an interpretor for rpy files regardless of any subprocesses.

You do realize that "interpreter" is a technical term, with a technical meaning. Linux is an operating system, not an interpreter. The reason why Linux does not infect programs running on it is because the license for Linux includes:

NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work".
Also note that the GPL below is copyrighted by the Free Software
Foundation, but the instance of code that it refers to (the Linux
kernel) is copyrighted by me and others who actually wrote it.

as a clarification.

The only way I can see which would break this interpretor/data relationship between ren'py and .rpy files if the interpreting of the rpy files was used to provide features for ren'py's main function. i.e. inteprets a rpy script to execute wine to emulate a windows version of libmad (GPL'd) to provide mp3 playing functions for ren'py. As you can see, all the emulating/interpreting steps are fine, the only part that isn't is using its mp3 decoding features for your program (indirectly linking it).

But this is basically the case we're talking about here. The game script (script.rpy, say) asks Ren'Py to show text in a particular font. Ren'Py (X/MIT license) passes the request to pygame (LGPL), SDL_ttf (LGPL), and freetype (LGPL). Freetype then loads the GPLed font file, which provides the function of showing text. It is only doing this because script.rpy asked it to... so I'd say that script.rpy would need to be covered by the GPL.

It's not clear to me if the rest of the Ren'Py complex would need to be distributed under the GPL... maybe, maybe not, but it's not like you can't distribute Ren'Py under the terms of the GPL.

(Oh, and let me just mention that I believe Jake's analysis is basically correct.)

[RedSlash]

OK, I can see that argument, but even if I wholly agreed with it I could only agree that it means by analogy that were Ren'Py being GPL-licensed it wouldn't force the game script to be GPL-licensed as well

Yeah, well I'm talking as if renpy was GPL'ed, which I know it isn't. But the purpose of this conversation is that if we can distinguish that ren'py is the code and the rpy scripts, images, fonts were considered data, then GPL fonts wouldn't infect everything else in your game because it is data.

As it is, though, I think it's more appropriate to consider Ren'Py as an engine than an interpreter;

Yes, renpy is an engine as described on the website. But in code, I believe renpy does this: reads rpy files, and does what the rpy file says. Which is why we can say rpy files are data, despite it being a code. Basically, when you look at a game as a whole, you split it into two parts, the code (engine) and the data (scripts, images, fonts). GPL only affects the code part (engine) so it doesn't matter if your scripts are programs, they are still in the "data" part of your game.

Without the runtime-compilable elements such as the game script Ren'Py is non-functional; without the engine, the game script is non-functional.

This doesn't really matter.. as a GPL'd emulator can't function without the executable, but anything it executes does not get infected by its license.

You do realize that "interpreter" is a technical term, with a technical meaning. Linux is an operating system, not an interpreter.

Yes, I messed up my words. What I mean is there is a interpretor in Linux which launches your exe programs.

NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work".
Also note that the GPL below is copyrighted by the Free Software
Foundation, but the instance of code that it refers to (the Linux
kernel) is copyrighted by me and others who actually wrote it.

I believe the purpose of this statement is to allow binary kernel modules and not for the purpose of running binary programs. I would assume that it is understood that running programs does not affect licensing status.

But this is basically the case we're talking about here. The game script (script.rpy, say) asks Ren'Py to show text in a particular font. Ren'Py (X/MIT license) passes the request to pygame (LGPL), SDL_ttf (LGPL), and freetype (LGPL). Freetype then loads the GPLed font file, which provides the function of showing text. It is only doing this because script.rpy asked it to... so I'd say that script.rpy would need to be covered by the GPL.

The way I see it is, script.rpy does not ask ren'py to do something, rather ren'py reads script.rpy and does what it says. On the other hand, if the .rpy script was programmed to use freetype to draw fonts, i.e.

Code: Select all

$ FT_Init_FreeType( )
$ Use FT functions to render text

Then there would be licensing issues between script.rpy and freetype, but whatever issues these two have, does not affect ren'py in any way because ren'py just interprets/executes the script (much like an emulator emulating an executable), and in this case the script loaded freetype, not ren'py.

[lordcloudx]

well... the problem with the internet is that it doesn't fall within the jurisdiction of any state. Intellectual property laws may vary with each state such as in a country like ours, there's the so-called fair-use doctrine wherein it is legal to use someone else's unregistered artwork etc. as long as the you don't make a profit out of it.

a good solution would be an international treaty but that's something for the league of nations to debate about.

[Jake]

But in code, I believe renpy does this: reads rpy files, and does what the rpy file says. Which is why we can say rpy files are data, despite it being a code. Basically, when you look at a game as a whole, you split it into two parts, the code (engine) and the data (scripts, images, fonts). GPL only affects the code part (engine) so it doesn't matter if your scripts are programs, they are still in the "data" part of your game.

The distinction between code and data is only a convinience to help determine which parts are - for lack of a more appropriate term - asking other parts to do work on their behalf. The GPL does not only apply to programs, it is merely the most common mode. I do not believe that it specifically excludes 'data files', since even a compiled C executable can validly be considered to merely be a data file that one passes to the processor if one is feeling particularly obtuse. What the GPL talks about, unless I'm mistaken, is 'derivative works'.

The first paragraph of the license is as follows, I've added italics to highlight relevant terms:

This License applies to any program or other work which contains
a notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License. The "Program", below,
refers to any such program or work, and a "work based on the Program"
means either the Program or any derivative work under copyright law:
that is to say, a work containing the Program or a portion of it,
either verbatim or with modifications and/or translated into another
language. (Hereinafter, translation is included without limitation in
the term "modification".) Each licensee is addressed as "you".

Fonts are programs, but the distinction probably matters little; games based on fonts are, I believe, derivative works of those fonts (along with being derivative works of any and all graphics, texts quoted, music played and so on); a Ren'Py game that uses a font based on the GPL is a derivative work of a program thta is covered by the GPL.

The second paragraph is possibly the part that allows interpreters and compilers to not 'infect' the code they run:

Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the Program
is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does.

- compiling Apache with GCC doesn't mean Apache has to be GPL licensed because Apache doesn't rely on GCC to operate, it doesn't derive from GCC code, it just happened to have been put together with that tool. A game put together with a font, on the other hand, does rely on that font for its normal execution.

This doesn't really matter.. as a GPL'd emulator can't function without the executable, but anything it executes does not get infected by its license.

The executable that the emulator is running wasn't derived from that emulator, which is why it's not an issue. It's a different case when talking about a program written against a particular set of libraries.

The way I see it is, script.rpy does not ask ren'py to do something, rather ren'py reads script.rpy and does what it says.

The script can contain python code, and the python code can call into renpy.* libraries, which means that the script is - generally - capable of asking Ren'Py to do something. Ren'Py and the game script are both fundamentally Python programs running inside the Python interpreter. If Ren'Py adopted the GPL, my suspicion is that simple VN entirely-in-Ren'Py-script scripts would not need to be GPLed, but games that start to do anything remotely complicated would. The boundary probably depending on what license things like the contents of the /common directory was under.

Either way, if Ren'Py were GPLed I would be very wary about trying to release scripts under any other license, just because - as I've said before - it can be too ambiguous for my tastes.