*** Bug 125822 has been marked as a duplicate of this bug. ***

Opened over a year ago.... is there any reason not to add it to the
next Fedora?

This looks like a "Fedora Extras" package to me.

Searched the Fedora Extras website, didn't find it.  Perhaps this
could be added to FC3 instead?

Maybe it's just me, but this particular package is a b%#^h to install
from the source provided on the homepage.

I'm not convinced that it's legal to bundle xscreensaver and RSS together.

RSS is GPL.  But xscreensaver uses an MIT-X-style BSD-variant license which
includes a "credit in documentation" clause, which renders it incompatible with
GPL.  This means that GPL code cannot be linked into xscreensaver.

The RSS programs draw pretty pictures, and only when combined with xscreensaver
do they constitute "a screen saver".  So, they behave as plugins to the
screensaver framework.

http://www.gnu.org/copyleft/gpl-faq.html#MereAggregation says

     Combining two modules means connecting them together so that they
     form a single larger program. If either part is covered by the GPL,
     the whole combination must also be released under the GPL--if you
     can't, or won't, do that, you may not combine them.

I have discussed this at length with Terry Welsh, the author of the RSS package,
since I believe the only way to solve this problem is for him to either switch
from GPL to BSD, or dual-license under GPL and BSD.  

He's not willing to do that.

Changing the license on xscreensaver is not practical, due to the huge number of
contributors over the years who would all have to agree.

FWIW, I think the keywords here are "... a _single_ larger program." (emphasis
mine). XScreensaver and the screensaver hacks are clearly separate programs even
if they act in a coordinated fashion. Speaking of rss, the hacks don't seem to
contain xscreensaver code(*), neither headers nor libraries of any sort, so I
don't think the border to "linking" can be considered crossed. Otherwise,
calling stuff not GPL-compatible from bash scripts and distributing these
scripts wouldn't be legal as well.

(*): I didn't examine the code but since it doesn't need any xscreensaver stuff
to compile it must be that way unless rss-glx upstream really have copied and
pasted.

My thinking is that, since the rss stuff is not a "screen saver" without the
rest of the package, that constitutes a kind of linking.  If "not using ld" was
all it took, then GPL's linking requirements could be circumvented at any time
by simply writing a plugin-like shim program that passed function calls over a
textual pipe.

I guess it's somewhat similar to the debate over non-GPL kernel modules.

Anyway, that's the reason I'm not comfortable including the rss savers with the
main xscreensaver distribution, and I suspect the same issues apply to you as to
me.  You might want to have Red Hat's lawyers look into it.

I think it's just silly that Welsh won't just dual-license the thing and remove
all the ambiguity, but I haven't been able to convince him to do that yet.  (He
doesn't seem to object to it outright, but I haven't convinced him that it's
necessary.)  Perhaps you (or your lawyers) would have better luck.

Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.

jpb... please change this to FC4test2  (or assign me as the owner of this...
I'll track it)

Maybe this should be moved to Fedora Extras?

Also: several RPMs I've seen of this do something kind of gross -- they have
%post/%postun scripts to munge /usr/X11R6/lib/X11/app-defaults/XScreenSaver. Is
there a cleaner way to do that?

Yeah, it is dirty.  The "right way" would be to package these right along with
the regular screensavers... or to have a
/usr/X11R6/lib/X11/app-defaults/XScreenSaver.d directory, no?

I like the .d approach, as it gives us more flexibility for subpackages of
screensavers.

As I said in comment #5 and #8, the reason these screen savers are not included
with the xscreensaver distribution is that I do not believe it is legal to do so.

Adding a .d directory would be a lot of work for very little benefit.  Aside
from the RSS savers, there are very few screen savers that are *not* included
with xscreensaver.  How many do you know of, maybe three or four?  It's far less
work to just run "patch" in %post in those couple of RPMs than to do the
structural work to make xscreensaver use a .d directory.  (Xrm is involved, so
that's more complicated than you may think.)

I think it would be nice to be able to break the gl screensavers out into a
subpackage, for example. But yeah, I also understand that it's a lot of work and
am certainly not asking you to just up and do it.

In any case, I'm going to move this bug to Fedora devel version -- maybe should
be moved to Fedora Extras, but there's no rss-glx component....

Hi Matt,

Note that in FC4 xscreensaver will be in 3 different packages,
xscreensaver-base, xscreensaver-extras, and xscreensaver-gl-extras.

Also, munging /usr/X11R6/lib/X11/app-defaults/XScreenSaver shouldn't ever be
necessary.  The xscreensaver package contains a canonical list of screensavers
that work with xscreensaver.  This list isn't necessarily limited the
screensavers that ship with xscreensaver.  If a screensaver can't ship with
xscreensaver for whatever reason, the canonical list can still be updated so
that the 3rd party screensaver works when it is installed.

The authors of the RSS-glx screensavers just need to email Jamie requesting that
their screensavers get added to the XScreenSaver.ad file that ships in the
upstream xscreensaver tarball.

How about I write you and request that Red Hat include said xscreensavers? ;-)

Surely that should suffice.

Hi,

This bug is being closed because it has been in the NEEDINFO state for a long
time now.  Feel free to reopen the bug report if the problem still happens for
you and you can provide any information that was requested.

Hello ????    What information did you request that you didn't get?  You may
have marked it as NEEDINFO, but we have all been discussing this for a while
now.  This case isn't "old" or "stale".  Sounds like you came up with a solution
per #16...  what is with this case being closed?

I think that was a mistake -- accidentally included in a batch of bugs it
shouldn't have been.

Hi Joshua, Matthew,

Yea, this bug was closed erroneously.

Since Jamie gives instructions with xscreensaver on how to add "any program that
can draw on the root window" as a saver ... surely the licensing issue is fairly
moot?  It could be perhaps addressed by asking Jamie to clarify the licensing
issue from his point of view, I would have thought he wouldn't have any problem
with this.

(no intention of speaking for Jamie here of course)

If anyone is interested in packaging and maintaining this package for Fedora
Extras, take a look at http://fedoraproject.org/wiki/Extras.

Getting into Extras would a good step for packaging review and feedback even it
is later deemed to be include in core.

Closing

As FC5 contains gnome-screensaver which is GPL, I plan to wrap up rss-glx so
that it works with it and submit that package to FE5.

Spec File URL: http://tiptoe.de/dav/rss-glx.spec
Source RPM URL: http://tiptoe.de/dav/rss-glx-0.8.1-0.0.src.rpm

rss-glx is a collection of cool graphics hacks that can be used in conjunction
with xscreensaver, gnome-screensaver or KDE.

NB: The package does NOT contain the original source. I've included a modified
tarball which doesn't include the matrixview hack as that one includes images
from the movie itself and I find it highly likely that we don't have permission
to include these.

Interesting, rss-glx is in debian/unstable.  I wonder if they had problems with
the matrix bits?

Bill, re comment #22: the licensing issue "from my point of view" doesn't make a damned bit of difference; 
it doesn't matter what I would prefer, or what I wish, or what seems reasonable.  All that matters is *what 
the licenses actually say*.  

And my reading of what they actually say says that the two licenses are incompatible in this context.

I *can't* change the license on xscreensaver: it has too many contributors for me to possibly be able to 
change the license on every file; I can't even contact most of those people any more.  And the RSS author 
is *unwilling* to change his license. Therefore, deadlock.

Jamie, I still don't buy your line of reasoning.

- The same http://www.gnu.org/copyleft/gpl-faq.html#MereAggregation that you
quoted says:

"""
By contrast, pipes, sockets and command-line arguments are communication
mechanisms normally used between two separate programs. So when they are used
for communication, the modules normally are separate programs. But if the
semantics of the communication are intimate enough, exchanging complex internal
data structures, that too could be a basis to consider the two parts as combined
into a larger program.
"""

All that xscreensaver, gnome-screensaver or KDE do is run the program
implementing the hack, so the "semantics of the communication" are pretty much
non-existent (not to mention far from exhibiting complex internal structures).

- Running the hack itself on the whole screen would cause it to act as a
"screensaver" without any involvement of xscreensaver/... themselves.

- From the GPLv2:

"""
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope.  The act of
running the Program is not restricted, [...]
"""

- Following your line of reasoning, xscreensaver couldn't include hacks that use
screen contents as they may display programs that are distributed under a
non-compatible license. This is clearly nonsensical.

- rss-glx can be used either standalone or in conjunction with one or more of
xscreensaver, gnome-screensaver, KDE, whatever else that can run an external
program to decorate a locked screen. Reaction to non-activity of the user,
locking the screen and decorating it are completely separate tasks. This voids
the notion that either rss-glx (which implements decoration) or xscreensaver
(which implements reaction on non-action as well as locking) would somehow be
derivatives of each other.

In conclusion, I would say that there is no licensing issue between rss-glx and
xscreensaver as they don't need to be compatibly licensed.

Doesn't seem to build in mock on FC5:

./stringify hufo_tunnel_textures/marblemap hufo_tunnel_textures/swirlmap >
hufo_tunnel_textures.cpp
./stringify: error while loading shared libraries: /usr/lib/libGL.so.1: cannot
restore segment prot after reloc: Permission denied
make[2]: *** [hufo_tunnel_textures.cpp] Error 127
make[2]: Leaving directory `/builddir/build/BUILD/rss-glx_0.8.1.p/oglc_src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/builddir/build/BUILD/rss-glx_0.8.1.p'
make: *** [all] Error 2

(This is potentially SELinux-related, as I'm running with SELinux enabled).

I guess it is, but it brings up the question why stringify is linked against
libGL in the first place (not that it matters much, it's only used during building).

Problem due to autofoo I guess (it just pulls any library needed for rss-glx as
well). Anyway, I've put up a new release which actually uses openal and freealut:

SRPM: http://tiptoe.de/dav/rss-glx-0.8.1-0.1.src.rpm
SPEC: http://tiptoe.de/dav/rss-glx.spec

NB: This one doesn't solve your problem with SELinux yet. I think this would
need a lot of revamping the build setup if it were to be done properly. But I
could still just compile the stringify binaries by myself prior to running make,
tell me what you think.

NB^2: You might need to check if other programs can use libGL as well.

Further problems rebuilding in mock:

driver.h wants X11/Intrinsic.h, which is provided by libXt-devel.

The modular-x section should therefore also add:

BuildRequires: libXt-devel

I've put the new build requirement in, files can be found at:

SRPM: http://tiptoe.de/dav/rss-glx-0.8.1-0.2.src.rpm
SPEC: http://tiptoe.de/dav/rss-glx.spec

It seems to me that this BZ entry being in state ASSIGNED confused people about
whether someone committed to do a review already, therefore I've opened a new one.

*** This bug has been marked as a duplicate of 188574 ***