On Wed, 6 Nov 2019 at 12:42, Markus Armbruster <arm...@redhat.com> wrote: > > Markus Armbruster <arm...@redhat.com> writes: > > > Alex Bennée <alex.ben...@linaro.org> writes: > > > >> Markus Armbruster <arm...@redhat.com> writes: > >> > >>> I hate to interfere with the merging of working code for non-technical > >>> reasons.... > >>> > >>> This is a plugin interface. As I wrote in reply to v4, I'd like to see > >>> a pragmatic argument why abuse of the plugin interface to circumvent the > >>> GPL is not practical. This might include "not a stable interface", "you > >>> have to link with a truckload of gpl code", "the set of things you can > >>> do is deliberately extremely limited". > [...] > >>> If merging this could be delayed until the licensing ramifications have > >>> become a bit more clear, I'd be obliged. > >> > >> I'd rather not unless we can make an exception for late merging of the > >> PR. I've worked quite hard to make sure everything is ready for the 4.2 > >> window and I'd rather not miss a whole release cycle on a > >> misunderstanding of what these plugins allow. > > > > I think there are multiple ways to avoid the nuclear outcome. > > > > Coming to a conclusion before the soft freeze is the nicest one. > > > > Making an exception for late merging is another one, but Peter may > > prefer not to. > > > > Yet another one is merging the pull request before the soft freeze with > > the understanding that it'll be reverted unless we come to a positive > > conclusion before say -rc0 (Nov 5). I'm confident we can work it out in > > Lyon. > > The series has since been merged, so just for the record: we did. The > plugin interface looks useful for its stated purposes, yet pretty > useless for GPL circumvention. We'll evolve it deliberately to preserve > that property.
The one specific thing that did come out of discussions at Lyon was that we'd like to have a basic "check the version" to catch mismatched/out-of-date plugins; Alex has a patch on list for that. thanks -- PMM
