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

[Aaron Rainbolt]

I believe I do understand, and think that we have a good plan. Some 
users can't or don't want to use distro packages and want newer 
software, so your upstream repo would be helpful for them. Other users 
can't or don't want to use upstream third-party repos and want distro 
version upgrades to be more likely to work, and so the distro packages 
(which you would not be expected to help maintain) would be helpful for 
them. I don't see any reason why we shouldn't have both. If you'd like, 
I might even be able to help with packaging for the upstream repos.


(If it's any consolation, users will oftentimes go and get upstream 
packages and then come to distro package maintainers for help, so I get 
the frustration of users seeking support from the wrong places :P)


Aaron

On 10/6/23 03:12, Jaak Ristioja wrote:
Please understand, that we might nevertheless decide to host our own 
Fedora repository for BibleTime as well.


BibleTime developers are not responsible for packages we did not 
create ourselves, but when issues with these packages arise many users 
still complain directly to us. Oftentimes they just ask for some newer 
version of BibleTime to be packaged for their platform. Many 
distributions also have restrictive packaging policies which prevent 
introducing new (major) versions of packages to stable distribution 
versions. Hosting our own repositories might help in that regard and 
we would also not be tied to having to support older versions of 
BibleTime we no longer can or wish to support. We have very limited 
resources and can't afford to manage BibleTime within distribution 
repositories.


On 06.10.23 09:58, Aaron Rainbolt wrote:

No worries there, I would be doing all the work of managing BibleTime
within the Fedora repositories, the devs wouldn't have to do extra
work for that to happen.

If the BibleTime developers are interested in hosting their own repos
for other distros, that's certainly their option (and a good idea in
my opinion), however having BibleTime directly in distribution repos
will obviously make it easier for end-users to install and use it, so
I'd like to make that happen by maintaining the package in Fedora. (I
also have experience with Debian packaging so if the current Debian
maintainer gives up on it, I might be able to help there too.)

On Fri, Oct 6, 2023 at 1:42 AM Jaak Ristioja  wrote:


Hi,

On 05.10.23 20:59, Aaron Rainbolt wrote:
Thanks! If all of the comaintainers for Xiphos and BibleTime are 
also no
longer available or interested, I think it would be helpful if you 
could

go into https://src.fedoraproject.org/rpms/xiphos and
https://src.fedoraproject.org/rpms/bibletime and click the "Orphan"
button on those. I'll take them once that's done and should be able to
help keep them maintained.


BibleTime would be interested in hosting their own package repositories
for different distributions and their versions, which would be updated
by the CI (see [1]) and perhaps be of low maintenance burden. We don't
have the resources to commit to managing BibleTime packages under the
umbrella of different distros.

Best regards,
J


[1]: https://github.com/bibletime/bibletime/issues/258
___
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

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

[Jaak Ristioja]

I apologize for leading this thread off-topic. I suggest the discussion 
on creating a repository for BibleTime to continue under the respective 
GitHub issue: https://github.com/bibletime/bibletime/issues/258


On 06.10.23 19:27, Fr Cyrille wrote:
For Ubuntu, there's already a ppa for Crosswire. It would be coherent 
for us to put everything together on this ppa: 
https://launchpad.net/~pkgcrosswire/+archive/ubuntu/ppa. You'd need to 
have full access rights, which I do, but I can't do it for you - you'd 
have to ask DImitri: https://launchpad.net/~xnox


Le 06/10/2023 à 10:12, Jaak Ristioja a écrit :
Please understand, that we might nevertheless decide to host our own 
Fedora repository for BibleTime as well.


BibleTime developers are not responsible for packages we did not 
create ourselves, but when issues with these packages arise many users 
still complain directly to us. Oftentimes they just ask for some newer 
version of BibleTime to be packaged for their platform. Many 
distributions also have restrictive packaging policies which prevent 
introducing new (major) versions of packages to stable distribution 
versions. Hosting our own repositories might help in that regard and 
we would also not be tied to having to support older versions of 
BibleTime we no longer can or wish to support. We have very limited 
resources and can't afford to manage BibleTime within distribution 
repositories.


On 06.10.23 09:58, Aaron Rainbolt wrote:

No worries there, I would be doing all the work of managing BibleTime
within the Fedora repositories, the devs wouldn't have to do extra
work for that to happen.

If the BibleTime developers are interested in hosting their own repos
for other distros, that's certainly their option (and a good idea in
my opinion), however having BibleTime directly in distribution repos
will obviously make it easier for end-users to install and use it, so
I'd like to make that happen by maintaining the package in Fedora. (I
also have experience with Debian packaging so if the current Debian
maintainer gives up on it, I might be able to help there too.)

On Fri, Oct 6, 2023 at 1:42 AM Jaak Ristioja  wrote:


Hi,

On 05.10.23 20:59, Aaron Rainbolt wrote:
Thanks! If all of the comaintainers for Xiphos and BibleTime are 
also no
longer available or interested, I think it would be helpful if you 
could

go into https://src.fedoraproject.org/rpms/xiphos and
https://src.fedoraproject.org/rpms/bibletime and click the "Orphan"
button on those. I'll take them once that's done and should be able to
help keep them maintained.


BibleTime would be interested in hosting their own package repositories
for different distributions and their versions, which would be updated
by the CI (see [1]) and perhaps be of low maintenance burden. We don't
have the resources to commit to managing BibleTime packages under the
umbrella of different distros.

Best regards,
J


[1]: https://github.com/bibletime/bibletime/issues/258
___
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

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

[Fr Cyrille]

For Ubuntu, there's already a ppa for Crosswire. It would be coherent 
for us to put everything together on this ppa: 
https://launchpad.net/~pkgcrosswire/+archive/ubuntu/ppa. You'd need to 
have full access rights, which I do, but I can't do it for you - you'd 
have to ask DImitri: https://launchpad.net/~xnox


Le 06/10/2023 à 10:12, Jaak Ristioja a écrit :
Please understand, that we might nevertheless decide to host our own 
Fedora repository for BibleTime as well.


BibleTime developers are not responsible for packages we did not 
create ourselves, but when issues with these packages arise many users 
still complain directly to us. Oftentimes they just ask for some newer 
version of BibleTime to be packaged for their platform. Many 
distributions also have restrictive packaging policies which prevent 
introducing new (major) versions of packages to stable distribution 
versions. Hosting our own repositories might help in that regard and 
we would also not be tied to having to support older versions of 
BibleTime we no longer can or wish to support. We have very limited 
resources and can't afford to manage BibleTime within distribution 
repositories.


On 06.10.23 09:58, Aaron Rainbolt wrote:

No worries there, I would be doing all the work of managing BibleTime
within the Fedora repositories, the devs wouldn't have to do extra
work for that to happen.

If the BibleTime developers are interested in hosting their own repos
for other distros, that's certainly their option (and a good idea in
my opinion), however having BibleTime directly in distribution repos
will obviously make it easier for end-users to install and use it, so
I'd like to make that happen by maintaining the package in Fedora. (I
also have experience with Debian packaging so if the current Debian
maintainer gives up on it, I might be able to help there too.)

On Fri, Oct 6, 2023 at 1:42 AM Jaak Ristioja  wrote:


Hi,

On 05.10.23 20:59, Aaron Rainbolt wrote:
Thanks! If all of the comaintainers for Xiphos and BibleTime are 
also no
longer available or interested, I think it would be helpful if you 
could

go into https://src.fedoraproject.org/rpms/xiphos and
https://src.fedoraproject.org/rpms/bibletime and click the "Orphan"
button on those. I'll take them once that's done and should be able to
help keep them maintained.


BibleTime would be interested in hosting their own package repositories
for different distributions and their versions, which would be updated
by the CI (see [1]) and perhaps be of low maintenance burden. We don't
have the resources to commit to managing BibleTime packages under the
umbrella of different distros.

Best regards,
J


[1]: https://github.com/bibletime/bibletime/issues/258
___
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

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

[Jaak Ristioja]

Please understand, that we might nevertheless decide to host our own 
Fedora repository for BibleTime as well.


BibleTime developers are not responsible for packages we did not create 
ourselves, but when issues with these packages arise many users still 
complain directly to us. Oftentimes they just ask for some newer version 
of BibleTime to be packaged for their platform. Many distributions also 
have restrictive packaging policies which prevent introducing new 
(major) versions of packages to stable distribution versions. Hosting 
our own repositories might help in that regard and we would also not be 
tied to having to support older versions of BibleTime we no longer can 
or wish to support. We have very limited resources and can't afford to 
manage BibleTime within distribution repositories.


On 06.10.23 09:58, Aaron Rainbolt wrote:

No worries there, I would be doing all the work of managing BibleTime
within the Fedora repositories, the devs wouldn't have to do extra
work for that to happen.

If the BibleTime developers are interested in hosting their own repos
for other distros, that's certainly their option (and a good idea in
my opinion), however having BibleTime directly in distribution repos
will obviously make it easier for end-users to install and use it, so
I'd like to make that happen by maintaining the package in Fedora. (I
also have experience with Debian packaging so if the current Debian
maintainer gives up on it, I might be able to help there too.)

On Fri, Oct 6, 2023 at 1:42 AM Jaak Ristioja  wrote:


Hi,

On 05.10.23 20:59, Aaron Rainbolt wrote:

Thanks! If all of the comaintainers for Xiphos and BibleTime are also no
longer available or interested, I think it would be helpful if you could
go into https://src.fedoraproject.org/rpms/xiphos and
https://src.fedoraproject.org/rpms/bibletime and click the "Orphan"
button on those. I'll take them once that's done and should be able to
help keep them maintained.


BibleTime would be interested in hosting their own package repositories
for different distributions and their versions, which would be updated
by the CI (see [1]) and perhaps be of low maintenance burden. We don't
have the resources to commit to managing BibleTime packages under the
umbrella of different distros.

Best regards,
J


[1]: https://github.com/bibletime/bibletime/issues/258
___
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

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

[Aaron Rainbolt]

No worries there, I would be doing all the work of managing BibleTime
within the Fedora repositories, the devs wouldn't have to do extra
work for that to happen.

If the BibleTime developers are interested in hosting their own repos
for other distros, that's certainly their option (and a good idea in
my opinion), however having BibleTime directly in distribution repos
will obviously make it easier for end-users to install and use it, so
I'd like to make that happen by maintaining the package in Fedora. (I
also have experience with Debian packaging so if the current Debian
maintainer gives up on it, I might be able to help there too.)

On Fri, Oct 6, 2023 at 1:42 AM Jaak Ristioja  wrote:
>
> Hi,
>
> On 05.10.23 20:59, Aaron Rainbolt wrote:
> > Thanks! If all of the comaintainers for Xiphos and BibleTime are also no
> > longer available or interested, I think it would be helpful if you could
> > go into https://src.fedoraproject.org/rpms/xiphos and
> > https://src.fedoraproject.org/rpms/bibletime and click the "Orphan"
> > button on those. I'll take them once that's done and should be able to
> > help keep them maintained.
>
> BibleTime would be interested in hosting their own package repositories
> for different distributions and their versions, which would be updated
> by the CI (see [1]) and perhaps be of low maintenance burden. We don't
> have the resources to commit to managing BibleTime packages under the
> umbrella of different distros.
>
> Best regards,
> J
>
>
> [1]: https://github.com/bibletime/bibletime/issues/258
> ___
> 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

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

[Jaak Ristioja]

Hi,

On 05.10.23 20:59, Aaron Rainbolt wrote:
Thanks! If all of the comaintainers for Xiphos and BibleTime are also no 
longer available or interested, I think it would be helpful if you could 
go into https://src.fedoraproject.org/rpms/xiphos and 
https://src.fedoraproject.org/rpms/bibletime and click the "Orphan" 
button on those. I'll take them once that's done and should be able to 
help keep them maintained.


BibleTime would be interested in hosting their own package repositories 
for different distributions and their versions, which would be updated 
by the CI (see [1]) and perhaps be of low maintenance burden. We don't 
have the resources to commit to managing BibleTime packages under the 
umbrella of different distros.


Best regards,
J


[1]: https://github.com/bibletime/bibletime/issues/258
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

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

[Aaron Rainbolt]

On 10/5/23 13:06, Greg Hellings wrote:

I've gone ahead and directly added you as an admin on the two projects.

Thank you so much!


On Thu, Oct 5, 2023 at 1:00 PM Aaron Rainbolt  
wrote:


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

Thanks! If all of the comaintainers for Xiphos and BibleTime are
also no
longer available or interested, I think it would be helpful if you
could
go into https://src.fedoraproject.org/rpms/xiphos and
https://src.fedoraproject.org/rpms/bibletime and click the "Orphan"
button on those. I'll take them once that's done and should be
able to
help keep them maintained.

Thanks for all your help, and God bless!

Aaron

>
> --Greg
>
>
>     God bless, and thanks again.
>
>     Aaron
>
>     On 9/28/23 07:05, Greg Hellings wrote:
>     > Aaron,
>     >
>     > As the previous maintainer 

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

[Greg Hellings]

I've gone ahead and directly added you as an admin on the two projects.

On Thu, Oct 5, 2023 at 1:00 PM Aaron Rainbolt  wrote:

> 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).
> >
> >
> > 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
> > <
> 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.
>
> Thanks! If all of the comaintainers for Xiphos and BibleTime are also no
> longer available or interested, I think it would be helpful if you could
> go into https://src.fedoraproject.org/rpms/xiphos and
> https://src.fedoraproject.org/rpms/bibletime and click the "Orphan"
> button on those. I'll take them once that's done and should be able to
> help keep them maintained.
>
> Thanks for all your help, and God bless!
>
> Aaron
>
> >
> > --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
> 

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

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



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.


Thanks! If all of the comaintainers for Xiphos and BibleTime are also no 
longer available or interested, I think it would be helpful if you could 
go into https://src.fedoraproject.org/rpms/xiphos and 
https://src.fedoraproject.org/rpms/bibletime and click the "Orphan" 
button on those. I'll take them once that's done and should be able to 
help keep them maintained.


Thanks for all your help, and God bless!

Aaron



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

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

[Fr Cyrille]

Le 01/10/2023 à 08:59, Aaron Rainbolt a écrit :

On 9/28/23 13:35, Fr Cyrille wrote:



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.


I actually know C and C++, so I might be able to help there. If I have 
some spare time and am itching to code, I'll fiddle with it and see if 
I can implement requested features and fix bugs.


Also I used to be an Ubuntu Developer, and intend on returning to 
Ubuntu development once work starts on 24.04 LTS. So I may end up 
being able to help accelerate the acceptance of updated SWORD-related 
software into Debian, Ubuntu, and Fedora if, Lord willing, all goes well.


Thanks for the encouragement!


You made my day! God be praised... I will help to with testing, ideas 
(many), compiling... May God send still 2 or 3 dev for it.


Aaron



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 

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

[Aaron Rainbolt]

On 9/28/23 13:35, Fr Cyrille wrote:



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.


I actually know C and C++, so I might be able to help there. If I have 
some spare time and am itching to code, I'll fiddle with it and see if I 
can implement requested features and fix bugs.


Also I used to be an Ubuntu Developer, and intend on returning to Ubuntu 
development once work starts on 24.04 LTS. So I may end up being able to 
help accelerate the acceptance of updated SWORD-related software into 
Debian, Ubuntu, and Fedora if, Lord willing, all goes well.


Thanks for the encouragement!

Aaron



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
  

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

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

    

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

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

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.

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 

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

[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

[Aaron Rainbolt]

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.


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 

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

[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 

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

[Aaron Rainbolt]

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