Binary distributability of codeblocks: GPL & OpenSSL conflict
jmr at macports.org
Mon May 4 04:39:58 PDT 2015
On 2015-5-4 21:36 , Joshua Root wrote:
> 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:
>>>> 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.
>> if test "x$BUILD_NASSISHNEIDERMAN_TRUE" = "x" ; then
>> 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.
... which, re-reading the above, isn't really relevant. Yes, it sounds
like license_noconflict would be appropriate. Boost should also move
from depends_lib to depends_build if only its headers are used.
More information about the macports-dev