The Affero GPL (AGPL)

[Alex Rousskov]

On Thu, 22 Jul 2004, Michael Bernstein wrote:

> Alex Rousskov wrote:
>
> > On Thu, 22 Jul 2004, Michael Bernstein wrote:
> >
> >
> >>>>The one 'bug' I'm aware of in the license is the explicit mention
> >>>>of HTTP as the transmission protocol, but this shouldn't affect
> >>>>it's acceptability to OSI. I know it doesn't affect it's
> >>>>acceptability to me.
> >>>
> >>>The OSL does not restrict to a protocol, and protocol restriction
> >>>would be a violation of the OSD anyway, by making the AFL not
> >>>technology neutral.  Check thy tenth commandment "License Must Be
> >>>Technology-Neutral"....
> >>
> >>The AGPL does not restrict the software to any technology.
> >
> > It does, in many ways, IMO. HTTP is technology.
>
> But it doesn't *restrict* to HTTP. Additional means of distribution
> are allowed within the terms of the license.

If I am writing embedded software that must fit into 64KB of RAM,
requiring me to _keep_ a piece of code (to provide an interface that
my program does not need) is a technical restriction.

>  > "Immediate transmission" is technology.
>
> I'm having trouble following your reasoning here. Is 'source code' a
> technology within your interpretation, then?

Not sure, but it does not matter as long as source code distribution
channels are independent of the program itself. I have to provide
sources in some reasonable way. What specific technology I use to
provide them, and whether that technology is embedded into my program,
should be up to me.

> > Under certain AGPL conditions, a derivative work cannot, for
> > example, substitute HTTP code with BEEP code or delay responses.
> > These are purely technical requirements that might prevent a
> > derivative work from being used on some computer networks (e.g.,
> > those that do not support HTTP).
>
> Hmm. Well, I am out of my technical depth here. I was under the
> impression that HTTP was transport neutral, and could be run perfectly
> well over other networks besides TCP/IP.

HTTP (RFC 2616, Section 1.4 Overall Operation) requires reliable
transport. Not all transport protocols are reliable (by design).
Consider self-building sensor networks, for example.

> > The AGPL requirement is also technically broken in several ways
> > (assuming I understand the intent correctly). For example, AGPL
> > requires certain derivatives to provide "an opportunity to request
> > transmission [...] of complete source code".  The license does not
> > seem to require the program to respond to that request or to
> > respond with complete source code. Responding with "403 Forbidden"
> > or "499 Good Luck" seems to be acceptable, from technical point of
> > view. Thus, I would not use this license if your intent is to
> > preserve "embedded source download" functionality in derivative
> > works.
>
> Yow! That could be a deal-breaker, all right. I'll forward this
> objection to the appropriate address.

For the record, I am not objecting to anything in the above paragraph.
Just indicating a technical bug. There are other bugs like that. For
example, HTTP acronym is undefined and might mean different things to
many people 30 years from now. Or, can I use HTTP/6.9 even though I
have just invented that HTTP version and never published the specs?

Alex.