A discussion on licensing and the AGPLv3

[Stephen John Smoogen]

On Tue, Jul 28, 2009 at 9:16 AM, Tom "spot" Callaway<tcallawa at redhat.com> wrote:
> Hi guys,
>
> After several rounds of discussion with Richard Fontana, I think we have
> more information about how to move forward here.
>
> This is Fedora's general policy around license compatibility concerns:
>
> * If the code is bundled together in the same tarball, and it is
> compiled together, then we worry about license compatibilities.
> * If the code is not bundled together, we worry about it if there is an
> incompatibility across shared library linking (e.g. GPL incompatible
> library cannot be used by GPL code)
> * For interpreted languages (Python, Java), we don't worry about it
> outside of the tarball.
>
> (This policy is subject to modification in specific cases but represents
> our default approach to license compatibility issues.)
>
> I've proposed that we apply this logic to the AGPLv3, and Red Hat Legal
> agrees.
>
> So, if we apply this to the AGPLv3, it means that we only need to be
> distributing the bits under AGPLv3 that make up our web app, and any
> other code that would be "bundled in the same tarball" for distribution.
> All of the other interpreted dependencies should be listed, but do not
> need to be provided.
>
> Now, there were some specific questions about how we should be
> distributing the sources to comply with the AGPLv3, here are the answers
> from Red Hat Legal:
>
> Q: What are legal means of giving people access to the corresponding source?
>
>     + Source repository at no particular version (assuming all of our
> patches are applied to trunk -- and trunk might contain other changes as
> well, including full or partial reversions of those changes in a later
> revision)
>
>     * Red Hat Legal feels this is not sufficient.
>
>     + Source repository at no particular version (assuming all of our
> patches are applied to a branch that mirrors production)
>
>     * Red Hat Legal feels this is not sufficient.
>
>     + Pointing exactly to source repository branch or tag of the exact
> version we're running
>
>     * Red Hat Legal says that this is OK.
>
>     + Home page of the project (example: http://fedorahosted.org/fas)
>
>     * Red Hat Legal feels this is not sufficient.
>
>     + Just a page specifically linking to the sources and all of the
> patches we've applied
>
>     * Red Hat Legal says that this is OK.
>
>     + links to base srpm and page listing patches
>
>     * Red Hat Legal says that this is OK.
>
>     + links to base srpm and tickets in trac that have patches attached
>
>     * Red Hat Legal says that this is OK.
>
>     + links to base srpm and tickets in trac that point to commits in
> SCM that are applied against different versions (HEAD vs the last
> release, for instance)
>
>     * Red Hat Legal feels this is not sufficient.
>
>     + A page linking to the sources and a page linking to any hotfixes
> we've applied to any of our apps (ie, a query in infrastructure's trac
> that gets all hotfixes for all of our apps).
>
>     * Red Hat Legal says that this is OK.
>
>     + I'm assuming these to be fine: tarball, srpm that matches what's
> running, actual links to base tarball and to all of the patches
>
>     * Red Hat Legal confirms that these are all OK
>
> Q:  Do config changes count as code changes if the config file is marked
> as being AGPL?
>
> Red Hat Legal feels that changes to configuration lines inside a script
> do not represent a copyrightable change to the script, and therefore
> they do not trigger the AGPLv3 section 13 requirement (this is the
> requirement on sharing the AGPLv3 covered code), because the config
> change does not result in a "modified version" as that term is used in
> AGPLv3.
>
> They advise that it would be preferred if applications clearly separated
> the configuration files from the actual web application code and
> scripts, as it minimizes licensing concerns.
>
> Q: What do we have to do to make config files not be licensed under
> AGPL? (We want to keep passwords private, for instance).
>
> Red Hat Legal advises that for config files included in an AGPLv3
> distribution, you can cause them to fall outside of the AGPLv3 (at least
> section 13), by explicitly granting an additional permission stating
> that such files (assuming that they are copyrightable) are covered by
> the AGPLv3, but are not subject to the AGPLv3 section 13 requirement.
>
> Red Hat Legal would be happy to draft up wording for such an additional
> permission for our needs.
>
> Q: Does each page of the web app have to have a link to the source?
>
> A:  No, you just have to make sure that users are "prominently offered"
> an opportunity to get the source. Links from the main page of the web
> application meet this criteria.
>
> Hopefully, this will provide a solid groundwork for Thursday's discussions.
>
> Thanks,

Thankyou Tom,

It would seem that the sufficient way to show our software would be to
put into process of deploying it via RPM or 'solid' tarball. The
process for dealing with hot-fixes etc that are outside of config file
changes will require a methodology so that we can do say a rpm -V
mooksha and see only files listed as c being changed.

What is a copyrightable change? I am guessing this is a standard loose
definition that basically falls under the usual legal "I know it when
i see it".  (eg changing PASSWORD="foobaz" is not copyrightable but
changing

if (PASSWORD != "foobaz")

to

if (PASSWORD == "foobaz")

is.


-- 
Stephen J Smoogen.

Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning