Rob Hoelz | 27 Sep 17:32

Lua licensing thoughts

Hello everyone,

I read another post on this list from about 7 years ago, but it didn't
do much to answer my questions, and Lua has since changed licenses.
Allow me to explain my situation:

I'm writing a game with some friends.  The engine (in C++) is under
the GPLv3, because we like the idea of our free code staying free.  And,
to admit some arrogance, we don't want our game getting stolen.

The game embeds a Lua interpreter.  Utility and general Lua code (code
that would apply to any game) is also under the GPL.  Again, free code
staying free.  Code specific to our game (story and the like) and
models/art are under a Creative Commons license.  Specifically this
one:

http://creativecommons.org/licenses/by-nc-nd/3.0/us/

We don't want people taking our ideas and exploiting them.  We're
okay with people using them, as long as they ask first.  Hence the CC
license.

The code will also likely contain changes to the Lua interpreter; we
haven't done this yet, but I can see it happening in the future.  It is
my intention to release the changes under the MIT license to allow the
Lua community to fully benefit.

Does anyone see any inherent problems with the way we're doing things?
We're pretty set on keeping the C++ side GPL, but I'm more than willing
to make the non-CC Lua MIT licensed.
(Continue reading)

Rob Kendrick | 27 Sep 18:33

Re: Lua licensing thoughts

On Sat, 27 Sep 2008 10:35:41 -0500
Rob Hoelz <rob <at> hoelzro.net> wrote:

> The code will also likely contain changes to the Lua interpreter; we
> haven't done this yet, but I can see it happening in the future.  It
> is my intention to release the changes under the MIT license to allow
> the Lua community to fully benefit.
> 
> Does anyone see any inherent problems with the way we're doing things?
> We're pretty set on keeping the C++ side GPL, but I'm more than
> willing to make the non-CC Lua MIT licensed.

The FSF's standpoint is that the MIT licence is compatible with the
GPL, and thus you can freely mix the code (as MIT is more permissive
than the GPL.)

You are under no requirement to release your changes to Lua at all,
although you might find that difficult if the rest of your project is
under a free or open source licence anyway!

I am not a lawyer, and you should therefor consult yours.

B.

Miles Bader | 28 Sep 05:14
Gravatar

Re: Lua licensing thoughts

Rob Kendrick <lua-l <at> nun.org.uk> writes:
> The FSF's standpoint is that the MIT licence is compatible with the
> GPL, and thus you can freely mix the code (as MIT is more permissive
> than the GPL.)

Yeah that's fine.  Many projects mix MIT and GNU GPL licensed code.

CC can be more problematic.  The CC license you [er, I mean, the
original poster] are using is incompatible with the GNU GPL.

-Miles

--

-- 
Mayonnaise, n. One of the sauces that serve the French in place of a state
religion.

Mildred Ki'Lya | 28 Sep 15:04

Re: Lua licensing thoughts


Le Sun 28/09/2008 __ 12:14 Miles Bader __ __crit:
> CC can be more problematic.  The CC license you [er, I mean, the
> original poster] are using is incompatible with the GNU GPL.

Not only that, but this licence is far from an open source/free
software licence. If you care about this ideal, you might want to
change it. To be clear, when it will be released, it won't be free
software.

--

-- 
Mildred Ki'Lya
______________________________ ____________________________________________________________ ______________________________
___ Jabber, GoogleTalk: <mildred <at> jabber.fr>
___ Site: <http://ki.lya.online.fr>              GPG ID: 9A7D 2E2B
___ Fingerprint: 197C A7E6 645B 4299 6D37 684B 6F9D A8D6 9A7D 2E2B

David Given | 28 Sep 16:38

Re: Lua licensing thoughts

Mildred Ki'Lya wrote:
[...]
> Not only that, but this licence is far from an open source/free
> software licence. If you care about this ideal, you might want to
> change it. To be clear, when it will be released, it won't be free
> software.

The CC people say specifically that you shouldn't use a CC license for
software:

http://wiki.creativecommons.org/FAQ#Can_I_use_a_Creative_Commons_license_for_software.3F

But using CC for the *artwork* and data downloadables should work.

--

-- 
┌─── dg@cowlark.com ─────
http://www.cowlark.com ─────
│
│ "All power corrupts, but we need electricity." --- Diana Wynne Jones,
│ _Archer's Goon_

Rob Hoelz | 29 Sep 00:43

Re: Lua licensing thoughts

David Given <dg <at> cowlark.com> wrote:

> Mildred Ki'Lya wrote:
> [...]
> > Not only that, but this licence is far from an open source/free
> > software licence. If you care about this ideal, you might want to
> > change it. To be clear, when it will be released, it won't be free
> > software.
> 
> The CC people say specifically that you shouldn't use a CC license for
> software:
> 
> http://wiki.creativecommons.org/FAQ#Can_I_use_a_Creative_Commons_license_for_software.3F
> 
> But using CC for the *artwork* and data downloadables should work.
> 

So if all the story is scripted in Lua, and it's under a CC license, I
can't run it on a GPL engine?

-Rob

Polarina | 29 Sep 00:56

Re: Lua licensing thoughts

Lua bytecode is just data, and GPL doesn't restrict what data a computer
program uses. Your statement is like saying that you can't view websites
containing CC licensed art because the browser is GPL licensed.

On Sun, 2008-09-28 at 17:43 -0500, Rob Hoelz wrote:
> David Given <dg <at> cowlark.com> wrote:
> 
> > Mildred Ki'Lya wrote:
> > [...]
> > > Not only that, but this licence is far from an open source/free
> > > software licence. If you care about this ideal, you might want to
> > > change it. To be clear, when it will be released, it won't be free
> > > software.
> > 
> > The CC people say specifically that you shouldn't use a CC license for
> > software:
> > 
> > http://wiki.creativecommons.org/FAQ#Can_I_use_a_Creative_Commons_license_for_software.3F
> > 
> > But using CC for the *artwork* and data downloadables should work.
> > 
> 
> So if all the story is scripted in Lua, and it's under a CC license, I
> can't run it on a GPL engine?
> 
> -Rob

Rob Hoelz | 29 Sep 01:39

Re: Lua licensing thoughts

Polarina <gabrielp <at> simnet.is> wrote:

> Lua bytecode is just data, and GPL doesn't restrict what data a
> computer program uses. Your statement is like saying that you can't
> view websites containing CC licensed art because the browser is GPL
> licensed.
> 
> On Sun, 2008-09-28 at 17:43 -0500, Rob Hoelz wrote:
> > David Given <dg <at> cowlark.com> wrote:
> > 
> > > Mildred Ki'Lya wrote:
> > > [...]
> > > > Not only that, but this licence is far from an open source/free
> > > > software licence. If you care about this ideal, you might want
> > > > to change it. To be clear, when it will be released, it won't
> > > > be free software.
> > > 
> > > The CC people say specifically that you shouldn't use a CC
> > > license for software:
> > > 
> > > http://wiki.creativecommons.org/FAQ#Can_I_use_a_Creative_Commons_license_for_software.3F
> > > 
> > > But using CC for the *artwork* and data downloadables should work.
> > > 
> > 
> > So if all the story is scripted in Lua, and it's under a CC
> > license, I can't run it on a GPL engine?
> > 
> > -Rob
> 
(Continue reading)

David Given | 29 Sep 02:23

Re: Lua licensing thoughts

Polarina wrote:
> Lua bytecode is just data, and GPL doesn't restrict what data a computer
> program uses. Your statement is like saying that you can't view websites
> containing CC licensed art because the browser is GPL licensed.

While the GPL doesn't restrict what data a program *uses*, it *does*
restrict your ability to redistribute that data. Lua bytecode is code
--- it's a compiled program. Therefore, if the source that made it is
GPLd, and you're not the original author, then you must provide a means
to get the source if you want to redistribute it.

On Sun, 2008-09-28 at 17:43 -0500, Rob Hoelz wrote:
> So if all the story is scripted in Lua, and it's under a CC license, I
> can't run it on a GPL engine?

You can *run* it on anything. But you won't be able to *distribute* a
combined package containing the engine and the story, because the two
different licenses are incompatible.

(There's nothing to stop you distributing the story and the engine as
different packages, each with their own license; this is how scummvm
works, which is a GPLd engine which runs proprietary data.)

...

The Oversimplified Guide To Distribution Licensing:

- all pieces of work have an owner.

- the owner can give you the work at their own discretion.
(Continue reading)

Benjamin Tolputt | 29 Sep 02:35

Re: Lua licensing thoughts

David Given wrote:
> While the GPL doesn't restrict what data a program *uses*, it *does*
> restrict your ability to redistribute that data. Lua bytecode is code
> --- it's a compiled program. Therefore, if the source that made it is
> GPLd, and you're not the original author, then you must provide a means
> to get the source if you want to redistribute it.
>   

Actually, that is incorrect. That would imply that all programs compiled
with gcc are GPL'ed. One can GPL a virtual machine & compiler but
distribute the code they produce under any license provided the compiled
byte/native code does not contain significant portions of GPL'd product.

Simply put - even if Lua was GPL-licensed (which it is not, it is simply
GPL-compatible), the byte code it produces can be released under any
license the author chooses. The simple fact that there are
hundreds-to-thousands of non-GPL applications compiled by gcc and
distributed as binaries are proof of that.

Also remember, I doubt any of those who have spoken here are lawyers
(agreeing or disagreeing with me). As such, everything we say as
"absolute" should be checked with someone with legal backing. I would
suggest checking out the Free Software Foundation's website and/or ask
them directly.

--

-- 
Regards,

Benjamin Tolputt
Analyst Programmer
(Continue reading)

Jan Schütze | 29 Sep 08:26

Re: Lua licensing thoughts

Benjamin Tolputt schrieb:
> David Given wrote:
>   
>> While the GPL doesn't restrict what data a program *uses*, it *does*
>> restrict your ability to redistribute that data. Lua bytecode is code
>> --- it's a compiled program. Therefore, if the source that made it is
>> GPLd, and you're not the original author, then you must provide a means
>> to get the source if you want to redistribute it.
>>   
>>     
>
> Actually, that is incorrect. That would imply that all programs compiled
> with gcc are GPL'ed. One can GPL a virtual machine & compiler but
> distribute the code they produce under any license provided the compiled
> byte/native code does not contain significant portions of GPL'd product.
>
> Simply put - even if Lua was GPL-licensed (which it is not, it is simply
> GPL-compatible), the byte code it produces can be released under any
> license the author chooses. The simple fact that there are
> hundreds-to-thousands of non-GPL applications compiled by gcc and
> distributed as binaries are proof of that.
I think he meant, the part about redistributing. As far as I know (I am 
not a lawyer) the GPL allows you to redistribute the application only, 
if you include all your parts under the terms of GPL. While LGPL 
allows/requires you to release only the LGPL part under LGPL and 
redistribute anything else under any other license (Speaking about 1 
download package, containing all).

Regards,

(Continue reading)

David Given | 29 Sep 12:13

Re: Lua licensing thoughts

Benjamin Tolputt wrote:
> David Given wrote:
>> While the GPL doesn't restrict what data a program *uses*, it *does*
>> restrict your ability to redistribute that data. Lua bytecode is code
>> --- it's a compiled program. Therefore, if the source that made it is
>> GPLd, and you're not the original author, then you must provide a means
>> to get the source if you want to redistribute it.
[...]
> Actually, that is incorrect. That would imply that all programs compiled
> with gcc are GPL'ed. One can GPL a virtual machine & compiler but
> distribute the code they produce under any license provided the compiled
> byte/native code does not contain significant portions of GPL'd product.

Actually, by 'source that made it' I mean the Lua source code that got
compiled into the bytecode, not the compiler that did the compiling. If
your Lua source code is GPL'd then you can't distribute the bytecode
without complying with the GPL. As you say, the license of the compiler
is *usually* irrelevant.

(Exceptions being: (a) if the compiler has an EULA that restricts the
situations in which you can use it, which Lua doesn't, but that some
commercial compilers do; or (b) if the compiler contains boilerplate
that gets emitted into the output bytecode, in which case the license of
the boilerplate applies. Lua doesn't do this, but you may note that
packages like STL implementations --- where all the code gets emitted
inline into your program --- have to have special licensing exceptions
to allow their use.)

--

-- 
David Given
(Continue reading)

Benjamin Tolputt | 30 Sep 01:07

Re: Lua licensing thoughts

David Given wrote:
> Actually, by 'source that made it' I mean the Lua source code that got
> compiled into the bytecode, not the compiler that did the compiling. If
> your Lua source code is GPL'd then you can't distribute the bytecode
> without complying with the GPL. As you say, the license of the compiler
> is *usually* irrelevant.
>   

This is indeed correct, and I apologise if my post caused confusion. It
IS possible for the distribution to have a GPL-licensed engine with the
content (images, models, audio, Lua code, etc) licensed separately. This
is known as an amalgamated release and is perfectly OK according to the
GPL & the Free Software Foundation. There are a number of games already
that use this method of engine/content divide.

--

-- 
Regards,

Benjamin Tolputt
Analyst Programmer
Mob:   0417 456 505
Email: btolputt <at> bigpond.net.au

This email and any files transmitted with it are confidential to the
intended recipient and may be privileged. If you have received this
email inadvertently or you are not the intended recipient, you may not
disseminate, distribute, copy or in any way rely on it. Further, you
should notify the sender immediately and delete the email from your
computer. Whilst we have taken precautions to alert us to the presence
of computer viruses, we cannot guarantee that this email and any files
(Continue reading)

Florian Weimer | 1 Oct 19:36

Re: Lua licensing thoughts

* Rob Hoelz:

> So if all the story is scripted in Lua, and it's under a CC license, I
> can't run it on a GPL engine?

The FSF position with regard to some bytecode interpreters (Emacs, for
instance) is that the GPL extends to the bytecode.

Benjamin Tolputt | 2 Oct 01:54

Re: Lua licensing thoughts

Florian Weimer wrote:
> The FSF position with regard to some bytecode interpreters (Emacs, for
> instance) is that the GPL extends to the bytecode

The reason for this is "boiler-plate" which is embedded in the
byte-code. FSF maintains (and correctly so) that when the byte-code
contains GPL'ed boiler-plate code without which it would not work, it is
a derivative of the GPL'ed code. Note that this only applies to "some"
bytecode interpreters, and these are ones that originate under the GPL
*and* have substantial "boilerplate" code embedded by the compiler.

There are a couple of things to remember:

   1. Lua is not GPL-licensed. It's license is GPL compatible, and hence
      can be included in GPL applications, but the terms it's copyright
      terms are still MIT
   2. Lua "bytecode" can originate from non-GPL compilers (obviously,
      standard "luac" comes to mind), as such the bytecode is not
      covered by GPL as "derived" by a GPL-compiler
   3. Provided the game engine being worked on could accept alternate
      bytecode, graphics, audio, etc - the GPL'd application is an
      "engine" with the Lua bytecode, sound files, etc as "content" that
      can come packaged with the GPL application as an "amalgamated
      distribution" - in other words, the content need not be GPL to
      comply with the GPL license.

It is still my strong opinion (though I am not a lawyer), that
distributing Lua bytecode with a GPL application is covered by the
amalgamation terms of the GPL license and as such one could make a GPL
game engine with alternately licensed content.
(Continue reading)

Florian Weimer | 3 Oct 09:59

Re: Lua licensing thoughts

* Benjamin Tolputt:

> Florian Weimer wrote:
>> The FSF position with regard to some bytecode interpreters (Emacs, for
>> instance) is that the GPL extends to the bytecode
>
> The reason for this is "boiler-plate" which is embedded in the
> byte-code.

Not really, they also claim that the GPL extends to the source code (or,
more precisely, that the source code must be distributed along with
bytecode, and distributed under GPL-compatible terms).

The argument is that Emacs Lisp programs won't work without Emacs, and
are designed to intermingle with Emacs, so they are a derivative work of
Emacs.

Re: Lua licensing thoughts

2008/10/1 Florian Weimer <fw <at> deneb.enyo.de>:
> * Rob Hoelz:
>
>> So if all the story is scripted in Lua, and it's under a CC license, I
>> can't run it on a GPL engine?
>
> The FSF position with regard to some bytecode interpreters (Emacs, for
> instance) is that the GPL extends to the bytecode.

The GPL FAQ differs:
http://www.fsf.org/licensing/licenses/gpl-faq.html#IfInterpreterIsGPL

Best
   Martin

Florian Weimer | 3 Oct 10:01

Re: Lua licensing thoughts

* Martin Schröder:

> 2008/10/1 Florian Weimer <fw <at> deneb.enyo.de>:
>> * Rob Hoelz:
>>
>>> So if all the story is scripted in Lua, and it's under a CC license, I
>>> can't run it on a GPL engine?
>>
>> The FSF position with regard to some bytecode interpreters (Emacs, for
>> instance) is that the GPL extends to the bytecode.
>
> The GPL FAQ differs:
> http://www.fsf.org/licensing/licenses/gpl-faq.html#IfInterpreterIsGPL

Note that the first paragraph of the answer deals with interpreters
which are GPLed and whose run-time environment is licensed more
permissively.  This is very rare.  Emacs is not in this category.

Re: Lua licensing thoughts

2008/10/3 Florian Weimer <fw <at> deneb.enyo.de>:
>> 2008/10/1 Florian Weimer <fw <at> deneb.enyo.de>:
>>> The FSF position with regard to some bytecode interpreters (Emacs, for
>>> instance) is that the GPL extends to the bytecode.
>>
>> The GPL FAQ differs:
>> http://www.fsf.org/licensing/licenses/gpl-faq.html#IfInterpreterIsGPL
>
> Note that the first paragraph of the answer deals with interpreters
> which are GPLed and whose run-time environment is licensed more
> permissively.  This is very rare.  Emacs is not in this category.

So we have to look at two licenses: Interpreter and run-time
environment. The license for the interpreter shouldn't be a problem
(unless it's really weird). It's the environment's we have to care
about.

Best
   Martin

Martin | 4 Oct 19:47

Re: [OT] Lua licensing thoughts

On Fri, Oct 03, 2008 at 03:12:14PM +0200, Martin Schröder wrote:
> So we have to look at two licenses: Interpreter and run-time
> environment. The license for the interpreter shouldn't be a problem
> (unless it's really weird). It's the environment's we have to care
> about.
> 
> Best
>    Martin

All this talk about licencing is starting to hurt my brain.
Just how effective is this open source copyright?
For example if I take some GPL (or some other licence that do not allow
commercial distribution) and based on that code develop some commercial
program that I sell. Who will know, and how, that I used GPL source
if I do show source code of derived program to anybody?

On the same note: If some big (or small for that matter) company take
GPL game engine and release the commercial game how is anybody able to
prove that it is using that particular game engine?

Martin

Tim Hunter | 5 Oct 23:57

Re: [OT] Lua licensing thoughts

Martin wrote:
> On Fri, Oct 03, 2008 at 03:12:14PM +0200, Martin Schröder wrote:
>> So we have to look at two licenses: Interpreter and run-time
>> environment. The license for the interpreter shouldn't be a problem
>> (unless it's really weird). It's the environment's we have to care
>> about.
>>
>> Best
>>    Martin
> 
> All this talk about licencing is starting to hurt my brain.
> Just how effective is this open source copyright?
> For example if I take some GPL (or some other licence that do not allow
> commercial distribution) and based on that code develop some commercial
> program that I sell. Who will know, and how, that I used GPL source
> if I do show source code of derived program to anybody?
> 
> On the same note: If some big (or small for that matter) company take
> GPL game engine and release the commercial game how is anybody able to
> prove that it is using that particular game engine?
> 
> Martin
> 

Very effective. Ask Verizon.
http://www.softwarefreedom.org/

Favicon

Re: [OT] Lua licensing thoughts

> All this talk about licencing is starting to hurt my brain.

Yeah, can we please get back on topic?

> Just how effective is this open source copyright?

A clear license like the MIT license goes a long way towards making it easy
to use open source software without any qualms.

Florian Weimer | 9 Oct 11:15

Re: [OT] Lua licensing thoughts

* Luiz Henrique de Figueiredo:

>> Just how effective is this open source copyright?
>
> A clear license like the MIT license goes a long way towards making it easy
> to use open source software without any qualms.

Only because the attribution requirement in the MIT license is
traditionally not enforced (the part that states "The above copyright
notice and this permission notice shall be included in all copies or
substantial portions of the Software").

Florian Weimer | 9 Oct 11:21

Re: Lua licensing thoughts

* Martin Schröder:

>> Note that the first paragraph of the answer deals with interpreters
>> which are GPLed and whose run-time environment is licensed more
>> permissively.  This is very rare.  Emacs is not in this category.
>
> So we have to look at two licenses: Interpreter and run-time
> environment. The license for the interpreter shouldn't be a problem
> (unless it's really weird). It's the environment's we have to care
> about.

You don't need two difference licenses.  You could simply state that
certain uses are not subject to the GPL if this is your intent.  The FSF
does the same with certain GPLed libraries.

Florian Weimer | 1 Oct 19:37

Re: Lua licensing thoughts

* Mildred Ki'Lya:

> Le Sun 28/09/2008 __ 12:14 Miles Bader __ __crit:
>> CC can be more problematic.  The CC license you [er, I mean, the
>> original poster] are using is incompatible with the GNU GPL.
>
> Not only that, but this licence is far from an open source/free
> software licence. If you care about this ideal, you might want to
> change it. To be clear, when it will be released, it won't be free
> software.

Exactly, and there will be some distributions that will not include such
software.

Rob Hoelz | 2 Oct 00:00

Re: Lua licensing thoughts

Florian Weimer <fw <at> deneb.enyo.de> wrote:

> * Mildred Ki'Lya:
> 
> > Le Sun 28/09/2008 __ 12:14 Miles Bader __ __crit:
> >> CC can be more problematic.  The CC license you [er, I mean, the
> >> original poster] are using is incompatible with the GNU GPL.
> >
> > Not only that, but this licence is far from an open source/free
> > software licence. If you care about this ideal, you might want to
> > change it. To be clear, when it will be released, it won't be free
> > software.
> 
> Exactly, and there will be some distributions that will not include
> such software.

Which is *kind of* fine.  For distribution, I plan to package the
engine and some kind of installer.  The installer will be run on first
execution of the program and will automatically download the media
packs.  This should be okay, yes?

Either way, I'll talk to the other members of the team and see if they
won't consider distributing their work under the GPL.

Thanks,
-Rob


Gmane