[sword-devel] Script to find a best fit v11n

Mon Jun 30 02:13:12 EDT 2025

On Sun, Jun 29, 2025 at 9:55 PM Aaron Rainbolt <arraybolt3 at gmail.com> wrote:

> From what I understand as someone who isn't a lawyer but has done
> licensing audits for applications in Ubuntu and Debian, you'll only
> run into issues if you publish *built binaries* of your code. If you
> just publish code, even if it's explicitly intended to be used with
> license-incompatible libraries, you're fine, because you aren't
> distributing someone else's code in a license-incompatible manner, and
> both GPLv2 and GPLv3 allow you to *use* the code however you want, you
> just have to take care when *distributing* it. If you want to make an
> unsightly kludge of GPLv2, GPLv3, and even CDDL on your own system,
> knock yourself out, just don't try to send that mess of a binary to
> anyone else. (This is why Debian gets away with distributing ZFS
> drivers - they distribute driver source code and the needed framework
> to build that code on the fly upon installation, thus they aren't
> breaking any licenses.)
>

Hmmm, that seems like lots of runaround to get things done for what's a
small script, essentially! The proper way would be to find a licensing
model that allowed me to distribute the binaries as well. With
non-programmer Windows users being one of the more likely users of the app,
it wouldn't be a very good experience to only distribute some BSD-licensed
code and wish them good luck.

>
> If you want to publish binaries though, then yes, you'll have a
> problem there. In that instance you might consider rewriting the UI
> with GTK and libadwaita, I know I've seen Rust projects that do that.
> Both of those use different LGPL versions, so you shouldn't run into
> any incompatibilities there unless the LGPLv2 (note, NOT v2.1) and
> GPLv2 are incompatible. I doubt they are, but the FSF apparently
> forgot to include that license in their compatibility matrix at
> https://www.gnu.org/licenses/gpl-faq.en.html#AllCompatibility.
>

Hard pass on GTK. I'm not a huge fan of it, and the bindings to Rust are
constantly in flux. Part of this move of the app to a GUI was simply that I
found a very easy and straightforward display kit that does a good job of
separating logic and display. LGPLv2 is compatible with GPLv2. It was
explicitly created to sit between GPLv2 and MIT/BSD levels of strictness.
Code in any of those more permissive licenses is quite free to easily be
bundled into GPLv2. But the GPLv3 code and GPLv2 only code cannot, alas, be
combined when distributed. At least according to everything I've read.

--Greg

> On Sun, Jun 29, 2025 at 7:05 PM Greg Hellings <greg.hellings at gmail.com>
> wrote:
> >
> > Someone left me alone for too long and I converted my original Python
> script for parsing versifications into a Rust GUI application. You can see
> the quick screencast of what I've done here: https://youtu.be/IwTQTF8PRC4
> >
> > I was about to publish it and produce binaries, but I ran into a problem:
> > I used Slint to create the UI, and Slint is licensed for either
> commercial or GPLv3
> > SWORD is licensed as GPLv2
> >
> > From my understanding, since v2 and v3 are incompatible, that means I
> can't release the both together in a single application. If that's
> incorrect, please someone let me know!
> >
> > --Greg
> >
> > On Thu, Jun 19, 2025 at 10:20 PM Greg Hellings <greg.hellings at gmail.com>
> wrote:
> >>
> >>
> >>
> >> On Thu, Jun 19, 2025 at 4:13 PM DM Smith <dmsmith at crosswire.org> wrote:
> >>>
> >>>
> >>> On Jun 19, 2025, at 3:24 PM, Greg Hellings <greg.hellings at gmail.com>
> wrote:
> >>>
> >>>
> >>> Like most things, it's a trade-off. Working with the bindings requires
> that the Sword bindings are installed on the host system. For someone
> running on Windows, this is particularly non-trivial. For someone running
> in macOS it's not too difficult to install from source (I don't believe
> Homebrew builds them). For users of major Linux distributions, it's
> downright trivial. On Fedora it's as simple as a single `dnf install
> python3-sword` command for a long time now, and it looks like the bindings
> are also available for Ubuntu starting in 25.04 with an `apt install
> python3-sword` as well.
> >>>
> >>>
> >>> Regarding building SWORD on a Mac, I use homebrew for extra packages.
> I tried to run ./autogen.sh, but it failed on libtoolize, which homebrew
> doesn’t have. Then I ran cmake, which failed because icu4c required C++17
> or better. Hacking that I got CMakeLists.txt, I got it to work. I’ll see if
> I can use that to run your script.
> >>
> >>
> >> For these purposes, neither ICU nor CLucene are needed. It's only
> pulling the versification data which is core to the library's builtins.
> >>
> >>>
> >>>
> >>> Advantages of the binding method are that it doesn't rely on parsing a
> C header file, nor on the file laying out the values in a certain way. It
> also can be used offline easily, doesn't require parsing the output of HTML
> in order to find all the applicable files, and is likely slightly faster.
> Not that the speed probably matters for a single run of this, but if you're
> bulk processing files the speed advantages can add up.
> >>>
> >>>
> >>> The way I wrote mine is that it could use the include/canon*.h files
> from a prior local SVN clone. This is very fast. I’d be curious to see how
> it differs in speed from yours. The default is to go against the web, which
> is painfully slow. (Note, it doesn’t yet do the standard disclaimer for the
> web.) Not big deal if it is a single run. Peter mentioned that he does
> additional analysis of the files in problematic areas that cannot be done
> by the script.
> >>>
> >>> Using the python bindings does have the advantages of not re-inventing
> the wheel. I was impressed with chatGPT’s regular expressions to slurp the
> arrays and how concise it was to read the files. There really wasn’t any
> difficulty in parsing the files. Since the canon*.h files are very static
> and not likely to affect the parse. I don’t think this is that big a deal.
> >>
> >>
> >> Yeah, the canon header files are pretty well structured following a
> standard format to make it easier on humans, and thus regex, to swallow.
> The thought of doing so had simply never crossed my mind.
> >>
> >>>
> >>>
> >>>
> >>>
> >>> Disadvantages of the binding method are that it's requiring you to
> revert back to a source build if you are using this to test a canon.h file
> or if you want to use a canon file that isn't available in the package
> manager of your Linux distribution. Building from source isn't terribly
> onerous for most of us contributors but it might be more of a problem for a
> module maintainer. Then again, how often do we add a new versification to
> the code base?
> >>>
> >>>
> >>>  So, it’s not something we’d expect a module maker to succeed at if
> not on Un*x. Maybe someone has a library release for the MacOS or Windows
> that could be used?
> >>
> >>
> >> Because our Python bindings are built as part of the library and
> generated by Swig, they aren't distributed onto PyPI (the PYthon Package
> Index), which is the standard way of installing third party Python modules.
> To install from PyPI, one simply uses the "pip" tool, or other standard
> Python package installers. But for ours, the binding code is generated by
> Swig from the library code and we don't then subsequently distribute the
> module separately. Doing so would not be terribly difficult, but it is not
> a route we have taken previously.
> >>
> >> Of course, installing Python modules that include C bindings
> necessitates having the Python.h file available as well as a compatible
> version of a C compiler. For the official Python distributions, this is
> always and only MSVC - or at least it has been in the past. Officially
> Python has not historically even supported building for Windows with gcc.
> It's enough of a bugbear that I've never even bothered with installing
> modules with Python on Windows.
> >>
> >> Nowadays, though, we don't really need to. Anyone who wants to can
> install Ubuntu under the WSL and just take advantage of the existing apt
> package and Python in there. As for macOS, I haven't a good solution there.
> I only use it as demanded for work. Probably best to just let people who
> want it compile it from source there, and let them know there isn't any
> need for the ICU add ons.
> >>
> >> An alternative is to go beyond a Python script and create a full
> utility in C that does this same work. That would make distribution much
> easier to all of the platforms. The reason I did not initially take that
> route is that Python is so convenient for working with XML in whereas the
> library has no such mechanism to readily parse it and query in the same
> way. Obviously it can be done, as osis2mod is already doing that work. Its
> parsing code could be repurposed to this effect.
> >>
> >>>
> >>>
> >>> So there are pros and cons between them. I was freshly off of getting
> the bindings to compile when I wrote the first draft of av11n.py so I
> naturally went that direction. I also try to avoid writing parsers when I
> can leverage existing ones, as grammars can be notoriously complex to get
> correct. So that dictated my choices as much as did anything else, really!
> >>>
> >>>
> >>> My computer science masters degree was in compiler writing! It’s
> definitely not for the faint of heart!
> >>
> >>
> >> Mine was in AI. Also not for the faint of heart, but much more
> approachable of a consumer product.
> >>
> >>>
> >>>
> >>>
> >>> Another possible enhancement might be a CLI flag to limit the testing
> range to a particular book (or testament) at a time. I have heard people
> talk about having modules split up to one book per file or similar. If they
> could say, "Only check this file against Joshua" then it could keep down a
> significant amount of extra output. But again - I'm not really an intended
> user of it!
> >>>
> >>>
> >>> Great idea. So David’s suggestion of a scope argument.
> >>
> >>
> >> Basically, yes.
> >>
> >>>
> >>>
> >>> And I’m not an intended user of it either. I’m just trying to get
> people to use something other than osis2mod to pick a versification.
> Looking at the Jira issues on osis2mod, in one issue a person listed their
> script that looped over the v11ns and called osis2mod with each. Yuck!
> >>
> >>
> >> Yeah, using osis2mod in that way seems fraught with trouble. But in the
> absence of knowing more about the internal of the library, I can see why
> someone would take that approach.
> >>
> >> --Greg
> >
> > _______________________________________________
> > sword-devel mailing list: sword-devel at crosswire.org
> > http://crosswire.org/mailman/listinfo/sword-devel
> > Instructions to unsubscribe/change your settings at above page
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://crosswire.org/pipermail/sword-devel/attachments/20250630/4028191b/attachment-0001.htm>