[OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]

[Andre McCurdy]

On Thu, Aug 13, 2015 at 1:42 AM, Philip Balister <philip at 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.burton at intel.com> wrote:
>>>
>>> On 11 August 2015 at 16:46, Khem Raj <raj.khem at 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 at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core