开源许可证的选择，你选对了吗？
出品|CSDN（ID：）
好多创业公司纠结于怎样设计开源项目的商业模式，以下内容是笔者目前对此问题的摸索，权当抛砖引玉。
开源许可证
既然我们决定了“向量搜索引擎”（笔者所在公司在上开源项目）要开源，第一步便是要选择合适的开源许可证。似乎自由软件创始人RMS以前提倡概念，但也是一种特殊的。
这么，哪些是开源许可证？简单来说，一个许可证只要经过OSI（Open）认证，就可以被称之为开源许可证。OSI有专门的流程来初审一个许可证是否符合开源定义（Open）。
例如说赚钱软件，新设计的SSPL（SeverSide）在完成OSI认证之前，只能说自己的许可证是源码可用（）赚钱软件，而不能说自己是开源（其实，这个限制属于行业惯例，没有强制性）。
目前主流的开源许可证，可以在OSI网站上查询到。网上也有好多文章去比较各个许可证之间的不同（可参考阮一峰老师的博客），我就不一一赘言了。
这儿主要结合我们的自身情况来谈一下开源许可证的选择。开源许可证简单来说，可以分为三档：
•严格，以GPL2.0许可证为代表，典型软件是MySQL
•适中，以2.0许可证为代表，目前使用最广泛
•修身，以BSD，MIT，许可证为代表，典型软件是
熟悉数据库的同事一定晓得MySQL和。MySQL是最流行的开源数据库，但是衍生项目最多的开源数据库。现今的新项目甚少使用GPL2.0许可证，它的传染性应当是你们最有疑虑的地方。
对于推广基础技术来说，MIT/BSD类的许可证是一个好选择。可能如今早已甚少人使用。但它也还在不断的发展，由于采用特别修身的2--BSD许可证，被不少厂商拿来开发自己的闭源系统。
例如，Sony的Play3和4的系统都基于，还有任天堂的游戏机也是。
Redis也采用修身的3--BSD许可证（相比2-多了对商标的使用限制）。不过，Redis整个工具链的许可证情况非常复杂。
以至于当Redis切换部份组件的许可证时，造成了业界很大的误会。因而中途将许可证变严格是件有点敏感的事情。
看上去颇为复杂的Redis许可矩阵
假如下策太紧，上策太缓。这么就选择中间的2.0。2.0目前是基金会与CNCF基金会推荐的默认开源许可证。
网站对2.0许可证的简易说明
2.0像其他开源许可证一样不限制商业使用，专利授权也默认包含其中。不过2.0也明晰规定了在此开源许可证下软件厂商的免责条款。这也就是提供订阅增值服务的法律基础。
不过虽然是2.0那么成熟的开源许可证，你们还是有一个担忧：公有云。
须要防范公有云厂商吗？
开源软件与公有云的关系这三年有点紧张，一个比较流行的观点是公有云导尿吸血开源软件，而对开源社区没有太多贡献。
不少开源项目开始找寻在公有云面前保护自己的方式。虽然公有云的出现，一定程度上搅乱了原有的开源商业模式。最终用户通过订购云服务，从公有云服务商哪里得到了保障，开源厂商被绕过了。
于是，应运而生。是一种附加条款，开源厂商仍然须要选择一个基本的主许可证。最终的方式类似：2.0+1.0。
比较精炼，全文只有3句话。
主要严禁别人在不降低开源软件价值的情况下，借助开源软件行骗。它的限制性主要彰显在以下三点：
假定第三方在开源软件的基础上建立了一整套面向用户的应用，这套新应用降低了原开源软件的价值，这么这套新应用不会遭到任何限制。这一点保证了开源厂商与合作伙伴之间的合作关系不会遭到影响。
不过没有经过OSI认证，因而添加了之后建议只说自己是源码可用（）。其实会造成一定的争议，不过初创开源项目选择添加看上去正遭到越来越多人的理解。
但是，我们的开源项目并不准备加上。有两个重要的诱因。
的启示
是开源项目成功的范例。一开始就采用AGPL3.0许可证。假如公有云要借助提供服务，这么公有云厂商须要公布相关底层服务的源码。因而，AWS，Azure，Cloud等一众日本公有云都选择自行开发文档型数据库。
而在日本以外，却很难用法律装备保护自己。2018年10月更改新版本的许可证时，再度埋怨了公有云厂商对利益的侵犯，主要指的就是日本以外的公有云厂商。
因而，志在全球的开源基础软件厂商或许很难仅靠一个许可证来对自己进行全面的保护。
另一方面，当AWS有了；Azure有了DB；Cloud有了Cloud以后，文档数据库不再是一家独大。在以后的联通互联网浪潮中，联通端的没有达到期盼中的影响力。
虽然Realm这样的联通端文档数据库可以直接和多个公有云文档数据库同步，极大的便捷了联通开发者。2019年4月，以3900万美金竞购了Realm。
防范他人的同时也部份影响了自己的发展空间，是否值得？答案因人而异，开源项目须要结合自身情况做出一个选择。
八爷的新策略
据咨询公司的统计，Cloud2018年抢占公有云IaaS市场4.0%的份额，排名全球第四。仍然不及老大AWS市场占有率（47.8%）的一个零头。Cloud想迎面赶上，他该如何办？
在去年的CloudNext会议上，新上任的CloudCEO一举请来了RedisLabCEO与CEO帮忙站台。
会议上Cloud推出了Redis的托管服务，上了Cloud。后续的Atlas云服务还和Cloud展开了一系列合作。
Redis和在开源界与互联网行业有较大的技术影响力。并且她们是开源界对公有云厂商开炮比较多的两家。
近日她们又先后针对公有云厂商更改了自己的许可证。因而CloudNext会议上传达的信息很有意思。
与成熟的开源厂商合作，看上去正是Cloud的新策略。这条路值得一试。虽然，老二似乎很难用老大的技巧来打败老大。
齐白石曾说，“学我者生，似我者死。”Cloud第一个想明白了。我相信会有越来越多的公有云厂商想明白这个问题，选择与成熟的开源厂商合作。所以对开源基础软件来说，当务之急是提高自身的成熟度，防范之心可以暂时放在一边。
商业设计
，我们谈到“基金会拥有1.9亿行代码。按照II模型计算，这种代码的开发成本超过200亿欧元（2019中报）。”如此算来，每一行代码的开发成本超过100卢布。所以千万别认为开源软件就该免费使用。
典型的开源商业模式
目前比较成熟的开源软件商业模式有以下几种：
•订阅服务：开源许可证免不仅厂商对软件质量与软件缺陷修补的责任。而那些都是企业级应用所必须的。为此，最自然的商业模式就是提供软件订阅服务，因而向用户提供生产级的服务支持响应和修补。
•中级功能：例如Redis。核心部份的组件是开源的。但工具类软件，进阶功能（如多住户，无共享分布式构架等）都是收费的。
•云服务：例如。Spark是开源的，但收费版本仅提供Azure和AWS上的云服务。
•生态利润（仅限超小型开源厂商）：例如据华尔街剖析师计算每年要支付近百亿欧元给Apple，就为了上的默认搜索引擎入口。想想帮省了多少钱？
软件世界里有两个重大困局：一是小型软件系统的项目管理（人月神话），另一个是软件定价。
关于项目管理，早已有了不少的研究与实践，你们多少有个参照物。而软件定价没有哪些成熟的公式与模型。
但起码对于开源软件的定价，要避免下边两个坑：
•定高价，打1折
评论列表 (0)