Slashdot: Alex, we're talking today about open sourcing parts of the
code that run the Raspberry Pi, simply the BCM2835 chip. Can you talk a little bit about what that chip does?
Alex: Sure. So the 2835, that's the core system-on-chip, which is comprised essentially, the whole of the Raspberry Pi in a sense, in that you've got on there the ARM, the GPU, and that the various libraries that are used to access that GPU by OpenGL-ES or OpenPG.
Slashdot: And how much closed-source code is actually used to run the Raspberry Pi right now? In other words, how much is not already open source? I think a lot of people are under the misimpression that the Raspberry Pi is an entirely open source project because it is so Linux centric and there's been so much open source involvement.
Alex: Yeah. Certainly we had, I mean, a substantial amount of it is open source. The Linux kernel module, which we use to communicate with the GPU, is fully open-sourced, GPL and BSD licensed. And the -- what we're open sourcing now are the libraries which run on the ARM side, the GL, the GL ES implementation, the OpenVG implantation, VGL, and so on. So really, how the architecture of the video core works is that there is some code that's running on the video core side that is quite proprietary, and that's unlikely to change in the near future, but what we've now been able to do is open up everything which runs on the ARM side. So everything which runs from Linux kernel up is now open source, essentially.
Slashdot: And is there new functionality that will -- either immediately or that you anticipate will -- be opened up by having this, the ARM side of the software stack being open source?
Alex: I think that in the near future it's going to make it a lot easier to get things like native Wayland implementations working because of the EGL implantations being opened up, which allows programmers to implement the Wayland platform requirements using the toolkits which we already have available. I mean, in general, I think it's going to make it much easier to work with the existing open source Linux stack, because quite understandably most people working graphics on Linux, it's all very centric around MESA and Gallium, the existing open source projects. It's very difficult to work with libraries which are closed and which they're constantly adding features to. Well, we've solved that problem now, and hopefully we'll start to see more people porting that technology to use Raspberry Pi.
Slashdot: Now you mentioned the GPL and BSD licenses are used extensively. What license is the new code or anything that's being open sourced now, is it all going be under the GPL?
Alex: It's all 3-clause BSD.
Alex: So the reason, so the stuff we use in the kernel module is BCHIQ, which is basically the machinery required to create a layer between the user space graphics driver implementation and the video core. So that's actually dual GPL and BSD, to be friendly to the BSD guys. Now that we've got all the user space stuff also BSD, which is a very, very permissive license, we anticipate it will be very useful to people who are wanting to port -- other people who are working on FreeBSD, NetBSD, Haiku, Plan 9, RISCOS, etc.
Slashdot: Has there been, to your knowledge, much sort of cross pollenization of the existing code that's under that license?
Alex: How do you mean by cross pollenization?
Slashdot: Have any of those projects you just named, have they been interacting with Raspberry Pi developers? You just named several big . . .
Alex: Oh yeah. We have had that to a certain extent, certainly reports on . . . they've been working with us on further developing through the API for doing low-level graphics, they've tried to build, you know, bring up their platforms. We've actually started to see patches reaching the mainline Linux kernel to start to provide platform support for the Raspberry Pi. We have a ways to go there, but that's something we're keen on pushing. I think we'll start to see much more collaboration with those projects with this open-source code. And we've also seen people who've been [hacking] on all the various device drivers, USB in particular. There's a Plan 9 guy, he got pretty far in doing a crash-free implementation implementation of the USB driver, which is going to be interesting to a lot of people because it's currently rather large and difficult to do.
Slashdot: Now, one thing, the term "open source" can mean a lot of things. In what way will this code that you're talking about open sourcing now on the ARM side of the stack be accessible to either developers, other programmers? Is it going to be, say, in a public facing Git repository? Or will it be distributed on request? How will the Raspberry Pi project get that open source goodness out to other people?
Alex: Yeah, totally, fully, 100% OSI, FSF compliant, open source Free Software. So it's available under a BSD license. We have a GitHub repository -- do your standard "Clone it, send your patches," or pull requests or whatever. Exactly what we do regarding opening up the development process, that's always quite difficult for us because when you have people who are contributing in their spare time, working on things, they don't always want to make promises they can't keep. So that's quite difficult too. We have to strike a balance there between talking about what we're actually working on and making sense of people's disappointment.
Slashdot: Now, Alex, Eben Upton basically described you as the project's Linux guru. Is there a team of people involved, both inside and outside Raspberry Pi, in making this open-source release happen? Or how many people are involved?
Alex: There's a small handful who've been involved in this open-source release particularly. I mean, the main issue as with most of these open-sourcing efforts, is, of course, working through all the necessary legals, persuading the people who matter that actually there's not going to be a really big downside for not releasing access. They're not good at giving away valuable IP which is going to downturn market position. So I think most of the work's being done with people like Eben, talking with Broadcom executives. Beyond that, there is a small handful of protocol engineers who then very generously give their time, and they've done the necessary legwork on cleaning up the code and making sure that it's ready for public distribution.
Slashdot: From that, it doesn't sound like you've faced a whole lot of resistance in opening this code. Is that true?
Alex: Well, my understanding is that it's something which has taken a long time. So it's been a slow process, but I think that it's partially due to the way that the video core is structured, whereby most of stuff which runs in user space is pretty much just a serialization of your GL request and then it sends it over to the video core. So there's still plenty of stuff on the video core side, which remains private. I think that structure makes it more palatable.
Slashdot: You describe this as a process, and it's obviously got both the actual development work, with the programming, coming up with open-source alternatives to closed-source options in some cases, and the licensing. What is the timeline going forward? Is this announcement, is there going to be a big 'We've open sourced all the ARM stuff" that is going to hit users immediately? If someone has a Raspberry Pi already, will they in the month of December be downloading a patch? What goes on for users from this point? For developers as well, for that matter?
Alex: Okay. Well, the big announcement is going to be on Wednesday, and the GitHub repository will go public and everybody can clone it to their heart's content and get hacking. I would say that there might not be an immediate difference to users. But what we'll see over the next few months is better integration with the open source with its graphics stack.
Slashdot: Okay. What's the most exciting aspect of this?
Alex: Well, for me, I think that this is a major announcement in that this is the first [open-source driven] SOC. Broadcom was the first vendor to fully open source their user space graphics drivers. So I think its a pretty major step for embedded Linux. People have been campaigning for, or begging for, for Mali drivers, the Adreno drivers and so on. So I hope that this is a step that other companies will look at it, they'll see the benefits which we're hoping to accrue over the next few months, and hopefully we'll start to see others following in our footsteps.