Fwd: Licensing audit of SWORD for Fedora - sharing results with upstream

Gah, forgot to use Reply List in Thunderbird.



-------- Forwarded Message --------
Subject: 	Re: [sword-devel] Licensing audit of SWORD for Fedora - 
sharing results with upstream
Date: 	Fri, 29 Sep 2023 11:01:12 -0500
From: 	Aaron Rainbolt <[email protected]>
To: 	Greg Hellings <[email protected]>



On 9/28/23 11:29, Greg Hellings wrote:
>
> On Thu, Sep 28, 2023, 12:14 Aaron Rainbolt <[email protected]> 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.

I wrote an implementation of ftpparse that worked for UNIX LIST output 
and seemed to work, but it looks like it will no longer be needed. I 
requested that D. J. Bernstein relicense it to something open-source, 
and this is the result: https://cr.yp.to/distributors.html (see the 
section "What are the distribution terms for ftpparse?") It's now 
public-domain and can be used under any of four different licenses, all 
of which are GPLv2 compatible and three of which are Fedora-compatible. 
So ftpparse is officially no longer a concern.

That was the last hurdle for getting SWORD back into Fedora :D

- Aaron

>
>
> 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
> <[email protected]> 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: [email protected]
> > http://crosswire.org/mailman/listinfo/sword-devel
> >     Instructions to unsubscribe/change your settings at above page
> >
> >
> > _______________________________________________
> > sword-devel mailing list: [email protected]
> > http://crosswire.org/mailman/listinfo/sword-devel
> > Instructions to unsubscribe/change your settings at above page
> _______________________________________________
> sword-devel mailing list: [email protected]
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
>
> _______________________________________________
> sword-devel mailing list: [email protected]
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: [email protected]
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page