<div dir="ltr">I've gone ahead and directly added you as an admin on the two projects.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 5, 2023 at 1:00 PM Aaron Rainbolt <<a href="mailto:arraybolt3@gmail.com">arraybolt3@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 9/28/23 11:29, Greg Hellings wrote:<br>
><br>
><br>
> On Thu, Sep 28, 2023, 12:14 Aaron Rainbolt <<a href="mailto:arraybolt3@gmail.com" target="_blank">arraybolt3@gmail.com</a>> wrote:<br>
><br>
> Hey, thanks for your help!<br>
><br>
> I was able to just repack and remove most everything offending. I<br>
> figured I should share the info upstream so that if there was<br>
> anything<br>
> you wanted to do on your end, you could, but obviously if you're<br>
> comfortable keeping things as they are, I don't have a problem<br>
> with that :)<br>
><br>
><br>
> There are others who are pumpkin holders for separate parts and <br>
> they'll need to decide on updating their pieces. I own CMake and the <br>
> Swig bindings (Python and Perl for us).<br>
><br>
><br>
> I'll submit a patch for the Python bindings, the fix was fairly<br>
> simple.<br>
><br>
> As for ftpparse, I could potentially try writing a replacement myself<br>
> and license it as GPLv2. We already probably have a good starting<br>
> point<br>
> since the FileZilla project is under GPL-2.0-or-later, and appears to<br>
> have its own independently developed directory litsing parser<br>
> written in<br>
> C++ (see<br>
> <a href="https://svn.filezilla-project.org/filezilla/FileZilla3/trunk/src/engine/directorylistingparser.cpp?revision=10945&view=markup" rel="noreferrer" target="_blank">https://svn.filezilla-project.org/filezilla/FileZilla3/trunk/src/engine/directorylistingparser.cpp?revision=10945&view=markup</a><br>
> <<a href="https://svn.filezilla-project.org/filezilla/FileZilla3/trunk/src/engine/directorylistingparser.cpp?revision=10945&view=markup" rel="noreferrer" target="_blank">https://svn.filezilla-project.org/filezilla/FileZilla3/trunk/src/engine/directorylistingparser.cpp?revision=10945&view=markup</a>>).<br>
><br>
> We could port the logic from that into something SWORD-compatible<br>
> perhaps?<br>
><br>
><br>
> That would probably work. Part of the goal with SWORD is that it needs <br>
> no hard external library dependencies. Thus why ftpparse has been <br>
> included inline. A novel contribution that replaces those but is still <br>
> highly portable C would likely be welcomed.<br>
><br>
><br>
> One more question about the CMake files, you mention that<br>
> FindXZ.cmake<br>
> is your original contribution and would be GPLv2, but it appears<br>
> to be<br>
> ported from the BSD-3-Clause FindBZIP2.cmake. Just to be clear,<br>
> since it<br>
> contains your modifications, it should be "upgraded" to GPLv2 as<br>
> it now<br>
> contains your GPLv2 contributions? If so, are there any other<br>
> files in<br>
> the CMake folder that should be similarly "upgraded"? Potentially<br>
> all of<br>
> them if they've all had to be modified for SWORD?<br>
><br>
><br>
> I don't believe I had to modify anything. They were simply pulled in <br>
> so I could maintain support for old versions of CMake - like on CentOS <br>
> 6 and old Ubuntu LTS versions at the time - that had the core <br>
> functionality needed but just lacked a file which newer CMake had <br>
> bundled. Including most of them is likely a moot point by now as those <br>
> versions are ancient. Yes, I undoubtedly modified it from FindBZIP2 as <br>
> it was a later addition to the optional dependencies. The only reason <br>
> to upgrade to GPL2 is that it's the exclusive license and version for <br>
> SWORD contributions, in absence of compelling reasons to the contrary.<br>
><br>
><br>
> Thanks so much for your help! Also, did you also previously maintain<br>
> Xiphos and Bibletime? If so, I would love to take maintainership of<br>
> those too so I can keep everything SWORD-related from dropping out of<br>
> Fedora.<br>
><br>
><br>
> I'm fairly certain that I am. If not the owner I was the defacto <br>
> maintainer. You are welcome to take over those packages, for sure. Let <br>
> me know if you need me to do the needful for that. I don't think <br>
> they've been officially orphaned for F39, but would be on the chopping <br>
> block for F40 in the absence of sword making it back in.<br>
<br>
Thanks! If all of the comaintainers for Xiphos and BibleTime are also no <br>
longer available or interested, I think it would be helpful if you could <br>
go into <a href="https://src.fedoraproject.org/rpms/xiphos" rel="noreferrer" target="_blank">https://src.fedoraproject.org/rpms/xiphos</a> and <br>
<a href="https://src.fedoraproject.org/rpms/bibletime" rel="noreferrer" target="_blank">https://src.fedoraproject.org/rpms/bibletime</a> and click the "Orphan" <br>
button on those. I'll take them once that's done and should be able to <br>
help keep them maintained.<br>
<br>
Thanks for all your help, and God bless!<br>
<br>
Aaron<br>
<br>
><br>
> --Greg<br>
><br>
><br>
> God bless, and thanks again.<br>
><br>
> Aaron<br>
><br>
> On 9/28/23 07:05, Greg Hellings wrote:<br>
> > Aaron,<br>
> ><br>
> > As the previous maintainer who dropped support, thank you for<br>
> picking<br>
> > it up. I have moved on from being a Fedora user (NixOS these<br>
> days) and<br>
> > was no longer maintaining those packages nor the apps that<br>
> depend on<br>
> > it. I am, however, the pumpkin holder for the Python and Perl<br>
> > bindings. If you want to submit a patch to us that gets those<br>
> working<br>
> > again I would be happy to include it upstream.<br>
> ><br>
> > Any files under the cmake folder were contributed by me. Those<br>
> noting<br>
> > a license were taken from later CMake versions and would match<br>
> > licenses there. The FindXZ file is my original contribution and is<br>
> > under the GPLv2 like all other original SWORD code.<br>
> ><br>
> > The gSOAP and Objective-C bindings should be safe to remove in<br>
> Fedora<br>
> > as there is no need for them there.<br>
> ><br>
> > The win32 files would only affect the MinGW build of sword in<br>
> Fedora,<br>
> > which was not retired as it was unaffected by the Python changes.<br>
> ><br>
> > ftpparse is a constant thorn in our side whenever people become<br>
> hung<br>
> > up on the commercial clause. While not strictly necessary to<br>
> SWORD, as<br>
> > HTTP and HTTPS are supported if the library is built with cURL<br>
> > support, it would be a huge loss of functionality for most<br>
> users. It<br>
> > probably is time to consider rewriting their functionality.<br>
> ><br>
> > The Android jar file is also unnecessary for your packaging and you<br>
> > can safely delete it. And the whole pqa folder for diatheke<br>
> should be<br>
> > tossed. Likely at the SVN level, as I'm sure we are not building<br>
> Palm<br>
> > binaries anymore.<br>
> ><br>
> > Hope that helps.<br>
> ><br>
> > --Greg<br>
> ><br>
> ><br>
> > On Thu, Sep 28, 2023, 01:06 Aaron Rainbolt<br>
> <<a href="mailto:arraybolt3@gmail.com" target="_blank">arraybolt3@gmail.com</a>> wrote:<br>
> ><br>
> > Good morning/evening, and thanks for your time.<br>
> ><br>
> > Recently SWORD was removed from Fedora 39 because of a bug<br>
> > relating to<br>
> > the python bindings (it's still using distutils rather than<br>
> > setuptools,<br>
> > which needed to be fixed, but the maintainer didn't fix it in<br>
> > time). I'm<br>
> > attempting to get SWORD back into Fedora by fixing the<br>
> issue, but<br>
> > as the<br>
> > package was already retired, I'm preparing to reintroduce it<br>
> as if it<br>
> > were being added for the first time. For the sake of making<br>
> things go<br>
> > smoothly, I did a full licensing audit on the SWORD source<br>
> code to<br>
> > ensure that all licenses were compliant with Fedora's<br>
> requirements.<br>
> ><br>
> > Some of the results of this audit were less-than-ideal, so I<br>
> > thought I<br>
> > would share the results with you so that you can take any<br>
> measures<br>
> > you<br>
> > deem appropriate. I'm in the process of resolving these<br>
> issues in<br>
> > Fedora.<br>
> ><br>
> > * There are several files under sword-1.9.0/cmake that have<br>
> unclear<br>
> > licenses (referring to "the BSD license" but without<br>
> specifying which<br>
> > version, and telling the user to look at a file that doesn't<br>
> exist<br>
> > for<br>
> > the license details). I *believe* these files are licensed under<br>
> > BSD-3-Clause, as I found the original source for all but one<br>
> of them,<br>
> > however I could not find the original source for<br>
> > sword-1.9.0/cmake/FindXZ.cmake.<br>
> ><br>
> > * The gSOAP bindings contain a file,<br>
> > sword-1.9.0/bindings/gsoap/include/stdsoap.h, which has no<br>
> license<br>
> > and<br>
> > an "All rights reserved" notice.<br>
> ><br>
> > * The Objective-C bindings have a similar problem - the<br>
> following<br>
> > files<br>
> > under sword-1.9.0/bindings/objc all have no license and an "All<br>
> > rights<br>
> > reserved" notice:<br>
> > - ObjCSword.h<br>
> > - src/Notifications.h (yes I realize this file consists<br>
> > entirely of<br>
> > comments but this is still worrying)<br>
> > - src/SwordBibleBook.h<br>
> > - src/SwordBibleBook.m<br>
> > - src/SwordBibleChapter.h<br>
> > - src/SwordBibleChapter.m<br>
> > - src/SwordBibleTextEntry.h<br>
> > - src/SwordBibleTextEntry.m<br>
> > - src/SwordInstallSource.h<br>
> > - src/SwordInstallManager.h<br>
> > - src/SwordInstallManager.mm<br>
> > - src/SwordInstallSource.mm<br>
> > - src/SwordKey.h<br>
> > - src/SwordKey.m<br>
> > - src/SwordListKey.h<br>
> > - src/SwordListKey.mm<br>
> > - src/SwordLocaleManager.h<br>
> > - src/SwordLocaleManager.mm<br>
> > - src/SwordModuleIndex.h<br>
> > - src/SwordModuleIndex.m<br>
> > - src/SwordModuleTextEntry.h<br>
> > - src/SwordModuleTextEntry.m<br>
> > - src/SwordTreeEntry.h<br>
> > - src/SwordTreeEntry.m<br>
> > - src/SwordVerseKey.h<br>
> > - src/SwordVerseKey.mm<br>
> > - src/SwordVerseManager.h<br>
> > - src/SwordVerseManager.m<br>
> > - src/VerseEnumerator.h<br>
> > - src/VerseEnumerator.m<br>
> > - src/services/Configuration.h<br>
> > - src/services/Configuration.m<br>
> > - src/services/iOSConfiguration.h<br>
> > - src/services/iOSConfiguration.m<br>
> > - src/services/OSXConfiguration.h<br>
> > - src/services/OSXConfiguration.m<br>
> > - SWORD/SWORD/SWORD.h<br>
> > - SWORD/SWORD/SWORD.m<br>
> > - test/SwordListKeyTest.h<br>
> > - test/SwordListKeyTest.m<br>
> > - test/SwordModuleLongRunTest.h<br>
> > - test/SwordModuleLongRunTest.mm<br>
> > - test/SwordModuleTest.h<br>
> > - test/SwordModuleTest.m<br>
> ><br>
> > * Two files under sword-1.9.0/src/utilfuns/win32 are under<br>
> non-free<br>
> > licenses - they prohibit the sale of media containing those<br>
> files for<br>
> > anything greater than the cost of distribution.<br>
> ><br>
> > * The files sword-1.9.0/include/ftpparse.h and<br>
> > sword-1.9.0/src/utilfuns/ftpparse.c are under informal non-free<br>
> > licenses<br>
> > prohibiting commercial use unless the copyright owner is<br>
> informed of<br>
> > what program uses the files. This code appears to be critical to<br>
> > SWORD's<br>
> > functionality (as FTP is used for module downloading), so I have<br>
> > attempted to contact the author and ask that ftpparse be<br>
> > relicensed to<br>
> > 0BSD (which should be compatible with the licenses in SWORD).<br>
> ><br>
> > In addition to the above, I discovered some pre-built binary<br>
> files<br>
> > floating around:<br>
> > -<br>
> ><br>
> sword-1.9.0/bindings/Android/SWORD/gradle/wrapper/gradle-wrapper.jar<br>
> > - sword-1.9.0/utilities/diatheke/pqa/Diatheke.pqa<br>
> ><br>
> > While these aren't strictly a problem, they do have to be<br>
> removed in<br>
> > Fedora. You might consider removing them from your SVN repo if<br>
> > possible<br>
> > and not too inconvenient.<br>
> ><br>
> > I hope this message finds you all doing well! God bless, and<br>
> > thanks for<br>
> > all the work you've put into the SWORD Project!<br>
> ><br>
> > _______________________________________________<br>
> > sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
> > <a href="http://crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer" target="_blank">http://crosswire.org/mailman/listinfo/sword-devel</a><br>
> > Instructions to unsubscribe/change your settings at above page<br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
> > <a href="http://crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer" target="_blank">http://crosswire.org/mailman/listinfo/sword-devel</a><br>
> > Instructions to unsubscribe/change your settings at above page<br>
> _______________________________________________<br>
> sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
> <a href="http://crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer" target="_blank">http://crosswire.org/mailman/listinfo/sword-devel</a><br>
> Instructions to unsubscribe/change your settings at above page<br>
><br>
><br>
> _______________________________________________<br>
> sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
> <a href="http://crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer" target="_blank">http://crosswire.org/mailman/listinfo/sword-devel</a><br>
> Instructions to unsubscribe/change your settings at above page<br>
_______________________________________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
<a href="http://crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer" target="_blank">http://crosswire.org/mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br>
</blockquote></div>