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 3D3BD1F4D7; Thu, 28 Apr 2022 10:53:32 +0000 (UTC) Date: Thu, 28 Apr 2022 10:53:32 +0000 From: Eric Wong To: Jason Yundt Cc: meta@public-inbox.org Subject: Re: Difficulty following the AGPL for example systemd units Message-ID: <20220428105332.GA8238@dcvr> References: <2827814.e9J7NaK4W3@jason-lemur-pro> <20220425232251.GA11277@dcvr> <20220426222705.GA30933@dcvr> <10086828.nUPlyArG6x@jason-lemur-pro> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <10086828.nUPlyArG6x@jason-lemur-pro> List-Id: Jason Yundt wrote: > > Eric Wong wrote: > > > 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". > > Now that I look at it, the top-level README only says that the program is > under the GNU AGPL. Does that mean that those units don’t have a license? I suppose there's no license, or just CC0/public-domain. I mean, we sometimes post config snippets in emails w/o licenses, too; and same happens on git@vger and various other development lists/forums/etc.. *shrug* > > > > 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. > Wait, so could I change that variable without modifying lib/ PublicInbox/ > WwwStream.pm? For context: I know very little about Perl and basically nothing > about PSGI. Yes, something like: { use PublicInbox::WwwStream; $PublicInbox::WwwStream::CODE_URL = "https://example.com/"; } should work from any Perl files. It's not very common, and maybe I'm misrembering due to old age...