Re: The impact of a module's license on the requiring Lua

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: The impact of a module's license on the requiring Lua

AllanPfalzgraf

This is an interesting question for my use of Lua.

 

I’ve built a scripting front end for a purchased, non-GPL, Ethernet/IP stack.  The stack cannot be freely distributed in source form by its license.

 

So long as the lib is only used within my company there is not an issue.

 

Sharing could be done with the GPL portion of the library with a text file informing the would be user where to get the key part that makes it worthwhile.  Would anyone really be interested in such a crippled part of a library?

 

 

 

 

Reply | Threaded
Open this post in threaded view
|

Re: The impact of a module's license on the requiring Lua

Enrico Tassi
On Fri, Apr 13, 2012 at 10:08:49AM -0400, [hidden email] wrote:

> This is an interesting question for my use of Lua.
>
> I've built a scripting front end for a purchased, non-GPL, Ethernet/IP
> stack.  The stack cannot be freely distributed in source form by its
> license.
> So long as the lib is only used within my company there is not an issue.
> Sharing could be done with the GPL portion of the library with a text
> file informing the would be user where to get the key part that makes it
> worthwhile.  Would anyone really be interested in such a crippled part
> of a library?

That is not so uncommon. Debian as an entire section of the archive
called "contrib" for stuff that is free but that really needs something
non free to be useful. In particular your module will be useful to every
other customer of the same proprietary network stack.

But we killed this thread, didn't we?

Cheers
--
Enrico Tassi

Reply | Threaded
Open this post in threaded view
|

Re: The impact of a module's license on the requiring Lua

Jay Carlson
[tl;dr: there *are* some lua-specific license issues; I hadn't thought of how they'd hit me either. and i'm rude to my hosts.]

On Apr 13, 2012, at 11:32 AM, Enrico Tassi wrote:

> On Fri, Apr 13, 2012 at 10:08:49AM -0400, [hidden email] wrote:
>> This is an interesting question for my use of Lua.
>>
>> I've built a scripting front end for a purchased, non-GPL, Ethernet/IP
>> stack.  The stack cannot be freely distributed in source form by its
>> license.
>> So long as the lib is only used within my company there is not an issue.
>> Sharing could be done with the GPL portion of the library with a text
>> file informing the would be user where to get the key part that makes it
>> worthwhile.  Would anyone really be interested in such a crippled part
>> of a library?
>
> That is not so uncommon. Debian as an entire section of the archive
> called "contrib" for stuff that is free but that really needs something
> non free to be useful. In particular your module will be useful to every
> other customer of the same proprietary network stack.
>
> But we killed this thread, didn't we?

It's a shame. Ignore the people arguing about tone; there really are some Lua-relevant license compatibility issues and if not here, where?

I don't like the conceit that everybody understands the licenses they use; debian-legal is years upon years of evidence that no, people are not born with deep knowledge of free software licenses and their interactions with other licenses. It's not fair to demand it, and not realistic to expect it. I think the assumption "the author knows what they are doing" is mostly a way to deal with mail traffic, and it is inferior to "ask authors about licenses off-list first, please."

The viral parts of the GPL can only become applicable when you write something that is a "derived work" of mine. If your code cannot function without my code, it is thought to be evidence your code is derived, under some legal theories in many copyright regimes.[1] This is the reasoning which placed any code using readline under the GPL.

Lua on Linux uses readline. This is not an abstract issue.

License terms are intertwined with languages. IMO, GNU Smalltalk crashed and burned partially because, in the tradition of Smalltalk, the executable unit was a whole-system image, and source code was distributed as patches to be merged into the image. The position taken by the GST authors was any software package written in the GST dialect would be covered by the GPL since the package realistically could not function without GST. (This was before Squeak, when all other non-toy Smalltalks were proprietary.) The GPL conclusion is hard to avoid. The application of the GPL to dynamic languages created some unanticipated consequences. If you think the only license should be the GPL, it is a happy accident, but I didn't think so.

One common pattern in Lua is to use both Lua and C code together, often building a single object file with both; LuaSocket is the best-known example. There are some advantages to distributing even pure Lua libraries archived in a DLLs with a thin veneer.

I had not thought of this until this discussion:[2]

Steve Donovan's tool to take a collection of Lua programs/modules, C libraries, and lua.exe and create a statically linked myprogram.exe can be a license trap waiting for the unwary. Tools like Squish and soar do this too, but linking with big non-Lua-flavored C libraries is most likely to result in an executable which cannot be distributed due to license conflicts. An intended use of soar is to feed such an .exe-builder, so I would love it if luarock owners were taking note of licensing/linking/redistribution issues.

Readline and libedit are the clarifying example for the limits of viral licensing through API use, as Miles says. Because libedit exists independently and has the same[3] API as readline an argument can be made that your code using the API is simultaneously a derivative work of both readline and libedit--which is absurd. I think the best interpretation is that independent implementation is "argument by code": readline was not so important as to create any moral right over your code that used it.

If someone reimplements my GPL'd library in this fashion, I am being interpreted as damage, and being routed around. My choice of the GPL for a small, cheap project can be seen as an overblown claim of my software's importance. If I instead sell a closed-source license with many restrictions I'm setting a high value as well, but people already flame rip-off commercial libraries. Either closed or GPL, the existence of my package does not take anything away from others, but an awful lot of public, announced Lua packages distributed under the MIT license; picking something different makes you, well, different. The vast majority of Lua code is distributed under highly restrictive licenses (Lightroom or pick your favorite games) and nobody seems to get upset about it here--but nobody promotes those packages as a resource on-list either.

So placing packages under the GPL can be seen as a claim of importance as well as just a dispassionate business decision. Let's look at the other end of the scale too, at software which really is expensive to replicate, and highly unlikely to have an API clone created. These are packages which are going to stay GPL'd. An interesting outcome of the GPL on infrastructure is that it can break Prisoner's Dilemma issues in cooperation. Both Intel and IBM are better off cooperating on Linux kernel development, but I'm sure an element of business management at each company would prefer to take and not give. Instead, by being forced to share code, they are cursed to get rich together (and flatten Sun in the process). This makes more sense at the level of tools; the majority of software packages discussed on lua-l (by the list's nature) are not standalone tools, and don't fit this GPL pattern.

Jay

[1]: I am not a lawyer, and I am not a lawyer in your jurisdiction. Your copyright laws vary.

[2]: I suppose I am arguing that some good *did* come from this thread. Watch me contradict lhf and Roberto in a single message--sigh. Twenty-something years on mailing lists and I still have no sense.

[3]: OK, libedit is not a complete readline reimplementation, it's an incomplete shim--it doesn't matter in this case I think, and if you're nitpicking here you can go audit lua.c for us.
Reply | Threaded
Open this post in threaded view
|

Re: The impact of a module's license on the requiring Lua

steve donovan
On Mon, Apr 16, 2012 at 10:26 PM, Jay Carlson <[hidden email]> wrote:
> Lua on Linux uses readline. This is not an abstract issue.

I've been worried ever since that linked document claimed that
readline _was_ a problem for non-GPL software, despite Miles'
assurances.

Well, working around the damange: I'm going to make linenoise an
option for luabuild. It's perfect for the usual use scenario, and it's
only about 600 lines of C so it can be statically linked. And, as the
man page for readline itself says, "It's too big and too slow". Mike
Pall very deliberately does not link LuaJIT against readline because
he has empirical evidence that it significantly slows down
non-interactive invocations of the interpreter.

By derfault, statically-linked Linux executables with luabuild do not
link against readline, but if you're actually distributing an
interactive application you do need some support for editing and
history, so I'll include the binding against linenoise for that.

Yes, a tool for static linking is potentially a minefield. I'm going
to very careful about this, because respect for licenses is part of
the core open source ethos. (and it can get you into trouble) (Oh, and
actually stick a proper MIT/X11 license on the thing ;))

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: The impact of a module's license on the requiring Lua

Mike Pall-38
steve donovan wrote:
> Yes, a tool for static linking is potentially a minefield. I'm going
> to very careful about this, because respect for licenses is part of
> the core open source ethos. (and it can get you into trouble) (Oh, and
> actually stick a proper MIT/X11 license on the thing ;))

While you're at it: Lua uses a variant of the MIT license, not the
MIT/X11 license. There's a difference. I've made that mistake
before. A discussion is somewhere in the mailing list archives.

I've decided to refer to it as the MIT license and link to:
  http://www.opensource.org/licenses/mit-license.php

--Mike

Reply | Threaded
Open this post in threaded view
|

Re: The impact of a module's license on the requiring Lua

steve donovan
On Tue, Apr 17, 2012 at 11:11 AM, Mike Pall <[hidden email]> wrote:
> While you're at it: Lua uses a variant of the MIT license, not the
> MIT/X11 license.

Thanks, Mike; these things do matter, and 'MIT' is easier to type.

Latest push of luabuild provides an option to build against linenoise
(which is BSD)

$ lua lake LINENOISE=1

ditto for a static build

$ lua lake LINENOISE=1 STATIC=1

(In both cases linenoise is linked statically)

Also includes Rob Hoelz's lua-linenoise binding, and I've done an
example.lua [1] file in lieu of any actual documentation.

There was a discussion about using linenoise in Lua [2]; the feeling
was that it was underpowered for some more interesting uses like
intelligent completion. However, this situation has changed materially
since then, since there is now adequate completion support, which is
exposed by lua-linenoise.  Doing a little Lua interpreter with
context-sensitive completion would not be difficult, especially if we
start with a more fully-featured version like ilua.

steve d.

[1] https://github.com/stevedonovan/luabuild/blob/master/modules/lua-linenoise/example.lua
[2] http://lua-users.org/lists/lua-l/2010-03/msg00865.html

Reply | Threaded
Open this post in threaded view
|

Re: The impact of a module's license on the requiring Lua

Roberto Ierusalimschy
In reply to this post by Mike Pall-38
> While you're at it: Lua uses a variant of the MIT license, not the
> MIT/X11 license. There's a difference. I've made that mistake
> before. A discussion is somewhere in the mailing list archives.
>
> I've decided to refer to it as the MIT license and link to:
>   http://www.opensource.org/licenses/mit-license.php

Since Lua 5.0 (2003) we have adopted the MIT license, not a variant. If
there is any difference, we should correct it. I just compared the text
in that link with the Lua license, and did not see any difference. Could
you point out what it is?

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: The impact of a module's license on the requiring Lua

Pierre Chapuis
On 2012-04-17 15:26, Roberto Ierusalimschy wrote:

>> While you're at it: Lua uses a variant of the MIT license, not the
>> MIT/X11 license. There's a difference. I've made that mistake
>> before. A discussion is somewhere in the mailing list archives.
>>
>> I've decided to refer to it as the MIT license and link to:
>>   http://www.opensource.org/licenses/mit-license.php
>
> Since Lua 5.0 (2003) we have adopted the MIT license, not a variant.
> If
> there is any difference, we should correct it. I just compared the
> text
> in that link with the Lua license, and did not see any difference.
> Could
> you point out what it is?

He is probably referring to the difference between the MIT/Expat (used
by
Lua and on the OSI site) and the more popular MIT/X11 variant.

See http://en.wikipedia.org/wiki/MIT_License#Various_versions for more
information about the difference.

--
Pierre Chapuis

Reply | Threaded
Open this post in threaded view
|

Re: The impact of a module's license on the requiring Lua

Mike Pall-38
In reply to this post by Roberto Ierusalimschy
Roberto Ierusalimschy wrote:

> > While you're at it: Lua uses a variant of the MIT license, not the
> > MIT/X11 license. There's a difference. I've made that mistake
> > before. A discussion is somewhere in the mailing list archives.
> >
> > I've decided to refer to it as the MIT license and link to:
> >   http://www.opensource.org/licenses/mit-license.php
>
> Since Lua 5.0 (2003) we have adopted the MIT license, not a variant. If
> there is any difference, we should correct it. I just compared the text
> in that link with the Lua license, and did not see any difference. Could
> you point out what it is?

I'm just repeating what was said here:

  http://lua-users.org/lists/lua-l/2011-08/msg00508.html

Ok, so the MIT/X11 license probably was first. And what we call
the MIT license nowadays is really the MIT/Expat license. But all
of that is mostly of historic interest.

Anyway, using the naming convention from opensource.org makes
sense. So let's just stay with "MIT license" when we refer to the
license of Lua (and most of its ecosystem).

The actual license text needs to be included in full length in
every package, anyway. That ought to make the lawyers happy, too.

--Mike

Reply | Threaded
Open this post in threaded view
|

Re: The impact of a module's license on the requiring Lua

Roberto Ierusalimschy
In reply to this post by Pierre Chapuis
> He is probably referring to the difference between the MIT/Expat
> (used by
> Lua and on the OSI site) and the more popular MIT/X11 variant.
>
> See http://en.wikipedia.org/wiki/MIT_License#Various_versions for more
> information about the difference.

That link talks about "versions" of the MIT license, not "variants".

A version is not a variant; a variant may mean "deviating from a
standard", "not agreeing or conforming", "varying usually slightly from
the standard form", etc.

My worry is that the claim "Lua uses a variant of the MIT license",
recorded in the archives, may cause unnecessary noise in the future.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: The impact of a module's license on the requiring Lua

Enrico Tassi
In reply to this post by steve donovan
On Tue, Apr 17, 2012 at 08:21:52AM +0200, steve donovan wrote:
> On Mon, Apr 16, 2012 at 10:26 PM, Jay Carlson <[hidden email]> wrote:
> > Lua on Linux uses readline. This is not an abstract issue.
>
> I've been worried ever since that linked document claimed that
> readline _was_ a problem for non-GPL software, despite Miles'
> assurances.

Well, on my Debian system '/usr/bin/lua5.1' is linked with readline.  
If Miles is wrong, and I don't think so, what happens? Nothing. The lua
interpreter inherits GPL and my lua scripts stays exaclty as they are,
under the license I gave to them.
Well, one may complain that the copyright file included with the Lua
package is wrong, but still there is nothing illegal going on there. A
GPL version of the lua interpreter can still be distributed, it is still
free software, and its sources are freely available.

On my very same Debian system, all applications using stock lua link
against /usr/lib/.../liblua5.1.so.0.0.0 that is not itself linked with
readline. So They can be licensed as their authors wanted them to be.

Moreover, even if I find it ridicolous, one could still claim GPL infects
lua.c, the interpreter main loop, but not the rest, that is clearly not
a derived work since it does not even use the readline APIs, and can be
built as a library not linked against readline.
Even in an embedded software that statically links the lua code, the
interpreter (lua.c) is very likely to be left out, and with it any
reference to readline.

Last, if you don't like readline, and you really think it's a problem to
link against it, just link with libedit. "Problem" solved.

Please don't make the awesome lua list look like debian-legal!

Regards.
--
Enrico Tassi

Reply | Threaded
Open this post in threaded view
|

Re: The impact of a module's license on the requiring Lua

steve donovan
On Tue, Apr 17, 2012 at 4:46 PM, Enrico Tassi <[hidden email]> wrote:
> Please don't make the awesome lua list look like debian-legal!

Amen!  I would much rather discuss software issues, like the merits of
linenoise ;)

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: The impact of a module's license on the requiring Lua

Marc Balmer
Am 17.04.12 17:35, schrieb steve donovan:
> On Tue, Apr 17, 2012 at 4:46 PM, Enrico Tassi <[hidden email]> wrote:
>> Please don't make the awesome lua list look like debian-legal!
>
> Amen!  I would much rather discuss software issues, like the merits of
> linenoise ;)

License issues, however, are important.  Lua is used in the industry,
where such things matter a lot.

Reply | Threaded
Open this post in threaded view
|

Re: The impact of a module's license on the requiring Lua

Jay Carlson
In reply to this post by steve donovan

On Tue, Apr 17, 2012 at 2:21 AM, steve donovan <[hidden email]> wrote:
> On Mon, Apr 16, 2012 at 10:26 PM, Jay Carlson <[hidden email]> wrote:
>> Lua on Linux uses readline. This is not an abstract issue.
>
> I've been worried ever since that linked document claimed that
> readline _was_ a problem for non-GPL software, despite Miles'
> assurances.

My belief is that it does not contaminate Lua for a couple of reasons and I'll agree that debian-legal is a better place to discuss why. However, *distributing* the combination of readline and Lua requires care, especially if statically linked.

> Yes, a tool for static linking is potentially a minefield. I'm going
> to very careful about this, because respect for licenses is part of
> the core open source ethos. (and it can get you into trouble) (Oh, and
> actually stick a proper MIT/X11 license on the thing ;))

Supporting LGPL'd packages may not be bad. The two technically significant terms are that the executable must support being run with a modified version of the LGPL'd code, and that the source for the LGPL'd parts be distributed.

The preferred form of the source is however you would want to edit it yourself. That's the version *before* running it through the squash/strip/minify/obfuscate tool....

Time is limited, and it may not be worth it to try to come up with a perfect solution for this. Ideally there could be just a single file which was both executable and transparent to disassemble and reassemble. That's hard for actual static binaries. People distributing full source don't care. The people who could use help from an executable-binder in order to comply with the LGPL are people using stuff like GTK but not wishing to ship the rest of their source code. The fastest way to solve this is to tell them to make sure to ship the exploded version of the app as well: their_modified_lua.exe and all the GTK DLLs and other goo. There are solutions involving partial linking (ld -r) but I don't want to deal with that cross-platform right now.

In the spirit of allowing relinking, I think it may be a good idea to allow the environment to jam a _LUABUILD_LUA_INIT in, and perhaps obey a _LUABUILD_LUA_PATH/CPATH. Something like _LUABUILD_LUA_INIT is necessary to nuke preloaded modules; this allows require() to reach out into the file system for replacements.

I don't adding such code solves license issues, but it can be awfully convenient. I wouldn't even make it a visibly tweakable option; people who want to turn it off can edit your tool.

Similarly, hooks to cat out resources from the exe are nice to have, but maybe it should be configurable. I have no idea.

Jay

Reply | Threaded
Open this post in threaded view
|

Re: The impact of a module's license on the requiring Lua

steve donovan
On Wed, Apr 18, 2012 at 10:58 PM, Jay Carlson <[hidden email]> wrote:
> I'll agree that debian-legal is a better place to discuss why. However,
> *distributing* the combination of readline and Lua requires care, especially
> if statically linked.

Yes, a brief search of the internets revealed some very strong
opinions on the matter; it all reads like theological discussion to
me.

Well, I have 'routed around the damage' by providing linenoise as a
statically-linkable BSD equivalent (adds less than 10KB) so that there
is a 'safe' option, which has the advantage of removing a somewhat
unstable dynamic dependency for standalone executables. (That phrase
is used in the technical sense, BTW; I have no beef against the GPL
and have used it myself)

LGPL is just going to be too complicated for such a project to manage...

> Similarly, hooks to cat out resources from the exe are nice to have, but
> maybe it should be configurable. I have no idea.

It could be very useful. I have a use case, a little personal web
server called Orbiter which needs to embed resources like CSS and
javascript.  The usual, LuaRocks-friendly strategy is to bundle text
resources as Lua modules - Yuri takes this to its elegant extreme with
Sputnik; he even embeds icons like this.[1]  But a clever tool could
do that for a person.

steve d.

[1] Windows executables have resources, which can be anything. No
doubt there is some equivalent out there for Unix.