[sword-devel] Resuming the development of Xiphos - introducing xiphos-ng (Was: Licensing audit of SWORD for Fedora - sharing results with upstream)

Aaron Rainbolt arraybolt3 at gmail.com
Sun Oct 1 18:12:25 EDT 2023


On 10/1/23 17:02, Peter von Kaehne wrote:
> Have you spoken with Karl, have you signed up to Xiphos’ mailing lists?

I don't know how to contact Karl, I figured he'd see stuff here since Fr 
mentioned him earlier.

The Xiphos mailing lists are either invisible or shut down. See 
https://www.crosswire.org/mailman/listinfo/

> 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 graceful.

Good to know, thank you!

Aaron

> Peter
>
> Sent from my phone. Please forgive misspellings and weird “corrections”
>
>> On 1 Oct 2023, at 21:50, Aaron Rainbolt <arraybolt3 at 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 <arraybolt3 at 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 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
>>>>>> _______________________________________________
>>>>>> 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
> _______________________________________________
> 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


More information about the sword-devel mailing list