GPLv3 licensing issues

[gschmottlach-xse]

FYI -

Although the license states that this module is licensed under a flexible MIT/BSD license, as built, it include GPLv3 sources. This is a direct result of using the autoolize 'bootstrap' script to generate the configure script. The 'bootstrap' script creates a file in "lib" called dummy.c that includes the GPLv3 license and is summarily compiled and linked to the module. As a result, this module is now GPLv3 for all intensive purposes. This is very unfortunate and I suspect not the intent. The 'dummy.c' file is a bogus file that is only there to make the linker on MacOSX, FreeBSD, and SunOS happy. The contents are either the definition of an unused typedef or the declaration of an unused int:

ifdef __sun

/* This declaration ensures that the library will export at least 1 symbol. */
int gl_dummy_symbol;

else

/* This declaration is solely to ensure that after preprocessing
this file is never empty. */
typedef int dummy;

endif

It's clear that this should be easy to remove and I believe it should be removed so that the commercially friendly MIT/BSD license can be maintained. One fix I would propose is to remove and/or re-write the file after 'bootstrap' runs to eliminate this issue.

Sorry for being picky, but without this change, it's makes it impossible to use this module in commercial projects where I believe many people already use it. Is this something you could fix?

[rrthomas]

Fixed in commit 94f96cb; thanks for the report.

[gschmottlach-xse]

I commend you on addressing this so quickly. Thank you for the prompt attention and resolution to this issue.

[rofl0r]

why is gnulib there in the first place ?
gnulib is an unportable abomination, maintainers nightmare, and should be burnt at stake

[rrthomas]

From this maintainer's point of view, gnulib is an excellent aid to portability: with it, I can write to standards, not systems, and gnulib takes care of the rest. If you find bugs in it, report them: the developers are highly active.

[rofl0r]

there is a standard, it's called POSIX
if some ancient AIX or IRIX implementation doesnt conform, it's not your problem.
try to build this using a modern libc such as musl, and it will fail:
fseterr.c:72:3: error: #error "Please port gnulib fseterr.c to your platform! Look at the definitions of ferror
freadahead.c:83:3: error: #error "Please port gnulib freadahead.c to your platform! Look at the definition of fflush

gnulib is horrible, it basically duplicates half the libc, is interdependant (so if you use one function it will pull in others) and its "in-tree" philosophy prevents fixing it once and be done with it.
in contrast, you have to fix any program that uses it.

[rrthomas]

Unfortunately few implementations of POSIX are perfect; this includes Darwin (Mac OS X) and GNU/Linux. gnulib does not duplicate anything, it provides implementations only for platforms which don't implement POSIX properly or fully. (For example, if you compile against glibc, very little gnulib code will be built.) It also adds a number of extra very useful APIs, from GNU and of its own.

But as I say, please report problems to bug-gnulib@gnu.org, as talking about them in a luaposix bug report won't get anything fixed.

[rofl0r]

gnulib does not duplicate anything

why does it build and link the entire printf suite then, when a perfectly conformant implementation is provided?

it only happens to work well with glibc because it accesses internal members (!) of glibc's FILE struct.
i am complaining here, because you have gnulib in your tree. if it gets fixed upstream, you will still have the old cruft in your tree.

[rrthomas]

I don't have gnulib C code in my tree. gnulib is not available under an MIT-compatible license, so luaposix uses no gnulib code (at least, not intentionally).

[rrthomas]

(I have written to bug-gnulib about the problems with musl; I suggest you file additional problem or bug reports as you see fit.)

[rrthomas]

I got the following reply from a gnulib maintainer about the particular problem you mention: "IIRC, gnulib's freadahead use is caused by musl's printf not being posix
compliant, causing gnulib to pull in its printf replacement, which doesn't work
on musl. A library that is new, actively maintained, and that calls itself
a "C/POSIX standard library" should really address that by making it's printf
posix compliant, so that gnulib's fallback doesn't even get built. It seems that
nobody who is interested in musl has looked at gnulib's config.log to understand
why does gnulib think musl's printf is not good enough."

I'll raise that on the musl mailing list.