Difficulty following the AGPL for example systemd units

Difficulty following the AGPL for example systemd units

[Jason Yundt]

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.

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”.

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.

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.
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.

From,
Jason Yundt

[1]: <https://jasonyundt.website/>
[2]: <https://public-inbox.org/public-inbox.git/tree/examples/public-inbox-httpd@.service>
[3]: <https://public-inbox.org/public-inbox.git/tree/examples/public-inbox-httpd.socket>
[4]: <https://www.gnu.org/licenses/agpl-3.0.html#section0>
[5]: <https://public-inbox.org/public-inbox.git/tree/>
[6]: <https://www.gnu.org/licenses/agpl-3.0.html#section1>
[7]: <https://www.gnu.org/licenses/agpl-3.0.html#section13>
[8]: <https://public-inbox.org/meta/_/text/mirror/>

Re: Difficulty following the AGPL for example systemd units

[Eric Wong]

Jason Yundt <jason@jasonyundt.email> 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]: <https://jasonyundt.website/>
> [2]: <https://public-inbox.org/public-inbox.git/tree/examples/public-inbox-httpd@.service>
> [3]: <https://public-inbox.org/public-inbox.git/tree/examples/public-inbox-httpd.socket>
> [4]: <https://www.gnu.org/licenses/agpl-3.0.html#section0>
> [5]: <https://public-inbox.org/public-inbox.git/tree/>
> [6]: <https://www.gnu.org/licenses/agpl-3.0.html#section1>
> [7]: <https://www.gnu.org/licenses/agpl-3.0.html#section13>
> [8]: <https://public-inbox.org/meta/_/text/mirror/>

Re: Difficulty following the AGPL for example systemd units

[Jason Yundt]

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 <https://public-inbox.org/meta/> and 
imported it into my mail client. The ability to do that is something that I 
really like about public-inbox.

> Eric Wong <e@80x24.org> wrote:
> > Jason Yundt <jason@jasonyundt.email> 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?

> > > 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.

> > > 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...

May be you could add a copyright section to examples/README (similar to how 
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 “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]: <https://jasonyundt.website/>
> > > [2]:
> > > <https://public-inbox.org/public-inbox.git/tree/examples/public-inbox-h
> > > ttpd@.service> [3]:
> > > <https://public-inbox.org/public-inbox.git/tree/examples/public-inbox-h
> > > ttpd.socket> [4]: <https://www.gnu.org/licenses/agpl-3.0.html#section0>
> > > [5]: <https://public-inbox.org/public-inbox.git/tree/>
> > > [6]: <https://www.gnu.org/licenses/agpl-3.0.html#section1>
> > > [7]: <https://www.gnu.org/licenses/agpl-3.0.html#section13>
> > > [8]: <https://public-inbox.org/meta/_/text/mirror/>

Re: Difficulty following the AGPL for example systemd units

[Eric Wong]

Jason Yundt <jason@jasonyundt.email> wrote:
> > Eric Wong <e@80x24.org> wrote:
> > > Jason Yundt <jason@jasonyundt.email> 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...

Re: Difficulty following the AGPL for example systemd units

[Julien Moutinho]

Le jeu. 28 avril 2022 10h53 +0000, Eric Wong a écrit :
> Jason Yundt <jason@jasonyundt.email> wrote:
> > 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*
You may want to use https://reuse.software to clarify this :

$ reuse init
> Initializing project for REUSE.
> 
> What license is your project under? Provide the SPDX License Identifier.
> To stop adding licenses, hit RETURN.
> AGPL-3.0-or-later
> 
> What other license is your project under? Provide the SPDX License Identifier.
> To stop adding licenses, hit RETURN.
> CC0-1.0
> 
> What other license is your project under? Provide the SPDX License Identifier.
> To stop adding licenses, hit RETURN.
> 
> 
> What is the name of the project?
> public-inbox
> 
> What is the internet address of the project?
> https://public-inbox.org/public-inbox.git
> 
> What is the name of the maintainer?
> Eric Wong
> 
> What is the e-mail address of the maintainer?
> e@80x24.org
> 
> All done! Initializing now.
> 
> Downloading AGPL-3.0-or-later
> Downloading CC0-1.0
> 
> Creating .reuse/dep5
> 
> Initialization complete.

$ cat .reuse/dep5
> Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> Upstream-Name: public-inbox
> Upstream-Contact: Eric Wong <e@80x24.org>
> Source: https://public-inbox.org/public-inbox.git
> 
> # Sample paragraph, commented out:
> #
> # Files: src/*
> # Copyright: $YEAR $NAME <$CONTACT>
> # License: ...
> 

And after editing .reuse/dep5:

$ git rm COPYING
$ git add LICENSES .reuse/dep5
$ reuse lint

Re: Difficulty following the AGPL for example systemd units

[Eric Wong]

Julien Moutinho <julm+public-inbox@sourcephile.fr> wrote:
> Le jeu. 28 avril 2022 10h53 +0000, Eric Wong a ??crit??:
> > Jason Yundt <jason@jasonyundt.email> wrote:
> > > 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*
> You may want to use https://reuse.software to clarify this :
> 
> $ reuse init

Interesting, though I'm trying to have less software installed
on my system(s)...

<snip>

> $ cat .reuse/dep5
> > Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> > Upstream-Name: public-inbox
> > Upstream-Contact: Eric Wong <e@80x24.org>
> > Source: https://public-inbox.org/public-inbox.git

Would prefer upstream contact to be something along the lines of:
  all contributors <meta@public-inbox.org>
...To emphasize that it's a community project.

As an aside, I've always been a shy introvert, so I always get
uncomfortable when seeing my name in "official-looking" places.
I'm even less comfortable as I age, and believe the acronym
expansion I added to the AUTHORS file is rather appropriate ;>

> > # Sample paragraph, commented out:
> > #
> > # Files: src/*
> > # Copyright: $YEAR $NAME <$CONTACT>
> > # License: ...
> > 
> 
> And after editing .reuse/dep5:
> 
> $ git rm COPYING
> $ git add LICENSES .reuse/dep5
> $ reuse lint

Anyways, I'll think about it; though I'm not sure if I want to
be an early adopter of this and put more .dotfiles into the
source tree.

Thanks.