No, if you don't distribute the binary then you still have no obligation to distribute the code under GPLv3. Similarly, if you only use a program via file descriptors then GPLv3 doesn't require you to do anything except point your customers at an upstream URL.

The OS X kernel includes a lot of code from FreeBSD, including most of the process management code, the MAC framework, much of the VM subsystem, and so on. The userland includes FreeBSD libc and mostly FreeBSD utilities (the NetBSD code was largely gone by Rhapsody DR2). Check the license files on opensource.apple.com sometime...

It's not that clear cut. Sony is actually distributing the binaries, but for a lot of potential contributors the GPL doesn't force anything: they use their derived work internally, never distribute it, so don't need to share any changes. One the other hand, they will often avoid GPL'd code because of the potential for it to affect their ability to turn something into a product later. In this case, they'll either develop their own or, more likely, license a proprietary version.

Without the legal constraint, there are still reasons to push changes upstream. Maintaining a fork is expensive. Bugs get fixed and new features introduced upstream and the more you've diverged, the harder it is to pull the changes. This is why Juniper has recently been pushing a lot of things to FreeBSD - they've realised how much it was costing them for JunOS to be significantly different to a modern FreeBSD.

Even with the GPL's constraint, there are lots of ways around it. Companies ship mobile phones with Linux kernels and binary display drivers, by only using the public kernel interfaces and loading the driver late in the boot process, with most of it running in userspace. At worst, they're required to release the code for their shim that exports the hardware registers directly to userspace. For other code, you can run it in a separate process and the GPL doesn't apply.

We've ported Dalvik to FreeBSD. The Binder IPC stuff also needs porting, however having done this the isolation between applications could be much better enforced using Capsicum. For real-world usage, you'd also need to port the GPU drivers, because Android has its own graphics stack.

Try again.

This is annoying, but it's something that legal tells most companies. If you were not hired for some reason that is not directly related to your ability to perform the job, then you might have grounds for a lawsuit. It's best not to give out any information.

I'd agree with the other poster. This kind of question is intended to see how you approach a problem. Can you think about intelligent solutions to a problem that you haven't seen before? The answer doesn't matter, the process of getting to it does. If they asked you to in-person interview, it means you passed the phone screening, which then isn't counted for the rest of the hiring process. The in-person interviews are fun. I turned down a job at Google, but I found the interviews fun - they ask you to think about things that you haven't thought about before (well, in theory - one of my interviewers hadn't done her homework and asked me a question about a subject I'd published papers on, expecting me to have no background knowledge). Whether you take the job or not, the experience is enjoyable (and you get to visit somewhere fun at their expense).

If you only got a free lunch, then you did the interview wrong. The trick with Google interviews is to make sure they take place in a country you want to visit. They'll pay for your flight, meals, and one night in a 4* hotel, and then you can tack on extra time if you want. If you visit somewhere where you have friends and can get free accommodation, then it's a good idea to go through it fairly frequently. Interestingly, even if you turn them down, their recruiters will start sending you emails about six months later about coming back to see if they have more interesting jobs for you.

Netflix is aggressively hiring anyone with FreeBSD kernel experience, irrespective of education, so if you want to work there now's a good time to start sending patches to FreeBSD - especially to the network stack.

We just did a round of hiring, and interviewers were asked to answer two questions about the candidate:

1. Is this person competent to do the job?
2. Would you be happy working on a team with this person?

For a lot of tech jobs, the answer to the second question would probably be 'no' for Woz, Jobs, Gates, Brin, and Page. That doesn't mean that they're not competent, it just means that they wouldn't fit in with the existing team, and that can be highly destructive to a creative environment. That same attribute makes them more likely to go and start a company, which also makes them less attractive to a big company: employees who leave to start a new company often take the best of their colleagues with them, so they increase turnover of the staff that you most want to keep.

If they're hiring you as a contractor, then they should be paying you contractor rates for that time, so they have an incentive to either hire you full time or let you go. Google doesn't like to do contracting, however, because they have a lot of trade secrets that they don't want to trust contractors with.

It's pretty easy. You ask the existing team whether they want to keep that person, and you pay the team bonuses according to the total team productivity. Developers are generally good at assessing the competence of other developers, and how well they fit in with the existing culture, but occasionally will try to sabotage competent people who they think might outshine them. If they get paid more for selecting better people as colleagues, then this incentive goes away.

With my FreeBSD Core Team hat on, I have fairly regular meetings with people at ARM (which, conveniently, is about half an hour's cycle ride away). It's coming, but it's coming more slowly than I'd like...

Because, at the time, the US government would only buy from US tech companies, and most big businesses had their purchasing decisions strongly influenced by what government bought (often for interoperability reasons), which influenced small businesses (for the same reason). Marketing in the USA required a big budget to get national penetration and there wasn't an obvious place to start.

In contrast, a tech company in California could start selling locally and then just expand slowly into more states. Their existing supply chain didn't need many modifications to sell things one or two states over. A British company trying to sell in the USA needed to establish a foothold somewhere. They needed to ship either components for assembly or completed devices to the USA.

For a small company, the cost of translation can be the difference between making a profit and making a loss. You need a big investment to sell enough in France or Germany to recoup the cost of localisation. In contrast, a US company had an English-speaking audience on its doorstep and so could ramp up to economies of scale in the tens of millions of units before they needed to consider localisation. At this point, the incremental cost is sufficiently low that it makes economic sense.

It did. Android's libc uses a lot of FreeBSD code. They've recently been talking to us about syncing some of their changes and treating us as they do other upstream projects that they pull code from, rather than maintaining a complete fork. They picked the Linux kernel for a very simple reason: Android was created by a small team, and they had experience with the Linux kernel.