This is a terrific project idea, but I agree that it should likely be under the GPL. Even if it is not legally derivative, it would be nice to preserve the GPL.
Sometimes the maximising the likelihood of a set of components being used is more important than potential licensing constraints. In this particular case, if they're not GPL, they're more likely to be used for various *BSD systems and in a variety of embedded contexts.
Improving the general security and reliability of all systems seems like it might potentially be a more valuable goal.
> In this particular case, if they're not GPL, they're more likely to be used for various *BSD systems and in a variety of embedded contexts.
This is a bit of a bugbear. The most common way to use the coreutils is through standard Unix pipes, which does not create a derivative work. I don't know of anyone who has found the copyleft of the coreutils prevents them from doing anything they would like to do. The situation with busybox and Linux is different, as the coupling there was much tighter, and without it we would not have OpenWrt.
I understand and agree with your particular assertions about copyleft and unix pipes, etc. but disagree that it's a "bugbear".
I know from experience some organizations are perfectly willing to contribute changes back upstream on MIT/BSD-licensed components, but avoid GPL components simply because of the additional constraints and potential liability concerns that have to be dealt with. Apple is a perfect example given the additional conditions of the GPLv3.
I'm with you there. Plus, mobile and embedded means lots of stuff gets integrated tightly with hardware. Those people will not risk hardware or interface secrets in firmware being released under GPL. So, having BSD'd stuff for them to use in stuff we have to buy is a nice quality improvement for us. Even Stallman admits it's better for things standardized between proprietary and FOSS like codecs where they surely won't use GPL stuff.
