近几年开源技术快速发展，在云计算、移动互联网、大数据等领域逐渐形成技术主流。开源一方面可以突破技术壁垒，推动技术创新，另一方面，不可避免的带来知识产权、信息安全等一系列问题。
逛Github时经常看到项目README旁边，有个License tab，不知道大家是不是跟我一样，撇了一眼就过去了，不太清楚这个license具体作用，有点法律意识的朋友可能会意识到这个可能是版权声明，不过难免还是会有其他疑问：既然都开源了，怎么还有各种条件限制？除了GPL还有Apache、MIT等，这些"License"又有哪些区别呢？
开源是近年来大火的词汇。自2017年7月Facebook的React开源软件被Apache基金会宣布禁止使用、百度也宣布全面停止使用以来，开源软件的合规性使用引发了大家的关注。
对于国内习惯了使用开源软件或框架，类库的程序员群体来说，最熟悉的License应该是开源许可证，也就是Open Source License。在开源许可证中，接触最多的可能是Apache License以及MIT这两个应用较为普遍的许可证了。
目前，开源软件被大规模的使用在生产环境，包括Linux，MySQL这些基础软件，以及各细分领域的专业软件，比如做大数据处理的hadoop/kafka/storm，搞机器学习的tensorflow等，可以说我们每天都在直接或间接的使用开源软件。使用开源软件就一定要遵循它的许可证，否则可能会面法律纠纷和行业谴责。
开源从开始到现在已经有几十年历史，开源许可证在开源运动的发展中起到了基石作用，不管是从文化还是法律的角度，都较好地推动了开源的发展。
2019年8月，中国开源云联盟（COSCL）推出了中英版的木兰宽松许可证, 第1版（Mulan PSL v1）[1]，被称为中国首个官方开源软件许可协议。由于当前主要的开源软件许可证大多来自欧美社区，而且这些许可证的文本语言，在法律上有效的大多是英文。因此，这张由中国的开源组织推出的中文许可证，引发了业内不小的关注，这些关注大多是项目开发等技术角度的。而本文的关注点在于，从法律与合规的层面怎么来看木兰许可证，以供开发者、软件项目参考。
开源许可证从最早的 GPL 开始， 逐渐演进到 GPLv2 和 v3，中间还有 Apache、MPL、AGPL、LGPL 等，但是近几年来有一批新的许可证的出现，引起了社区的一些激烈的讨论。这些新的许可证包括 BSL、SSPL、Elastic 以及一个比较特殊的附加条款 Commons Clause。
过去几年，开源界一片火热，开源软件技术已全面进军操作系统、云原生、人工智能、大数据、半导体、物联网等行业领域。
近日，开放源代码促进会（Open Source Initiative，以下简称 OSI ）在官网发布文章，转述了一项来自美国法院的判决：未获 OSI 开源许可证许可，而自称「开源」的软件属于虚假广告。 OSI 成立于 1998 年，是一个旨在推动开源软件发展的非盈利组织。多年来，OSI 在制定开源协议标准、促进开源推广上做出了重要贡献，是公认的开源「官方」组织。此次来自美国联邦第九巡回上诉法院的判决，也是从法律层面对 OSI 在开源领域的权威性进行了认定。 一 事件回顾 本次案件的判决方——第九巡回上诉法
国际公认的开源许可证有 80 多种，共同特征是允许用户免费使用、修改、共享源码，只是都有各自使用的条件。
在很多人眼中，「开源」是一个时髦且有情怀的词汇，始终伴随有理想主义色彩，因此不少公司开始给自己贴上“开源”标签。但一个优秀的开源项目远远不止是简单的公开源代码，而是需要将其当作公司战略进行贯彻，才能架设起牢不可破的信任桥梁。
开源软件一般都有对应的开源许可证（Open Source License）对软件的使用、复制、修改和再发布等进行限制。许可证即授权条款，开源许可证就是保证开源软件这些限制的法律文件，目的在于规范受著作权保护的软件的使用或者分发行为。开源许可证是开源软件生态系统的基础，可以促进软件的协同开发。
感谢张俊霞老师提供反馈意见。张俊霞老师是中国信息通信研究院高级工程师，知识产权中心副主任，开源社法律咨询委员会成员。张老师在信通院主要工作范围包括专利分析、评估、风险预警，及软件相关知识产权问题研究。
发现国内不少软件都开源了。但很奇怪，他们都有自己相同一套的软件版权许可协议。这些软件许可协议跟开源本身的精神是有冲突的。举个例子： 摘自Discuz!NT 里的许可协议：禁止在 Discuz!NT 的整体或任何部分基础上以发展任何派生版本、修改版本或第三方版本用于重新分发。 与其它条款无抵触的前提下，允许以自用为目的的进行进行二次开发或整合，但同样受前文第3项约束和限制，即保留Discuz!NT名称与链接。 以上规定显然是违背开源精神的，通过OSI认证的许可协议：如GNU GPL
什么是开源许可证，它们如何运作？以下指南适用于创作者、用户以及其他想要参与这场精彩的开源运动的人士。
2022年1月份，Apache SkyWalking社区在其blog上实锤字节跳动的火山引擎里面违反Apache 2.0许可证，重新发布了Apache SkyWalking开源软件。
作为一个开发者，如果你打算开源自己的代码，千万不要忘记，选择一种开源许可证（license）。 许多开发者对开源许可证了解很少，不清楚有哪些许可证，应该怎么选择。本文介绍开源许可证的基本知识，主要参考
作为一个开发者，如果你打算开源自己的代码，千万不要忘记，选择一种开源许可证（license）。
在软件领域，开源和专有软件是两种主要的授权模式。它们在许多方面都有所不同，从开发方式、商业模型到用户权利等。本文将深入探讨这两种软件的特点，以及它们之间的主要差异。
开源意味着创作者将软件、硬件甚至是大语言模型免费提供给社区使用。开源项目通常由社区中来自不同公司的开发者共同努力开发和维护。产品或软件的许可证类型明确规定了可以如何使用不同的开源产品。
本文介绍了GitHub中开源许可证的作用以及如何在项目中添加和修改开源许可证。作者以自己项目为例，讲解了如何在GitHub上创建新的许可证，并提供了相关实用资料链接。
不久前笔者写了一篇《如何选择开源许可证》来分享如何为开源项目选择开源许可证，这是一篇小型的科普文章，目的是为了打破一些人对开源的妄想，开源并没有那么高深，只要你愿意去了解并认同开源的理念，就可以成为开源运动的参与和贡献者。
没有开源软件，现在的互联网根本无法存在，开源的历史可以追溯到 ARPANET 建立。开源在今天已经不再是一个时髦的词了，对于互联网的开发者来说，它现在就像空气和水一样，就在我们的生活中。
[2be4df79f80801fcb9df711c64f0c0a6bf3.jpg] 摘要 本文翻译自 CMSWire 网站的《Open Source vs. Open Core: What's the
CockroachDB 是一个开源的分布式数据库，最近改变了代码授权，放弃了 Apache 许可证。
没有开源软件，现在的互联网根本无法存在，开源的历史可以追溯到ARPANET建立。开源在今天已经不再是一个时髦的词了，对于互联网的开发者来说，它现在就像空气和水一样，就在我们的生活中。
开源计划办公室最重要的责任之一，是要在整合开源代码与专有的、第三方的源代码到商业产品中时，确保您的组织符合其法定义务。
Grafana、Grafana Loki 和 Grafana Tempo 从 Apache License 2.0 转为 AGPL v3 许可证。而相关插件、代理与部分特定库仍将保持 Apache 许可状态。
1． 使用该开源软件的代码再散布（redistribute）时，源码也必须以相同许可证公开。
Linux发行版本实在太多了，成千上万肯定是有的。但我们常用的其实主要就是少数几个发行版本，这样的发行版本，我把它称为“主流的Linux发行版本”。
开源即开放源代码，兴起于软件行业，是源代码可开放共享的开发模式。开发者依托互联网平台，通过共同参与协作，不断累积群体智慧，实现持续创新的方法，具有自由开放、共建共享的特性，是促进信息技术创新的重要途径。开源对于量子计算产业技术价值的提升具有重要意义，同时还有利于提升企业的市场影响力以及产业生态的协同构建。本文将阐述量子计算与开源软件的关系。
写前一篇网志时，我参考了Ryan Paul的文章。 他是资深Linux程序员和评论者。他对Android许可证的评论，是我见到的最准确、最通俗易懂的介绍。当时，我翻译了一些片段，打算在自己的文章中引用，但是后来没用上。我觉得不甘心，于是今天就把全文译出，贴在下面，希望让更多的朋友看到。 如果你对GPL、ASL、BSD这一类的许可证名字，只有一些模模糊糊的概念，搞不清楚它们之间的区别。那么，我强烈推荐你阅读此文，读完后，你就会对开源软件的许可证，有一个基本的认识了。 值得指出的是，此文写于2007年，当时Go
几周前，Apache软件基金会（ASF）决定将BSD +专利许可证列为Category-X license。这一举措影响了Facebook开源软件的大部分用户，特别是受欢迎的React项目及其周边项目。因此，有许多人要求我们考虑修改React和所有其他开源项目的证书。通过这些讨论，我们可以清晰地看到，ASF与Facebook在维护和分发开源软件的出发点上有很大的不同。
平时我们在日常开发生活都在大量和开源软件打着交道，例如安卓、Linux、Github、Docker等，而其中开源协议比如MIT、Apache也是耳熟能详，但是真正对开源协议的了解相信对大部分人来说都是一知半解。而近来频繁冒出一些事件让我们对开源协议产生了更大的疑问。
开源许可协议是指开源社区为了维护作者和贡献者的合法权利，保证软件不被一些商业机构或个人窃取，影响软件的发展而开发的协议。开源协议规定了用户在使用开源软件时的权利和责任，虽然不一定具备法律效力，但是当涉及软件版权纠纷时，也是非常重要的证据之一。
呼吁“禁止开源”最早出现在去年秋天——部分原因是Meta和其他公司“开放”大型语言模型 (LLM)。游说者在政治集会和政策圈中四处散布这个词。然而，许多批评者无法解释开源在任何情况下意味着什么，并且不熟悉开源定义 (OSD)。不知道或不理解技术细节似乎并不妨碍分享负面意见。
世界上的开源许可证（Open Source License）大概有上百种，而我们常用的开源软件协议大致有GPL、BSD、MIT、Mozilla、Apache和LGPL。
延迟开源发布（DOSP）的做法，是首先以私有许可证发布软件，然后按计划过渡到开源许可证。
主流的开源协议有哪些？我们该如何选择？ License是软件的授权许可，里面详尽表述了你获得代码后拥有的权利，可以对别人的作品进行何种操作，何种操作又是被禁止的。软件协议可分为开源和商业两类，对于商业协议，或者叫法律声明、许可协议，每个软件会有自己的一套行文，由软件作者或专门律师撰写，对于大多数人来说不必自己花时间和精力去写繁长的许可协议，选择一份广为流传的开源协议就是个不错的决策。 世界上开源软件协议OPEN SOURCE LICENSE的种类非常之多，并且同一款协议有很多变种，协议太宽松会导致作者丧失对
最近，Redis 从开放源代码的 BSD 许可证过渡到了更加限制性的 Server Side Public License (SSPLv1)。一石激起千层浪，Redis 的这一举动，不仅分化了前 Redis 维护者，也再次引发业界对于“开源项目可持续性以及许可证决策对其社区的影响”的讨论。
作者：pdai 开源不等于免费！为了加速我们的开发，我们会使用开源的软件和源码； 为避免商业风险，需要在使用时了解第三方如软件协议，版本，和已知CVE风险等；本文旨在从开源软件再发布过程使用权限的角度入手，总结各个常见开源协议的异同，方便理解。
开发人员经常在软件中引入开源的代码片段、函数、方法和操作代码。因此，软件代码中经常会包含各种声明不同许可证的子组件。这些子组件的许可证条款和条件与项目整体主许可证的条款和条件冲突时，就会产生许可证合规风险。
因而国内各界开始重新审视开源项目的法律约束问题。人们呼吁：我们也需要更多 “开源自立”。
License是软件的授权许可，里面详尽表述了你获得代码后拥有的权利，可以对别人的作品进行何种操作，何种操作又是被禁止的。软件协议可分为开源和商业两类，对于商业协议，或者叫法律声明、许可协议，每个软件会有自己的一套行文，由软件作者或专门律师撰写，对于大多数人来说不必自己花时间和精力去写繁长的许可协议，选择一份广为流传的开源协议就是个不错的决策。
近段时间，数据库的开源领域动作很多，很多大厂也纷纷加入开源行业。之前也分享过关于开源的一些内容。近期读些资料，对开源有了些新的认识，特分享如下。下面是之前两篇开源话题的文章。
詹毅律师评 “木兰”许可证是法律文件，是份格式的标准化合约。因此，这个说明，如果想具有同样的效力，不应以文章的形式。而应以“木兰”许可证的附件的形式，以让已经或有意遵循的项目，有法律效力上的可期待性。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
