 |
lua-l archive |
|
|
||
|
On Tue, Apr 17, 2012 at 2:21 AM, steve donovan <steve.j.donovan@gmail.com> wrote:
> On Mon, Apr 16, 2012 at 10:26 PM, Jay Carlson <nop@nop.com> 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