On Sat, 21 Aug 2021 at 16:46, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
On Sat, 2021-08-21 at 14:17 +0200, Alexander Kanavin wrote:
> Then let’s just go for it. 

It isn't that simple. There are member organisations who care about this and
would not be happy at that approach. We're probably talking a load of meetings
and discussion and a need to provide documentation/solutions and debug issues.
There will be a request to do this with a notice period, probably a couple of
years. I suspect a chunk will fall to me as I'm the only person officially able
to have tasks assigned and nobody else will want to do it. I guess that is why I
end up fixing it as there are other things that need the time more urgently.

Is the following realistic?
- meta-gpl2 is maintained in master builds until the next LTS is out in April 2022
- thereafter it is maintained only in that LTS release, until (at least) April 2024
- if, at that point, someone still has products where the bash problem is not resolved,
it is not unreasonable to ask that they copy the old bash recipe to their private layer
and maintain it there for themselves.
 
> I think there are enough examples on how to make gpl3 free images without it,
> and mbition has a full infotainment build based on recent master with no gpl3
> and no meta-gpl2. It’s doable and highly overdue.

That doesn't solve the bash issue. Yes, it works if you can remove any bash
script from your target image.

I suspect the problem becomes easier once member organizations enforce no-gpl
only for the images that ship to customers with the HW. Test and developer images that never leave
the organization or its subcontractors (that can reflash the target HW) can do as they please.

Alex