[sword-devel] Fwd: Licensing audit of SWORD for Fedora - sharing results with upstream
Aaron Rainbolt
arraybolt3 at gmail.com
Fri Sep 29 12:01:43 EDT 2023
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 <arraybolt3 at gmail.com>
To: Greg Hellings <greg.hellings at gmail.com>
On 9/28/23 11:29, Greg Hellings wrote:
>
> On Thu, Sep 28, 2023, 12:14 Aaron Rainbolt <arraybolt3 at 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.
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
> <arraybolt3 at 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 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
>
>
> _______________________________________________
> 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
More information about the sword-devel
mailing list