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,
~spot
_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
