专利赋予其所有者,禁止其他人制造、使用和销售所主张的发明的权利。相反,开源许可证授予修改、编译、分发和使用软件的权利。随着软件专利的申请授权量的增加,开源许可证涉及的软件代码的背后也很有可能涉及专利方案。
开源,简单可以理解为是“开放源代码”的简称。根据最权威的开源组织OSI的定义(https://opensource.org/osd/),开源需要满足免费分发、包含源代码、允许修改为衍生作品等10个标准。开源许可证是随开源软件分发所附带的协议,开源软件的用户应当遵守该开源许可证的全部条款。
根据开源许可证对于后续用户分发修改软件的宽松程度,对常见的开源许可证依次排列为:MIT、BSD、Apache、LGPL、Mozilla、GPL。具体地,GPL是最为严格的开源许可证,首先新增代码必须同样开源且也同样使用GPL许可证,由此被业界称为具有传染性,基于Apache的Android系统就是为了避免基于GPL的Linux内核的传染性,而设立虚拟机将Linux内核切割开来。MIT协议则最为宽松,后续的开发者基本可以不受约束的使用开源代码,仅需要表达对原作者著作权的尊重即可。
专利问题,目前也越来越需要受到开源软件的开发者或用户的关注。第一,开源许可证中不一定包含明示的专利权许可,因此可能会面临其他贡献者的专利权主张;第二,开源软件也可能包含技术方案需要获得第三方的专利授权。例如,近期联想公司就因为使用AV1(AOMedia Video 1)视频编解码格式被知名NPE InterDigital起诉专利侵权,尽管AV1是个开源、免费的生态系统。第三,很多开发者可能认为开源软件无法申请专利,而未及时将软件代码所涵盖的技术方案申请专利。
笔者将几个常见开源许可证的专利条款总结如下,理解可能有偏差,具体条款建议读者可以阅读英文原文:
许可证 | 是否存在专利条款 | 明示的专利许可 | 被许可的限制 | 专利许可的终止 | 源代码专利免责声明 | 贡献代码的专利不侵权保证 |
Apache 2.0 | √ | √ | × | 针对开源代码发起专利诉讼时终止 | × | × |
GPL 3.0 | √ | √ | 不包含对作品的进一步修改部分的专利许可 | × | × | 需保证自由软件的完整性,因此对于涉及有偿专利许可的部分需停止分发 |
GPL 2.0 | √ | √ | × | × | × | 需保证自由软件的完整性,因此对于涉及有偿专利许可的部分需停止分发 |
Mozilla | √ | √ | 对于贡献者从开源代码去掉的代码,新增的代码,开源代码和其他代码的组合,不提供额外的专利许可 | × | × | × |
Eclipse | √ | √ | 不提供针对硬件本身的许可; | 发起专利诉讼发起时终止 | √ | × |
BSD | × | × | × | × | × | × |
MIT | × | × | × | × | × | × |
首先,笔者认为目前合规使用开源代码基本不存在来自于开源社区本身的专利风险。目前大部分的许可协议都已经包括明示的专利许可,BSD和MIT虽然无明示的专利许可,但是根据一些美国的判例,法官会适用暗示专利许可或权利用尽原则来判定不侵权。实操中的另一个案例是,基于BSD的OpenCV曾将涉及专利许可的模块放到了收费库(Non-Free)里面,例如知名的SIFT和SURF算法,明示开发者可能需要承担专利风险,直至这两个算法对应的专利过期。
但是由于开源许可证一般都含有不保证任何风险的条款(虽然仅有Eclipse明示了专利风险需要用户自己承担),因此一般不能免除来自第三方(开源社区之外)的专利权风险,例如上文提到的联想和InterDigital案例。相对来说,适用GPL协议的软件可能专利风险会更低,因为GPL为了保证自由软件的完整性,在协议中明确说明了如果贡献的代码含有专利权利负担,则应当使其免费给所有人或者应从代码中删除。
其次,对于开源软件开发者来说,针对开源软件所涉及的方案申请专利意义不大,虽然目前开源许可证并不禁止开发者申请专利,但是需要无条件将开源代码所涉及的专利许可给后续的用户或开发者。但是有些开源许可证中也包含专利权许可中止的条款,可以起到一定的自我保护能力,或者震慑不遵守开源许可证的用户。
部分信息参考:
https://google.github.io/opencasebook/patents/