From fr.cyrille at tiberiade.be Mon Sep 4 06:27:11 2023 From: fr.cyrille at tiberiade.be (Fr Cyrille) Date: Mon, 4 Sep 2023 12:27:11 +0200 Subject: [sword-devel] Common folder for modules under android Message-ID: Hi, I'm not sure where to open this issue. But it concerns everyone developing on Android 10 and above. With older versions of Android it was possible to share a common folder for sword modules. This no longer works. So I was wondering if it wouldn't be possible to make a convention that would define where module folders are placed and that each software program could use the same folder. This would avoid having to install the same modules over and over again. In principle, Tuomas, Troy and Tobias are involved. The three T, funny ? Br Cyrille -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfhdfh at protonmail.com Fri Sep 15 11:53:02 2023 From: dfhdfh at protonmail.com (David Haslam) Date: Fri, 15 Sep 2023 15:53:02 +0000 Subject: [sword-devel] Adding some new modules to the Bible collection In-Reply-To: References: Message-ID: Transcribing Bibles from the age before digital computers is best done by volunteers with MissionAssist UK. I can put you in contact with some of the friends who are volunteers. David Haslam Sent from [Proton Mail](https://proton.me/mail/home) for iOS On Fri, Sep 15, 2023 at 16:44, D. Almeida <[daviacastro20 at gmail.com](mailto:On Fri, Sep 15, 2023 at 16:44, D. Almeida < wrote: > Peace be upon you!!! > > I'd like to ask you, whether you could put in a digital format some old facsimiled Bibles, which have become out of print. All of them are on Public Domain: they range from the XVI-th to the XIX-th century. > > There are some old Ottoman Turkish, and Venice Mekhitarist translations, that could be of immense value, once made part of the library or digitalised:H > > 1. Helleno-Turkish (Turkish written in Greek alphabet): > > https://books.google.com/books?id=lj47AAAAcAAJ > https://www.google.com/books/edition/Biblia_Turco_Greek/5Iw8AAAAcAAJ > > 2. Armeno-Turkish (Turkish written in Armenian alphabet): > > https://books.google.com/books?id=paxBAAAAYAAJ > https://www.google.com/books/edition/Turkish_New_Testament_Written_in_Armenia/ViwwAAAAYAAJ > https://www.google.com/books/edition/The_Bible_in_Turkish_written_in_Armenian/GhuHo5BZTcoC > > 3. Armeno-Kurdish (Kurdish written in Armenian alphabet): > > https://books.google.com/books?id=zywwAAAAYAAJ > > Added to these, another very useful Jewish translation of the Pentateuch: the Ferrara Bible > > https://www.larramendi.es/i18n/catalogo_imagenes/grupo.cmd?path=1001869 > > Also, there is another Bible, in Basque, by Jean-Pierre Duvoisin: > > This is the facsimile version, by the Biblioth?que de France > > https://gallica.bnf.fr/ark:/12148/bpt6k96656209.r=bible%20saindua?rk=21459;2 > > Here is its electronic version, made by Josu Landa Ijurko: > > https://klasikoak.armiarma.eus/idazlanak/D/DuvoisinBibleaI.htm > > https://klasikoak.armiarma.eus/idazlanak/D/DuvoisinBibleaII.htm > > https://klasikoak.armiarma.eus/idazlanak/D/DuvoisinBibleaIII.htm > > So, please consider adding these to the Library, as well. > > Thank you for your efforts, God bless them, always, as well as yourselves, and thank God, you've been sharing the Word with the whole world, making It available to us! > > God bless you, guys, and thank you so much for your efforts, more and more -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.hellings at gmail.com Fri Sep 15 13:45:26 2023 From: greg.hellings at gmail.com (Greg Hellings) Date: Fri, 15 Sep 2023 12:45:26 -0500 Subject: [sword-devel] Adding some new modules to the Bible collection In-Reply-To: References:

Message-ID: It is also worth noting that CrossWire doesn't undertake these types of tasks and does not want to be the main source for such original texts. However, if another organization does make a digital text available, CrossWire likely would be able to create a module from that efforts in a reproducible way. On Fri, Sep 15, 2023 at 10:54?AM David Haslam wrote: > Transcribing Bibles from the age before digital computers is best done by > volunteers with MissionAssist UK. > > I can put you in contact with some of the friends who are volunteers. > > David Haslam > > Sent from Proton Mail for iOS > > > On Fri, Sep 15, 2023 at 16:44, D. Almeida > wrote: > > Peace be upon you!!! > > I'd like to ask you, whether you could put in a digital format some old > facsimiled Bibles, which have become out of print. All of them are on > Public Domain: they range from the XVI-th to the XIX-th century. > > There are some old Ottoman Turkish, and Venice Mekhitarist translations, > that could be of immense value, once made part of the library or > digitalised:H > > 1. Helleno-Turkish (Turkish written in Greek alphabet): > > https://books.google.com/books?id=lj47AAAAcAAJ > https://www.google.com/books/edition/Biblia_Turco_Greek/5Iw8AAAAcAAJ > > 2. Armeno-Turkish (Turkish written in Armenian alphabet): > > https://books.google.com/books?id=paxBAAAAYAAJ > > https://www.google.com/books/edition/Turkish_New_Testament_Written_in_Armenia/ViwwAAAAYAAJ > > https://www.google.com/books/edition/The_Bible_in_Turkish_written_in_Armenian/GhuHo5BZTcoC > > 3. Armeno-Kurdish (Kurdish written in Armenian alphabet): > > https://books.google.com/books?id=zywwAAAAYAAJ > > Added to these, another very useful Jewish translation of the Pentateuch: > the Ferrara Bible > > https://www.larramendi.es/i18n/catalogo_imagenes/grupo.cmd?path=1001869 > > Also, there is another Bible, in Basque, by Jean-Pierre Duvoisin: > > This is the facsimile version, by the Biblioth?que de France > > > https://gallica.bnf.fr/ark:/12148/bpt6k96656209.r=bible%20saindua?rk=21459;2 > > Here is its electronic version, made by Josu Landa Ijurko: > > https://klasikoak.armiarma.eus/idazlanak/D/DuvoisinBibleaI.htm > > https://klasikoak.armiarma.eus/idazlanak/D/DuvoisinBibleaII.htm > > https://klasikoak.armiarma.eus/idazlanak/D/DuvoisinBibleaIII.htm > > > So, please consider adding these to the Library, as well. > > Thank you for your efforts, God bless them, always, as well as yourselves, > and thank God, you've been sharing the Word with the whole world, making It > available to us! > > > God bless you, guys, and thank you so much for your efforts, more and more > > _______________________________________________ > 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: From arraybolt3 at gmail.com Thu Sep 28 01:05:30 2023 From: arraybolt3 at gmail.com (Aaron Rainbolt) Date: Thu, 28 Sep 2023 00:05:30 -0500 Subject: [sword-devel] Licensing audit of SWORD for Fedora - sharing results with upstream Message-ID: 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! From greg.hellings at gmail.com Thu Sep 28 08:05:00 2023 From: greg.hellings at gmail.com (Greg Hellings) Date: Thu, 28 Sep 2023 08:05:00 -0400 Subject: [sword-devel] Licensing audit of SWORD for Fedora - sharing results with upstream In-Reply-To: References: Message-ID: 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 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arraybolt3 at gmail.com Thu Sep 28 12:13:18 2023 From: arraybolt3 at gmail.com (Aaron Rainbolt) Date: Thu, 28 Sep 2023 11:13:18 -0500 Subject: [sword-devel] Licensing audit of SWORD for Fedora - sharing results with upstream In-Reply-To: References:

Message-ID: <240cae68-ae08-4b23-352a-c7a46df2c28a@gmail.com> 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. 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 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 From greg.hellings at gmail.com Thu Sep 28 12:29:26 2023 From: greg.hellings at gmail.com (Greg Hellings) Date: Thu, 28 Sep 2023 12:29:26 -0400 Subject: [sword-devel] Licensing audit of SWORD for Fedora - sharing results with upstream In-Reply-To: <240cae68-ae08-4b23-352a-c7a46df2c28a@gmail.com> References:

<240cae68-ae08-4b23-352a-c7a46df2c28a@gmail.com> Message-ID: On Thu, Sep 28, 2023, 12:14 Aaron Rainbolt 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). > > 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. --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 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arraybolt3 at gmail.com Thu Sep 28 12:40:58 2023 From: arraybolt3 at gmail.com (Aaron Rainbolt) Date: Thu, 28 Sep 2023 11:40:58 -0500 Subject: [sword-devel] Licensing audit of SWORD for Fedora - sharing results with upstream In-Reply-To: References:

wrote: > The Berean Standard Bible is available in two machine-readable formats: USFM, and "translation tables", a 40MB Excel spreadsheet with a row for every Hebrew or Greek word in their chosen source texts with the English text it's translated to. I would like to make one module with the nice formatting of the USFM sources and the metadata from the spreadsheet, so I've spent the last few weeks writing a script that runs through them both in parallel and makes sure everything lines up, so I'm now confident that I have an accurate mapping between them. > > My question now is, how can I translate the data from the spreadsheet into OSIS? > > Here's the information the spreadsheet gives me: > > Column Example Notes > he_ordinal 1 "Hebrew Ordinal", increments for each spreadsheet row in the Old Testament, set to 999999 for each row in the New Testament > el_ordinal 0 "Greek Ordinal", set to 0 for each row in the Old Testament, increments for each row in the New Testament, except for Mark 1:1 which has a word with the number 18379.5 (presumably something needed to be inserted and they didn't want to renumber everything else) > en_ordinal 1 "English Ordinal", increments for each spreadsheet row (except for that word in Mark 1:1) > language Hebrew "Hebrew", "Greek", or sometimes "Aramaic" > verse_ordinal 1 Increments for each verse in the Bible, so every word in Genesis 1:1 has "1", etc. > source_word ???????????? The word in the original source text. Sometimes includes fancy brackets to mark sources other than WLC or Nestle 1904: {TR} ?RP? (WH) ?NE? [NA] ?SBL? [[ECM]] > transliteration b??r????? A transliteration of the source word into the Latin alphabet > grammar_code Prep-b | N-fs A code describing the grammatical form of the word; these don't appear to be Robinson codes, but their own custom thing for Hebrew (https://biblehub.com/hebrewparse.htm) and Greek (https://biblehub.com/abbrev.htm) > grammar_description Preposition-b | Noun - feminine singular The grammar code, unabbreviated > strongs_number 7225 The Strongs number of the basic form of this word > translation In the beginning The English text that appears in the BSB > gloss 1) first, beginning, best, chief > 1a) beginning > 1b) first > 1c) chief > 1d) choice part A definition from the Brown-Driver-Briggs Hebrew Lexicon, or Thayer's Greek Definitions, as appropriate > > Looking at the OSIS 2.1.1 User's Manual (and sniffing around in the KJVA module), to represent this information in OSIS I should use the element, which supports the following attributes (copy/pasted from the Manual): > > - gloss Record comments on a particular word or its usage. > - lemma Use to record the base form of a word. > - morph Use to record grammatical information for a word. > - POS Use to record the function of a word according to a particular view of the language's syntax. > - src Use to record origin of the word. > - xlit Use to record a transliteration of a word. > > The first problem is that sometimes multiple source words are translated into a single English span, and it's not made clear how to express that in these attributes. From poking around in the KJVA module, I get the impression these are supposed to be space-delimited lists. Is that correct? > > Assuming that's the case, here's my guesses at how to fill out these attributes for each span: > > - gloss can't be done, because each gloss contains spaces which means the displaying app can't figure out which part of the gloss goes with which word > - lemma is where Strongs numbers go; Greek Strongs numbers should be prefixed with "G" and Hebrew/Aramaic ones with "H0" > - morph might be used for the "grammar code" content, but I would probably need to figure out how to translate them into Robinson codes first, since that seems to be the only morphological dictionary module in the Crosswire repositories > - POS is unclear to me, I don't see how it differs from the "morph" attribute > - src is also unclear: is this for the word order (he_ordinal or el_ordinal, possibly numbered from the beginning of the verse rather than the beginning of the entire Bible) or the actual choice of source text (Nestle1904, TR, NA, SBL, etc.)? > - xlit clearly comes from the "transliteration" field > > One thing that's clearly missing is where to put the source word. How does that work? > > Is there other way to represent information that doesn't fit into the element? I'd like this module to be as useful as possible, so I'm hesitant to toss out any information that can be usefully represented. > > Is there anything else I've missed or misunderstood? > > Timothy. -------------- next part -------------- An HTML attachment was scrubbed... URL: