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

[Jay Carlson <nop@...>]

[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, AllanPfalzgraf@eaton.com 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.