From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,AWL,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id A922D1F4D7; Mon, 25 Apr 2022 23:22:51 +0000 (UTC) Date: Mon, 25 Apr 2022 23:22:51 +0000 From: Eric Wong To: Jason Yundt Cc: meta@public-inbox.org Subject: Re: Difficulty following the AGPL for example systemd units Message-ID: <20220425232251.GA11277@dcvr> References: <2827814.e9J7NaK4W3@jason-lemur-pro> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2827814.e9J7NaK4W3@jason-lemur-pro> List-Id: Jason Yundt wrote: > Hello¸ > > I’m trying to set up public-inbox-httpd on my Web site [1], and I would like > to use the public-inbox-httpd systemd units from the examples folder [2] [3]. > They don’t exactly fit my needs, so I would like to modify them before > deploying them. Here’s where I run into a problem: > > Section 0 of the GNU AGPL says “"The Program" refers to any copyrightable work > licensed under this License.” [4] For public-inbox, I think that the Program > is the entire public-inbox source tree [5]. In other words, I think that those > two systemd units [2] [3] are part of the Program. > > Section 1 says “The Corresponding Source for a work in source code form is > that same work.” [6] I think that the work in this case is the entire public- > inbox source tree. This means that the Corresponding Source is the entire > public-inbox source tree which in turn means that those two systemd units are > part of the Corresponding Source. Paragraph 4 of section 1 states: The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work. I consider systemd, cron, logrotate, etc. to be "general-purpose tools" and there's no "intimate data communication or control flow" between them and public-inbox. > Section 13 says “[…]if you modify the Program, your modified version must > prominently offer all users interacting with it remotely through a computer > network (if your version supports such interaction) an opportunity to receive > the Corresponding Source of your version by providing access to the > Corresponding Source from a network server at no charge, through some standard > or customary means of facilitating copying of software.” [7] > > Since those two systemd units are part of the Program, when I modify them I’m > modifying the Program. In other words, when I modify those two systemd units, > I’ll have to follow that section 13 requirement. In other words, “[my] modified > version must prominently offer all users interacting with it remotely through a > computer network […] an opportunity to receive the Corresponding Source of > [my] version”. I don't consider systemd units or config files part of the program; especially since they're loaded by systemd without "intimate data communication or control flow between those subprograms and other parts of the work". > The right way to do this would be to create a Git repo for my soft fork of > public-inbox and change the mirror page [8]. The mirror page says > > “AGPL code for this site: > git clone https://public-inbox.org/public-inbox.git” > > As far as I can tell, the only way for me to change that URL is to edit lib/ > PublicInbox/WwwStream.pm. If I did that, then I would no longer be able to > rely on my distro’s public-inbox packages. I would have to create my own > system for updating public-inbox. I think having a globally-writable "our" variable is sufficient for $CODE_URL. The .psgi file is Perl, and setting a few variables/pathnames/URLs doesn't meet the barrier for "intimate data communication or control flow" to me. > This makes using those example units annoyingly complicated. Here’s some ideas > that I have for improving this situation: > > 1. Release those systemd units under something other than the GNU AGPL. Maybe this one for examples/ and contrib/. I definitely don't want to clutter individual example files with copyright lines, though... > 2. Add a public-inbox source tree option to config files. This option would > allow you to override the “AGPL code for this site” URL. > > Either option would work and both are definitely not necessary. Fwiw, I personally have zero interest nor ability to do (A)GPL enforcement. I still prefer (A)GPL since it lets me use (steal :P) code from other copyleft projects; and developers of those projects can still maintain and enforce their copyrights. Thanks. > From, > Jason Yundt > > [1]: > [2]: > [3]: > [4]: > [5]: > [6]: > [7]: > [8]: