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
On 07/28/2009 08:16 AM, Tom "spot" Callaway wrote:
Hopefully, this will provide a solid groundwork for Thursday's discussions.
Excellent! I think this provides some good options for us wrt distributing changes for production. Are the questions about our staging and publictest environments still in discussion with legal?
In case those questions were missed, here they are again:
== Related to Staging ==
We use the staging environment for both some development duties and integration testing. Because of that we want to be able to deploy into staging things that we aren't providing exact corresponding source for at the moment. The staging environment is reachable by members of the general public but we'd like to find out if we can consider it an internal service that doesn't need to track every little change we make. Here's the portions of the AGPL we think is relevant:
From the preamble: """ public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version. """
Section 13: """ Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. """
* Is the preamble legally binding/part of the AGPL or should we ignore anything there?
* admin.stg.fedoraproject.org is accessible by the general public but it isn't meant for the general public's use -- it's for developers to collaborate on what will be on the production site, admin.fedoraproject.org. Those developers collaborate over the internet which is why it's available on the internet. Does this excuse us from providing source to people who do not have shell access to the server itself?
* If we can run apps in staging without providing source to those without shell accounts there, can we also run apps on publictest boxes without providing source to those without shell accounts there?
-Toshio
On 07/28/2009 12:06 PM, Toshio Kuratomi wrote:
On 07/28/2009 08:16 AM, Tom "spot" Callaway wrote:
Hopefully, this will provide a solid groundwork for Thursday's discussions.
Excellent! I think this provides some good options for us wrt distributing changes for production. Are the questions about our staging and publictest environments still in discussion with legal?
In case those questions were missed, here they are again:
Q: Is the preamble legally binding/part of the AGPL or should we ignore anything there?
Red Hat Legal advises that the preamble is not legally binding. It is there only to provide some guidance as to how to interpret the binding parts of the license. In general, Red Hat Legal advises that no one should think too much about (A/L)GPL preambles. ;)
Q: admin.stg.fedoraproject.org is accessible by the general public but it isn't meant for the general public's use -- it's for developers to collaborate on what will be on the production site, admin.fedoraproject.org. Those developers collaborate over the internet which is why it's available on the internet. Does this excuse us from providing source to people who do not have shell access to the server itself?
Red Hat Legal says: No. However, I suppose you could solve the problem by writing an additional permission that says that pushing the webapp to admin.stg.f.o does not trigger AGPL sec. 13. (You could also word something more broadly to allow downstream non-Fedora users to take advantage of the same principle, in circumstances involving testing on public staging sites, but it might be difficult to word that without creating a loophole.) This doesn't work if you start using upstream-of-Fedora AGPL code.
~spot
On 07/28/2009 12:09 PM, Tom "spot" Callaway wrote:
On 07/28/2009 12:06 PM, Toshio Kuratomi wrote:
On 07/28/2009 08:16 AM, Tom "spot" Callaway wrote:
Hopefully, this will provide a solid groundwork for Thursday's discussions.
Excellent! I think this provides some good options for us wrt distributing changes for production. Are the questions about our staging and publictest environments still in discussion with legal?
In case those questions were missed, here they are again:
Q: Is the preamble legally binding/part of the AGPL or should we ignore anything there?
Red Hat Legal advises that the preamble is not legally binding. It is there only to provide some guidance as to how to interpret the binding parts of the license. In general, Red Hat Legal advises that no one should think too much about (A/L)GPL preambles. ;)
Q: admin.stg.fedoraproject.org is accessible by the general public but it isn't meant for the general public's use -- it's for developers to collaborate on what will be on the production site, admin.fedoraproject.org. Those developers collaborate over the internet which is why it's available on the internet. Does this excuse us from providing source to people who do not have shell access to the server itself?
Red Hat Legal says: No. However, I suppose you could solve the problem by writing an additional permission that says that pushing the webapp to admin.stg.f.o does not trigger AGPL sec. 13. (You could also word something more broadly to allow downstream non-Fedora users to take advantage of the same principle, in circumstances involving testing on public staging sites, but it might be difficult to word that without creating a loophole.) This doesn't work if you start using upstream-of-Fedora AGPL code.
Okay guys, time to get creative :-)
The exception would be one way we could go with this. It doesn't help if we deploy launchpad or similar. It also doesn't help third parties looking to deploy our code (without legal sitting down and working out something that doesn't have loopholes).
Deploying to staging directly from a specific VCS branch could work -- but then we'd have to have different methods for VCS vs rpm (since we're using staging for both deployment testing and late development testing).
Having a cron job that took differences between staging and baseline and uploaded it somewhere public could work but it would be hard to make the script generic enough, I think.
Should we ask Legal if we could stick Apache Basic Auth (using mod_auth_postgres) in front of staging and then it would be okay? Or if we used openvpn to connect to http(s) on staging?
-Toshio
On 07/28/2009 03:38 PM, Toshio Kuratomi wrote:
Should we ask Legal if we could stick Apache Basic Auth (using mod_auth_postgres) in front of staging and then it would be okay? Or if we used openvpn to connect to http(s) on staging?
These are both good ideas, would you like me to float them past RH Legal?
~spot
On 07/28/2009 01:21 PM, Tom "spot" Callaway wrote:
On 07/28/2009 03:38 PM, Toshio Kuratomi wrote:
Should we ask Legal if we could stick Apache Basic Auth (using mod_auth_postgres) in front of staging and then it would be okay? Or if we used openvpn to connect to http(s) on staging?
These are both good ideas, would you like me to float them past RH Legal?
Yes, please.
I think it would look something like this:
sysadmin-XXX group can ssh into publictest boxes to work on applications.
sysadmin-YYY group can ssh into staging boxes to work on applications.
Not all the people in those groups will be working on the same applications (some work on Fedora Community, some on FAS, some don't work on developing applications at all) but they will all be part of the Fedora Infrastructure team.
For legal: If we limit who can hit the web apps via apache basic auth or openvpn to the sysadmin-XXX and sysadmin-YYY groups, can we forgo having a direct pointer to the corresponding source?
On the infrastructure side, we have to figure out if this is going to be too limiting. (ie, we need people specifically not in sysadmin-XXX or sysadmin-YYY to test our changes before we deploy).
-Toshio
On 07/28/2009 08:16 AM, Tom "spot" Callaway wrote:
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.
I take these two to answers to mean roughly:
Configuration is not copyrightable. Therefore changes to configuration files and configuration within scripts is not something that needs to be provided under the AGPLv3. If we are still concerned about them, Red Hat Legal will help us write a license for the config files that makes clear that changes to them do not have to be distributed.
Is that a good summary?
Thanks again spot! -Toshio
On 07/28/2009 12:11 PM, Toshio Kuratomi wrote:
I take these two to answers to mean roughly:
Configuration is not copyrightable. Therefore changes to configuration files and configuration within scripts is not something that needs to be provided under the AGPLv3. If we are still concerned about them, Red Hat Legal will help us write a license for the config files that makes clear that changes to them do not have to be distributed.
Yes, that's precisely how I interpreted this as well.
I did miss the other questions, and have just now sent them over to RH Legal.
~spot
On Tue, Jul 28, 2009 at 9:16 AM, Tom "spot" Callawaytcallawa@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.
infrastructure@lists.fedoraproject.org
-
Stephen John Smoogen -
Tom Callaway -
Toshio Kuratomi