Re: Difficulty following the AGPL for example systemd units

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

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