Advertisement
GStreamer Conference 2013, 22-23 Oct, Edinburgh
GStreamer, Embedded Linux, Android, VoD, Smooth Streaming, DRM, RTSP, HEVC, PulseAudio, OpenGL. Register now to attend.
Weekly Edition
Return to the Distributions page
| |||||||||||||
Jean-Baptiste Quéru quits AOSP
Jean-Baptiste Quéru, the developer behind the successful development of the
Android Open Source Project, has announced
that he is leaving that project. "There's no point being the
maintainer of an Operating System that can't boot to the home screen on its
flagship device for lack of GPU support, especially when I'm getting the
blame for something that I don't have authority to fix myself and that I
had anticipated and escalated more than 6 months ahead." According
to Android and Me, the new Nexus 7 tablet was the straw that broke
the camel's back.
Many thanks to JBQ for the work he has done for AOSP! (Log in to post comments)
GPL (Jean-Baptiste Quéru quits AOSP) Posted Aug 7, 2013 19:53 UTC (Wed) by simlo (subscriber, #10866) [Link]
I am not into this issue, but as far as I understand it, the missing source is for a Linux _kernel_ driver. And that is a violation of GPL:
You have to ship the full source for the kernel of the device you ship. It does not matter if your kernel is loaded runtime or not - then the kernel should be LGPL, not GPL.
Ok, why can NVIDIA make closed source drivers? Because, it is not shipped on the same device/media as the kernel. You install Linux, then you download and install the closed source driver. It is your own problem. But as far as I can see, you can not sell or give away the the PC without violating GPL!
Same thing with Android devices: As soon they install a closed source driver on the device and sell it, they violate GPL.
Shouldn't someone get this tried as court some day? If it goes on much longer, GPL will loose it's meaning.
GPL (Jean-Baptiste Quéru quits AOSP) Posted Aug 7, 2013 20:31 UTC (Wed) by lkundrak (subscriber, #43452) [Link]
> You have to ship the full source for the kernel of the device you ship. It does not matter if your kernel is loaded runtime or not
What actually matters when GPL-ed and non-free code is distributed together is whether the non-free code is a derivative of GPL-ed code.
While it's probably very unlikely to see a module that is not a derivative of the kernel, is there anything that would make it impossible in principle? (Linus seems to think nvidia and afs modules might not be derivatives [1])
[1] http://yarchive.net/comp/linux/gpl_modules.html
Also, my understanding is that the driver in question is a GPU driver. That would mean the most vital part resides in userspace. Not that it would matter much; the userspace driver does not use standard system calls and thus is likely a derivative of the kernel part and would be subject to GPL if the kernel part were subject to GPL too.
GPL (Jean-Baptiste Quéru quits AOSP) Posted Aug 7, 2013 20:45 UTC (Wed) by simlo (subscriber, #10866) [Link]
> What actually matters when GPL-ed and non-free code is distributed together is whether the non-free code is a derivative of GPL-ed code.
No, the combined work is a derived work and must therefore be GPL as a whole.
> While it's probably very unlikely to see a module that is not a derivative of the kernel
If you just use well defined API, your work is not a derivative. Otherwise, all Java programs would be a derivative of Suns Java. All Linux programs would be be a derivative of libc...
> Also, my understanding is that the driver in question is a GPU driver. That would mean the most vital part resides in userspace. Not that it would matter much; the userspace driver does not use standard system calls and thus is likely a derivative of the kernel part and would be subject to GPL if the kernel part were subject to GPL too.
That is a bit far-fetched. With the explicit exception in the kernel license, a judge would say that any ioctl() is a standeard call.
GPL (Jean-Baptiste Quéru quits AOSP) Posted Aug 8, 2013 0:04 UTC (Thu) by atai (subscriber, #10977) [Link]
>No, the combined work is a derived work and must therefore be GPL as a whole.
Not necessarily. If you somehow make a Windows device driver work under Linux, there is no way you can make the Windows device driver GPL'd (and of course you cannot, since most likely you have no source to the driver)
GPL (Jean-Baptiste Quéru quits AOSP) Posted Aug 8, 2013 0:28 UTC (Thu) by rsidd (subscriber, #2582) [Link]
NDIS drivers for example. They were written for Windows but work on Linux when loaded via a (GPL'd) module. I believe Nvidia too claim that their binary blob is cross-platform and not a Linux derivative, and the shim that loads it is GPL.
GPL (Jean-Baptiste Quéru quits AOSP) Posted Aug 8, 2013 3:51 UTC (Thu) by kevinm (guest, #69913) [Link]
All that you have shown is that you cannot legally ship a work which consists of the Linux kernel together with a non-GPL Windows driver. No-one claims that this "makes the Windows device driver GPL'd" - it is simply a copyright violation of the Linux kernel copyrights.
In this instance it is not the Windows driver itself that is a "derived work" - it is the mooted combined work that consists of the Linux kernel and the Windows driver together as one work. That work is undeniably a derivative of both the Linux kernel *and* the Windows driver, just as if you created a book that included chapters of both Harry Potter and Lord of the Rings that would be a derived work of both sources.
GPL (Jean-Baptiste Quéru quits AOSP) Posted Aug 8, 2013 9:49 UTC (Thu) by Otus (guest, #67685) [Link]
> In this instance it is not the Windows driver itself that is a "derived
> work" - it is the mooted combined work that consists of the Linux kernel > and the Windows driver together as one work. That work is undeniably a > derivative of both the Linux kernel *and* the Windows driver, just as if > you created a book that included chapters of both Harry Potter and Lord of > the Rings that would be a derived work of both sources.
There's a difference between derived works and aggregation. Aggregation is
Depending on how tightly they are tied and using which interfaces, you might
However, IANAL.
GPL (Jean-Baptiste Quéru quits AOSP) Posted Aug 8, 2013 0:34 UTC (Thu) by khim (subscriber, #9252) [Link] What actually matters when GPL-ed and non-free code is distributed together is whether the non-free code is a derivative of GPL-ed code. Derivative or not is not important. When you publish collection of sci-fi works from unrelated authors your compilation is automatically derived from all works includes - and of Alice hates Bob's guts and does not give you permission to include her story under same cover as Bob's story, then that's it: you can not publish such book. The only one thing which protects you from reach of GPL is "mere aggregation" clause. Mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. You can try to play "mere aggregation" clause even with kernel modules (hey, they are more-less programs which run in kernel space, right?), but it's hard to see how it'll work for module which is so essential that without it your device can't even boot!
GPL (Jean-Baptiste Quéru quits AOSP) Posted Aug 9, 2013 2:23 UTC (Fri) by dvdeug (subscriber, #10998) [Link]
That's not what the law says. US Code, Title 17, Section 1 says
A “collective work” is a work, such as a periodical issue, anthology, or encyclopedia, in which a number of contributions, constituting separate and independent works in themselves, are assembled into a collective whole.
A “compilation” is a work formed by the collection and assembling of preexisting materials or of data that are selected, coordinated, or arranged in such a way that the resulting work as a whole constitutes an original work of authorship. The term “compilation” includes collective works.
...
A “derivative work” is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications, which, as a whole, represent an original work of authorship, is a “derivative work”.
It has a whole section "§ 103 . Subject matter of copyright: Compilations and derivative works" that talks about them as two separate things.
GPL (Jean-Baptiste Quéru quits AOSP) Posted Aug 9, 2013 5:54 UTC (Fri) by khim (subscriber, #9252) [Link] You are correct to some extent. I was sloppy. “Compilation work” and “derivative work” are different things, but you can not rely on it: you still need a license even for “compilation work”. And GPL quite explicitly does not talk about “compilation work”, it talks about “mere aggregation”. Now if you can really argue in the court that two halves which are totally useless in the absence of other half comprise “mere aggregation” or not depends on many factors. For example if userspace binary can be used not with Linux but with *BSD, too, and kernel stub only forwards some requests from hardware to userspace and back then your assertion that this is “mere aggregation” will probably work. If driver and userspace are more intertwined then it may be harder to do.
GPL (Jean-Baptiste Quéru quits AOSP) Posted Aug 7, 2013 20:41 UTC (Wed) by arnd (subscriber, #8866) [Link]
No, none of the involved parties would make such a mistake. The GPU driver in question resides in user space and talks to a relatively boring kernel driver that has a GPL compatible license and comes with source code but does not get merged into the mainline kernel because there is no free user space (the Freedreno project is working on changing the last bit).
The same situation exists for almost any other mobile GPU. One can argue that having part of the device driver in user space and another part in the kernel makes one a "derived work" of the other, but the interpretation that all the GPU vendors have apparently picked is that this is covered by the Linux kernel's "normal syscall call" exception.
I have not seen any explanation what the problem for shipping AOSP source is, but I suspect that Qualcomm restricts the distribution of the binary drivers more than the other GPU companies are doing.
GPL (Jean-Baptiste Quéru quits AOSP) Posted Aug 8, 2013 1:08 UTC (Thu) by swetland (subscriber, #63414) [Link]
AOSP source for 4.3 is already available.
Personally, I'd rather have the resource/memory management side of things as open source code in the kernel and the vendor "secret sauce" around commands as a binary in userspace than the alternatives I've seen:
a. link a binary blob with a small open source shim (like the NVIDIA and AMD drivers on desktop linux)
b. map the entire register space of the GPU and possibly large chunks of physical ram into userspace and do all hardware and resource management from their (super scary).
Of course a full open source, performant GPU driver is the ideal to strive towards, but refusing to ship any hardware until it's accomplished has not been a practical path thus far. I hope the future is better.
GPL (Jean-Baptiste Quéru quits AOSP) Posted Aug 8, 2013 5:51 UTC (Thu) by nhippi (subscriber, #34640) [Link]
> Of course a full open source, performant GPU driver is the ideal to strive towards
> but refusing to ship any hardware until it's accomplished has not been a > practical path thus far.
I don't expect google not ship any hardware with binary only drivers. But I would expect google to require from vendor at least "redistributable binaries" before giving a product the Nexus badge.
I don't really understand why mobile GPU vendors (apart from nvidia) fail to provide redistributable binaries. It doesn't stop competitors from reverse engineering anything, as binaries can be lifted from devices anyways.
> I hope the future is better.
We had the same situation of legal and ipr excuses with Wifi drivers. For most chips you had a binary-only driver or worse, used ndiswrapper. But community reverse engineered the drivers and now even the vendors them self commit changes to the reverse engineered free wifi drivers.
So, more community members need to join the reverse engineering GPU drivers effort if we want to see open drivers for those chips.
GPL (Jean-Baptiste Quéru quits AOSP) Posted Aug 8, 2013 9:44 UTC (Thu) by khim (subscriber, #9252) [Link] I don't expect google not ship any hardware with binary only drivers. Liability limitation. Their drivers most likely include hodge-podge of sources of uncertain origin. They really have no idea who actually owns rights for what. But if they only allow shipments of drivers with actual silicone then they can claim that they only ever issued X number of copies (all others are illegal and not their problem), which, in turn, gives them starting point for the damages estimates. This is compounded by another problem: software for embedded components was traditionally considered part of the hardware (that is: it was supplied with silicone and was supposed to be used also only with corresponding silicone by manufacturer) and I'm pretty sure legal clearance of all that mess is just prohibitively expensive because in some cases they just don't know who to ask to give different kind of permission. But community reverse engineered the drivers and now even the vendors them self commit changes to the reverse engineered free wifi drivers. That's right. In most companies engineers are ready and willing to work with open source community and legal department usually allows that - but only for the code produced in-house. Sadly sources for GPU drivers rarely are produced in house and usually have long and convoluted history. NVidia and AMD already had some form of accounting they can/should trust because they distribute Windows drivers (albeit only in binary form).
GPL (Jean-Baptiste Quéru quits AOSP) Posted Aug 8, 2013 11:14 UTC (Thu) by robclark (subscriber, #74945) [Link]
> So, more community members need to join the reverse engineering GPU drivers effort if we want to see open drivers for those chips.
+1
GPL (Jean-Baptiste Quéru quits AOSP) Posted Aug 12, 2013 16:06 UTC (Mon) by Arker (guest, #14205) [Link]
"So, more community members need to join the reverse engineering GPU drivers effort if we want to see open drivers for those chips."
I am honestly not sure that is a good idea. Buying hardware from a manufacturer that refuses to support that hardware properly, then providing the support yourself, may be a good idea in extreme circumstances where no other path is practically possible, but otherwise it should be avoided. Manufacturers that fail to offer a proper product really should not be rewarded with sales.
GPL (Jean-Baptiste Quéru quits AOSP) Posted Aug 12, 2013 16:25 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
That translates as "Don't buy ARM hardware".
GPL (Jean-Baptiste Quéru quits AOSP) Posted Aug 8, 2013 11:13 UTC (Thu) by robclark (subscriber, #74945) [Link]
> Of course a full open source, performant GPU driver is the ideal to strive towards, but refusing to ship any hardware until it's accomplished has not been a practical path thus far. I hope the future is better.
btw, I expect freedreno should be "good enough" at this stage to bring up the UI. I certainly won't claim the performance or functionality matches the binary driver, and I'm sure it would fall down in the face of some advanced game or that sort of thing. But just to bring up the android UI, that should be less demanding. AFAIU the new nexus7 is the same apq8064 SoC that is working reasonably well with freedreno on my nexus4 and ifc6410.
That all said, other than some high level familiarity with android graphics stack, I've not really got the hands-on experience with android (ie. wouldn't know where to start). But if someone who did know the android side of things better wanted to have a go with freedreno, come hang out on #freedreno and I'll do my best to help debug/fix any issues that come up.
GPL (Jean-Baptiste Quéru quits AOSP) Posted Aug 8, 2013 17:30 UTC (Thu) by swetland (subscriber, #63414) [Link]
It would definitely be interesting to take a look. The framework's drawing system makes pretty extensive use of OpenGL ES 2.0 (and now in 4.3 takes advantage of 3.0 features when present), SurfaceFlinger (the compositor) needs applications to be able to render into surfaces that are then treated as textures, synch object support for coordination with the overlay hardware and itself, etc.
I need to check, but I think we have some sample/test code that sits directly on top of hwcomposer and opengl, which should be useful to verify basic interoperation without needing to bring up and debug the entire high level Android stack at the same time.
GPL (Jean-Baptiste Quéru quits AOSP) Posted Aug 8, 2013 17:50 UTC (Thu) by robclark (subscriber, #74945) [Link]
> It would definitely be interesting to take a look. The framework's drawing system makes pretty extensive use of OpenGL ES 2.0 (and now in 4.3 takes advantage of 3.0 features when present), SurfaceFlinger (the compositor) needs applications to be able to render into surfaces that are then treated as textures, synch object support for coordination with the overlay hardware and itself, etc.
As long as there isn't a dependency on ES 3.0 features, that should be ok. I did most of my a320 r/e work on a n4 w/ android 4.2, and didn't have ES 3.0 blob driver... so I haven't really started looking into adding ES 3.0 support yet.
AFAIU, mesa seems to have some support for android. I would *assume* that should be were all the sync pt handling, and communication w/ SF should be. That isn't something that belongs in the individual gallium driver. What I'm not sure about is whether mesa's android EGL bits are updated to work w/ android 4.3, or if there is some work needed there.
Might be a good idea to try to disable hw composition initially, at least then one could rely on the GPU having only a single ring to execute things in the correct order, which could paper over some potential synchronization issues. (Hey, gotta walk before you can run ;-))
GPL (Jean-Baptiste Quéru quits AOSP) Posted Aug 8, 2013 21:20 UTC (Thu) by swetland (subscriber, #63414) [Link]
If you want to poke at the 3.0 stuff, the 4.3 update to the N4 should bring ES 3.0 support in. 3.0 is not a requirement yet (since a number of platforms, like the original N7, still lack 3.0 support).
I'm not sure off the top of my head if the SurfaceFlinger's old pure-software composition is still supported, but I suspect it is. I'm pretty sure it's deprecated though.
You can definitely use a "dumb" hwcomposer hal if you don't have the hw overlay support wired up, and say "sorry, can't compose anything" when the SF asks, and the SF will do the composition itself in GL ES (this is almost always less power/performance efficient).
Multiple contexts will be hard to operate without -- getting to the home screen, for example, can involve four contexts:
GPL (Jean-Baptiste Quéru quits AOSP) Posted Aug 8, 2013 22:15 UTC (Thu) by robclark (subscriber, #74945) [Link]
> If you want to poke at the 3.0 stuff, the 4.3 update to the N4 should bring ES 3.0 support in. 3.0 is not a requirement yet (since a number of platforms, like the original N7, still lack 3.0 support).
Yeah, I was actually attempting to move to 4.3.. (not so much for ES 3.0 features in the short term, but because it should help me figure out a lot more texture and vtx buffer formats)
Sadly not too much luck there so far. Or rather, 4.3 by itself works fine, but I've yet to be able to figure out a commit-id on kernel tree to build my own kernel. If I go by the commit-id mentioned at https://android.googlesource.com/device/lge/mako-kernel (android-4.3_r1 tag), I get a nice endless stream of "ioctl MSMFB_BUFFER_SYNC failed, err=Invalid argument", which seems like kernel/user ABI break/mismatch.
Could be PEBKAC on my part.. I'm not really setup to build full android filesystem, I'm just trying to build the kernel by itself.
> I'm not sure off the top of my head if the SurfaceFlinger's old pure-software composition is still supported, but I suspect it is. I'm pretty sure it's deprecated though.
fwiw, it does look like mesa was updated for android 4.2:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=8b2a967e...
I'm not sure if there are any further changes that would be required for 4.3
> Multiple contexts will be hard to operate without -- getting to the home screen, for example, can involve four contexts:
multiple contexts should be no issue. They still all feed through a single ringbuffer. As opposed to some of the desktop nv stuff which (afaiu) has per-context rb's.
Ok, well, I think qcom was working on emulating this in the kernel, so they could prioritize SF higher, but not sure if that landed in 4.3. Should be easy enough to disable if it did.
GPL (Jean-Baptiste Quéru quits AOSP) Posted Aug 8, 2013 1:03 UTC (Thu) by swetland (subscriber, #63414) [Link]
You are incorrect.
Google has never shipped binary-only kernel drivers for lead or Nexus devices and the 2013 Nexus 7 is no different in that regard. All kernel and kernel driver source code is available. Information on kernel source for such devices is here: http://source.android.com/source/building-kernels.html -- the 2013 N7 wifi device is "flo".
The binaries under discussion are userland libraries (such as the OpenGL library), firmware (such as for the wifi part), etc.
I believe the availability issue for these proprietary binaries and factory images will be resolved in the near future. It's unfortunate that it was not sorted out before launch, but not unprecedented (it took a while to get the N4 binaries made available as well, for example).
Jean-Baptiste Quéru quits AOSP Posted Aug 7, 2013 21:06 UTC (Wed) by karim (subscriber, #114) [Link]
This is huge loss. JBQ was the cornerstone of what we know as "Android". I'm not entirely sure how this loss is going to be compensated for. A tremendous amount of thanks to JBQ for having carried it so far and best of luck to whomever takes his job. Surely there needs to be some soul-searching upstairs on how this unfolded.
Jean-Baptiste Quéru quits AOSP Posted Aug 8, 2013 2:54 UTC (Thu) by aryonoco (subscriber, #55563) [Link]
This is a tremendous loss to AOSP and the Android community. Most people don't understand the major effect that JBQ has had on what we know as Android today, and how much swimming against the tide he's had to do to keep a true open source OS going in the mobile world. It's been a herculean effort.
I've known of JBQ from his time at Be Inc. and BeOS, and he's greatly admired and respected. Best of luck for him in his future endeavours, but I have a feeling that the FOSS community will look back at this day with sadness.
Jean-Baptiste Quéru quits AOSP Posted Aug 8, 2013 10:42 UTC (Thu) by malor (subscriber, #2973) [Link]
Wow, and I was really interested in buying one of these, too.... my sole reservation was in not knowing the overall lock status of the device.
Well, now I know.
JBQ, if you read LWN, thanks much for your hard work. Just in the last few weeks, I started to really avail myself of the work you've done to ensure my freedom to use my computing devices as I wish. I bought my Galaxy Nexus because I knew that work was there, but I only just now started to exercise it.
Your efforts have directly made my life better than it otherwise would have been, and I appreciate it very, very much.
Jean-Baptiste Quéru quits AOSP Posted Aug 9, 2013 10:28 UTC (Fri) by Aissen (subscriber, #59976) [Link]
> Wow, and I was really interested in buying one of these, too.... my sole reservation was in not knowing the overall lock status of the device.
The Nexus devices still have an unlockable bootloader. The "no redistributable binaries" for GPU drivers is a different issue from device locking.
Jean-Baptiste Quéru quits AOSP Posted Aug 9, 2013 10:31 UTC (Fri) by malor (subscriber, #2973) [Link]
Well, in my original draft, I actually referred to 'freedom level', but it felt like I was overusing the word, so I switched it to 'lock status'.
Lack of drivers is a sufficient problem that I've lost interest in buying one.
|
|||||||||||||