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: AS14061 206.189.176.0/20 X-Spam-Status: No, score=-3.6 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from box.jasonyundt.email (box.jasonyundt.email [206.189.182.84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 4A6ED1F4D7 for ; Wed, 27 Apr 2022 22:51:07 +0000 (UTC) Received: from authenticated-user (box.jasonyundt.email [206.189.182.84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by box.jasonyundt.email (Postfix) with ESMTPSA id 219A57EA6F; Wed, 27 Apr 2022 18:50:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=jasonyundt.email; s=mail; t=1651099835; bh=9lS1xXqRnhMUNVeq1tgwqpD8Oul+gQkqo+w8oFjvxQY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jQ8Y9P/y5u/hSILlAoudPOdErz3EnehqXgieKzta+gi4wkTdEn7SyvDBW1geT+jmr 0ue+C3gt0vEjqzDtC65Bzv9smzH2n4wQ34SZdvcyoWknE8uLTXuIBc8hHVZD/AEC+g EJ0+TGTwJt8TLfVCthSVRC+ydMFfcNWfPS+qYqghBOHo4pPj8wRFeMIdTiwuT8UsE0 FwnqhM+q05hKMIvpYJjqLbSOLBZGiblAgWhkKZYBmXrHyPG1vxhnUhWJpI9Lh9dJ6f E8axJN6o3XETiPtydCtsKDfemftvPLLDuqFZQ++V6002dKrgh96k/8qGB+xNa/Yrr1 ZgO/fVEvGZL9w== From: Jason Yundt To: Eric Wong Cc: meta@public-inbox.org Subject: Re: Difficulty following the AGPL for example systemd units Date: Wed, 27 Apr 2022 18:50:32 -0400 Message-ID: <10086828.nUPlyArG6x@jason-lemur-pro> In-Reply-To: <20220426222705.GA30933@dcvr> References: <2827814.e9J7NaK4W3@jason-lemur-pro> <20220425232251.GA11277@dcvr> <20220426222705.GA30933@dcvr> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" List-Id: On Tuesday, April 26, 2022 6:27:05 PM EDT Eric Wong wrote: > (resending because the entire /64 my IPv6 address belongs to was > blacklisted, I guess my SMTP server will remain IPv4-only) I actually picked up the original from and= =20 imported it into my mail client. The ability to do that is something that I= =20 really like about public-inbox. > Eric Wong wrote: > > Jason Yundt wrote: > > > Hello=C2=B8 > > >=20 > > > I=E2=80=99m trying to set up public-inbox-httpd on my Web site [1], a= nd I would > > > like to use the public-inbox-httpd systemd units from the examples > > > folder [2] [3]. They don=E2=80=99t exactly fit my needs, so I would l= ike to > > > modify them before deploying them. Here=E2=80=99s where I run into a = problem: > > >=20 > > > Section 0 of the GNU AGPL says =E2=80=9C"The Program" refers to any > > > copyrightable work licensed under this License.=E2=80=9D [4] For publ= ic-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. > > >=20 > > > Section 1 says =E2=80=9CThe Corresponding Source for a work in source= code form > > > is > > > that same work.=E2=80=9D [6] I think that the work in this case is th= e 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. > >=20 > > 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. > >=20 > > 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. > >=20 > > > Section 13 says =E2=80=9C[=E2=80=A6]if you modify the Program, your m= odified 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.= =E2=80=9D > > > [7] > > >=20 > > > Since those two systemd units are part of the Program, when I modify > > > them I=E2=80=99m modifying the Program. In other words, when I modify= those two > > > systemd units, I=E2=80=99ll have to follow that section 13 requiremen= t. In > > > other words, =E2=80=9C[my] modified version must prominently offer al= l users > > > interacting with it remotely through a computer network [=E2=80=A6] an > > > opportunity to receive the Corresponding Source of [my] version=E2=80= =9D. > >=20 > > 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=20 under the GNU AGPL. Does that mean that those units don=E2=80=99t have a li= cense? > > > The right way to do this would be to create a Git repo for my soft fo= rk > > > of > > > public-inbox and change the mirror page [8]. The mirror page says > > >=20 > > > =E2=80=9CAGPL code for this site: > > > git clone https://public-inbox.org/public-inbox.git=E2=80=9D > > >=20 > > > As far as I can tell, the only way for me to change that URL is to ed= it > > > lib/ PublicInbox/WwwStream.pm. If I did that, then I would no longer = be > > > able to rely on my distro=E2=80=99s public-inbox packages. I would ha= ve to > > > create my own system for updating public-inbox. > >=20 > > 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 noth= ing=20 about PSGI. > > > This makes using those example units annoyingly complicated. Here=E2= =80=99s some > > > ideas that I have for improving this situation: > > >=20 > > > 1. Release those systemd units under something other than the GNU AGP= L. > >=20 > > Maybe this one for examples/ and contrib/. I definitely don't > > want to clutter individual example files with copyright lines, > > though... May be you could add a copyright section to examples/README (similar to how= =20 you have one for the top-level README). > > > 2. Add a public-inbox source tree option to config files. This option > > > would > > > allow you to override the =E2=80=9CAGPL code for this site=E2=80=9D U= RL. > > >=20 > > > Either option would work and both are definitely not necessary. > >=20 > > Fwiw, I personally have zero interest nor ability to do (A)GPL > > enforcement. I still prefer (A)GPL since it lets me use (steal > >=20 > > :P) code from other copyleft projects; and developers of those > >=20 > > projects can still maintain and enforce their copyrights. > >=20 > > Thanks. > >=20 > > > From, > > > Jason Yundt > > >=20 > > > [1]: > > > [2]: > > > > > ttpd@.service> [3]: > > > > > ttpd.socket> [4]: > > > [5]: > > > [6]: > > > [7]: > > > [8]: