[Bug 461077] Review Request: nxtvepg - A nexTView EPG decoder and browser

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=461077





--- Comment #25 from Torsten Rausche <trausche at fedoraproject.org>  2008-11-25 14:00:21 EDT ---
We have following situation:

[1] Nxtvepg (GPLv2) does not need the Perl script (GPLv3+). It can use the
script if it is there but also runs fine without it. Both communicate with each
other and exchange data. But there is no hard link between both. Nxtvepg simply
pipes preprocessed data from /dev/vbi to the script, the script parses the data
and gives XML as output, which in turn nxtvepg reads via pipe.

My opinion is that if this is not legal then no GPLv2 UNIX tool could interact
with a GPLv3+ one. Upstream also does not seem to see a problem here.

[2] The Perl script (GPLv3+) can also run without nxtvepg. But it needs
preprocessed input data to do something useful. This data has to come from a
file or standard input. Optionally it can use the VBI device directly -- if the
Perl module Video-ZVBI (GPLv2+) is available. This module is not packaged for
Fedora yet. But this could be done...

Because of [1] the script is included in the nxtvepg tarball. Because of [2] it
is also available in its own tarball under
http://nxtvepg.sourceforge.net/tv_grab_ttx

I think it is enough to set License to GPLv2 and GPLv3+ and keep the script in
the nxtvepg package. But I admit that my knowledge about licensing is pretty
low. There is also the way to introduce two new packages (no subpackages, one
for the script and one for the Video-ZVBI Perl module) and remove the script
from the nxtvepg package. Of course this also means two more package reviews to
work on ;-)

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.