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