关于开源许可 GPL 与 LGPL的区别

目前我们使用的很多软件资源都来自开源世界，包括各种软件工具的开源版和相应的工具套件，类库等等，但是我们在使用这些资源的同时也需要履行相应的责任与义务，否则甚至会在某种程度上构成侵权，接下来我会介绍一下通用的 GPL 与 LGPL 许可协议，通常情况下，你可以在软件许可协议，或者项目附录的 txt 文件里找到它。

GPL

GPL 是 GNU General Public License (GNU 公共许可证的缩写) ，它通常会具有 “传染性”，当某一项目使用了 GPL 下的软件部分的话，那么该项目将被 “感染” 使得他也变成了 GPL 协议下产品，也即是你需要将其开源和免费。举个简单的例子：如果你正在开发某个桌面项目，但是其中需要调用到某个可视化窗口控件，而这个控件又恰好是 GPL 下的产品。那么很不幸地告诉你，你的项目变成了 GPL 许可，在你最后的项目发布时你有义务且必须提供基于整个项目的源代码

LGPL

LGPL 是 GNU Lesser General Public License (GNU 宽松公共许可证) 的缩写，旧称 GNU Library General Public License (GNU 库通用公共许可证)；LGPL 允许商业软件通过类库引用 (link) 方式使用 LGPL 类库而不需要开源商业软件的代码，这使得采用 LGPL 协议的开源代码可以被商业软件作为类库引用并发布和销售，但是前提是你不能修改 LGPL 许可的软件部分。还是上面那个例子，在你，如果我们是以动态链接的方式调用该窗口控件，那么你可以不需要开源你的项目，但是需要说明链接的部分。

GPL 与 LGPL 部分使用情况分析

1. 如果你的作品中使用了 GPL/LGPL 软件，但是没有对这些软件做任何修改，那么你有提供使用的这部分项目的源代码的责任和义务。

2. 对 LGPL 条款里的自由软件（通常是函数库）的 “正常使用”，通常的理解是，始终以动态链接的形式链接这个函数库 —— 如果以静态的方式链接，该函数库成为您作品的一部分，从而使得你的项目成为该函数库的衍生作品。
   解决方式： 以动态链接方式链接 LGPL 函数库，并为您的产品提供扩展接口及程序上载接口，将衍生作品置于 LGPL 条款下发布。在必须静态链接的情况下，如果你的软件只是对 LGPL 进行调用，连接而不是包含，那么这里可以选择将这部分使用 LGPL 的代码进行封装并开源，这将使得其余部分代码不需要开源。

3. 当你直接从 GPL/LGPL 许可下拿出 10 行以上的源代码用于自己的作品中时，那么你的作品规模有多大，都将成为该 GPL/LGPL 软件的衍生作品，也即是需要发布时提供源代码

开发人员的考虑

1. 开源工作者

   对于愿意开源共享自己的开发项目，为自由的开源世界贡献自己力量的开发人员来说，我将之称为开源工作者，因为他们很享受这两个协议所带来的好处的，所以也很乐意接受相关的协议许可。（毕竟这是为开源而生嘛）
   Everything is for freedom，开源协议使得你可以直接使用别人所提供的软件开发成果来构建自己的项目，但是最后也别忘了，你同样需要在自己的项目完成时将你的工作（通常为项目源代码）共享给其他开发者。

2. 自由开发者
   通常来说，自由开发者会比较享受开源项目带来的丰富资源，但是需要强调的是，也正是这部分人员通常最纠结于这个是否该遵守开源协议的问题，在这里，我觉得这里主要看你的 idea： 如果你有一个很价值的 idea，并且这个 idea 落实到实际项目中会带来比较大的收益；或者说最后你只希望个人私有该项目并且闭源发布的话，那么你最好别选择 GPL，慎重选择 LGPL（这里后续会详细介绍）
   当然，如果你只是享受开发的乐趣和希望借以学习提升自己，那么直接用就 OK 了，因为庞大的资源共享会让你爱不释手的。
    

3. 商业开发者
   通常情况下，商业开发者是指以公司或者团队为单位，进行商业应用的开发人员。他们所开发的项目一经落地就会直接与利益挂钩。所以他们一般不会使用开源的软件部分作为自己项目的构成，只有在不得不引用时也是慎重使用 LGPL 的相关调用许可。
   在这里补充一下，现阶段国内的很多中小型公司对于软件的版权意识并不强，很多开发人员只知道埋头开发，寻找资源解决问题，从而忽视了寻找资源途径带来的版权问题。甚至我有了解到有一个十年的程序员竟然不知道这引用两个协议有什么区别（我猜也许是他从来不用开源的东西吧）。但是版权问题真的非常严重，举个例子，一旦你的项目中有使用 GPL 的部分，那么你的竞争者有权要求你公布源代码，一瞬间你就会丧失你的竞争优势。