A discussion on licensing and the AGPLv3
by Tom Callaway
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
14 years, 9 months
Thursday meeting.
by Stephen John Smoogen
Mike will be out at training for this meeting. Please send me any
agenda items that you feel need to be addressed so we can get through
them in the requisite 50 minutes or so.
1) AGPL Licensing updates.
2) Mirror madness
3) ...
4) ...
--
Stephen J Smoogen.
Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning
14 years, 9 months
bash_history on x86-5
by Dennis Gilmore
I just deleted my bas_history on x86-5 i typed my password on accident
Dennis
14 years, 9 months
AGPL Licensing: Another "configuration" file example
by Toshio Kuratomi
This wsgi script also helps illustrate some of smooge's concerns about
what happens when configuration information is mixed into a script. It
has two areas that differ between upstream's distribution and our own:
The first is bad application design but I've seen this done frequently
in PHP apps (and it sounds like Java frameworks like JBoss promote this
as well). The fact that our apps are doing it shows it can occur in any
language although we should be able to change our apps to work around it
fairly easily:
The scripts that start up our web applications under mod_wsgi all seem
to have a bit of config tweaking. Historically, this is because we
deployed with a start-app.py script that used the config file
exclusively and started as a standalone daemon. The app.wsgi script
would load the standalone daemon config file and then make some config
changes in the wsgi script before starting the application server. This
can be seen in the attached wsgi script in lines like this::
turbogears.update_config(configfile="/home/ricky/work/fedora/fas/fas.cfg",
modulename="fas.config")
turbogears.config.update({'global': {'server.environment':
'development'}})
For our TurboGears apps it should be pretty easy for us to work around
that by moving all such lines into the config file instead of being in
the script. But for third party PHP scripts licensed under AGPL and
single file cgi scripts that we write what is our responsibility? I can
see several options:
1) We must patch every script/app/etc to put the config into its own
file. Those changes fall unde the AGPL and we try to get them upstream.
The config file falls outside of the AGPL either via explicit license
or some other way.
2) configuration, even embedded inside of an AGPL script is not subject
to the AGPL because it's not copyrightable data.
Second piece of code that varies between installations::
import sys
sys.path.append('/home/ricky/work/fedora/fas/fas/')
Setting the path at which to find the code must be done otherwise the
script won't be able to find the code related to the web application
itself. On different installations (our servers, developers' test
machines, etc) this path will vary. Are those changes that are covered
by the AGPL or are they non-copyrightable? Is there a difference if
this is done manually by the system administrator vs automatically by
the Makefiles/build scripts provided by upstream?
This issue is harder to work around in code since finding the path to
files is a chicken and egg problem. At some point, the executable has
to hardcode at least one path to be able to load the rest of its
information.
-Toshio
14 years, 9 months
blogs.fedoraproject.org Update
by Nick Bebout
This is just a quick note to update everyone on the status of
blogs.fedoraproject.org
We have the FAS authentication plugin working, puppet set up, and are now
working on installing and testing a spam filter plugin, currently we are
testing bad behavior. As soon as this is done we plan to deploy it.
Nick
14 years, 9 months
Fwd: Re: Is F-community using its FAS account?
by Toshio Kuratomi
-------- Original Message --------
Subject: Re: Is F-community using its FAS account?
Date: Mon, 27 Jul 2009 14:35:50 -0400 (EDT)
From: John Palmieri <johnp(a)redhat.com>
To: Toshio Kuratomi <a.badger(a)gmail.com>
It is used for getting a user's info when you are not logged in similar
to the functionality of the bots in #fedora-devel. Going to this link
(https://admin.fedoraproject.org/community/?username=jkeating#people)
works so the password change worked.
----- "Toshio Kuratomi" <a.badger(a)gmail.com> wrote:
> Hey,
>
> lmacken and I realized that we probably hadn't changed Fedora
> Community's password since moving it from the publictest machines to
> production so I did that today. But when I went to test it we
> couldn't
> figure out where it would actually be used::
>
> [10:00:02] <lmacken> abadger1999: hmm, I'm actually not sure if
> that
> account is getting used at all. It looks like it is only used when
> the
> user is not logged in, but in that case they can't view users or
> anything FAS related as far as I can tell. J5 would know for sure
>
> So, is the account being used? If so how can I test that the
> password
> update worked okay? If not, can we disable the account?
>
> -Toshio
--
--
John (J5) Palmieri
Software Engineer
Red Hat, Inc.
14 years, 9 months
Is F-community using its FAS account?
by Toshio Kuratomi
Hey,
lmacken and I realized that we probably hadn't changed Fedora
Community's password since moving it from the publictest machines to
production so I did that today. But when I went to test it we couldn't
figure out where it would actually be used::
[10:00:02] <lmacken> abadger1999: hmm, I'm actually not sure if that
account is getting used at all. It looks like it is only used when the
user is not logged in, but in that case they can't view users or
anything FAS related as far as I can tell. J5 would know for sure
So, is the account being used? If so how can I test that the password
update worked okay? If not, can we disable the account?
-Toshio
14 years, 9 months
Re: Cron <nobody@xen11> /bin/rpm -Va --nofiles --nomd5
by Stephen John Smoogen
On Sat, Jul 25, 2009 at 6:00 PM, Cron Daemon<root(a)fedoraproject.org> wrote:
> Unsatisfied dependencies for hpadu-8.10-4.i386: hpsmh
>
Probably noted somewhere but this is the HP System Management
Homepage. Product looks like it only works on RHEL-4 and before and
seems to be considered dead software by HP (all the main pages say go
find another product...) I am downloading the latest tools for this
and see what it comes up as.
--
Stephen J Smoogen.
Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning
14 years, 9 months
torrent1 warnings.
by Stephen John Smoogen
Found some very old log btt files that were huge gzipped from January.
Look like they were left over before new naming structure in logrotate
was used. Removed them to give space. Looks like the service did not
properly rotate logs last time and has been writing to a bad file
descriptor for a while. Restarting bttrack btseed to reset log files.
--
Stephen J Smoogen.
Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning
14 years, 9 months
Second try, patch set for sigul
by Jesse Keating
Here is a second try. This time I fixed with Ricky pointed out
and squashed everything into one commit since it is all related.
Arguably it should be two commits, one for the addition of the module
and another commit for the .pp changes, but I'm already writing this
so oh well.
--
Jes
14 years, 9 months