distributable_lib: only check depends_lib

[mohd-akram]

Checking depends_build results in many false positives due to unrelated build dependencies deep down in a port's dependency tree. License compatibility should only be determined by libraries and not build tools.

Some of the common build dependencies that cause this problem:

• perl (because of gdbm)
• python27 (because of openssl11)
• vala (because of graphviz)

[ryandesign]

It is necessary to check the license of build dependencies too. Build dependencies could also contain libraries (e.g. static libraries or header-only libraries).

Ports that don't install libraries should so indicate using installs_libs no; then their licenses won't be checked.

[mohd-akram]

It is necessary to check the license of build dependencies too. Build dependencies could also contain libraries (e.g. static libraries or header-only libraries).

If a port is using static libraries from another port, then it should be fixed to link dynamically. From what I've seen, projects that use static libraries bundle them as vendored dependencies. As for header-only libraries, I'm not sure how common this is, but a simple fix would be just to put them in depends_lib which in some ways is semantically more correct.

Ports that don't install libraries should so indicate using installs_libs no; then their licenses won't be checked.

I'm not sure that this would work for the examples I put. If some nested dependency uses perl as a build dependency, which depends on gdbm - how do you resolve the license incompatibility between gdbm and the main port? See my comment here for instance. If there's a way to fix this kind of thing, then this PR isn't needed.