* Mark Hatle <mark.ha...@windriver.com> [150812 16:50]: > On 8/11/15 3:36 PM, Burton, Ross wrote:
> > Or more usefully, reboot it. Philip, you're turning into Koen! Alex, if > > someone on this list asks what Poky is, 99% of the time they're trolling. > > :) > > The original and unanswered question was "should oe-core continue to > > maintain > > GPLv2 recipes where upstream has moved to GPLv3 or should those recipes > > move to > > a standalone layer" with various implied questions: > > - If the v2 recipes move to a separate layer, who own/maintains/tests it? > > - Should there be v2 recipes for every recipe that has moved to v3, or only > > (as > > is now) the "more-core" recipes (currently YP tests that core-image-base > > builds > > without GPLv3, nothing else more complicated) > > - Should meta-gplv2 only contain recipes from oe-core, or all layers? If > > other > > layers decide to hold both v3 and v2 recipes (not that I'm aware any have), > > what > > makes oe-core special? > > I'm torn, Richard is torn. Neither of those are useful to forming a > > decision. > > Does anyone else have any *useful* feedback? > Not sure how useful, but I can give what I remember as the history behind the > GPLv2 work and my opinion as someone who has a lot of customers who don't want > GPLv3 software on the target. I'm basically agreeing with Mark, as quite often, customers want a non-GPLv3 image (and this is one of the strong selling points during training sessions on OpenEmbedded / Yocto Project, that we have the INCOMPATIBLE_LICENSE option). And having that option, and testing it, requires that we have at least enough for a core-image-minimal to be built and deployed. I'm also using non-GPLv3 builds internally, for the same reasons... >From reading earlier discussions, when recipe updates are proposed, which replaces GPLv2-versions with GPLv3-versions, there usually are a few people complaining (if they notice the change). > Originally when this work was proposed (keeping older GPLv2 software in > oe-core) > the decision was made to keep a small core set of components. Things that the > system wouldn't work without. I.e. coreutils, util-linux, gettext, etc.. I > believe the bar was set just above core-image-minimal. > Anything more then a small (busybox or discrete component) filesystem can > require GPLv3 and at that point it's up to others to figure out how they want > to > deal with it. > So based on the original theory here, parted (GPLv2) is right on the edge of > small system or not. It wasn't originally included because were were not > considering (embedded) systems that would have to be partition at runtime. (I > did much of the original scoping for GPLv2 components... so at least that is > why > I left it off the list.) > (opinion part) That however doesn't mean we have to just reject this as being > out of scope, but I think it does push this more toward the "not part of > oe-core" side of things. Sure, we need to revise that "core" part, and which of the components are required in order to really state that we can support non-GPLv3 builds. Both as SW migrates from GPLv2 -> GPLv3, but also as HW and system changes, as that might make new applications "really core". > As someone who has a lot of customers that need non-GPLv2 components for > various > reasons, I would like an ecosystem for components above and beyond what is > allowed into oe-core for contributed things like this older version of parted, > but not concern is bit-rot. If it's in oe-core, it's (generally) being used > and > tested and we get discussions like this... if it's shifted off into another > layer, that layer needs a maintainer or it's going to fall away. Yep, it's that part, the testing of non-GPLv3 builds that's so attrictive to a lot of potential new-comers. > So I honestly don't want to move any of the existing GPLv2 items out of > oe-core > at this time.. possibly someday, but not now. I have to agree with Mark here; the GPLv2 components in oe-core should really stay in core at this time. (And for quite some time) > Additional (old) GPLv2 versions > really should be able to go somewhere and be shared, but I don't have a good > idea as to "where". This is an opportunity for a new layer to focus on > non-oe-core GPLv2 or possibly a layer as part of meta-openembedded. (I'm not > sure though Martin wants to take on that, even if it turns out to be minimal > additional work.) Sure, a meta-legacy or meta-gplv2 layer for the rest of non-core applications and libraries would likely be a good idea. The main question is as always, can we get enough to help maintain that stuff. > (rant part) > In the end for people who can't use GPLv3 for whatever reason, there really > should be a coordinated effort to either update old versions of software > (GPLv2) > or simply replace the items with BSD/MIT or other appropriately sourced and > licensed code. I just don't see much coordination beyond oe-core (and the > Yocto > Project) for this kind of work -- and the most I'm willing to sign up for is > to > keep what we have functional for as long as my customers need it. Cheers, Anders -- Anders Darander ChargeStorm AB / eStorm AB -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core