I've gone ahead and directly added you as an admin on the two projects. On Thu, Oct 5, 2023 at 1:00 PM Aaron Rainbolt <arraybo...@gmail.com> wrote:
> On 9/28/23 11:29, Greg Hellings wrote: > > > > > > On Thu, Sep 28, 2023, 12:14 Aaron Rainbolt <arraybo...@gmail.com> wrote: > > > > 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 :) > > > > > > There are others who are pumpkin holders for separate parts and > > they'll need to decide on updating their pieces. I own CMake and the > > Swig bindings (Python and Perl for us). > > > > > > 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 > > < > 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? > > > > > > That would probably work. Part of the goal with SWORD is that it needs > > no hard external library dependencies. Thus why ftpparse has been > > included inline. A novel contribution that replaces those but is still > > highly portable C would likely be welcomed. > > > > > > 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? > > > > > > I don't believe I had to modify anything. They were simply pulled in > > so I could maintain support for old versions of CMake - like on CentOS > > 6 and old Ubuntu LTS versions at the time - that had the core > > functionality needed but just lacked a file which newer CMake had > > bundled. Including most of them is likely a moot point by now as those > > versions are ancient. Yes, I undoubtedly modified it from FindBZIP2 as > > it was a later addition to the optional dependencies. The only reason > > to upgrade to GPL2 is that it's the exclusive license and version for > > SWORD contributions, in absence of compelling reasons to the contrary. > > > > > > 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. > > > > > > I'm fairly certain that I am. If not the owner I was the defacto > > maintainer. You are welcome to take over those packages, for sure. Let > > me know if you need me to do the needful for that. I don't think > > they've been officially orphaned for F39, but would be on the chopping > > block for F40 in the absence of sword making it back in. > > Thanks! If all of the comaintainers for Xiphos and BibleTime are also no > longer available or interested, I think it would be helpful if you could > go into https://src.fedoraproject.org/rpms/xiphos and > https://src.fedoraproject.org/rpms/bibletime and click the "Orphan" > button on those. I'll take them once that's done and should be able to > help keep them maintained. > > Thanks for all your help, and God bless! > > Aaron > > > > > --Greg > > > > > > 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 > 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