date:20230928

Re: [sword-devel] Licensing audit of SWORD for Fedora - sharing results with upstream

2023-09-28 Thread Fr Cyrille

Le 28/09/2023 à 18:13, Aaron Rainbolt a écrit :

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

Dear Aaron,
What a magnificent proposal this is!! I have been lamenting to the Lord
for months, seeing Xiphos stagnate... and risking disappearing.
Personally I am under Ubuntu.
At the beginning of the year I asked the Lord in my prayer to give us
developers for Xiphos, you could be the answer to this prayer. If Karl
could react to your proposal that would be great.

I will follow this proposal with great interest.

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,

[sword-devel] [PATCH] Migrate setup.py files from using distutils to using setuptools

2023-09-28 Thread Aaron Rainbolt


Good morning/evening, and thanks for your time.

As distutils has been deprecated and finally removed in Python 3.12, 
SWORD is unable to build in Fedora without the following patch. The patch:


* Replaces all references to distutils with their setuptools equivalents.

* Modifies the build system to allow specifying a new CMake argument, 
"SWORD_PYTHON_INSTALL_ROOT", which allows setting the installation path 
for the Python bindings without generating a Python egg. (This is 
necessary since Python eggs have been deprecated as well and will likely 
be removed later. See https://github.com/pypa/setuptools/issues/3143 - 
specifying both a --root and a --prefix to the setup.py scripts seems to 
work around this issue.)


All contributions in this patch are made available to the SWORD Project 
under the terms of the GNU General Public License version 2.


Thanks for your consideration, and have a blessed day!

Aaron

(P.S. - the reason this appears to be a Git patch is because I used Git 
to let me generate a multi-file patch more easily. I realize SWORD uses 
SVN, sorry if this looks confusing.)




From 07b31a74ea920077fa0d69cdab2ab188dd17b322 Mon Sep 17 00:00:00 2001
From: Aaron Rainbolt 
Date: Wed, 27 Sep 2023 10:51:27 -0600
Subject: [PATCH] Migrate to setuptools

---
 bindings/swig/oldmake/Makefile.am   | 2 +-
 bindings/swig/package/Makefile.am   | 3 +--
 bindings/swig/package/Makefile.in   | 3 +--
 bindings/swig/python/CMakeLists.txt | 7 +--
 4 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/bindings/swig/oldmake/Makefile.am 
b/bindings/swig/oldmake/Makefile.am

index 45a37ef..789813b 100644
--- a/bindings/swig/oldmake/Makefile.am
+++ b/bindings/swig/oldmake/Makefile.am
@@ -76,7 +76,7 @@ python_makebuild: $(PYTHONSWIG)
 echo "writing python/setup.py"
 @echo "#! /usr/bin/python" > python/setup.py
 @echo "" >> python/setup.py
-    @echo "from distutils.core import setup, Extension" >> python/setup.py
+    @echo "from setuptools import setup, Extension" >> python/setup.py
 @echo "setup (name = \"sword\"," >> python/setup.py
 @echo "    version = \"$(VERSION)\"," >> python/setup.py
 @echo "    maintainer = \"Sword Developers\"," >> python/setup.py
diff --git a/bindings/swig/package/Makefile.am 
b/bindings/swig/package/Makefile.am

index 14500c3..f44974d 100644
--- a/bindings/swig/package/Makefile.am
+++ b/bindings/swig/package/Makefile.am
@@ -84,8 +84,7 @@ python_makebuild: $(PYTHONSWIG)
 echo "writing python/setup.py"
 @echo "#! /usr/bin/python" > python/setup.py
 @echo "" >> python/setup.py
-    @echo "from distutils.core import setup" >> python/setup.py
-    @echo "from distutils.extension import Extension" >> python/setup.py
+    @echo "from setuptools import setup, Extension" >> python/setup.py
 @echo "import commands" >> python/setup.py
 @echo "" >> python/setup.py
 @echo "def pkgconfig(*packages, **kw):" >> python/setup.py
diff --git a/bindings/swig/package/Makefile.in 
b/bindings/swig/package/Makefile.in

index b5f05c9..370a9e7 100644
--- a/bindings/swig/package/Makefile.in
+++ b/bindings/swig/package/Makefile.in
@@ -938,8 +938,7 @@ python_makebuild: $(PYTHONSWIG)
 echo "writing python/setup.py"
 @echo "#! /usr/bin/python" > python/setup.py
 @echo "" >> python/setup.py
-    @echo "from distutils.core import setup" >> python/setup.py
-    @echo "from distutils.extension import Extension" >> python/setup.py
+    @echo "from setuptools import setup, Extension" >> python/setup.py
 @echo "import commands" >> python/setup.py
 @echo "" >> python/setup.py
 @echo "def pkgconfig(*packages, **kw):" >> python/setup.py
diff --git a/bindings/swig/python/CMakeLists.txt 
b/bindings/swig/python/CMakeLists.txt

index cbb4058..247bc79 100644
--- a/bindings/swig/python/CMakeLists.txt
+++ b/bindings/swig/python/CMakeLists.txt
@@ -25,7 +25,7 @@ ENDIF(NOT PYTHONLIBS_FOUND)

 SET(PY_SCRIPT "#!${PYTHON_EXECUTABLE}

-from distutils.core import setup, Extension
+from setuptools import setup, Extension
 setup(
 name='sword',
 version='${SWORD_VERSION}',
@@ -51,8 +51,11 @@ 
ADD_CUSTOM_TARGET(swordswig_python${SWORD_PYTHON_VERSION} ALL

 WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}")

 # Allow user installation to custom directory
+IF(NOT SWORD_PYTHON_INSTALL_ROOT STREQUAL "")
+    SET(SETUP_ARGS "\"--root=${SWORD_PYTHON_INSTALL_ROOT}\"")
+ENDIF(NOT SWORD_PYTHON_INSTALL_ROOT STREQUAL "")
 IF(NOT SWORD_PYTHON_INSTALL_DIR STREQUAL "")
-    SET(SETUP_ARGS "\"--prefix=${SWORD_PYTHON_INSTALL_DIR}\"")
+    SET(SETUP_ARGS "${SETUP_ARGS}\"--prefix=${SWORD_PYTHON_INSTALL_DIR}\"")
 ENDIF(NOT SWORD_PYTHON_INSTALL_DIR STREQUAL "")
 CONFIGURE_FILE("${CMAKE_CURRENT_SOURCE_DIR}/install.cmake.in"
    "${CMAKE_CURRENT_BINARY_DIR}/install.cmake")
--
2.41.0

___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to

Re: [sword-devel] Licensing audit of SWORD for Fedora - sharing results with upstream

2023-09-28 Thread Aaron Rainbolt

On 9/28/23 11:29, Greg Hellings wrote:

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

https://svn.filezilla-project.org/filezilla/FileZilla3/trunk/src/engine/directorylistingparser.cpp?revision=10945=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

I'm

Re: [sword-devel] Licensing audit of SWORD for Fedora - sharing results with upstream

2023-09-28 Thread Greg Hellings

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

Re: [sword-devel] Licensing audit of SWORD for Fedora - sharing results with upstream

2023-09-28 Thread Aaron Rainbolt

Hey, thanks for your help!

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

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.

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.

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.

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

Re: [sword-devel] Licensing audit of SWORD for Fedora - sharing results with upstream

2023-09-28 Thread Greg Hellings

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

Re: [sword-devel] Licensing audit of SWORD for Fedora - sharing results with upstream

[sword-devel] [PATCH] Migrate setup.py files from using distutils to using setuptools

Re: [sword-devel] Licensing audit of SWORD for Fedora - sharing results with upstream

Re: [sword-devel] Licensing audit of SWORD for Fedora - sharing results with upstream

Re: [sword-devel] Licensing audit of SWORD for Fedora - sharing results with upstream

Re: [sword-devel] Licensing audit of SWORD for Fedora - sharing results with upstream

6 matches

Site Navigation

Mail list logo

Footer information