mirror of
https://github.com/Dichgrem/Blog.git
synced 2025-02-23 14:08:37 -05:00
199 lines
15 KiB
Markdown
199 lines
15 KiB
Markdown
+++
|
||
title = "乱七八糟:开源软件与协议"
|
||
date = 2024-03-03
|
||
|
||
[taxonomies]
|
||
tags = ["乱七八糟"]
|
||
+++
|
||
|
||
前言 本文旨在介绍开源以及开源许可证，这些许可证规定了使用、修改和分发开源软件的条件。通过了解不同类型的开源许可证及其特点，读者将能够更好地理解在开发和使用开源软件时的法律和道德责任。
|
||
<!-- more -->
|
||
|
||
## 开源的概念
|
||
|
||
「开源」一词对应英文 Open Source，最初起源于软件开发领域，因此也称为「开放源代码」，对应的软件则称为开源软件（Open Source Software，简称 OSS）。除了我们熟知的开源软件以外，开源的表现形式还有很多，例如开源硬件（Open Source Hardware）、开放设计（Open Design）、开放文档（Open Document）等等。开源的目的是分享共享、加速创新，可以说开源已经成为一种超越软件生产界限的运动和工作方式。
|
||
|
||
对于很多刚踏入软件这个行业的小伙伴来说，「开源」是个比较陌生的概念。但是随着经手项目逐渐增多，会发现很多项目，尤其是一些大型项目，经常会引用到别人一些优秀的开源代码，而这些优秀的开源代码通常都会在最开始简单地附上一段关于授权的声明或在项目根目录下提供完整的授权声明文件，比如：「The project is licensed under the Apache 2 license.」，诸如此类便是「开源许可证」。
|
||
|
||
开源不等于免费，开源也不等于没有约束
|
||
|
||
### **开源的好处**
|
||
#### **1. 透明度和安全性**
|
||
开源软件的代码是公开的，任何人都可以检查和改进它。这使得潜在的安全漏洞更容易被发现和修复，提升了软件的安全性。
|
||
|
||
#### **2. 促进创新**
|
||
开源允许开发者自由研究和修改代码，推动技术进步。例如，Linux、Python、TensorFlow 等开源项目极大地促进了计算机科学和人工智能的发展。
|
||
|
||
#### **3. 降低成本**
|
||
企业和个人可以免费使用开源软件，而不需要支付高昂的许可证费用。例如，使用 Linux 服务器代替 Windows Server 可以减少 IT 成本。
|
||
|
||
#### **4. 快速迭代和社区支持**
|
||
开源项目通常由全球开发者社区维护和改进，Bug 修复和新功能开发的速度比封闭源代码的软件更快。例如，开源浏览器 Firefox 就依赖社区贡献不断改进。
|
||
|
||
#### **5. 避免供应商锁定**
|
||
开源软件允许用户自由选择和修改代码，而不是被某个公司的专有软件绑定，避免了供应商锁定的问题。例如，MySQL 和 PostgreSQL 等开源数据库是很多企业的首选，避免依赖单一厂商。
|
||
|
||
## 开源软件
|
||
开源软件，顾名思义是指能够免费且不受限制地使用、再开发、再发布的软件。但在狭义上，只有符合开放源代码促进会（Open Source Initiative）定义的软件才能被称为开源软件。这个定义提出了十个特征，必须全部符合才能认定为开源软件。
|
||
|
||
这些特征包括：
|
||
```
|
||
可自由再分发。
|
||
|
||
提供源代码。
|
||
|
||
允许衍生作品。
|
||
|
||
不得过度限制原始代码的修改。
|
||
|
||
不得歧视特定人、群体或用途。
|
||
|
||
必须「技术中立」等。
|
||
```
|
||
根据这些标准，一些看似自由使用的软件可能不符合开源软件的定义。例如，Elasticsearch原本使用Apache 2.0授权，是真正的开源软件。但面对云服务提供商如AWS等将其用于营利目的却不回馈改进的情况，Elasticsearch在2021年1月选择了SSPL（Server Side Public License，服务器端公共许可证）和Elastic License两种许可证并行；SSPL要求如果将程序的功能或修改后的版本作为服务提供给第三方，则必须免费公开提供服务源代码，这违背了开源软件的定义。另一方面，Elastic License要求不能向第三方提供主机或托管服务，也违反了开源软件的定义，因此也不算严格意义上的「开源」。
|
||
|
||
|
||
## 常用优秀开源软件
|
||
|
||
以下是一些常用的跨平台开源软件，涵盖了多个领域，包括办公、开发工具、多媒体处理等。
|
||
|
||
| 分类 | 软件名称 |
|
||
|--------------|---------|
|
||
| **输入法** | Rime, Fcitx |
|
||
| **浏览器** | Brave, FireFox, Floorp |
|
||
| **解压** | PeaZip |
|
||
| **下载器** | Motrix |
|
||
| **播放器** | VLC |
|
||
| **密码管理器** | KeePassXC, BitWarden |
|
||
| **邮件客户端** | Thunderbird |
|
||
| **Office** | OnlyOffice, LibreOffice |
|
||
| **RSS 阅读器** | Fluent Reader, News |
|
||
| **电子书阅读器** | Readest, Koodo Reader & Legado, KOReader, Celibre |
|
||
| **本地音乐** | VLC, Harmonoid, Strawberry, Metro |
|
||
| **截屏** | Flameshot, Snipate |
|
||
| **录屏** | OBS Studio |
|
||
| **Matrix** | Element/SchildiChat, FluffyChat, MatterMost |
|
||
| **网盘** | Alist, NextCloud |
|
||
| **笔记** | Joplin, logseq, siyuan, notesnook, Trillium, Bluestone |
|
||
| **文件同步** | SyncThing |
|
||
| **文件传送** | LocalSend, KDE connect |
|
||
| **远程文件传输** | muCommander, cyberduck |
|
||
| **S3 文件管理** | muCommander |
|
||
| **SSH 终端** | Tabby, electerm, Termux, NxShell |
|
||
| **代码编辑** | VSCodium |
|
||
| **远程桌面** | RustDesk, moonlight |
|
||
| **内网穿透** | NPS, ZeroTier, Tailscale/HeadScale, Nconnect |
|
||
|
||
|
||
## 开源许可证
|
||
|
||
开源许可证是软件许可证的一种特殊形式，用于规定开源软件的使用、修改、分享等相关事宜。它是一种格式合同，涉及版权、专利、商标等权利义务，自动生效。
|
||
|
||
在美国，一些法院认为软件许可证是合同（contract），一些法院则认为是许可（license）。两者的区别在于，许可在传统上是由地产或物主作出的，目的在于允许他人使用自己的地块或物品。因此，它是单方向的，不构成完整的合同，而是作为合同的一个要素，用来和他人交换的条件。由于合同和许可之分在法律上有着重要的意义，它们的违约救济和版权侵权救济等方面有着不同的规定。
|
||
|
||
与美国不同，大陆法系国家如中国普遍认为开源软件许可证构成合同，但这种合同是事先规定好的标准化格式合同，并且自动生效。
|
||
|
||
开源许可证的种类繁多，据不完全统计，广义上的开源许可证超过200种，其中OSI批准的许可证有96个。这些许可证的内容各不相同，有些条款非常有意思，例如，啤酒软件许可证（Beerware License）规定，用户与作者聚会时可以请作者喝一杯啤酒；Jason Hunter 许可证规定，如果将该许可证下的代码用于商业目的，那么项目开发团队的所有成员都必须拥有 Jason Hunter 撰写的《Java Servlet编程》最新版。
|
||
|
||
## 常见开源许可证
|
||
|
||
世界上的开源许可证（Open Source License）大概有上百种，而常见的开源协议大致有GPL、BSD、MIT、Mozilla、Apache和LGPL等。
|
||
|
||
|
||
## Apache License
|
||
|
||
Apache License（Apache许可证），是Apache软件基金会发布的一个自由软件许可证。
|
||
|
||
Apache Licence 是著名的非盈利开源组织 Apache 采用的协议。该协议和BSD类似，同样鼓励代码共享和最终原作者的著作权，同样允许源代码修改和再发布。但是也需要遵循以下条件：
|
||
|
||
- 需要给代码的用户一份 Apache Licence。
|
||
- 如果修改了代码，需要再被修改的文件中说明。
|
||
- 在衍生的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。
|
||
- 如果再发布的产品中包含一个 Notice 文件，则在Notice文件中需要带有 Apache Licence。你可以在 Notice 中增加自己的许可，但是不可以表现为对 Apache Licence 构成更改。
|
||
|
||
Apache Licence 也是对商业应用友好的许可。使用者也可以再需要的时候修改代码来满足并作为开源或商业产品发布/销售。
|
||
|
||
使用这个协议的好处是:
|
||
|
||
- 永久权利 一旦被授权，永久拥有。
|
||
- 全球范围的权利 在一个国家获得授权，适用于所有国家。假如你在美国，许可是从印度授权的，也没有问题。
|
||
- 授权免费 无版税， 前期、后期均无任何费用。
|
||
- 授权无排他性 任何人都可以获得授权
|
||
- 授权不可撤消 一旦获得授权，没有任何人可以取消。比如，你基于该产品代码开发了衍生产品，你不用担心会在某一天被禁止使用该代码
|
||
|
||
## BSD
|
||
|
||
BSD 是"Berkeley Software Distribution"的缩写，意思是"伯克利软件发行版"。
|
||
|
||
BSD开源协议：是一个给于使用者很大自由的协议。可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。 当你发布使用了BSD协议的代码，或则以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件：
|
||
|
||
- 如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
|
||
|
||
- 如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
|
||
|
||
- 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。
|
||
|
||
BSD代码鼓励代码共享，但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。
|
||
|
||
## GPL
|
||
|
||
GPL （GNU General Public License） ：GNU通用公共许可协议。
|
||
|
||
Linux 采用了 GPL。
|
||
|
||
GPL 协议和 BSD, Apache Licence 等鼓励代码重用的许可很不一样。GPL 的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。这也就是为什么我们能用免费的各种 linux，包括商业公司的 linux 和 linux 上各种各样的由个人，组织，以及商业软件公司开发的免费软件了。
|
||
|
||
## LGPL
|
||
|
||
LGPL是GPL的一个为主要为类库使用设计的开源协议。和 GPL 要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。LGPL允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用 LGPL 协议的开源代码可以被商业软件作为类库引用并发布和销售。
|
||
|
||
但是如果修改 LGPL 协议的代码或者衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用 LGPL 协议。因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以 LGPL 协议代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。
|
||
|
||
GPL/LGPL都保障原作者的知识产权，避免有人利用开源代码复制并开发类似的产品。
|
||
|
||
## MIT
|
||
|
||
MIT是和BSD一样宽范的许可协议,源自麻省理工学院（Massachusetts Institute of Technology, MIT），又称X11协议。作者只想保留版权,而无任何其他了限制。MIT与BSD 类似，但是比 BSD 协议更加宽松，是目前最少限制的协议。这个协议唯一的条件就是在修改后的代码或者发行包包含原作者的许可信息。适用商业软件。使用MIT的软件项目有：jquery、Node.js。
|
||
|
||
MIT与BSD类似，但是比BSD协议更加宽松，是目前最少限制的协议。这个协议唯一的条件就是在修改后的代码或者发行包包含原作者的许可信息。适用商业软件。使用MIT的软件项目有：jquery、Node.js。
|
||
|
||
## MPL (Mozilla Public License 1.1)
|
||
|
||
MPL 协议允许免费重发布、免费修改，但要求修改后的代码版权归软件的发起者 。这种授权维护了商业软件的利益，它要求基于这种软件的修改无偿贡献版权给该软件。这样，围绕该软件的所有代码的版权都集中在发起开发人的手中。但MPL是允许修改，无偿使用得。MPL 软件对链接没有要求。
|
||
|
||
## EPL (Eclipse Public License 1.0)
|
||
|
||
EPL允许 Recipients 任意使用、复制、分发、传播、展示、修改以及改后闭源的二次商业发布。
|
||
|
||
使用EPL协议，需要遵守以下规则：
|
||
|
||
当一个 Contributors 将源码的整体或部分再次开源发布的时候,必须继续遵循EPL开源协议来发布,而不能改用其他协议发布.除非你得到了原"源码"Owner 的授权；
|
||
|
||
EPL协议下,你可以将源码不做任何修改来商业发布.但如果你要发布修改后的源码,或者当你再发布的是 Object Code 的时候,你必须声明它的 Source Code 是可以获取的,而且要告知获取方法；
|
||
|
||
当你需要将EPL下的源码作为一部分跟其他私有的源码混和着成为一个 Project 发布的时候,你可以将整个 Project/Product 以私人的协议发布,但要声明哪一部分代码是EPL下的,而且声明那部分代码继续遵循EPL；
|
||
|
||
4.独立的模块(Separate Module),不需要开源。
|
||
|
||
## Creative Commons 知识共享协议
|
||
|
||
Creative Commons (CC) 许可协议并不能说是真正的开源协议，它们大多是被使用于设计类的工程上。 CC 协议种类繁多，每一种都授权特定的权利。 一个 CC 许可协议具有四个基本部分，这几个部分可以单独起作用，也可以组合起来。下面是这几部分的简介：
|
||
|
||
- 署名 作品上必须附有作品的归属。如此之后，作品可以被修改，分发，复制和其它用途。
|
||
|
||
- 相同方式共享 作品可以被修改、分发或其它操作，但所有的衍生品都要置于CC许可协议下。
|
||
|
||
- 非商业用途 作品可以被修改、分发等等，但不能用于商业目的。但语言上对什么是"商业"的说明十分含糊不清 (没有提供精确的定义)，所以你可以在你的工程里对其进行说明。例如，有些人简单的解释"非商业"为不能出售这个作品。而另外一些人认为你甚至不能在有广告的网站上使用它们。 还有些人认为"商业"仅仅指你用它获取利益。
|
||
|
||
- 禁止衍生作品
|
||
|
||
CC 许可协议的这些条款可以自由组合使用。大多数的比较严格的CC协议会声明 "署名权，非商业用途，禁止衍生"条款，这意味着你可以自由的分享这个作品，但你不能改变它和对其收费，而且必须声明作品的归属。这个许可协议非常的有用，它可以让你的作品传播出去，但又可以对作品的使用保留部分或完全的控制。最少限制的CC协议类型当属 "署名"协议，这意味着只要人们能维护你的名誉，他们对你的作品怎么使用都行。
|
||
|
||
CC 许可协议更多的是在设计类工程中使用，而不是开发类，但没有人或妨碍你将之使用与后者。只是你必须要清楚各部分条款能覆盖到的和不能覆盖到的权利。
|
||
|
||
## 参考
|
||
|
||
- [开源软件指南](https://opensource.guide/zh-hans/)
|
||
- [Browse Software Licenses and Summaries](https://www.tldrlegal.com/browse)
|
||
- [开源协议检索](https://opensource.org/license)
|
||
- [开源指北](https://oschina.gitee.io/opensource-guide/) |