From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 4IhsKj9llmDKaAAAgWs5BA (envelope-from ) for ; Sat, 08 May 2021 12:17:35 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id 4DbrJT9llmAFQAAAbx9fmQ (envelope-from ) for ; Sat, 08 May 2021 10:17:35 +0000 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 0810A10C1C for ; Sat, 8 May 2021 12:17:35 +0200 (CEST) Received: from localhost ([::1]:33784 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lfK1e-0007zp-6s for larch@yhetil.org; Sat, 08 May 2021 06:17:34 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55222) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lfK1R-0007zg-Kd for guix-devel@gnu.org; Sat, 08 May 2021 06:17:22 -0400 Received: from mailrelay.tugraz.at ([129.27.2.202]:41942) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lfK1M-0000XQ-BN for guix-devel@gnu.org; Sat, 08 May 2021 06:17:20 -0400 Received: from [10.0.0.4] (91-114-247-246.adsl.highway.telekom.at [91.114.247.246]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4Fcjsx0Mbqz3xlr; Sat, 8 May 2021 12:17:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1620469029; bh=R65FeAAkRGTAe5h+LgSYjQlbKsEjfYv6szehLjyTTQM=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=VVYZ9wvSH0C2mRPMslLqtz7l8ON2vK8K+dUzS10dfoswwYIuCSWScTqAysuw6WJm1 gjK/pc040AoEcjfUFyRHYu6GtFbI7mYrNOt/anRt2xSAcIu27PAATZNQcWJUr7jel+ 4TeP3w4CYvNfHHQCGC0Ies1SOp5vCOejt4f3zMJk= Message-ID: Subject: Re: The purpose of the "license" list of a Guix package (Was: Re: Jam: which licence is this?) From: Leo Prikler To: Chris Marusich , Leo Famulari Date: Sat, 08 May 2021 12:16:48 +0200 In-Reply-To: <871rai2y5f.fsf_-_@gmail.com> References: <87tunuq1ei.fsf@elephly.net> <87sg3ejmxv.fsf@netris.org> <87h7juje1a.fsf@netris.org> <874kflrb1t.fsf@netris.org> <871rai2y5f.fsf_-_@gmail.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-TUG-Backscatter-control: bt4lQm5Tva3SBgCuw0EnZw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.9 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.117 Received-SPF: pass client-ip=129.27.2.202; envelope-from=leo.prikler@student.tugraz.at; helo=mailrelay.tugraz.at X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 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@gnu.org Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1620469055; 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=R65FeAAkRGTAe5h+LgSYjQlbKsEjfYv6szehLjyTTQM=; b=VIvBhhW+RoyoAEcjA5xhDSJ4JNnD3CU59qmD9s27wdBi8/2Xu3V5r1WZoxtiYngwCkdBEu 1VoUT8h8xYYlDfrG4k62/pSek/Go+nDR85NwqZ8jkOoWl6eY8J2NCBQLFquzmHEiAkR0pv 5V6fco3KEPvfOow/1GbRVt3erTTWknu8PtveshCfTJFvKUZeGaYah79i4hHcoOv7GgN7Wh BHjue6EUMDZP/LroVfL4kdcIL7zJllyjbilUVbfRTd6Yj+3wdkexQzh3kAhK1J95PDMsAK nidkey+Rgau547od6NetA69C6vqwLZgw+cH0rdB8DuCOXgnF9KxaLPrbtl++ew== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1620469055; a=rsa-sha256; cv=none; b=PC5kvHlD4gRR8AnEBorYD5/jmiIFOOfYigAR2ZmAG60EnLkuETxRsRqdkiJ9V4Wt2S4DvG H4ldtdF3z04lCGXG24NhSyeinck0MmycTqjW/wcmM4oWpzylrhxNLyYTC1bnJai7Q9RmpU oYb9YSXHSOXo4W2TPsFq6vqcXrI4eoPdOUrZMvtpCwfK3yu3qdcGUTY0zUyUmqd39FxwEn IyHDYsXtyfZtBZaqV9a+kLFvmOUnbRuW0EWbh/Jd7WG1aDpe+caT7DQdfYDRd/yRVGaSE2 I6q4TAexFGGVbtbaqVU80nc8uGuJGokNkY+QtZ38DIqLhpVPr3q0TrfGRsrliA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=tugraz.at header.s=mailrelay header.b=VVYZ9wvS; dmarc=pass (policy=none) header.from=student.tugraz.at; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Spam-Score: -3.15 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=tugraz.at header.s=mailrelay header.b=VVYZ9wvS; dmarc=pass (policy=none) header.from=student.tugraz.at; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: 0810A10C1C X-Spam-Score: -3.15 X-Migadu-Scanner: scn0.migadu.com X-TUID: Eb4xR5K/zXLL Hi, Am Freitag, den 07.05.2021, 11:31 -0700 schrieb Chris Marusich: > My understanding is that the intent of the "license" > field (which can be a list) in a Guix package is to call out the > "main" > (deliberately vague here) licenses related to the code, not to > provide > an exhaustive or authoritative description of all the licenses > affecting > every file in every possible situation. As Leo has demonstrated, a > package's license field (like probably most summaries of license > information) is surely not exhaustive or authoritative; the licenses > in > the source code files themselves are authoritative. I agree with both you and the other Leo, but I think we're getting a little off-topic here. The reason,why it's necessary to argue about jam's license is because (as I see it) we don't have a jam package and it is a necessary tool to build a package someone wants to contribute. The reason why we don't care about this when it comes to Autotools is that we have Autotools packaged, and it is expected that all the stuff generated by it exists in the package post the configure phase of a package that uses gnu-build-system unmodified. This makes it, so that this question only ever arises for packages distributing `make dist`- generated packages in the first place, and the question for those should not be "Do we include those licenses", but "Do we trust, that this was really generated with `make dist`"? > My understanding is that a packager is expected to audit the licenses > in > the files when adding the package. If an exhaustive audit is not > feasible (which is often the case), they should perform a reasonable > spot check and then list the "main" licenses in play in the licenses > file. As in the GNU Hello case, there is clearly a judgment call > regarding what goes into the Guix package's licenses list, since a > simple list cannot describe everything. In general, even if > hypothetically you did do an exhaustive audit of all files, it is not > practical to try to describe all the licensing implications in the > Guix > package definition. I don't think that's the purpose of the license > field. I agree, that the main license (the one that appears first in the license list, or the one that appears alone) should more or less cover "the whole package", but if there's a range of *actual* source files (including source files from which a bizarre compiler or build tool is built, that is afterwards used by the package), that should imo be included in that list with a suitable comment. I don't fault any packager, who misses one or two licenses in some obscure hidden file, but if someone finds and adds them, I think that patch should likely be accepted. > One more thing. I have always felt that the license field of a Guix > package is intended to call out the licenses that apply to the built > output of the package in particular. In other words, I think the > license field is intended to call out the licenses that are most > likely > to apply in the situation where you "link" with the built output of > the > package. That is the purpose of many packages: to be "linked" from > other source code. Since it is often the case that software you > write > will not be "linking" with the package's build scripts, but rather > with > the package's built output, the license of the build scripts are less > relevant for that use case. I think this misses the point when it comes to stuff like the artwork for a game. Clearly, that artwork is a substantial part of the game and deserves a place in the license field. The other way around, whenever you encounter some Creative Commons license with the comment "artwork", this might not concern linkage (unless the artwork is baked into the program itself, as might be the case in some GTK and Qt applications, but those are rarely "linked" from other programs), but rather redistribution. > In the end, I think a packager is expected to be operating in good > faith, in accordance with the FSDG. This means that packagers look > for > freedom issues and address them when found. It does not mean that > packagers are expected to provide a detailed "bill of materials" for > every single package, although that is certainly something that some > people think is important (and some people don't). > > This reminds me of the following fun debate from FOSDEM 2020: > > "Does Careful Inventory of Licensing Bill of Materials Have Real > Impact > on FOSS License Compliance?" > https://archive.fosdem.org/2020/schedule/event/debate_license_compliance/ > > I think you might enjoy watching it. Basically, the "negative" > argument > (careful inventory of licensing bill of materials does NOT have a > real > impact on FOSS license compliance) is somewhat relevant here, and it > went something like this: the transitive closure of required source > code > itself is a kind of "bill of materials", and if you only use free > software, it is always easy to comply - just provide the source code. Just saw that debate. I think the actual argument went somewhat like "the transitive source closure *contains* whatever you might argue constitutes a bill of materials", and I think that holds. Every given package should only need to consider what licenses itself brings into the mix, not what some person upstream does (of course while complying with the licenses of its dependencies). However, compliance is not *that* simple. If you're dealing with copyleft, providing the source is not enough, you also need to license your own work under that copyleft license, e.g. the GPL. That said, GNU Guix makes it fairly easy to check when you need to do that. Have a package with (license:gplN+?) in your inputs? You probably need to GPL it. > It was a fun debate. I happened to be in the audience, and I > mentioned > in a question at the end that Guix makes it easy to provide the > transitive closure of source for any given piece of software. I > don't > know of any other tool that does this for all software in an > operating > system, except maybe Nix. For the record, what command gives you transitive source closure? I can see transitive binary closure with `guix pack`, but I don't think we do source closure unless asked to `guix build --no-substitutes`. Maybe a missing feature? Regards, Leo