想写一篇关于开源生态的文章已经有一段时间了，却一直没写，写这一篇则打算简单谈一下关于自由软件和开源相关的东西，关于是否应当使用，怎样使用，以及其它相关的东西。和往常一样，写这篇的时候也没打什么草稿，就想到啥写啥好了，如果提到的内容有误还请指正，如觉得行文混乱还请责怪我语文学的烂 :)

给普通用户

自由及开放源代码软件——就在你身边

可能很多人对计算机相关知识并不熟悉或者并不主动关注从而不了解，但事实上自由软件其实就在你的身边改善着你的生活。或是你使用 Android 操作系统的手机时，或是你使用 Chromium （内核的）浏览器或 Firefox 时。但到底什么是自由软件呢？

尽管自由软件基金会对 自由软件（Free Software）一词有其定义，但我们暂且先宽泛的讨论 自由及开放源代码软件（Free and open source software），顾名思义，即能够自由使用的开放源代码的软件。如果你不知道“源代码”的含义，就比方你使用的软件是一道名菜，而自由软件则会提供菜谱并允许你自由的使用菜谱来做菜、“调整”、“改善”甚至“创造”你想做的新菜。开放式的“菜谱”给了越来越多“厨子”们做出更好吃的菜肴的可能，自然而然也有越来越多的“食客”也能从中受益，而自由及开放源代码软件也正是如此，甚至非自由软件也会从中受益——例如使用 Qt 作为图形界面库的 WPS Office。

我应当使用自由软件吗

当有一家很好吃的菜馆免费提供菜谱供食客自由使用时，你会使用那份菜谱吗？尽管真实的答案很可能是“看情况”，但如果条件允许的话，“为什么不试试呢”？

各行各业各个方面的计算机软件中都或多或少有一些自由及开放源代码软件能够作为替代品或好助手来帮助你完成需要的任务，例如你可能见过使用 Krita 或 GIMP 的画师，使用 Blender 构建模型的 3D 建模师，使用 MuseScore 打谱的作曲家，使用 pyTorch 或 TensorFlow 炼丹的机器学习工程师等。而事实上，自由/开源软件也并没有什么使用门槛。例如你可以简单的从网上下载 Notepad++ 来代替 Windows 内建的记事本应用，下载 ShareX 来截图或录制 gif ，下载 Kdenlive 来剪辑视频等。无论是新手还是专家，都能让你首先体会到自由/开源软件给你带来的益处。

尽管你可能会说，Adobe Photoshop 可能比 GIMP 更好用，Autodesk 3DS Max 可能比 Blender 更好用，那我为什么要使用后者呢？事实上，你的确总是应当使用能让你更快的把任务完成的软件，但如果有一个开放且自由的选择摆在你面前，尝试一下何尝不是一个很好的选择呢？

那么开源/自由软件到底有什么好处

在前段时间，GOG 发起了一个名为 FCK DRM （去你喵的数字版权保护）的倡议活动，告诉广大玩家或用户，在诸多非自由软件中，都包含着各种各样形式的使用版权检查，并在一旦它检查出异常时停止工作——它们有时候还会有异常，例如 Windows 可能在你更换硬件后提醒你你使用的 Windows 不是正版，或是你购买的软件在你不小心误删注册密钥文件后无法继续工作。

尽管该活动倡议的是 DRM-free（没有版权保护）的软件，但实际上，DRM-free 将使用的自由交给了用户，而自由/开源软件则直接将完全的自由1交给了用户，从而缔造了无限的可能。

开源/自由软件让用户不再需要考虑非自由软件带来的限制，将最大的权力交给了用户，换句话说，即便是用户，除了最基本的自由使用的权力之外，也有了参与进来，一同改善软件本身，让更多人受益的过程中来。

仅仅是使用就能让更多人受益吗

并不是所有的人都懂编程而能够直接的参与到软件的打造过程中，但所有人都能以各种形式参与到开源/自由软件的生态构建中来。开源软件生态并非有人开发软件有人使用这么简单，一个良性的开源软件生态能够帮助开发者打造更优秀的软件，并使得用户从中受益，而参与到其中的形式则多种多样。很多人第一个想到的可能是捐款，这的确是很直接的形式之一，除此之外，还有非常多的方式：

  • 例如你可以前往开发者提供的反馈渠道提交错误反馈，以帮助开发者更快的定位错误并修复错误。
  • 你也可以加入到用户社区，参与到帮助解答其它社区用户的问题的过程中，和其它社区成员一同进步。
  • 甚至仅仅是告诉朋友，“这里有一个更自由的选择”，也是个不错的做法。即便仅仅是使用，也是一种形式的支持了。

但闭源软件的质量往往更高更安全不是吗

比较中肯的回答是“不一定”。尽管简单的闭源可以非常直接的减少恶意的竞争抄袭，但并不能保证闭源软件的质量就一定比开源的高，也不能代表它们更安全。就安全与否这一议题而言，开放源代码的软件给了所有用户一窥源码的权利2，就可以拥有更多双眼睛一起协助检查发现问题，及时的发现问题更能够使得问题更早暴露而更早被修复，作为用户也自然能更早的享受到安全更新了。

开源/自由软件是否伤害到了其它开发者的利益

或许你会觉得，开放“菜谱”可能会使得“厨子”的利益受损，但实际并非如此，开源/自由的环境可以使得双方受益。例如用户的贡献使得开发者可以构建更好的应用，用户因而也可以享受更好的软件，而软件的开发者也可以提供付费技术支持给大客户。此外，“菜谱”本身也可以包含各类的开源协议来使得用户在协议限定的条件内自由使用，例如 GPL 限定了基于 GPL 协议的“菜谱”而衍生出来的“新菜品”也必须将其新“菜谱”以 GPL 协议开放出来3，避免了其它“厨子”的恶意挪用而不参与到生态的贡献中来。

当然，对于软件原作者而言，其肯定放弃了自己的部分权利，这部分“权利”针对不同开源协议而言不尽相同，但这些权利能够换得的或许是能吸引更多的用户和开发者参与到良性循环中来，最终帮自己带来更多好处的正向收益。当然，开发者有自由选择是否开源，以及选择究竟应该选择哪种开源协议来保证在自己能够接受的情况下做到更开放更自由，但倘若开发者能够接受并主动的参与到其中，就有机会为整个开源社区的环境的正向循环贡献新的力量，同时为自己也带来更多的收获。

但是 XXX 做的真的很烂

作为用户而言，或许在尝试某些开源软件作为平时做某些工作时的替代品，会觉得某个软件做的可能的确没有你曾经使用的软件好，这时候你可能会很想吐槽它实在是太难用了。不过要知道，仅仅是吐槽的话，不会对改善软件质量本身起到任何作用。开源软件的开发者也好，社区活跃的志愿者也好，普通用户群体也好，都会希望软件能够变得更好，而参与到这个过程中的所有人都是凭着自愿互助来改善整个环境的。作为开源软件的使用者而言，其它志愿者或开发者并不亏欠用户什么，而作为用户而言，能够积极的协助开发者发现并修复错误，反而比一味的吐槽更有作用。

正确的反馈问题能够使得开发者更快的修复问题改善体验，从而使用户受益。如果你恰巧碰到了一些软件错误或体验问题，抽出一点时间反馈给开发者，或许就能尽快的得到修复，何乐而不为呢？

给开发者

开源了我还怎么盈利

事实上，如果你阅读过那些开源协议，甚至仅仅是摘要，就会发现，主流开源协议中没有任何一个协议是限制你盈利的。开源自由软件盈利的方式自然也多种多样，你可以选择正常的销售你的软件并提供源码（例如 Ardour, Redis Desktop Manager , Krita Gemimi 等）或是提供付费的技术支持等。

开源就是把源代码放到 GitHub 吗

并不是说简单的将你的软件源码放到 GitHub 或者别的什么地方就叫开源，反过来也成立，即并不是说允许你看代码的项目就叫开源项目4。开源可以认为是开发者授予其它用户权利的表现，而这种授权体现在对应的协议文件中。简单的翻翻开源软件的代码仓库，你很容易找到名为 LICENSE 或 COPYING 的文件，里面的内容就是开发者所提供的授权协议，而用户则需要遵循所提供的这份开源协议的要求来规范的使用源码。所以，如果你是开发者，根据自己的接受能力和需求挑选适合的开源协议是不容忽视的一步。

倘若你不希望你的源码的使用者在发现错误后修复错误并提供到自己的产品中但不将其错误修复提供给你5，那么 GNU General Public License 或 GNU Lesser General Public License 协议很可能值得你看看，倘若你希望源码的用户随意使用你的源码而只需要保留你的大名，则 MIT 协议就是个不错的选择。当然，如果你完全不想限制用户使用你的源码，你还可以使用类似 CC0 这样的协议6。

“GPL 是病毒！”

在不同的中文开源社区中都很容易看到一种说法，称 GPL 为及具传染性的协议，讲 “如果你用了是 GPL 协议的软件，那你的软件也得是 GPL” 之类，实际上 GPL 并没有这么可怕。

比如，如果你给一个被 GPL 协议覆盖的程序写了个模块，那么你的模块是应当 能够 在 GPL 协议下使用的，对于你的源码，你可以选择任意一个 与 GPL 相兼容的许可协议 开源你的源码，而不必使用 GPL 协议。同样的，如果你只是使用了一个 GPL 协议的库，你的源码也并不要求必须使用 GPL 开源，你可以选择和 GPL 相兼容的任何许可协议发布你的代码。

如果你的程序包含任意代码是与 GPL 相结合的，并且你打算发布你的程序7， GPL 要求和 GPL 结合的程序本身必须使用和 GPL 协议兼容的协议发布，也就意味着这时候你的程序肯定是开源的了8。于是， GPL 提供了一种模式去要求其源码的使用者也参与到开源自由软件的开发生态中来。对于原开发者来说其具有一定保护作用，而对于整个开源生态而言它也具有推进的作用。当然，它至少很明确你的程序是需要开源的了8，如果你在选择协议的过程中认为这个要求有些过于严格，那么很可能你应该看看其它的协议，如上面提到过的 LGPL ，Apache，MIT 或 BSD 协议等等。

GPL 是一个能够保障用户使用自由的前提下也能保护开发者的成果不被转变为非自由软件的协议，然而正如上面的例子，很多人（包括几年前的我）在仅仅是听他人谈论过 GPL 的情况下就觉得 GPL 可能很可怕而规避使用。实际上，简单的检索 GPL 的常见问答页面 就能找到很多问题的答案，也能消除很多对 GPL 的误解了。

当然，作为软件的开发者，使用任何协议发布你的软件是你的自由，如果你在了解 GPL 协议之后依然觉得它可能不符合你的预期，那么选择一个其它的更符合你自身需求的许可协议显然是更正确的做法。使用任何你喜欢的协议发布软件是你的自由，但我们仍希望我们的选择不要建立在一个错误的印象之上不是吗？

其它常见问答

开源软件都良心，都安全，可以随便用，对吗

并不是。尽管开放源代码可以带来更多双眼睛帮助检查代码是否安全，但并不能保证你看到的一份代码就一定是安全可靠的，甚至不能保证它没有恶意代码。以下按照可用性和是否恶意两方面简单描述。

对于可用性，很多开源协议都具有对应的免责条款，即不需要为程序可能存在的潜在缺陷承担责任（想象一下一份存粹兴趣爱好撑起来的代码却需要因为无意导致的程序缺陷而向使用者给予赔偿是一件多可怕的事情）。不过用户也不必因此过于担心，如果项目非常活跃，积极维护代码，维护者可靠，那么对应项目的可用性也相对更好了，而对于维护者较少的项目或个人项目，那么花一点时间评估代码质量则是个不错的选择，当然，如果你选择了一份较为冷门的开源项目，参与进来一起进行开发对于原开发者和你自己而言都是好事。

而软件是否是恶意软件则实际和开源与否并无关联。恶意软件可以挂着开源的名号引诱一些不加辨别就使用开源软件/库的人上当，而这种做法在闭源的情况也不稀奇——例如包含恶意代码的闭源第三方库或是一些伪装成免费“绿色”软件的木马。无论开源或闭源，我们在使用任何软件之前都应当仔细辨别并时刻注意信息安全，而开源软件则在我们一般能做的防范工作之外，给予了我们通过源码检查其安全性的能力。

凭什么我不能为一个只有 GPL 协议授权的软件开发非自由/闭源插件

开发者为其软件选择许可协议，无论是开源还是闭源软件，自由或是非自由软件，都是为了能够保障许可协议上所列出的权益，而 GPL 则是众多协议中的一种。 GPL 试图保障开发者和用户的使用权益，其中的一些做法可能相对其它协议更严格，但无论如何如果开发者选择使用这份协议，作为用户则只有接受协议或拒绝协议这两种选择。正如同其它所有开源协议或闭源的最终用户许可协议一样，如果你不能够接受其协议，正确的选择只有拒绝并放弃使用这份软件，并尊重开发者的选择。

如果软件开发者本身更希望提供相对更宽松限制的许可，那么开发者应当选择比 GPL 更松弛的其它许可协议，或是在发布软件时和 GPL 协议一同附带相应需求的附加条款8。但倘若开发者并没有这么做，那我们应当尊重开发者选择 GPL 协议的做法，并遵守使用协议来使用软件和源码。

另外，正如上方所提到的，无论何时，在使用软件之前充分了解使用协议所提供的权益和限制都是重要的。作为用户，理解使用协议是用户使用软件前应该做的事情。

写这一篇是因为平时会遇到不甚了解开源自由软件的人，一些甚至已经在使用开源自由软件但并不知道自己也能参与到其中的人，以及一些对开源软件和相关协议有误解的人。这篇的目的就是简单的给遇到的这些人所对应的一些常见情况的罗列和阐述。如果你恰巧阅读了这篇文章并觉得这篇文章有任何错误，疏漏，或是建议，可以任意方式与我取得联系。同时，你可以在遵循 CC BY 4.0 协议的前提下任意使用这篇文章。

  1. 仍需要遵循开源协议，后述。 ↩

  2. 尽管如此，也并不能代表所有的“开源软件”就都是安全的，无论开源或闭源软件，都应当具备基本的安全意识，仔细辨别然后使用。 ↩

  3. 并不是很精准的比喻，另外在中文博文中常常能见到对 GPL 的错误解读。如果你是开发者，请阅读 GPL 原文。 ↩

  4. 比如 Unreal Engine 并不是开源自由软件，你只是能够看代码罢了。 ↩

  5. 这里的 “提供到自己的产品中” 代表 “发布” 的意思。如果他人只是使用了你的 GPL 覆盖的源码到了他并不打算发布的软件中时，他并不需要提供任何源码给你，你也不能因此要求开源其未发布且不打算发布的程序源码。 ↩

  6. 其实这里本来打算写的是个叫 WTFPL 的协议，但出于名字不雅很多时候这个协议“上不了台面”。不过鉴于我喜欢这个协议所以我还是打算在脚注提一下它 :P ↩

  7. 如果仅仅是自用的话，你不需要“发布”你的程序，进而也 不需要 将其开源或是提供你的任何修改了。 ↩

  8. 如果你所使用的 GPL 代码有附带其它条款，这些其它条款中的条目可能会将 GPL 的要求放宽。比如一个 GPL 协议发布的程序支持插件功能，而如果这个程序附带了条款允许程序链接到非自由程序中，那么如果你要为这个程序开发插件，你也可以选择以非自由的形式发布你的插件。 ↩ ↩2 ↩3