[DGD] AGPL and mudlibs under DGD 1.4

[Shentino]

On Wed, Feb 3, 2010 at 3:31 PM, Felix A. Croes <felix at dworkin.nl> wrote:

> <jimorie at gmail.com> wrote:
>
> > In the light of recent events, I would like to ask what DGD's new
> > license will entail for a MUD running under it, if anything.
> >
> > Reading up on GNU AGPL I understand that modifications to DGD 1.4 must
> > be made available to all users of the server running the modified
> > code. My immediate question then becomes whether it can be argued that
> > the mudlib of a MUD running DGD 1.4 falls under this clause?
>
> The mudlib is separate.  The running code of the objects is also
> separate, just like the license of gcc does not affect the code it
> compiles.  The statedumps are separate.  None of them are affected
> by DGD's license.
>

I think an apt analogy might be the_linux_kernel:userspace::driver:LPC.  In
fact there was a debate about a very similiar issue on LKML, where the
syscall boundary was defined as quarantining the GPL nature of the kernel
behind it.  I think that the LPC abstraction layer is similiar.

Regarding precompiling I doubt it's more than a moot point anyway unless the
precompiler-generated C that you link with DGD proper is itself
distributed.  If the precompilation process itself is done completely
locally then no derived-work combination even gets out.

Unless the license controlling the LPC itself has an allergic reaction to
the AGPL governing DGD I don't think there'd be a problem, since local,
unconveyed modifications of AGPLv3 material are completely kosher.

IMHO it would only be a problem if one attempted to distribute DGD source or
binary with a precompiled mudlib embedded within, Come to think of it
though...building a "mudlib" into DGD proper via precompilation could be
pretty snazzy...but I digress :)

Anyway, the LPC stuff is independent, while the DGD source code is core.
Presumably, any C code generated in the process of precompiling the
mudlib would be a derived work of both.  IIRC though, the AGPL doesn't
regulate such unless you attempt to "convey" the resulting C source.

Then again, the generated C might just be considered "compiler output" that
isn't derived from DGD itself after all, much like assembler or object
code output from gcc.  Considering that the generated C cannot even function
without the rest of the source it's compiled and linked with at DGD build
time it's probably moot anyway.

I'm inclined to doubt that generating C source via precompilation
constitutes the creation of a work derived from DGD.

Were it up to me though I'd rather just distribute the LPC and let the end
user precompile it themselves.

Naturally I am not a lawyer, so yada yada yada.

The FSF, btw has recognized this sort of thing with source code being
independent while object code linked against GPL libraries being derived.
In fact, they addressed this issue in the license notice for glibc by
granting a "linkage exception" that allows one to distribute object code
derived from the gpl'ed source of glibc (headers and static libs and
whatnot).