Even if somebody is completely and wholly ignorant of what open source licences require. And in some ways that's the best case, right? Even in a company like Google where we have staff in place, as new repositories are created, as new projects are started - we're not always pretty. We have to be extremely up to date on what the company is doing, so that we can make sure that when it comes to the time to launch a product that they're able to do so in compliance with open source licences and, frankly, using the most up-to-date versions of open source software - they can be up to date on bugfixes and that sort of thing.
We try to get in early, so that we're not seen as a barrier to launch because if we're slowing down launches, we're failing in a company like Google, and we don't want to be that group.
LXF: Is that kind of compliance in the DNA of people that work at Google?
CDB: Yes and no. You have to realise that open source licences can be extremely complex. You don't necessarily want engineers to become experts at licences, because if they're doing that sometimes they're not developing quickly because they're worrying too much about these interactions. We try to give them broad guidelines and smart tooling so they know the implications of that which they're building. We try not to have them become experts in licensing because it's a scale just like any other: if you're good at this do you have the capacity to be good at this other thing too? Maybe, but I'd rather have them concentrate solely on product development and all the rest.
LXF: Has Google's approach to open source changed over those nine years?
CDB: Sure. It's funny because depending on the project, they have different perspectives on open source.
LXF: So ChromeOS has a different perspective than Android?
CDB: I'd say so, yeah. I mean ChromeOS is a different approach to operating system development than Android. It's funny because if you're going to ship a browser, for instance, there are certain plugins that you want to make more secure, but those plugins are by their nature closed source - things like Flash.
If you want a ChromeOS box to render Flash content and do it in a secure way, well, we had to cut a special deal with Adobe that would allow us to ship that version of Flash in that way. And that's something that doesn't show up in Chromium or ChromiumOS, right? It just shows up in ChromeOS. And so you have these funny borderlands between open source and proprietary software and how does that work?
Similarly, if you want to cut a deal with one of the content producers in the USA, in Europe and the rest, they want to know that they have that whole "secure path" and to ensure that you have to make sure that the deal does not interact poorly with the open source licences in an operating system or program. That can be extremely tricky.
On top of that is our standards work. We have one part of the company that is advocating for encrypted media extensions, for instance, so that they can ship Netflix players and that kind of thing, and then you also have Ian Hickson, who works for me, saying that that doesn't belong in the Web WG (Web Hypertext Application Technology Working Group) specification for HTML 5.
LXF: So who makes the decision?
CDB: This is the interesting thing about a company like Google. We can have both. Or we can have neither, depending on your perspective. We will sometimes have things that look conflicting, but they're not really. There's nothing wrong with us wanting the Web WG HTML 5 specification to be a pure document that doesn't depend on patent-laden technologies, like you'd find in some specifications, and also have an ancillary specification that adds to HTML 5 that allows for it. You can drive yourself crazy.
