From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id YEKpJ/mI+GFjNgEAgWs5BA (envelope-from ) for ; Tue, 01 Feb 2022 02:12:25 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id WOwOJfmI+GEl2wAA9RJhRA (envelope-from ) for ; Tue, 01 Feb 2022 02:12:25 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id CFC1A37370 for ; Tue, 1 Feb 2022 02:12:24 +0100 (CET) Received: from localhost ([::1]:43226 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nEhiZ-0000ZJ-Sq for larch@yhetil.org; Mon, 31 Jan 2022 20:12:23 -0500 Received: from eggs.gnu.org ([209.51.188.92]:45184) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nEhbk-0005mZ-NN for guix-devel@gnu.org; Mon, 31 Jan 2022 20:05:22 -0500 Received: from [2607:f8b0:4864:20::834] (port=43560 helo=mail-qt1-x834.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nEhbZ-0004Aw-M2 for guix-devel@gnu.org; Mon, 31 Jan 2022 20:05:13 -0500 Received: by mail-qt1-x834.google.com with SMTP id x5so43962qtw.10 for ; Mon, 31 Jan 2022 17:05:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=philipmcgrath.com; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=qOwFPDAWSuTaGYvfvlLw3HevQ4wb+/RcrvSgujmqx08=; b=aIikYCq0v0HSPv09vPHjouEqoc3wXcZdGjjufpQqypQ54A0oCpMRyhiTkJNoTp/QiJ +Sli+po+vrrOuwpZUKkGAlor0RkrXdQ+ABhadU4g9I4eXpyXvuPYTqp35uLMP+lQLrTI MP4R0EPArFM42/2Soypkkg2mdzb8iZ+KmvoOywarJMjiy16ieAkzo/rbYNNp8TeA0IUY CcabP+7dqrpRazvcBl4kjw/11CjPW521dY1K5d1KtsuuVlrvPf/zlxcAVfmPd26bgd0Z 8QX6+KIOe04+TRSC97eoVBOCCw3rQNJMVwnz2uBniWCjQS2Y6eoPUws/pnE1llQbO3N3 xsnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=qOwFPDAWSuTaGYvfvlLw3HevQ4wb+/RcrvSgujmqx08=; b=jaCf9DJvlDJcb121Vo3Xk0qhRJbSjeORMqMQvGFKCpdhZO8Yf4lZhv4x463L/xvLnD 4m8iSG5Jnkmr68aVFewbuy000DwTLRpjdu4RUcYGm1d7EBxvAR8w3TdG7tHtqGk1De03 sX8QGSfpsQcJVoYsvXK1UMj55Ww3U3+e5kpDz0TdUso+qcqR71/f1oWeEfK3MUKqKfcu PRbvqM8xEjantLws3Gsvml+nY6RCr0Mv2TT5lrC8jdyoD/2oakVO9lf5yu4x0FoZRfti LroswkXZnMcAwNjoLqHD4zGb4pjl3sl5N30D8cbmrQCXSYCmw4gZ9yatLKxF6e90gBjN qLbQ== X-Gm-Message-State: AOAM533gVol3Hn3tjJ/TKzzuEsFe6UjnkKwtvE4V8BudaQmbMqcztPkB ocuVbZkroDXU5R1FCx6lkaPslO0o0Wu8owE6LkQ= X-Google-Smtp-Source: ABdhPJxxI6OJxMcC6B+pItSXBlFqZBLJK8U4vzHez5CriyamGOm9Qog+n3thFueLXf+x61HcjgEdLQ== X-Received: by 2002:ac8:5a49:: with SMTP id o9mr17186726qta.665.1643677505892; Mon, 31 Jan 2022 17:05:05 -0800 (PST) Received: from [192.168.45.37] (c-73-125-98-51.hsd1.fl.comcast.net. [73.125.98.51]) by smtp.gmail.com with ESMTPSA id d17sm10599642qkn.84.2022.01.31.17.05.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 31 Jan 2022 17:05:05 -0800 (PST) Message-ID: <3ba35147-9974-381e-e273-9ccb4d00ac14@philipmcgrath.com> Date: Mon, 31 Jan 2022 20:05:04 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: License issue with SRFI 5 Content-Language: en-US To: =?UTF-8?Q?Ludovic_Court=c3=a8s?= References: <87o877zy9t.fsf@gnu.org> From: Philip McGrath In-Reply-To: <87o877zy9t.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::834 (failed) Received-SPF: neutral client-ip=2607:f8b0:4864:20::834; envelope-from=philip@philipmcgrath.com; helo=mail-qt1-x834.google.com X-Spam_score_int: -4 X-Spam_score: -0.5 X-Spam_bar: / X-Spam_report: (-0.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, PDS_HP_HELO_NORDNS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Guix Devel Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1643677945; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=qOwFPDAWSuTaGYvfvlLw3HevQ4wb+/RcrvSgujmqx08=; b=E/hspkMZfaIYezxvFBQ91tR8Uo0UPnJhVpU5WqdWyYDz7v56gPgnpNlyIlC96fG9G4m3ip BKpiVPMchhIi/SatCSRs59JweakbL9RB0QdQkLPe7zIhE5vYx3xBJ3LSHFc8s56rdlRqrN JOr3f+Fpwy//zwp84A2/SFM1glyjfJxxAAJUX/N0Sjtk2qeUxQxGmQhKbOF/hodBipblmk Cl42Up8emtjjuSh+RzaBRpm2E389slKQ23KckzKih14O8hduQ1tM6w0JI0ftCTz6EkwPTu joq+TRS5i7Kn/oWzIczNhhA4LmWMiED5DkWFclqcky0vfuSLV5DllSDjKXeC1A== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1643677945; a=rsa-sha256; cv=none; b=hUnai0+lcugw/YeUX/wRpMOCQc5g3qhls9LJnnVEWbgx5NQ4jbOM3w/8DGWeeyFfEsSFo2 TLTCKBNDvmJ+A7+SJuWpIwcCYJ2Df0O0NkOUVlTzjQoADXYkiPJG8YhwFFSfjzMkXt7rcE aPrRKE+Ft4Qf2FFSvXmXfvpuUrf3eWwow+FFl0oTtFXCRDQH9M3GVjyvH+RoAwfoYutvW0 1rnEXrBJ37fMC4l2VTTmXLPWMGEO9o2QCS23EdYIELxzE9rvhKcvKdhUS2wlGBrp29/sbg 3n5SSphvrTHRd4wrkIgYQixOZtpxbsLpgxZ2OP9dxkpRjKi6sj4UKTnMXim+dg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=philipmcgrath.com header.s=google header.b=aIikYCq0; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -3.83 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=philipmcgrath.com header.s=google header.b=aIikYCq0; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: CFC1A37370 X-Spam-Score: -3.83 X-Migadu-Scanner: scn1.migadu.com X-TUID: Yd6KxIDHrmXL Hi, On 10/29/21 10:44, Ludovic Courtès wrote: > Hi, This reply has taken a while because I did as you suggested and wrote some free replacement documentation (which involved paging back in some confusing details[1] and shaving several yaks), so now we have something concrete to talk about. To start with that, my proposed approach, which I hope satisfies the FSDG, is here: https://github.com/racket/srfi/pull/15 There are some loose ends to tie up (e.g. I have 48 pull requests open making tedious changes to the HTML markup of SRFI specification documents to bring Racket's version into alignment with upstream, which the current SRFI editor, Arthur Gleckler, is stalwartly reviewing), but Guix can cherry-pick it on top of Racket 8.4 (which may be released as soon as this week). The question is, do these changes resolve the situation for Guix (as I hope they do for Debian and Fedora, too), or is there anything more/different that needs to be done? > > Philip McGrath skribis: > >> Since 2005, SRFIs have used the MIT/Expat license, and all but two >> older SRFIs were relicensed: however, the SRFI editors were not able >> to contact the author of SRFI 5, Andy Gaynor, so it remains under the >> original SRFI license.[1] That license, modeled on that of IETF RFCs, >> was intended to be quite permissive while also trying to ensure >> derivative works would not be confused with the final, official SRFI >> itself. (The many versions of some SRFIs that nonetheless have come up >> while hunting down related issues has given me some sympathy for that >> goal.) Unfortunately, the restrictions on modifications went to far, >> at least in the judgement of Debian and Fedora. >> >> Here is the license text, as it appears at >> and >> : > > Oh. > > Do people actually use SRFI-5? (Honest question, I didn’t know about it > and don’t feel much appeal.) > > Is there code inside Racket that uses it? In short, no. When the Debian package maintainer first discovered the problem in late 2017 [2], the conclusion was that SRFI 5 wasn't used by any other part of Racket. The workaround [3] contributed by the Fedora package maintainer in early 2018 was to move the offending files into new "srfi-lib-nonfree" and "srfi-doc-nonfree" packages and for distribution maintainers to patch out the dependencies on them from the "srfi" package. This was all to accommodate Racket's exceptionally strong commitment to backwards compatibility, because it's a breaking change for a Racket package to stop providing a particular module (or documentation for a module) without adding an `implies` dependency on the new package it has moved to, and Racket packages are never supposed to make breaking changes. (The idea is you should make a new package under a different name, analogous to how a Debian system could have both the "guile-2.2" and the "guile-3.0" packages installed.) (At the time there were also issues with SRFIs 32 and 29 at the time, but those had actually been relicensed to MIT/Expat; it was just a matter of resolving lots of confusing different versions of things.) I then noticed "srfi-lib-nonfree" fly across my terminal, learned of the whole mess, and contributed a free reimplementation of SRFI 5 in 2019 [4], using `syntax-parse` to give vastly better error reporting. At that point "srfi-lib-nonfree" became an empty, free package that exists only to provide an `implies` dependency on "srfi-lib". According to [5], though, SRFI 5 is also implemented for Chez, Gauche, Larceny, STklos, and Scsh: I'm in the process of adapting my free implementation and compatibility test suite, which covers various ambiguities and errata [1], to R6RS to send upstream, so hopefully no one has to deal with this headache again. > >> Racketeers have high expectations of their documentation, like being >> able to right-click on an identifier in DrRacket (or the equivalent in >> Emacs with racket-mode) and jump to the locally-installed >> documentation for the relevant binding according to lexical scope and >> the module system---even for a binding like `let`, which is defined by >> 27 different Racket modules, including `srfi/5`. [...] >> >> This all raises a few questions about Guix policy: >> >> 1. Can Guix distribute the official SRFI 5 standard document under >> the license listed above? > > I don’t think so; it looks like a non-free software license to me. > >> 2. If not, can Guix distribute free documentation that links >> to an online copy of the official SRFI 5 standard document? > > I think it would be easy to do a “clean room” section documenting SRFI-5 > no? I mean, once you know the spec, documenting it is trivial, to the > point that it’s even hardly copyrightable (there’s little invention). > This is what I've done. With these changes, documentation for the `srfi/5` module points to the new, free Scribble documentation I've written. That let me remove the dependency from "srfi" on "srfi-doc-nonfree", which in turn means that "srfi-doc-nonfree" will no longer be a transitive dependency of "main-distribution". >> 3. Would it be permissible for the free documentation to >> include instructions for installing the official SRFI 5 standard >> document locally, e.g. `raco pkg install srfi-doc-nonfree`? >> (Or perhaps `raco pkg install srfi-5-std-doc`, to avoid the >> implication of arbitrary non-free materials?) > > Per the FSDG, no. > > [...] > >> However, there are a few less-than-fully-developed sentences in the >> FSDG that cast some doubt, e.g., "Programs in the system should not >> suggest installing nonfree plugins, documentation, and so on."[8] I do >> not think this should be read to prohibit free documentation for free >> software for referring to restrictively licensed standards implemented > > [...] > > You’re right that the FSDG can be interpreted in different ways. > Hopefully its spirit is clearer than its wording. > > For this case, I’d take the pragmatic approach (if Debian and Fedora > haven’t done it way) to either remove SRFI-5 from Racket if it’s > possible, or to do, like you suggest, a clean-room implementation of the > code and spec. Rewriting is likely going to take less time and be more > fun than trying to disentangle all the issues you mention. > I hope the way I've handled this can satisfy even a much more stringent interpretation of the FSDG than the reading I proposed in my last email. Before I give my opinion, though, let me point to the Scribble code in question, from : --8<---------------cut here---------------start------------->8--- (define srfi-nf-doc '(lib "srfi/scribblings/srfi-nf.scrbl")) ] Original specification: @seclink[#:indirect? #t #:doc srfi-nf-doc srfi-5-std-taglet]{SRFI 5} For @hyperlink[srfi-license-history-url]{historical reasons}, the SRFI 5 specification document has a @seclink[#:indirect? #t #:doc srfi-nf-doc srfi-5-license-taglet]{ restrictive license} and is not included in the main Racket distribution. The implementation in @racketmodname[srfi/5] and this documentation are distributed under the same @seclink["top" #:doc '(lib "scribblings/main/license.scrbl")]{license} as Racket: only the original specification document is restrictively licensed. --8<---------------cut here---------------end--------------->8--- The Scribble sections documenting SRFIs with free specification documents begin with "Original specification: SRFI N", where "SRFI N" is linked to the installed copy of "srfi-n.html". In this case, since there will not be a local copy installed, these expressions: --8<---------------cut here---------------start------------->8--- @seclink[#:indirect? #t #:doc srfi-nf-doc srfi-5-std-taglet]{SRFI 5} @seclink[#:indirect? #t #:doc srfi-nf-doc srfi-5-license-taglet{ restrictive license} --8<---------------cut here---------------end--------------->8--- will generate links to and . By using those esoteric Scribble incantations, though, the target of the link is not resolved until the very last minute, and, if it turns out the user has already installed the specification locally, the link will point to the local copy. In FSDG terms, neither the free Scribble documentation nor the docs that will be on the Racket website "suggest installing nonfree ... documentation". On the contrary, in all three places that so much as mention the existence of the original specification document---the one quoted above, an almost-empty Scribble file that needs to exist to put the document in place on docs.racket-lang.org, and a sort of banner at the top of the Racket's copy of the "srfi-5.html" document itself---I've given "a clear and serious exhortation" along the lines of the above warning that the SRFI 5 specification is restrictively licensed (which copy does not explicitly point out) and linking readers to the free documentation, instead. Since this exceeds the example set by `info "(gcc)Standards"`, I hope it fully satisfies the FSDG. Indeed, if someone does want to use SRFI 5, I hope the new free documentation I've written will be more useful than the original specification document, since the new documentation addresses the confusion and ambiguity [1] I've found in the standard over the last … um, over three years, somehow. > > Thanks for raising this issue; HTH! > > Ludo’. I do think there are some interesting things to think about from a philosophical/political perspective. Mostly I find the whole license situation quite sad. I think the Scheme community intended to create a free license for SRFIs, as evidenced particularly by the fact that, when concerns were raised, the editors managed to track down all but two of the authors of the c. 77 SRFIs finalized up to that point and successfully obtained permission to relicense. I think a sufficiently creative lawyer---but I am not any kind of lawyer---could argue that the restrictive language should be interpreted as a less well worded attempt to state the same substantive requirement as the Haskell Language Report License [7] saying, "Modified versions of this Report may also be copied and distributed for any purpose, provided that the modified version is clearly presented as such, and that it does not claim to be a definition of the Haskell 2010 Language." But I'm also glad Guix aims for a higher standard than "maybe arguably free"! Anyway, I hope these changes will finally resolve this issue for Racket, but, if anyone thinks something more or different ought to be done, please do let me know. -Philip [1]: https://srfi-email.schemers.org/srfi-discuss/msg/18709900/ [2]: https://github.com/racket/srfi/issues/4 [3]: https://github.com/racket/srfi/pull/5 [4]: https://github.com/racket/srfi/pull/7 [5]: https://practical-scheme.net/wiliki/schemexref.cgi?SRFI-5 [6]: https://srfi-email.schemers.org/srfi-announce/msg/2652023/ [7]: https://spdx.org/licenses/HaskellReport.html