[Ksummit-discuss] [CORE TOPIC] GPL defense issues

[Mark Brown]

On Tue, Aug 30, 2016 at 05:33:36PM +0200, Arnd Bergmann wrote:
> On Tuesday 30 August 2016, Maxime Ripard wrote:

> > They used to yes. However, even though I don't really how Linaro works
> > internally, my understanding was that being part of Linaro doesn't
> > imply that you have engineers assigned. It's probably related to some
> > level of membership.

> Correct, the higher membership levels require assigning engineers,
> but that doesn't mean these engineers work on upstreaming code
> of that member company, or even working on the kernel.

To be more concrete: the assignees function essentially as contractors
for Linaro.  They're doing Linaro work on free software products and
infrastructure like direct Linaro employees do, they're not working for
the member company but rather for Linaro when they're assignees.

Linaro does also have landing teams for members at higher levels, these
function in the opposite direction and have their work assigned by the
members but there's no requirement that this work be upstreaming or even
kernel related, it is in some cases (eg, a bunch of the Qualcomm and ST
work upstream is being done by Linaro landing teams) but not all.

> We do provide all kinds of help to member companies and engineers
> to learn everything about upstreaming their code and working with
> the communities, and a lot of member companies use that help, but
> other members don't.

Plus the fact some member companies are large enough that they have
several groups working with Linux and in those cases it may only be one
of those groups that's joined Linaro and the SoCs people generally see
may be from another group.

[Specifically in the context of Linaro working on Allwinner SoCs]
> > Anyway, like I was saying, no one from Linaro ever contributed
> > something meaningful (except some cross-tree patches, and the usual
> > "maintainance" patches).

> I'm not surprised at all. Most of the kernel work we do in
> Linaro is intentionally cross-platform (so it benefits all members
> equally), or it is done on those platforms that the members decide
> are important upstream.

Where possible we'll try to use platforms that already work well
upstream rather than trying to do basic upstreaming work.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/ksummit-discuss/attachments/20160830/b0628cb2/attachment.sig>