On 12/9/23 09:19, Marc Nieper-Wißkirchen wrote: > Hi Maxim, > > Am Sa., 9. Dez. 2023 um 14:49 Uhr schrieb Maxim Cournoyer > <xxxxxx@gmail.com <mailto:xxxxxx@gmail.com>>: > > Hi Marc, > > Marc Nieper-Wißkirchen <xxxxxx@gmail.com > <mailto:xxxxxx@gmail.com>> writes: > > > [...] > > > I'm afraid I have to disagree here. If a sample implementation > is licensed > > under a copyleft license and cannot be incorporated into a particular > > Scheme implementation because that implementation is not licensed > under the > > GPL, it is the problem of that Scheme implementation, and the > author must > > not be persuaded to choose a weaker license. On the contrary, > the Scheme > > implementer should be persuaded instead to choose the GPL. > > > > (Some may disagree with these ethical aspects, so in the end, it > has to be > > up to the individual author of the sample implementation to > decide whether > > a copyleft license or a weak free license is appropriate.) > > I appreciate your strong stance toward the free software cause, but for > the goal of SRFIs sample implementations, which I assume is to maximize > participation and usefulness across as many Schemes as possible, it > seems fitter to use a permissive (weak) rather than copyleft (strong) > free software license. Even Guile, a GNU project, would have its > effective license changed from LGPL to GPL if combined GPL licensed > sources as it is LGPL licensed. > > > SRFI means "Scheme Request for Implementation". This is a task for the > implementer of a Scheme system. The primary goal of a sample > implementation is not to provide code that can simply be copied (in this > case the SRFI process is not needed but the author's work can simply be > distributed as a portable library) but to prove that the request for > implementation is feasible. It is okay if Scheme systems whose license > does not forbid that the work that went into them can be cannibalized by > vendors of proprietary software are put at a disadvantage compared to > Scheme systems who choose the GPL (or a compatible strong copyleft license). > > That said, please note that I didn't say (nor meant) to encourage > authors to use the GPL. My point was that an author must not be > dissuaded to use the GPL if he or she wishes so. My contributions to > the SRFI project so far all use the MIT license. > While in many contexts I advocate for copyleft, I agree with Maxim here. Past SRFI editors have articulated "the intent that the SRFI documents and associated reference implementations would be usable in as many circumstances as possible," explicitly including "allowing for proprietary systems to use SRFIs" (see <https://srfi-email.schemers.org/srfi-announce/msg/2652023/>). A strong copyleft license on a sample implementation might also impede the SRFI process if it deterred implementers from reading it so as to ensure their potential future implementations could not be considered "derived works" of the sample. I am in fact not aware of any Scheme implementation that uses the GPL: as Maxim points out, even GNU Guile is LGPL, and specifies in <https://www.gnu.org/software/guile/manual/html_node/Guile-License.html>: > Scheme level code written to be run by Guile (but not derived from Guile itself) is not restricted in any way, and may be published on any terms. We encourage authors to publish on Free terms. There seems to be a broader norm that programming language implementations ought not to place restrictions on the programs they run (compile and/or interpret), and that this principle may justify special permissiveness, as in the GCC Runtime Library Exception to the GPL or the LLVM Exceptions to the Apache-2.0 License. I fear that if this principle were to be breached, it would be to the great detriment of free software. I view SRFIs as requests for implementers to extend the dialect of the Scheme language they implement, so similar permissiveness seems justified here. But in any case, my personal view is not especially relevant, as a policy for the SRFI process has already been established. In fact, I see now that <https://srfi-email.schemers.org/srfi-announce/msg/2652023/> already articulated criteria for a suitable license in the SRFI context, so I propose we just adopt that language, amending the text of the process document to read: In addition to the SRFI document, any software written specifically for the SRFI should be published under the above license. However, at the editors' discretion, the SRFI may reference software that was already written and published under another widely accepted free license which is GPL-compatible, OSI certified, and non-copyleft, citing that software as its sample implementation. The BSD 2- and 3-clause licenses are specifically allowed for this purpose. > > >>> I've opted for the pragmatic solution, which is to mark these > >>> insignificant files as MIT licensed, knowing it wouldn't be found > >>> protected by copyright in court anyway (no harm done), which was > >>> suggested somewhere. > >>> > >> > > If files carry no license (so the license status is unclear), a > license > > must not be added without consent by the author. Either it is > > insignificant, in which case nothing would have changed in front > of a court > > anyway, or it is significant, in which case it would have been > wrong to > > guess and attach a license. > > That's going to make things a bit more difficult. Reaching out to > historical SRFI authors has yet to produce a reply. On the other hand, > this highlights the importance of adding guidelines to have SRFI authors > ensure their submission is clean with regard to 'reuse lint', so that we > do not need to hunt down their consent many years from now. > > > What's the problem with not touching existing files that don't include a > license? It would be counterproductive to guess and add a license > because then a mechanical check may actually give wrong results (namely > in case that the guess was wrong). > I think the SRFI process document is sufficiently clear that the MIT/Expat license applies to "this software and associated documentation files" unless some other license is explicitly noted (by permission of the SRFI editors, by accident, or for historical reasons). Philip
