问：那你们的核心搜索产品是不是也在使用2.4内核？
答：人们提到谷歌时，通常认为搜索业务是处在一个静态的内核上，但实际情况并非如此。不同的数据中心情况不同。我认为内核2.6应该占主导地位。
还有的被讨论互惠的。当通用公共许可（GPL）第3版问世以后，自由软件基金会（Free Software Foundation）把Affero从GPLv3中拆分了出来，形成了一个单独的许可。Eben Moglen（Software Freedom Law Center共同创始人）说，“如果谷歌开始变得太‘寄生性’，那么我们将重新评估它。”你对于这种负面的看法---索取大于贡献，有何担心呢？
我对此确实有些。我认为这基本上是一个不正确的看法。虽然你一直就给予很多，但总是有一些人会感到不满意。我们可以得到更多的回报吗？当然。其中一个改善这个问题的方法是通过类似于Summer of Code这样的项目。不算Android或者类似于GWT这样的大型开源项目，谷歌每两个或三个星期都会发布一个新项目，或者是每个月都会给很多项目发布补丁，这些年来一直如此。我保守地估计了一下，每年我们发布的代码大约有100万行左右。
如果你与开源开发人员---参与开源项目的工作人员---进行交流的话，我认为他们能了解这一点。我始终认为，社会爱好者会最终明白这些，我认为这是一定的。还有一些人，总是给我们制造麻烦，因为我们并没有支持Affero式的GPL，但我们那么做是不实际的。当他们在GPLv3中包含 Affero式的条款时，我告诉Eben的是，“听着，你可以采取你想要的任何东西。我们将仍然尽可能多地支持FSF和SFLC，但这意味着我们将无法在内部使用该许可，因为对我们来说那么做将是不切合实际的。”我认为这是一个很现实的回应。Affero GPL已经出台了。对于能用到它的人来说，它的确很伟大。但它却不适合我们。
这就是免费软件的问题。你没有义务使用它。谷歌在这些事情方面的粒度控制足够细，我们不会使用我们不想使用的东西。
问：你首选的许可是什么？
答：我们一般是在Apache许可，也就是Apache 2下进行发布的。我们认为Apache 2的许可语言是最公平的。而GPL需要太多的管理和补丁流，我们在这上面花费的时间要比我们运行一个项目花费的时间还要多。Apache 2鼓励人们运行它，没有太多地繁文缛节。这就是我们发布代码的时候为什么使用Apache 2的原因，而不论是让人们采用我们确实很喜欢的技术，还是一些API的例子。这就是说，如果我们在GPL、LGPL、GPLv3、BSD下发布了产品，它默认是支持Apache许可的。
问：对于致力于重要开源项目的工作人员，你们的补贴如何？
答：我们已经雇用了很多开源技术领域的专家，比如Jeremy Allison 和Andrew Morton。他们对于Google App Engine 和Mondrian做出了相当重大的贡献。我觉得让他们把开源项目作为自己工作的一部分是非常正常的，这样他们就能随时对他们正在使用的类库进行修补。我们认为这要比仅仅让他做开源项目这种工作方式更健康。
问：你们在内部使用了很多开源技术。那么在使用这些技术之前，你们是否有某种形式的知识产权的审批或审查工作呢？
答：这是一定的。通常我们有两种方法。当有人想要用一些来自外部的代码---开源的或商业的---我们会把这些代码放在一个特殊的我们称之为“第三方”的目录下。然后，我们会把它们放在一个说明文件里，这个说明文件详细描述了这些代码的出处、如何授权、授权的类别是什么等等。我们所寻求的东西是显而易见的。也有一些项目的知识产权出处很可疑，而且我们知道这些情况，我们是决不会使用这些项目的。
由于谷歌并没有发布很多软件，所以我们要比那些既发布硬件又发布软件的厂商要轻松得多。当我们发布软件的时候--- Google Search Appliance以及一些可下载的应用程序，我们也会根据情况采取不同的许可检查措施，我们所要做的就是过一点点额外的关注。同样地，当我们开发较大的项目时，比如Google Android，我们有一个更高级别的检测过程---每两个星期，我们会聚在一起看看外界的许可状况是否发生了变化。
跟踪模型确实很适合我们使用。我们有一些内置于开发平台内的工具，项目经理或产品发布经理可以按照这些工具的选项选择一定级别的警告，那么这些工具就会告诉他们那些开源软件被使用了，以及如何遵守这些开源软件的规定，以免违反知识产权。利用这种方法，我们给项目经理带来了一面镜子，随时就能检查许可授权问题。
这是我们处理这种问题的第一种方式。第二种方法是，每当谷歌开发人员把修改的一段代码放到变更列表里面时，我们就用我们的代码搜索产品在互联网上进行搜索，然后把这段代码与搜索到的所有已知的开源代码进行比较。然后寻找二者的交集。每当我们找到了一个交集，我就会停下来仔细检查一下，看看它是不是一个真正的副本。如果是，我们确定它在正确的目录下并且被真确标示。如果它不是一个真正的副本，我们就会给开发人员联系以确保它被正确表示，以便我们能够用这些许可做我们想做的事。
这个工具目前正处于萌芽状态。我们正在试图找到如何让它自动化的方法。但它的确是一个伟大的‘发明’。我们团队的目标不是阻止研发过程，而是让开发人员能够使用尽可能多的开源代码。我们这种方式很健康，因为这样能保证开发人员所写代码的合法性。
问：你们审核代码的专利或版权吗？
答：事实上我们对此并不审核。我们有专门的法律人员负责跟踪这些事情。主要有两类法律人员：审核谷歌使用的外部代码的开源许可；审核谷歌发布代码的开源许可。在专利或版权方面，我们绝不能有任何含糊，因为它太‘狡猾’了。
问：如果你曾经维护并发布过自己的开源代码或补丁程序，那么是不是更容易在谷歌获得聘用？
答：如果你在开源领域有自己的一席之地，那么很明显他会对你有帮助。如果你自己就负责一个健康的开源项目，我相信它肯定会对你有利。雇用委员会聘用人才的一个很重要的标准就是这个人过去是不是有过从事开源工作的经历。从个人的工作经历很容易就能确定这个人的水平。面试的内容很广，但是它并不是非常深，因为它只有45分钟的时间。因此，在如此短的时间里，面试管如何才能真正感觉到面试人员很善于编程呢？很显然，工作经历是一个很好的证明。
就此而言，开源技术与社会关系联系很紧密。
开源确实能迅速揭示社会关系。你可以看看开源开发人员所写的代码，他们如何处理来自真实用户反馈的错误，如何处理真正的用户问题。这是一个令人难以置信的资源。
Summer of Code不是一个真正招聘得计划。如果是这样的话，这个招聘计划可以称得上是一个非常昂贵的计划。去年我们创造了大约200行开源代码，来自全国的900 名学生参加了这次会议。在这些学生中，可能有三分之一还要继续参与这个项目，因为其余的都返回大学校园了。
有一些学生已经参加该计划中两三年了。我们这个计划的主要目的是在暑假期间能给孩子们提供一个编程的平台，因而他们能够互相交互编程经验，更快地提高编程水平，而是在整个暑假都从事与编程无关的其它工作。今年是我们实施这一计划的第四个年头了，而参加今年活动的学生有1109个并且遍布95个国家。
文章来源于领测软件测试网 https://www.ltesting.net/
