2019年3月16日(土) 17:32 Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de>:
- snip -
> If a Scheme implementation just ships GPL'd code so that it can be loaded by Scheme programs, this would probably not make the implementation a derived work of the GPL'd code.
> (For example, the GCC is not a derived work of the GNU libc.)

GCC simply does not shipped with GNU libc(which is LGPL); although
these are closely related products, these are distributed as separate
products. We can use GCC without GNU libc, some Linux(Alpine) uses
MUSL libc, macOS or *BSD uses BSD libc, Android uses bionic libc and
MinGW uses MSVCRT w/ some supplemental code.

I guess you meant libgcc/libstdc++ here, which is a bit more closely
related with GCC (and licensed with GPL3). Although libstdc++ is GPL3,
it explicitly added exception clauses (
https://gcc.gnu.org/onlinedocs/libstdc++/manual/license.html ) so it
would allow the library used by proprietary programs.

AFAIK, there is none of language platform that uses *plain* GPL2 or 3
on its runtime library, to enforce language users to be GPL compliant
with their applications. The most of language implementations that is
licensed under GPL2/3, it applies some special clauses to explicitly
exclude user applications from GPL. e.g. Every GCC languages, GNAT,
classpath. (Guile simply uses LGPL here.)

An interesting exception here is CLISP. CLISP explicitly states apps
needs to be GPL-compatible iff it uses beyond what Common Lisp
defines( https://clisp.sourceforge.io/impnotes/faq.html#faq-licensing
). But it should be noted that their GPL portions are for
implementation specific features.

> Of course, Scheme programs loading or linking that GPL'd code have to be GPL'd as well.

In SRFI context, it's depends with how the programs distributed. In
case the program distributed with any form that can comply every GPL
requirements -- in short, as source code -- it can be licensed under
any GPL-compatible license.
Anyone can create derived work of the program that does not depends on
GPL'd code, and may be distribute under non-GPL-compliant form.

This is because SRFI would just define software interface that can
anyone create GPL-free implementation of the same interface. It's
something different from GPLed-API issues on GPL software such as
CLISP or Linux Kernel Modules. But anyway, the program can be
dual-licensed explicitly to allow such derived works.

> In any case, I think this is an advantage, not a disadvantage. :)

GPL is complex; it would even make a troll
https://opensource.com/article/17/8/patrick-mchardy-and-copyright-profiteering
...

GNU R can be an example for what would happen if the system licensed
under GPL; https://www.r-bloggers.com/how-gpl-makes-me-leave-r-for-python/
. Once the ecosystem became that is not GPL-free, people would be
uncertain about they are GPL-compliant with their works, because there
is certain risk that pull-in GPL dependency unexpectedly by web of
library dependencies.

At least, I'd recommend to avoid GPLv2-only, that is illegal to
compile on ChezScheme(that is, Apache 2.0 only). GPLv2-or-later and
GPLv3 are still safe to use on any implementation known to me.

In case there's serious need for copyleft license for a
sample/reference implementations, I'd recommend "L"GPLv2-or-later,
because:

1) Easy to follow for macro libraries without any exception clauses.
Eigen(now licensed under MPL2 though) FAQ is written very well on this
http://eigen.tuxfamily.org/index.php?title=Licensing_FAQ&oldid=1117#So_what_does_the_LGPL_require_me_to_do.3F
2) It's compatible with ChezScheme in any form
3) Less restriction on it's usage compared with GPL

please note that some companies still effectively bans (L)GPL because
of its requirements (patents licensing, reverse engineering and
"installation information").

Overall, I do not recommend (L)GPL licenses anywhere possible.
Historically, IIRC, SRFI sample/reference implementations are licensed
under MIT-like licenses. SRFI-46 is the only exception I'm aware of.