[139862] trunk/base/portmgr/jobs/port_binary_distributable.tcl
Ryan Schmidt
ryandesign at macports.org
Mon Aug 31 03:22:51 PDT 2015
On Aug 31, 2015, at 5:19 AM, Joshua Root wrote:
> On 2015-8-31 19:22 , Ryan Schmidt wrote:
>>
>> On Aug 31, 2015, at 4:07 AM, David Evans wrote:
>>
>>> But now I get
>>>
>>> $ port_binary_distributable.tcl -v empathy
>>> "empathy" is not distributable because its license "cc-by-sa" conflicts with license "GPL-2+" of dependency "yelp-tools"
>>>
>>> yelp-tools is a build dependency of empathy. Shouldn't port_binary_distributable.tcl only look at lib deps not build or
>>> run deps when determining binary distributability?
>>
>> It needs to also look at build deps. A build dep might include a static library, for example.
>>
>> Ports like yelp-tools that don't install any libraries should indicate this via the line "installs_libs no"; license checks will then no longer be done for that port.
>
> Also, if only the documentation or other non-code resources are under
> this license, it's likely irrelevant for the purposes of conflict
> checking. A dependent port is unlikely to be generating its
> documentation by taking extracts from a dependency's docs and adding to
> them.
>
> We don't have a good way of indicating this kind of thing currently.
> Often the license for the docs is just left out (not ideal because it
> gives the user an incomplete picture of what licenses apply to the
> installed files), or specified as though there was a choice of licenses,
> e.g. {GPL-3+ CC-BY-SA-4} (which is not really true and could lead to
> incorrect conflict checking in some cases). The other choice is to
> verify manually that there is no conflict (which is what binary distros
> do) and use license_noconflict, as cal mentioned.
This is one of the reasons why I like making documentation a separate (sub)port, so that its license can be separately declared. But many build systems aren't set up to make that easy to do.
More information about the macports-dev
mailing list