Hello, Thank you for your reply.
Marc Nieper-Wißkirchen <[email protected]> writes: > As a SRFI author, I prefer to have the license in text form in each > (non-trivial) source file, making the files self-contained as far as > licensing goes. This is not unimportant when files are copied or merged by > users of the code. That's an interesting perspective. Perhaps, as others have suggested, we could leave the preexisting license texts in, but for every other files lacking it, they could be annotated with their correct SPDX metadata (license and copyright notices equivalent), taking care to also add the textual licenses referred by the SPDX IDs to LICENSES/MIT.txt or accordingly? E.g., https://github.com/scheme-requests-for-implementation/srfi-160/blob/master/srfi/160/at-impl.scm would get the added: ;;; SPDX-FileCopyrightText: 2019 John Cowan <cowan@...> ;;; ;;; SPDX-License-Identifier: MIT Then it'd be a win-win for all share holders (current status maintained with regard to self-containment, and the newly added annotations help clarify the copyright/license status of each file). > I agree that only "canonical" and well-recognized licenses should be used. > > I don't believe in mass-copying SRFI sample implementations into Scheme > systems/library distributions because the sample implementations are > usually not tuned to a particular system or tuned at all. The time needed > to check the licence is neglectable to the time needed to understand the > code and tuning/rewriting it for a particular system. In my (limited) experience with Guile, the sample implementations are often used as-is without any issues, and rarely (?) fine tuned. For example that's what I've done with this recent series adding SRFI 209 [0]. [0] https://lists.gnu.org/archive/html/guile-devel/2023-12/msg00050.html At least it makes for a good starting point (an unoptimized copy is better than none). -- Thanks, Maxim
