[Pkg-crosswire-devel] Please update the World English Bible module to version 1.8

[Jonathan Morgan]

On Mon, Jan 11, 2010 at 9:08 AM, John Zaitseff <J.Zaitseff at zap.org.au>wrote:

> Dear Dmitrijs et al.,
>
> > > I sent an e-mail to the Debian bug tracker about a new version
> > > of the World English Bible (WEB) module almost three years ago.
> > > Unfortunately, no one seems to have done anything about it.
> >
> > pkgcrosswire team has been started after that.
>
> Well, if the team picks up this package, all to the good! :-)
>
> > > I have therefore packaged a newer version of the WEB module,
> > > version 1.8, and placed it on the ZAP Group package repository.
> > > Could you (or someone else) please take this and incorporate it
> > > into an official Debian package?
> >
> > Well your packaging simply installs binary blobs.  Quite a few
> > sword-text-* packages do that.  I believe this fails DFSG-
> > freeness.  As change-log suggests the source for this module is
> > OSIS, hence the deb package must be build from OSIS (converted to
> > a module).
> >
> > For this package to be included in Debian Main please release orig
> > tarball with sources (OSIS) and create a debian package which
> > builds crosswire module and installs it.
>
> This is a problem indeed: the reason the sword-text-* packages
> install what look like binary blobs is that the original upstream
> packages (from http://www.crosswire.org/sword/modules/) are in that
> format; they are NOT in OSIS (or GBS/VS/VPL/TEI) format.  You are,
> no doubt, acutely aware of this, so this is just for the record.
>
> As I see it, there are four possible solutions:
>
> 1. Continue the status quo.  The data can be extracted at any time
>   by running the mod2osis(1) tool in the libsword8 (sword) package.
>   You therefore could argue that the module format is simply a
>   compressed version of the data, since running osis2mod(1), then
>   mod2osis(1), is lossless---at least, that is the goal of the
>   upstream sword library.
>
> 2. Download the relevant package from www.crosswire.org, then run
>   mod2osis on the data manually to create a "pseudo-upstream"
>   source.  I don't really see any benefit of doing this, although
>   it does allow the final package to be compatible with the
>   upstream CrossWire one.
>
> 3. Go further upstream, directly to the OSIS/GBS/TEI source (or USFX
>   in the case of the World English Bible), bypassing CrossWire
>   altogether.  This almost certainly means the final packages will
>   NOT be compatible with the CrossWire modules, which could be a
>   problem with programs like BibleTime.
>
> 4. Give up packaging CrossWire modules entirely, and hope that the
>   end user will do it himself or herself.  BibleTime, for example,
>   makes this somewhat easier to do.  Needless to say, I don't like
>   this solution at all!
>
> One further wrinkle, again for the record, is the FAQ on this very
> question from CrossWire:
>
>  How do I convert Sword modules to text?
>
>  We would like to discourage this.  Please work with us in making
>  our software better.  But, if you really need the text, each
>  module has a conf file which will tell you about the origin of the
>  text.  Please obtain the source the same way we did.  You may not
>  convert the modules that have been licensed to CrossWire for
>  distribution.  The KJV module is the only one for which we
>  maintain the source, which you can obtain [here].
>
>
> http://www.crosswire.org/index.jsp?section=FAQ#How_do_I_convert_Sword_modules_to_text.3F
>
>
Just to make it clear (if it wasn't already) "the modules that have been
licensed to CrossWire for distribution" speaks specifically of copyrighted
modules (such as the NET Bible or the ESV) for which permission has been
given to CrossWire to distribute, but has not been given to Debian et al to
distribute them (and definitely not to change them).  For the reasons DM
gives CrossWire *discourages* people from using CrossWire modules as a
source, but if they are in the public domain (as the WEB is) then CrossWire
cannot do anything to *stop* them being distributed and used.

It is because of these copyrighted modules that I would prefer not to have
modules packaged by Debian/Ubuntu.  My problem is that these packages do not
show the full capabilities of our software, and there is a chance that users
will not discover the remaining modules.  Unless the collection of modules
in the repository is complete, it gives a false representation of what is
available and possible.  I believe that a majority of upstream developers
agree with this principle.  It is this that causes the comment "Upstream was
quite hostile of packaging sword modules in Debian."

I'm hoping that solution 1 will prevail: yes, the data is in
> compressed and processed format, but it is trivially retrievable
> using the mod2osis(1) utility program.
>

If modules must be packaged, I prefer solution 1, because it is simpler.
The work has already been done by CrossWire, and I see no purpose in doing
it again for every Linux distribution just because we can.

Jon

PS: DM, would mod2imp and imp2mod losslessly roundtrip all modules,
including OSIS modules?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-crosswire-devel/attachments/20100111/a2069b8f/attachment.html>