On Thu, Jul 11, 2013 at 03:12:39PM +0200, Ansgar Burchardt wrote:
> > I'm no expert but that would be my interpretation. Also when I asked
> > about the basis of the network part of the AGPL during the GPLv3 talk
> > at DebConf10 in NYC, Bradley said the AGPL was specifically based on
> > modification, _not_ on public performance or other use.
>
> You have to make the source available in this case. Otherwise it would
> be a trivial way around the AGPL (just have a third party modify the
> program and give it to you).
Co-author of AGPLv3 here, including the section at issue. You do not
have to make the source available in this case, in general. In unusual
cases of circumvention, like what I believe you are suggesting, the
answer might arguably be different, but in the context of ordinary
Linux distributions, when a user gets AGPLv3-licensed software that
the *distro* has modified, that software is *unmodified* from the
standpoint of that user downstream from the distro and therefore the
user needs to do something to trigger the section 13 requirement.
Otherwise you have to explain why modification was made to be the
trigger. If the modified/unmodified distinction was meant to be
meaningless, section 13 would have been drafted not to make any
reference to modification. Indeed, other Affero-like licenses
typically are broader than AGPLv3 in the sense that they work by
redefinition of 'distribution' and thus are not limited to cases where
the user has modified the software. This approach was specifically
rejected when AGPLv3 was being drafted.
> Section 13 (Remote Network Interaction) requires modified version to
> offer access to the source. If you modify the software, but do not
> provide this, you violate this license requirement and lose the right to
> modify and distribute the covered work under section 8 (Termination).
>
> And with open source software you often deal with "modified" versions,
> so claiming this is a special case ("[...] was specifically based on
> modification, _not_ on public performance or other use") seems a bit odd
> to me.
That's another issue, what does it take for the software to be
'modified' for purposes of that section, and you rightly call
attention to it. But to say that the package *as received from the
distro* triggers section 13 *inherently* is inconsistent with the
language of section 13 and the intent of the drafters.
- RF
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130711135511.ga19...@redhat.com
