Re: Binary distributability of codeblocks: GPL OpenSSL conflict
[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. (The build is broken on 10.9 and later, but I have no clue how to fix it.) A while ago it was apparently distributable – or at least one file exists in http://packages.macports.org/codeblocks/ That was before the boost dependency was added. - Josh Thank you, Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Binary distributability of codeblocks: GPL OpenSSL conflict
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 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Binary distributability of codeblocks: GPL OpenSSL conflict
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: 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. ... 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. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Binary distributability of codeblocks: GPL OpenSSL conflict
Looks like jmr took care of updating the port for me, thanks jmr! On Fri, Jul 11, 2014 at 7:38 PM, Ryan Schmidt ryandes...@macports.org wrote: On Jul 11, 2014, at 7:19 AM, Eric Gallager eg...@gwmail.gwu.edu wrote: Right, this just reminded me, I need to update the port-depgraph port to work with MacPorts 2.3+... is there already a newer subversion revision that I could point it at, or would I have to update the actual port-depgraph script myself, too? It doesn't look like the script has been modified since 2011. However, 2.3 compatibility should be easy; see other scripts for the minor changes that need to be made. I have some other changes to depgraph that I need to commit too... ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Binary distributability of codeblocks: GPL OpenSSL conflict
Right, this just reminded me, I need to update the port-depgraph port to work with MacPorts 2.3+... is there already a newer subversion revision that I could point it at, or would I have to update the actual port-depgraph script myself, too? On Fri, Jul 11, 2014 at 6:48 AM, Ryan Schmidt ryandes...@macports.org wrote: Or if you prefer a more visual representation, install the port-depgraph port. $ port info port-depgraph port-depgraph @0.1.0 (sysutils, macports) Description: Run a recursive dependency listing against a given port, outputing a Graphviz graph description. Homepage: http://svn.macports.org/repository/macports/contrib/port-depgraph Fetch Dependencies: subversion Library Dependencies: graphviz Platforms:darwin License: BSD Maintainers: eg...@gwmail.gwu.edu, openmaintai...@macports.org On Jul 10, 2014, at 8:20 PM, Joshua Root j...@macports.org wrote: port rdeps On 2014-7-11 10:15 , David Strubbe wrote: Is there a simple way to determine the sequence of dependencies, like ffmpeg-gnutls-nettle-openssl ? David On Thu, Jul 10, 2014 at 6:51 PM, David Evans dev...@macports.org mailto:dev...@macports.org wrote: On 7/10/14 3:18 PM, Mojca Miklavec wrote: Actually, something similar is true for ffmpeg as well: ffmpeg is not distributable because its license gpl conflicts with license OpenSSL of dependency openssl ffmpeg-gnutls-nettle-openssl ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Binary distributability of codeblocks: GPL OpenSSL conflict
On Jul 11, 2014, at 7:19 AM, Eric Gallager eg...@gwmail.gwu.edu wrote: Right, this just reminded me, I need to update the port-depgraph port to work with MacPorts 2.3+... is there already a newer subversion revision that I could point it at, or would I have to update the actual port-depgraph script myself, too? It doesn't look like the script has been modified since 2011. However, 2.3 compatibility should be easy; see other scripts for the minor changes that need to be made. I have some other changes to depgraph that I need to commit too... ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Binary distributability of codeblocks: GPL OpenSSL conflict
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. A while ago it was apparently distributable – or at least one file exists in http://packages.macports.org/codeblocks/ Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Binary distributability of codeblocks: GPL OpenSSL conflict
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. A while ago it was apparently distributable – or at least one file exists in http://packages.macports.org/codeblocks/ That was before the boost dependency was added. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Binary distributability of codeblocks: GPL OpenSSL conflict
On Thu, Jul 10, 2014 at 8:52 PM, 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. A while ago it was apparently distributable – or at least one file exists in http://packages.macports.org/codeblocks/ Actually, something similar is true for ffmpeg as well: ffmpeg is not distributable because its license gpl conflicts with license OpenSSL of dependency openssl http://packages.macports.org/ffmpeg/ Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Binary distributability of codeblocks: GPL OpenSSL conflict
On 7/10/14 3:18 PM, Mojca Miklavec wrote: Actually, something similar is true for ffmpeg as well: ffmpeg is not distributable because its license gpl conflicts with license OpenSSL of dependency openssl ffmpeg-gnutls-nettle-openssl ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Binary distributability of codeblocks: GPL OpenSSL conflict
Is there a simple way to determine the sequence of dependencies, like ffmpeg-gnutls-nettle-openssl ? David On Thu, Jul 10, 2014 at 6:51 PM, David Evans dev...@macports.org wrote: On 7/10/14 3:18 PM, Mojca Miklavec wrote: Actually, something similar is true for ffmpeg as well: ffmpeg is not distributable because its license gpl conflicts with license OpenSSL of dependency openssl ffmpeg-gnutls-nettle-openssl ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Binary distributability of codeblocks: GPL OpenSSL conflict
port rdeps On 2014-7-11 10:15 , David Strubbe wrote: Is there a simple way to determine the sequence of dependencies, like ffmpeg-gnutls-nettle-openssl ? David On Thu, Jul 10, 2014 at 6:51 PM, David Evans dev...@macports.org mailto:dev...@macports.org wrote: On 7/10/14 3:18 PM, Mojca Miklavec wrote: Actually, something similar is true for ffmpeg as well: ffmpeg is not distributable because its license gpl conflicts with license OpenSSL of dependency openssl ffmpeg-gnutls-nettle-openssl ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
