Re: Difficulty following the AGPL for example systemd units

[Eric Wong <e@80x24.org>]

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