linux-kernel - Re: Forked android kernel development from linux kernel mainline

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTimFkdArTMscJOiPf-YwKaEKsq59XM_u4Twes4PP@mail.gmail.com>
Date:	Mon, 15 Nov 2010 22:23:29 -0800
From:	Brian Swetland <swetland@...gle.com>
To:	Stefan Monnier <monnier@....umontreal.ca>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Forked android kernel development from linux kernel mainline

On Mon, Nov 15, 2010 at 9:34 AM, Stefan Monnier
<monnier@....umontreal.ca> wrote:
>> Just a small comment to say that Android is not the only one (but
>> certainly the most visible, and thus easiest to bash on) not making
>> effort to get their stuff in mainline.
>
> It's not only that.  But Android in general is also a very poor citizen
> w.r.t Free Software since it tends to be distributed in closed form for
> devices that only work if you add proprietary code, and it supports
> DRM-style nightmares.

We release the userspace and kernel work we do under Apache2/BSD/MIT
and GPLv2 respectively.

We have always insisted on only GPLv2 code for kernel drivers, and
have never supported binary loadable kernel drivers.

We typically have to deal with some proprietary userspace libraries
(opengl es 2 libraries are a typical example), though we've been
working to reduce the number from release to release.  This is an
artifact of the current SoC offerings more than any policy we have --
we much prefer entirely open solutions and actively pursue them
whenever possible.

I'm not sure what DRM-style nightmares we're talking about -- last I
looked, the stock Android platform doesn't have any DRM support of any
sort built-in.

We certainly can't demand that every OEM work this way, but so it goes.

> It's not as dangerous to Free Software as the iphone, tho.

Whew!

>> OpenWRT people are also maintaining their fork of the kernel, without
>> even using git, and not contributing much to mainline (I'm certainly
>> mistaken on that last comment).
>
> I can assure you that the contributions are as frequent, important, and
> significant as the OpenWRT can muster: they have very limited resources,
> which is the main limitation.  But also because of those limited
> resources, it's in their best interest to get things upstream.
>
> Android is different since the company behind it made a conscious
> decision to fork even though they have/had the resources necessary to
> push their changes upstream.

I view it more as we made a decision to ship (and enable others to
ship) successful products as priority one, while still making the
source available (as is required, or in some cases not required).

I am always intrigued that everyone is an expert in our resource
availability.  Apparently my team has a bunch of engineers loafing
around when they could be contributing patches upstream!  Or, maybe,
we're also a very busy bunch of people supporting multiple SoCs,
multiple hardware platforms, multiple releases, who also send code
upstream from time to time, but clearly not as much or as often as
people would like (including ourselves).

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/