[oe] Per-binary-package LICENSE? and/or dependent on PACKAGECONFIG?

[Daniel F. Dickinson]

Hi all,

I have a question about packages which by default don't ship e.g. LGPL 
code in their binaries, but if a configure option is turned on then the 
package generates examples / test programs that are LGPL (in this case 
due to a shell script from shunit2).

How can you define the LICENSE so that it's correct in each case?

Is it possible to do e.g. LICENSE_ LICENSE_${PN}-examples, etc?

What about making LICENSE contents conditional on PACKAGECONFIG
(for if the offending examples are built)?

Or is it best to not just build the examples and not worry about the 
LGPL source code that's not in the output packages?

Also, I'm planning on a two patches for this package (libubox in 
meta-oe/recipes-devtools); one which corrects the LICENSE (it's actually 
BSD-1-Clause&BSD-3-Clause for the shipped binaries), and another which 
updates to the latest stable release from upstream.  Since this is a new 
ABI version/SOVERSION, should this be built as a separate recipe that 
can exists alongside the older version?  (Not that there are likely many 
users of this library yet; it really is primarily useful for the work 
I'm doing on munging Openwrt packages like procd and netifd which depend 
on ubus and libubox so they are useful outside Openwrt.

In particular I'm interested in procd as a tiny init with 
process-handling (e.g. rewspawn, hotplug, network, and config change 
triggers).

IIRC < 100K for procd stack vs. some # of MB's for systemd (not 
including network).

The real question is whether there is any *modern* *Linux* embedded 
hardware where that's a big deal.  Obviously old routers with 8MB flash 
and 128 MB RAM it matters, but I'm have no insight into how common that 
size of hardware is in any new development.

If not much, then a better road for me would be to deal with UX for 
headless (e.g. network/web) systemd builds.

Regards,

Daniel