开源软件执照检查和工具探讨（Discuss the audit tools for open source license GPL/LGPL/MIT)

1前言

Open source 的代码越来越多的被商业化应用起来，有时候，项目的构建里面开源代码会引用一堆开源代码，而这些开源代码的软件执照并不相同。最恶劣的情况就是，你不小心在你的商用软件里面增加了一个GPL的开源库，然后，还被竞争的对手或者被自由软件基金会给发现并起诉了，那么好了，也许你将不得不开源你所有的代码或者面临一场软件的所有权官司。如何解决这个问题？

2 一个实际的开源代码遇到的问题

https://opensource.stackexchange.com/questions/5480/how-to-audit-licensing-of-old-project

I manage a project with a very long open source history - Zikula (and https://github.com/zikula/core).

Zikula grew out of PHPNuke and PostNuke. Most of the oldest code is long gone, but some legacy remains. Early documentation states "Zikula is free software released under the GPL license!". Most files within the project have a header which directs to a copy of the GPL or LGPL and there is a NOTICE which discusses the mixture of licenses within. Additionally, we depend heavily on Symfony which uses MIT and contributions since beginning on Github in March 2010 are tagged as MIT. We also have many vendors within the project of various licensing.

We have a ticket requesting some clarity on the licensing and I am unable to answer. First, because of the information above and second because of my lack of understanding.

I think I would prefer Zikula be licensed with a permissive license like MIT or LGPL (as I believe they are?). The GPL seems to be too restrictive for our case, but likely was the dominant option at the time (15 - 20 years ago?). From what I understand the GPL is "infections" and subjugates other licenses within the project.

How can I straighten out this spaghetti? I'm a coder, not a lawyer. How do I audit the current code base and know what was contributed under what licensing and how do I ensure compliance in the future? How to I mix these licenses together or change and relicense as MIT/LGPL or similar?

上述的例子里，原作者面临了一个很老的项目，里面有各种库，包括GPL.

文章还做了，软件执照的可能的更变的讨论方法，非常复杂，有兴趣可以看一下：

The license change proccess

A license change is a social problem. You will need buy-in and agreement of your community. If the idea of a license change is received positively, you can:

Stop accepting contributions unless the contributors explicitly agree to relicense their changes to the new license.
Contact all copyright holders of all past contributions, and ask them to license their contributions to your project under the new license. You should keep a permanent record of their consent to this license change. Ideally you get a signed letter. In practice, I guess using GitHub issues would be OK. You can ping contributors in an issue with @example mentions.

Note that the contributors don't always personally hold the copyright to their contributions, e.g. if the copyright belongs to their employer. You would then have to get permission from their employer at the time.
Wait for the responses to roll in. This may take multiple months. Remember that contributors may be on a vacation, may have shifted their focus away from open-source contributions, or may be dead. You can try to follow up if they don't respond in a reasonable time frame.
If everyone agreed, you can change all license headers and publish the project with the changed license.
A note on licensing new contributions differently in a GPL project

I see your pull request template specifies the MIT license. This is a great step to give you maximum flexibility during this relicensing.

But since your current license is GPL, any contributions are derivative of existing GPL code in the project and therefore also have to be GPL-licensed. Your contributors do not have the right to issue them under the new license unless you can give them the code under the new license, which requires that all previous contributions have been relicensed.

These changes are therefore not MIT-licensed, but the contributors have given you the option of relicensing them later under the MIT license or a compatible license. If a contributor has given you this option for all their contributions, there is no need to contact them about the license change.

Dealing with code where consent to license change could not be obtained

If not everyone agreed to the license change, this becomes more complicated.

Silence is not consent! If someone does not respond, you have to assume that they oppose the license change.
If a contributor died, note that their copyright term extends for 70 years after death in most jurisdictions. You can try to contact the current copyright owners, most likely the deceased contributor's estate.
If you have anonymous or pseudonymous contributions, relicensing is exceedingly difficult and I won't discuss that here.
If a contributor only made very minor contributions that do not pass the “threshold of originality”, then these contributions are not subject to copyright and you do not need their permission to relicense the project including these licenses. Where this threshold is set depends on the case law in your jurisdiction. This threshold does not give you a right to use these contributions, but just a possible legal defence when accused of copyright violation in respect to these changes. I would be uncomfortable relying on this for anything more substantial than typo fixes.

You can track the license status independently for each file or component. The possible statuses are:

The file or component still includes GPL code.
All past and present contributors agreed to license change, but the file or component directly or indirectly depends on GPL code.
All past and present contributors agreed to license change, and the file or component has no dependencies on GPL code.
Only in the last case can you update the file to display the copyright/license header for the new license. This might allow you to immediately relicense some components, if your project has a suitable architecture (a win for decoupling and inversion of control!). But while even one piece of GPL code is still present in the project, the project as whole remains subject to the GPL.

For the remaining GPL files, you can try to rewrite them so that they no longer include GPL parts. This is quite tricky because the GPL is a copyleft license: although the other authors of the file agree to the license change, their contributions are derived from GPL code so they can only license their changes under the GPL, not under the new license. It is therefore not sufficient to just rewrite any lines touched by a contributor who didn't agree to the license change. You will have to rewrite the complete file or component from scratch, preferably as a clean-room implementation.

As an additional difficulty, GPL code may have been copy–pasted within the project. Again, the pasted code and any code derived from the pasted code may not be relicensed until the original author has agreed to the license change. Auditing for this might be very difficult, unless the problematic contributions are fairly recent and comparatively minor.

Conclusion

Depending on your goals, resources, and community, this might be over fairly quickly, or be a long process that extends across multiple months or even years. And it could be the case that significant authors do not agree with the license change, thus requiring unreasonable effort to eliminate their contributions. In that case, you may want to accept that the project has been locked in to the GPL, and clarify your documentation to reflect this license.

3 经典的几个License的简单介绍

An open-source license should not be chosen because it is popular, but because it is aligned with your goals:

Strong copyleft licenses like the GPL (and for web apps: the AGPL) try to maximize freedom for end users of any application using this code. This limits how other developers can use the code.
Weaker copyleft licenses like the LGPL don't ensure end-user freedoms for the complete application, but only to those components subject to the license. This allows developers to incorporate such code into proprietary projects under certain conditions, but does not allow them to turn the code proprietary.
Permissive licenses like the MIT license and Apache License 2.0 try to maximize freedoms for developers at the expense of end users. Developers can create and distribute modified versions without having to publish their source code. For new projects, the Apache License 2.0 should probably be strongly preferred since it includes a contributor patent grant.

在我的另外一篇文章里面有比较详细的介绍，这里不重复。

4 开源代码审查工具的使用（open source license compliance software system and toolkit）

4.1 商用的代码审查工具有如下两种：

4.1.1 BLACKDUCK

国内代理：https://www.blackducksoftware.com/zh-hans/products/hub

国外官网：

Black Duck Hub开源安全管理
自动统计您代码中的开源代码
映射到已知的漏洞
管理修复活动
在接到新的威胁报告时进行监测和提醒

4.1.2 roguewave

roguewave的介绍文档，我在我的源码里面有上传，可以看一下，这份文档对代码审查做了比较好的总结。

https://www.roguewave.com/

4.2 开源代码审查工具如下：

4.2.1 scancode-toolkit

https://github.com/nexB/scancode-toolkit

4.2.2 fossology

https://github.com/fossology/fossology