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.
