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).
Ah, that makes perfect sense to me. I'll send the patch for the Python stuff soon.


    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.
Great, that will probably be the next thing I work on then.


    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.

The only reason I'm reticent to simply say "everything here is GPL2" is because of the following clause in Fedora's policies:

> The License: field is meant to provide a simple enumeration of the licenses found in the source code that are reflected in the binary package. **No further analysis should be done regarding what the "effective" license is, such as analysis based on theories of GPL interpretation or license compatibility or suppositions that “top-level” license files somehow negate different licenses appearing on individual source files.** There is no agreed-upon set of criteria or rules under which one can make conclusions about “effective” licenses or reduce composite license expressions to something simpler.

(From https://docs.fedoraproject.org/en-US/legal/license-field/)

The page goes into further detail, emphasizing that glossing over any license in the project is not allowed, even if the project's "effective" license is something else. As I want everything to go as smoothly as possible, I don't want to say "this file that says it's BSD-3-Clause is really GPLv2" unless there's been actual modifications to the file by SWORD contributors that are undeniably GPLv2 licensed. In that instance, ideally SWORD upstream would include notices on files that were modified in this way to avoid doubt about what files can be used how (since otherwise the file just says "this is BSD licensed" and someone may try to use it as such).

That being said, I guess even if the files were "upgraded", they still came from (and therefore contain some) BSD/BSL/whatever else code, so it's valid to list their licenses in the spec file even if they aren't entirely what they say they are. I can discuss that with the Fedora developers so that everything goes as smoothly as possible.

Aaron



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

Reply via email to