避免这种常见的开放源码扫描错误

159 阅读7分钟

英国摇滚乐队The Who的传奇吉他手Pete Townshend以弹奏悬挂和弦而闻名。悬吊和弦为歌曲增加了音乐张力。对于那些(像我一样)喜欢用C调演奏的钢琴演奏者来说,只需演奏一个C大调和弦(音符C、E和G),然后用F或D替换E音,你就可以成为一名英国摇滚明星了1

音乐通常充满了和弦的组合,如悬垂和弦,它提供了张力,然后释放。虽然给音乐作品增加张力是可取的,但给使用开源工具的扫描软件增加张力肯定是不受欢迎的。

红帽公司的一个涉及扫描软件的问题导致我写了这篇文章。

最近,一位重要的客户在扫描了我们的一些软件的源代码后提出了一个问题。正如你所知,Red Hat提供了其软件的源代码。该客户的扫描工具报告说,某个软件文件是根据GPLv3授权的,这是不应该的。事实上,该软件文件被明确地、单独地标记为根据Apache 2.0许可证授权。客户要求我们调查这个问题,我们很乐意这样做。

经过我们的深入研究,我们得出结论,他们的扫描软件显然是不正确的。我们提出了一个假设来解释这个异常现象,我现在就来解释一下。

一种流行的开源软件扫描工具将被扫描的软件与预先存在的庞大的开源软件库进行比较,并报告任何匹配情况。例如,假设有一个名为MIT.c的开放源码文件,它返回的整数比传给它的整数高一个。换句话说,它是一个简单的加法器。它可能看起来像这样。

Copyright 2021 Jeffrey R. Kaufman
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
int foo(int x) {
        x+=1;
        return x;
}

在这个假设的例子中,假设MIT.c被放在一个名为The Simple Maths Project的GitHub仓库中,作为一个解决简单算术问题的开源社区项目。这个项目包含许多其他类似的C语言文件,都在同一个MIT许可证下。

由于这个假设的例子函数非常有用(当然它不是,但在这里请听我说),它被包括在GitHub上的许多其他开源项目中,以提供简单的算术效用。另外,假设这些其他项目中,有一个名为 "持续和弦计算器 "的项目使用这个来自 "简单数学项目 "的MIT.c源文件来帮助计算悬浮和弦的音乐表述。

假设的中止和弦计算器项目,除了使用MIT.c外,还包括几个以GPLv2许可的源文件。当悬空和弦计算器项目被编译时,你可以假设产生的可执行文件将包含GPLv2许可的软件和MIT许可的MIT.c作为一个组合作品,MIT.c本身不能被合理地认为是独立和单独的作品。由此产生的可执行文件将正确地被认为是根据GPLv2许可的,并且必须遵守GPLv2的义务。遵守意味着提供(或在三年内提供)用于创建二进制或可执行文件的所有来源,包括所有根据GPLv2和MIT.c许可的软件文件。

回到我们的问题上...

假设你的一个软件产品除了使用你自己编写的软件外,还使用MIT.c。由于MIT.c完全在MIT许可之下,这将使你有义务只遵守MIT许可条款,这很容易做到。通常情况下,人们在分发软件时提供一份MIT许可证的副本和版权声明。或者,如果你是像Red Hat这样的公司,提供包含许可证文本的源代码也是一种合规的方法--我推荐的方法。(见 一个经济上有效的开源软件许可证遵守模式.)

如果你决定使用参考开源项目库的那种源代码扫描器来扫描你的软件产品的源代码,你的扫描器可能会报告说MIT.c是根据GPLv2许可的!为什么?为什么呢?因为它将看到MIT.c,以源代码的形式,与在GPLv2下许可的悬垂和弦计算器项目相关联,并天真地认为MIT.c也必须遵守GPLv2条款。尽管MIT.c源文件清楚地标有MIT许可,而且你只是从原始的MIT许可的简单数学项目中复制了它。

这是使用这些类型的扫描系统的一个不幸的后果。在这个例子中,这类系统会错误地报告其资源库中每一个使用MIT.c的开源项目。可能有几十、几百、甚至几千个程序使用MIT.c,而且都有不同的许可证,你会被提供一大堆项目来审查,表明MIT.c可能是MIT许可证,也可能是BIT许可证。在我的经验中,很少有这种类型的扫描是有理由的,即使是有理由的,文件许可证的结果也与你的预期不同。这种情况会发生,但很罕见。

还有一种软件扫描系统,只通过寻找与项目源文件中已知的许可证文本相匹配的内容来报告许可证情况。这种类型的扫描器会检测到源代码中的MIT许可文本,并正确报告该软件受MIT许可条款的约束,尽管MIT.c可能在许多其他开源项目中使用不同的许可条款。虽然这种类型的源代码扫描器也会出现误报,但根据我的经验,参考开源项目库的源代码扫描器,由于前面讨论的原因,误报率明显较高。

坦率地说,参考开放源码软件库以确定许可证数据的源代码扫描器在某些情况下是有用的,例如,当你可能非常担心一个工程师无意中复制和粘贴了一个不可接受的许可证的源代码,而没有同时复制适用的许可证文本。在这种情况下,那种只寻找与许可证文本相匹配的源代码扫描器将无法检测到这种包含。然而,正如我之前所说,这种情况是非常罕见的,这使得资源库匹配的源代码扫描器容易出错,并浪费了追踪真相的资源。这些时间和资源可以用在更多的实质性问题上。你也可以通过培训你的开发人员来解决这种情况,让他们永远不要从其他来源复制软件而不复制任何适用的许可证。

一个报告错误许可证的扫描器要求你解决一个假阳性的问题,这对你的组织是一种巨大的伤害。正如我们的客户所经历的那样,无数个小时的资源被浪费在这些乱七八糟的事情上。

我们不会再上当了。


我想感谢我的同事Richard Fontana提出的这篇文章的标题。请阅读他在Opensource.com的法律栏目下的一些精彩文章。

1.如果你想了解更多关于音乐理论和悬垂和弦的知识,请查看Rick Beato对The Who另一首伟大曲目的分析:What Makes This Song Great?™ Ep. 96 The Who.