On Thu, Aug 13, 2015 at 1:42 AM, Philip Balister <phi...@balister.org> wrote: > On 08/11/2015 10:46 PM, Otavio Salvador wrote: >> On Tue, Aug 11, 2015 at 5:36 PM, Burton, Ross <ross.bur...@intel.com> wrote: >>> >>> On 11 August 2015 at 16:46, Khem Raj <raj.k...@gmail.com> wrote: >>>> >>>> can we freeze this thread please. >>> >>> >>> 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? >> >> I think it is a matter of resource usage. >> >> Up to now, the GPLv2 maintenance has not been so hard and thus I would >> say for us to stay as is for now. We should revisit this for every >> release and review if it is time for split it or not. >> > > This would be a good time to remind us who the audience is for the gplv2 > recipes so we understand the amount of manpower behind their maintenance. > > My concern keeping then in core is that the commnunity who uses them > will reduce over time and they will bitrot. If that happens, we should > create a layer for them and remove them from core.
As others have also mentioned, there are certain classes of product (set-top boxes, automotive, medical, etc, etc) where secure boot and signed firmware images are a non-negotiable requirement. I don't see these classes of product going away any time soon, so it's hard to see the overall need for "GPLv3-free" embedded distros reducing. Some forward-thinking companies making these types of products are already switching to OE [1], but I guess the majority are still using legacy build environments and home-grown distros. Since these home-grown distros typically take a "conservative" approach to updating packages, the pain of sticking with older, pre-GPLv3 versions might not be felt very strongly yet. It will inevitably increase over time though and as it does there's going to be a growing number of developers working to maintain pre-GPLv3 versions (or working to switch to replacement packages with more permissive licenses). [1] http://www.slideshare.net/linaroorg/hkg15506-comcast-lessons-learned-from-migrating-the-rdk-code-base-to-the-openembeddedyocto-build-framework > Philip > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core