Have you spoken with Karl, have you signed up to Xiphos’ mailing lists? Xiphos 
has had development pauses of years and suddenly spurts , and Karl is as far as 
I know still very much around. 

I think he would welcome any new input for sure and if (I have not the 
foggiest) he wants to pass it on - he handled 15 years ago the transition in 
maintainership/lead developership  from Terry to himself in the most gracious 
possible form. He will handle a new one from him to someone else equally 


Sent from my phone. Please forgive misspellings and weird “corrections”

> On 1 Oct 2023, at 21:50, Aaron Rainbolt <arraybo...@gmail.com> wrote:
> The Xiphos fork has been created! https://github.com/ArrayBolt3/xiphos-ng 
> I'm about to push a build failure fix to it in a few moments. Feel free to 
> make new pull requests, bug reports, suggestions, etc. here. Lord willing 
> I'll be monitoring things and getting additions made.
> Currently the fork is named xiphos-ng (ng for Next Generation, since that's a 
> rather popular naming convention for when you pick up an old project), 
> however I intend for the program name to remain Xiphos. This is because I 
> don't expect there to ever be a release of xiphos-ng, but rather hope that it 
> will just be absorbed into the Xiphos project and then development will 
> resume there. In the event Xiphos is truly and permanently dead, however, we 
> can come up with a better name for xiphos-ng and then mass-rename and rebrand 
> everything.
> Also, the SWORD fixes in Fedora seem to be coming along (I'm working on 
> getting the package through initial review currently), so we should be OK on 
> that front if all goes well.
> Aaron
>> On 10/1/23 03:34, Fr Cyrille wrote:
>>> Le 01/10/2023 à 08:59, Aaron Rainbolt a écrit :
>>> On 9/28/23 13:35, Fr Cyrille wrote:
>>>> Le 28/09/2023 à 18:13, Aaron Rainbolt a écrit :
>>>>> Hey, thanks for your help!
>>>>> I was able to just repack and remove most everything offending. I figured 
>>>>> I should share the info upstream so that if there was anything you wanted 
>>>>> to do on your end, you could, but obviously if you're comfortable keeping 
>>>>> things as they are, I don't have a problem with that :)
>>>>> I'll submit a patch for the Python bindings, the fix was fairly simple.
>>>>> As for ftpparse, I could potentially try writing a replacement myself and 
>>>>> license it as GPLv2. We already probably have a good starting point since 
>>>>> the FileZilla project is under GPL-2.0-or-later, and appears to have its 
>>>>> own independently developed directory litsing parser written in C++ (see 
>>>>> https://svn.filezilla-project.org/filezilla/FileZilla3/trunk/src/engine/directorylistingparser.cpp?revision=10945&view=markup).
>>>>>  We could port the logic from that into something SWORD-compatible 
>>>>> perhaps?
>>>>> One more question about the CMake files, you mention that FindXZ.cmake is 
>>>>> your original contribution and would be GPLv2, but it appears to be 
>>>>> ported from the BSD-3-Clause FindBZIP2.cmake. Just to be clear, since it 
>>>>> contains your modifications, it should be "upgraded" to GPLv2 as it now 
>>>>> contains your GPLv2 contributions? If so, are there any other files in 
>>>>> the CMake folder that should be similarly "upgraded"? Potentially all of 
>>>>> them if they've all had to be modified for SWORD?
>>>>> Thanks so much for your help! Also, did you also previously maintain 
>>>>> Xiphos and Bibletime? If so, I would love to take maintainership of those 
>>>>> too so I can keep everything SWORD-related from dropping out of Fedora.
>>>> Dear Aaron,
>>>> What a magnificent proposal this is!! I have been lamenting to the Lord 
>>>> for months, seeing Xiphos stagnate... and risking disappearing. Personally 
>>>> I am under Ubuntu.
>>>> At the beginning of the year I asked the Lord in my prayer to give us 
>>>> developers for Xiphos, you could be the answer to this prayer. If Karl 
>>>> could react to your proposal that would be great.
>>>> I will follow this proposal with great interest.
>>> I actually know C and C++, so I might be able to help there. If I have some 
>>> spare time and am itching to code, I'll fiddle with it and see if I can 
>>> implement requested features and fix bugs.
>>> Also I used to be an Ubuntu Developer, and intend on returning to Ubuntu 
>>> development once work starts on 24.04 LTS. So I may end up being able to 
>>> help accelerate the acceptance of updated SWORD-related software into 
>>> Debian, Ubuntu, and Fedora if, Lord willing, all goes well.
>>> Thanks for the encouragement!
>> You made my day! God be praised... I will help to with testing, ideas 
>> (many), compiling... May God send still 2 or 3 dev for it.
>>> Aaron
>>>>> God bless, and thanks again.
>>>>> Aaron
>>>>> On 9/28/23 07:05, Greg Hellings wrote:
>>>>>> Aaron,
>>>>>> As the previous maintainer who dropped support, thank you for picking it 
>>>>>> up. I have moved on from being a Fedora user (NixOS these days) and was 
>>>>>> no longer maintaining those packages nor the apps that depend on it. I 
>>>>>> am, however, the pumpkin holder for the Python and Perl bindings. If you 
>>>>>> want to submit a patch to us that gets those working again I would be 
>>>>>> happy to include it upstream.
>>>>>> Any files under the cmake folder were contributed by me. Those noting a 
>>>>>> license were taken from later CMake versions and would match licenses 
>>>>>> there. The FindXZ file is my original contribution and is under the 
>>>>>> GPLv2 like all other original SWORD code.
>>>>>> The gSOAP and Objective-C bindings should be safe to remove in Fedora as 
>>>>>> there is no need for them there.
>>>>>> The win32 files would only affect the MinGW build of sword in Fedora, 
>>>>>> which was not retired as it was unaffected by the Python changes.
>>>>>> ftpparse is a constant thorn in our side whenever people become hung up 
>>>>>> on the commercial clause. While not strictly necessary to SWORD, as HTTP 
>>>>>> and HTTPS are supported if the library is built with cURL support, it 
>>>>>> would be a huge loss of functionality for most users. It probably is 
>>>>>> time to consider rewriting their functionality.
>>>>>> The Android jar file is also unnecessary for your packaging and you can 
>>>>>> safely delete it. And the whole pqa folder for diatheke should be 
>>>>>> tossed. Likely at the SVN level, as I'm sure we are not building Palm 
>>>>>> binaries anymore.
>>>>>> Hope that helps.
>>>>>> --Greg
>>>>>> On Thu, Sep 28, 2023, 01:06 Aaron Rainbolt <arraybo...@gmail.com> wrote:
>>>>>>     Good morning/evening, and thanks for your time.
>>>>>>     Recently SWORD was removed from Fedora 39 because of a bug
>>>>>>     relating to
>>>>>>     the python bindings (it's still using distutils rather than
>>>>>>     setuptools,
>>>>>>     which needed to be fixed, but the maintainer didn't fix it in
>>>>>>     time). I'm
>>>>>>     attempting to get SWORD back into Fedora by fixing the issue, but
>>>>>>     as the
>>>>>>     package was already retired, I'm preparing to reintroduce it as if it
>>>>>>     were being added for the first time. For the sake of making things go
>>>>>>     smoothly, I did a full licensing audit on the SWORD source code to
>>>>>>     ensure that all licenses were compliant with Fedora's requirements.
>>>>>>     Some of the results of this audit were less-than-ideal, so I
>>>>>>     thought I
>>>>>>     would share the results with you so that you can take any measures
>>>>>>     you
>>>>>>     deem appropriate. I'm in the process of resolving these issues in
>>>>>>     Fedora.
>>>>>>     * There are several files under sword-1.9.0/cmake that have unclear
>>>>>>     licenses (referring to "the BSD license" but without specifying which
>>>>>>     version, and telling the user to look at a file that doesn't exist
>>>>>>     for
>>>>>>     the license details). I *believe* these files are licensed under
>>>>>>     BSD-3-Clause, as I found the original source for all but one of them,
>>>>>>     however I could not find the original source for
>>>>>>     sword-1.9.0/cmake/FindXZ.cmake.
>>>>>>     * The gSOAP bindings contain a file,
>>>>>>     sword-1.9.0/bindings/gsoap/include/stdsoap.h, which has no license
>>>>>>     and
>>>>>>     an "All rights reserved" notice.
>>>>>>     * The Objective-C bindings have a similar problem - the following
>>>>>>     files
>>>>>>     under sword-1.9.0/bindings/objc all have no license and an "All
>>>>>>     rights
>>>>>>     reserved" notice:
>>>>>>         - ObjCSword.h
>>>>>>         - src/Notifications.h (yes I realize this file consists
>>>>>>     entirely of
>>>>>>     comments but this is still worrying)
>>>>>>         - src/SwordBibleBook.h
>>>>>>         - src/SwordBibleBook.m
>>>>>>         - src/SwordBibleChapter.h
>>>>>>         - src/SwordBibleChapter.m
>>>>>>         - src/SwordBibleTextEntry.h
>>>>>>         - src/SwordBibleTextEntry.m
>>>>>>         - src/SwordInstallSource.h
>>>>>>         - src/SwordInstallManager.h
>>>>>>         - src/SwordInstallManager.mm
>>>>>>         - src/SwordInstallSource.mm
>>>>>>         - src/SwordKey.h
>>>>>>         - src/SwordKey.m
>>>>>>         - src/SwordListKey.h
>>>>>>         - src/SwordListKey.mm
>>>>>>         - src/SwordLocaleManager.h
>>>>>>         - src/SwordLocaleManager.mm
>>>>>>         - src/SwordModuleIndex.h
>>>>>>         - src/SwordModuleIndex.m
>>>>>>         - src/SwordModuleTextEntry.h
>>>>>>         - src/SwordModuleTextEntry.m
>>>>>>         - src/SwordTreeEntry.h
>>>>>>         - src/SwordTreeEntry.m
>>>>>>         - src/SwordVerseKey.h
>>>>>>         - src/SwordVerseKey.mm
>>>>>>         - src/SwordVerseManager.h
>>>>>>         - src/SwordVerseManager.m
>>>>>>         - src/VerseEnumerator.h
>>>>>>         - src/VerseEnumerator.m
>>>>>>         - src/services/Configuration.h
>>>>>>         - src/services/Configuration.m
>>>>>>         - src/services/iOSConfiguration.h
>>>>>>         - src/services/iOSConfiguration.m
>>>>>>         - src/services/OSXConfiguration.h
>>>>>>         - src/services/OSXConfiguration.m
>>>>>>         - SWORD/SWORD/SWORD.h
>>>>>>         - SWORD/SWORD/SWORD.m
>>>>>>         - test/SwordListKeyTest.h
>>>>>>         - test/SwordListKeyTest.m
>>>>>>         - test/SwordModuleLongRunTest.h
>>>>>>         - test/SwordModuleLongRunTest.mm
>>>>>>         - test/SwordModuleTest.h
>>>>>>         - test/SwordModuleTest.m
>>>>>>     * Two files under sword-1.9.0/src/utilfuns/win32 are under non-free
>>>>>>     licenses - they prohibit the sale of media containing those files for
>>>>>>     anything greater than the cost of distribution.
>>>>>>     * The files sword-1.9.0/include/ftpparse.h and
>>>>>>     sword-1.9.0/src/utilfuns/ftpparse.c are under informal non-free
>>>>>>     licenses
>>>>>>     prohibiting commercial use unless the copyright owner is informed of
>>>>>>     what program uses the files. This code appears to be critical to
>>>>>>     SWORD's
>>>>>>     functionality (as FTP is used for module downloading), so I have
>>>>>>     attempted to contact the author and ask that ftpparse be
>>>>>>     relicensed to
>>>>>>     0BSD (which should be compatible with the licenses in SWORD).
>>>>>>     In addition to the above, I discovered some pre-built binary files
>>>>>>     floating around:
>>>>>>         -
>>>>>> sword-1.9.0/bindings/Android/SWORD/gradle/wrapper/gradle-wrapper.jar
>>>>>>         - sword-1.9.0/utilities/diatheke/pqa/Diatheke.pqa
>>>>>>     While these aren't strictly a problem, they do have to be removed in
>>>>>>     Fedora. You might consider removing them from your SVN repo if
>>>>>>     possible
>>>>>>     and not too inconvenient.
>>>>>>     I hope this message finds you all doing well! God bless, and
>>>>>>     thanks for
>>>>>>     all the work you've put into the SWORD Project!
>>>>>>     _______________________________________________
>>>>>>     sword-devel mailing list: sword-devel@crosswire.org
>>>>>>     http://crosswire.org/mailman/listinfo/sword-devel
>>>>>>     Instructions to unsubscribe/change your settings at above page
>>>>>> _______________________________________________
>>>>>> sword-devel mailing list: sword-devel@crosswire.org
>>>>>> http://crosswire.org/mailman/listinfo/sword-devel
>>>>>> Instructions to unsubscribe/change your settings at above page
>>>>> _______________________________________________
>>>>> sword-devel mailing list: sword-devel@crosswire.org
>>>>> http://crosswire.org/mailman/listinfo/sword-devel
>>>>> Instructions to unsubscribe/change your settings at above page
> _______________________________________________
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

sword-devel mailing list: sword-devel@crosswire.org
Instructions to unsubscribe/change your settings at above page

Reply via email to