[sword-devel] SWORD license issues

[Troy A. Griffitts]

Dear Bastian,

Thank you for your email and my apologies for taking so long to get back
with you.  I've been slowing committing changes over the past weeks in
response to your comments.  More response below, inline.

On 11/9/20 12:56 PM, Bastian Germann wrote:
> Hi,
>
> Packaging SWORD 1.9.0 for Debian, I found possible license issues.
>
> The file src/utilfuns/zlib/untgz.c stems from some older zlib release.
> At that state, one could have assumed it to be zlib licensed which is
> not clearly stated in any version of that file. I opened a zlib issue at
> https://github.com/madler/zlib/issues/531 which documents that the
> original author is okay with it being distributed under zlib license.

Thank you for doing the legwork to assure under which the license this
code can be distributed!  As you note below, this file came into SWORD's
repository with the other zlib files, so I can't image we obtained it
from anywhere else but some zlib package or cut from their source
repository.  We may have made some changes before committing to make the
code compile on Windows or WinCE or someplace else (where we initially
needed to pull this code into our repo), making the first commit to our
repository not match exactly any version from the zlib source.


> The SVN revision 283 that introduced that file in Crosswire SVN does not
> match untgz in any released zlib versions. 1.1.3 to 1.2.0.4 are the
> closest. With the sword changes all the file's revisions in the SVN
> violate the following sentence of the zlib license:
> "2. Altered source versions must be plainly marked as such,
>     and must not be misrepresented as being the original software."
>
> There is also one untgz derived file: src/modules/common/zipcomprs.cpp
> This has SWORD's GPL-2 header and is clearly marked as changed.
> However, you cannot find the zlib license info by just looking at that
> file, the files next to it, or the general license info, so this might
> be a violation of: "3. This notice may not be removed or altered from
> any source distribution."

So, yes, this changed in the recent 1.9.0 release.  We no longer need
untgz.c but the relevant functions we do need have been pulled into our
zipcomprs.cpp.  There, per your suggestion, I have updated the header to
reflect what I hope meets the intent from license and discussion.

http://crosswire.org/svn/sword/trunk/src/modules/common/zipcomprs.cpp

(NB: not exactly at the top, but near the top, just above the private
namespace where the untgz functionality is located)


> If SWORD's untgz.c comes from some other source that is even more
> liberal licensed than zlib (public domain equivalent), the previous
> claims might be wrong. But that should be documented clearly in the file
> then. Please note that the issues do not affect binary SWORD distributions.
>
> A general side note: Maybe you want to reconsider (outdated) zlib
> inclusion in the source tree. I understand that this is needed for
> compilation on windows. But there are other means to it, e.g., using the
> vcpkg tool.

Yes, I agree.  Thank you for pointing this out and for the suggestion. 
I have a commit pushed which removes the src/utilfuns/zlib folder and
updates the related files.


>
> Furthermore, some files in the cmake directory miss accompanying
> licenses. At least CMake's 3-clause BSD license, cmake/toolchains's
> 2-clause BSD license, and the Boost Software License have to be included
> in source distributions. The BSD license also applies to binary
> distributions but as that only affects the CMake build, there should not
> be any copies of those files ending up in the binaries.

Greg Hellings is the pumpkin holder for our CMake build system and trust
he will respond accordingly.


> And one other issue shortly mentioned as I did not dive too deep into
> it: The java-jni and cordova bindings are (partly) licensed under
> Apache-2.0 license. They might be derivative works of SWORD. As
> GPL-2-only and Apache-2.0 licenses are incompatible, binary
> distributions of those bindings might be legally problematic for
> non-copyright holders, which can be healed by adding an exception for
> the bindings in SWORD's license. More info on this:
> https://www.apache.org/licenses/GPL-compatibility.html

Yes, I can see how this would pose a problem.  We licensed the bindings
themselves with a less restrictive license, but they access the SWORD
engine in some way which might be considered binary linking.  I suppose
this would effectively render the Apache license moot and overridden by
the GPL if anyone uses the bindings in their own application.  At this
point, I am not sure if we should change the Apache license in the
bindings to GPL or add an except or ???.

License discussions are often a bear to tackle.  While we should resolve
this, I don't believe it would prevent distribution of the bindings
right now, as we release directly the cordova plugin, which also is the
only binary distribution of the java-jni plugin which I know about. 
Thanks for pointing this out and putting it on our mental to-do list.

Thank you so much!  Comments welcome to what we've done thus far,

Troy


>
> Regards,
> Bastian
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page