Binary distributability of codeblocks: GPL & OpenSSL conflict

[Joshua Root]

On 2015-5-4 19:47 , Mojca Miklavec wrote:
> [waking the thread from the dead]
> 
> On Fri, Jul 11, 2014 at 12:14 AM, Joshua Root wrote:
>> On 2014-7-11 04:52 , Mojca Miklavec wrote:
>>> Hi,
>>>
>>> I would like to ask if there is any chance to make Code::Blocks
>>> distributable and what would have to be done.
>>>
>>>> /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/base/portmgr/jobs/port_binary_distributable.tcl -v codeblocks
>>>
>>> "codeblocks" is not distributable because its license "gpl" conflicts
>>> with license "OpenSSL" of dependency "openssl"
>>>
>>> Codeblocks depends on boost which further depends on openssl.
>>
>> Not quite, boost depends on python27 which depends on openssl.
>>
>> Check if codeblocks is linked against the boost libs that use python,
>> and also check if the boost python libs use any of python's SSL-using
>> modules. If not, you can add 'license_noconflict boost' to codeblocks.
> 
> I'm probably blind, but I'm unable to find *any* library that would
> even link against boost.
> 
> The headers are used in NassiShneiderman, but
>     otool -L /opt/local/lib/codeblocks/plugins/libNassiShneiderman.so
> doesn't shouw any link against boost. I also don't see anything trying
> to link against boost in Makefiles.
> 
> Just
>     if test "x$BUILD_NASSISHNEIDERMAN_TRUE" = "x" ; then
>       AC_LANG_PUSH([C++])
>         AC_CHECK_HEADER([boost/spirit/include/classic.hpp],[],[AC_MSG_ERROR([...])])
>       AC_LANG_POP([C++])
>     fi
> 
> I'll add 'license_noconflict boost' like you suggested.

Including the headers is the equivalent of copying them into the
program. It quite likely makes the resulting binary a derivative work of
boost, and thus subject to its license.

- Josh