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