微信小程序制作
当前位置:网站首页 > 软件开发制作 > 软件开发中的开源协议详解! 返回列表

软件开发中的开源协议详解!

作者:admin 时间:2019-06-22 浏览量:1288
开源不等于免费!为了加速我们的开发,我们会使用开源的软件和源码; 为避免商业风险,需要在使用时了解第三方如软件协议,版本,和已知CVE风险等;本文旨在从开源软件再发布过程使用权限的角度入手,总结各个常见开源协议的异同,方便理解。大部分人都希望作品能够被多数人分享查阅。这样不仅提高自己业界的知名度,同时也方便了需要的人为开源做出了贡献。但是代码一旦被贴出来,任何人都可以看到并获取,之后发生的事情你就无法控制了。所以为了公开分享你的代码,同时又让你对代码保留一定权利,在作品中声明一个许可协议是非常有必要的。有协议和没声明协议的裸代码是有非常重要区别的,一般作品当中没声明协议的默认为Copy right的,也就是版权保留。此种情况表明他人没有任何授权,不得复制分发修改使用等等。有了协议的声明,在未来你的维权上面会方便很多,让你的作品在分享的同时保留了自身的一些权利。
License是软件的授权许可,里面详尽表述了你获得代码后拥有的权利,可以对别人的作品进行何种操作,何种操作又是被禁止的。
软件协议可分为开源和商业
对于商业协议,或者叫法律声明、许可协议,每个软件会有自己的一套行文,由软件作者或专门律师撰写。因为涉及到以后侵权打官司这种事情,这种商业条款的行文是非常严谨而讲究的,读起来很晦涩难懂。对于开源协议,要知道开源不等于免费,也不等于没有约束。虽然相对商业协议要更加简明,但对于很多人来说还是像在看天书一样。
1. Apache 许可协议
Apache许可证(Apache License),是一个在Apache软件基金会发布的自由软件许可证,最初为Apache http服务器而撰写。Apache许可证要求被授权者保留版权和放弃权利的申明,但它不是一个反版权的许可证。 

此许可证最新版本为“版本2”,于2004年1月发布。 Apache许可证在Apache社区内外被广泛使用。Apache基金会下属所有项目都使用Apache许可证,许多非Apache基金会项目也使用了Apache许可证:据统计,截至2008年4月,在sourceforge上有超过3000个项目使用了Apache许可证。
Apache 许可协议, 2.0 版本, 授予了用户大量的权利。这些权利可以应用于拷贝权,也可以用于专利权。因为很多许可协议只能适用于拷贝权,不适用于专利权,所以这个灵活性就成了让有专利的开发者们选择许可协议时的一个显著参考因素 (要想明白两者之间的不同,请参考 How Stuff Works 上的这篇文章 )。
下面是关于 Apache 许可协议所允许的事项的详细说明:
  •   权利永恒。
一旦被授权,权利永久不失。
  •   权利无疆界。
在一个国家里被授权,形同于在所有国家被授权。例如,你在美国,但许可权最初在印度被授予,你同样可以使用这个被授权的程序。
  •   授权无需付费和支付酬劳。
你既不需要在使用之前支付任何的费用,也无需在每次使用时支付任何的费用,或者其它类似情况。
  •   权利不排他。
使用这种许可协议下的软件时,不妨碍你使用其它软件。
  •   权利不可变更。
权利一旦授予,不可剥夺。也就是说,你在使用这个软件的过程中,你无需担心这种情况:当你开发出了令人羡慕的基于这种授权软件的衍生产品时,有人突然跳出来对你说,抱歉,你将不再被允许使用这个程序。
(在这个协议里有个条款声明:如果你控告别人在这个许可协议下的产品有侵犯专利的行为,那你的授权将会自动终止,但这只是适用于有专利权的作品。只要你不搞有专利作品的诉讼,你永远无需担心这种问题。)
  •   对再分发的作品还有个特殊要求,总的就是说要给予这些程序的作者和许可协议的维护者适当的名誉。
2. MIT 许可协议
MIT 协议应该是在流行的开源协议中最简短的、使用最广泛的一种协议。它的条款非常的宽松,而且跟其它协议相比更自由。 MIT 协议是目前最少限制的协议。
它基本上是任何人可以对这个协议下的软件的做任何的事情,只要你能认可这个协议。这种协议最基本的条款 ( the information that it is provided without warranty, which comprises the final paragraph)如下:
特此授权,任何人都可免费获得这个软件以及相关文档(the Software)的拷贝,可以无限制的使用这个软件,包括无限制的权利去使用、复制、修改、合并、发布、附加从属协议,以及/或者出售软件的拷贝, 同时,为了让软件的提供者有权利做到这些,下面的条件必须遵守:
上面的拷贝权声明和许可声明必须包含在所有的这个软件拷贝里和实际分署部分里。这也就是说:
  •   你可以随意使用,复制,修改这个软件。没有人能够阻止你在任何工程里使用它,你可以复制任意次数、以任何形式,或按你的愿望修改它。
  •   你可以向外免费发放,或出售。你可以随意的分发它,没有任何限制。
  •   唯一的限制是你必须接受协议条款。
3. BSD 许可协议
BSD 协议有很多分支,它们都代表了一种宽松的自由软件协议,相对其它协议,例如GPL,来说,它们对软件的传播给予了更少的限制。
在这种协议的各种版本中,有两个版本格外的重要: 新 BSD 协议/修订版 BSD 协议和简化 BSD 协议/FreeBSD 协议。这两类协议都实现的对 GPL 兼容的自由软件协议,而且被 Open Source Initiative 认可为开源软件协议。
新 BSD 协议(3-clause license)无任何限制的允许你以任何目的二次分发这种软件,唯一的要求是必须保留拷贝权的声明和协议里的软件权利放弃条款。这种协议还有一个限制,未经许可不得使用这个作品的所有曾经捐助者的署名。 新 BSD 协议和简化 BSD 协议的最主要的区别是后者删除了署名条款。
BSD开源协议是一个给于使用者很大自由的协议。基本上使用者可以”为所欲为”,可以自由的使用,修改源代码,也可以将修改后的代码作为开源或者专有软件再发布。
但”为所欲为”的前提当你发布使用了BSD协议的代码,或则以BSD协议代码为基础做二次开发自己的产品时,需要满足三个条件:
  •   如果再发布的产品中包含源代码,则在源代码中必须带有原来代码中的BSD协议。
  •   如果再发布的只是二进制类库/软件,则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
  •   不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。
  •   BSD 代码鼓励代码共享,但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码,也允许使用或在BSD代码上开发商业软件发布和销售,因此是对商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选BSD协议,因为可以完全控制这些第三方的代码,在必要的时候可以修改或者二次开发。
4. GPL许可协议
我们很熟悉的Linux就是采用了GPL。GPL协议和BSD, Apache Licence等鼓励代码重用的许可很不一样。GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用,但不允许修改后和衍生的代 码做为闭源的商业软件发布和销售。
这也就是为什么我们能用免费的各种linux,包括商业公司的linux和linux上各种各样的由个人,组织,以及商 业软件公司开发的免费软件了。
GPL协议的主要内容是只要在一个软件中使用(”使用”指类库引用,修改后的代码或者衍生代码)GPL 协议的产品,则该软件产品必须也采用GPL协议,既必须也是开源和免费。这就是所谓的”传染性”。GPL协议的产品作为一个单独的产品使用没有任何问题, 还可以享受免费的优势。
由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议,对于使用GPL协议的开源代码,商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。
其它细节如再发布的时候需要伴随GPL协议等和BSD/Apache等类似。
5. LGPL许可协议
LGPL 是GPL的一个为主要为类库使用设计的开源协议。和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。LGPL 允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并 发布和销售。
但是如果修改LGPL协议的代码或者衍生,则所有修改的代码,涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。因 此LGPL协议的开源 代码很适合作为第三方类库被商业软件引用,但不适合希望以LGPL协议代码为基础,通过修改和衍生的方式做二次开发的商业软件采用。
GPL/LGPL都保障原作者的知识产权,避免有人利用开源代码复制并开发类似的产品。
6. MPL许可协议
MPL是The Mozilla Public License的简写,是1998年初Netscape的 Mozilla小组为其开源软件项目设计的软件许可证。
MPL许可证出现的最重要原因就是,Netscape公司认为GPL许可证没有很好地平衡开发者对源代码的需求和他们利用源代码获得的利益。同著名的GPL许可证和BSD许可证相比,MPL在许多权利与义务的约定方面与它们相同(因为都是符合OSIA认定的开源软件许可证)。
但是,相比而言MPL还有以下几个显著的不同之处:
- MPL虽然要求对于经MPL许可证发布的源代码的修改也要以MPL许可证的方式再许可出来,以保证其他人可以在MPL的条款下共享源代码。但是,在MPL许可证中对“发布”的定义是“以源代码方式发布的文件”,这就意味着MPL允许一个企业在自己已有的源代码库上加一个接口,除了接口程序的源代码以MPL许可证的形式对外许可外,源代码库中的源代码就可以不用MPL许可证的方式强制对外许可。这些,就为借鉴别人的源代码用做自己商业软件开发的行为留了一个豁口。
- MPL许可证第三条第7款中允许被许可人将经过MPL许可证获得的源代码同自己其他类型的代码混合得到自己的软件程序。
对软件专利的态度,MPL许可证不像GPL许可证那样明确表示反对软件专利,但是却明确要求源代码的提供者不能提供已经受专利保护的源代码(除非他本人是专利权人,并书面向公众免费许可这些源代码),也不能在将这些源代码以开放源代码许可证形式许可后再去申请与这些源代码有关的专利。
对源代码的定义
  •   而在MPL(1.1版本)许可证中,对源代码的定义是:“源代码指的是对作品进行修改最优先择取的形式,它包括:所有模块的所有源程序,加上有关的接口的定义,加上控制可执行作品的安装和编译的‘原本’(原文为‘Script’),或者不是与初始源代码显著不同的源代码就是被源代码贡献者选择的从公共领域可以得到的程序代码。”
  •   MPL许可证第3条有专门的一款是关于对源代码修改进行描述的规定,就是要求所有再发布者都得有一个专门的文件就对源代码程序修改的时间和修改的方式有描述。
GPL协议、LGPL协议与BSD协议的法律区别。
简而言之,GPL协议就是一个开放源代码协议,软件的初始开发者使用了GPL协议并公开软件的源程序后,后续使用该软件源程序开发软件者亦应当根据GPL协议把自己编写的源程序进行公开。GPL协议要求的关键在于开放源程序,但并不排斥软件作者向用户收费。
虽然如此,很多大公司对GPL协议还是又爱又恨,爱的是这个协议项下的软件历经众多程序员千锤百炼的修改,已经非常成熟完善,恨的是必须开放自己后续的源程序,导致竞争对手也可以根据自己修改的源程序开发竞争产品。
正因大公司对GPL协议在商业上存在顾虑,因此,另两种协议被采用的更多,第一种是LGPL(亦称GPL V2)协议,可以翻译为更宽松的GPL协议。与GPL协议的区别为,后者如果只是对LGPL软件的程序库的程序进行调用而不是包含其源代码时,相关的源程序无需开源。
调用和包含的区别类似在互联网网网页上对他人网页内容的引用:如果把他人的内容全部或部分复制到自己的网页上,就类似包含,如果只是贴一个他人网页的网址链接而不引用内容,就类似调用。有了这个协议,很多大公司就可以把很多自己后续开发内容的源程序隐藏起来。
第二种是BSD协议(类似的还有MIT协议)。BSD协议鼓励软件的作者公开自己后续开发的源代码,但不强求。在BSD协议项下开发的软件,原始的源程序是开放源代码的,但使用者修改以后,可以自行选择发布源程序或者二进制程序(即目标程序),当然,使用者有义务把自己原来使用的源程序与BSD协议在软件对外发布时一并发布。因为比较灵活,所以BSD深受大公司的欢迎。
联系方式:18066528545   029-89298792

阅读过此文章的读者,还阅读过下面的文章

  • 微信小程序凭借其无需下载、即用即走的特性,已成为企业触达用户的重要渠道。在开发技术选型中,原生开发依然是许多项目的首选。那么使用原生开发微信小程序都有什么帮助呢?

    首先就是提高小程序的性能和流畅性。原生开发直接对接微信客户端渲染引擎,减少中间层带来的性能损耗,动画、长列表滚动等场景更流畅。原生代码打包体积更小,结合微信的预加载机制,显著提升小程序打开速度。微信支付、订阅消息、直播组件等新API优先支持原生开发,无需等待第三方框架适配。原生API可无缝调用微信通讯录、地理位置、扫一扫等系统级功能,提升用户粘性。提供实时预览、真机调试、性能分析等一站式支持,快速定位内存泄漏、渲染层级问题。原生开发可搭配WXS脚本优化渲染性能,跨平台框架需额外处理兼容性问题。使用跨平台框架可能会存在版本升级导致的API变更风险,原生代码无需担忧兼容性问题。

    原生开发在性能、生态融合、长期维护上的优势显著,适合对体验要求高、功能复杂的核心业务。若需同时发布微信、支付宝、百度等多平台,可评估跨平台方案。建议结合项目周期、团队能力、业务目标综合决策,避免盲目追求技术潮流。

  • 在移动互联网时代,小程序已成为企业快速触达用户的重要入口。面对微信、支付宝、百度、抖音等多平台小程序的开发需求,开发者往往需要投入大量成本适配不同平台。而UniApp作为一款基于Vue.js的跨平台开发框架,凭借其独特的优势,已成为众多企业和开发者的首选方案。本文将从技术、效率、成本等多个维度解析UniApp的核心竞争力。那么使用UniApp开发小程序有什么优势呢?

    一次开发,多端发布

    UniApp最显著的优势在于“跨平台兼容性”。开发者只需编写一套代码,即可编译发布到微信、支付宝、抖音、百度、QQ、快应用等10+主流小程序平台,同时兼容H5、Android、iOS原生应用。对于需要快速覆盖多端用户的企业,可节省80%以上的重复开发成本。

    学习成本低,开发效率高

    UniApp基于Vue.js语法,前端开发者可快速上手。熟悉的组件化开发模式、双向数据绑定、生命周期管理等特性,大幅降低学习门槛。同时,UniApp提供丰富的API和组件库,直接调用原生能力,无需额外适配。

     强大的生态与插件市场

    UniApp拥有活跃的开发者社区和丰富的插件生态。在UniApp插件市场中,可快速集成支付、地图、UI库、数据统计等上千种功能模块。例如,通过uView UI组件库,可快速搭建美观的界面;通过uni-push实现统一的消息推送服务。

    与原生混合开发无缝衔接

    对于需要调用摄像头、蓝牙等深度硬件功能的场景,UniApp支持通过原生插件扩展机制集成原生代码,或直接嵌入原生页面。这种灵活性使其既能满足轻量级需求,又能应对复杂业务场景。

    UniApp凭借其跨端能力、开发效率和成熟的生态,已成为小程序开发的标杆框架。无论是追求快速验证的初创团队,还是需要降本增效的中大型企业,UniApp都能提供“多快好省”的解决方案。

  • 在移动互联网持续渗透的今天,企业是否还需要开发小程序?这个问题没有绝对的答案,但可以从行业趋势、用户习惯、技术迭代等多个维度展开分析。本文将从真实商业场景出发,探讨企业开发小程序的必要性,并给出场景化建议。

    一、流量入口的底层逻辑正在重构

    微信小程序DAU突破6亿,抖音小程序日活用户增长400%,支付宝小程序链接超300万商家——这些数据背后是用户行为模式的根本转变。用户在刷短视频时直接下单外卖,在微信群聊中完成拼团支付,在搜索附近餐厅时直接预约座位。小程序已经演变为"即用型服务终端",企业若放弃这个触达窗口,相当于主动关闭了用户最自然的消费场景。

    二、成本效益的二次方法则

    某上市餐饮连锁企业的数字化报告显示:开发原生APP的获客成本是17元/人,而小程序仅为2.3元/人。更值得关注的是用户生命周期价值(LTV)差异:通过小程序下单的客户复购率比APP用户高出32%。这源于小程序特有的"三秒定律"——用户从产生需求到完成服务的时间压缩至传统路径的1/5。服装品牌UR的案例更具说服力:通过微信小程序+直播的融合模式,其单场活动GMV突破800万,用户沉淀效率是H5页面的7倍。

    三、生态壁垒背后的战略考量

    头部平台正在构建"小程序护城河":微信强化搜一搜直达服务,抖音将小程序与内容推荐算法深度绑定,支付宝重点布局民生服务场景。某家电品牌的市场总监透露:"我们在抖音小程序的转化率比独立站高4倍,因为平台会把优质小程序推送给精准用户。"这意味着企业需要像布局线下门店一样,在多个流量生态中建立"数字分店",每个小程序都是特定场景的服务节点。

    四、技术红利的窗口期缩短

    当谷歌推出Instant App,苹果上线App Clips时,全球开发者都意识到轻量化应用已成必然。但国内小程序生态的成熟度领先国外2-3年,使用Taro框架开发跨平台小程序,迭代速度比维护三个原生团队快5倍。

    结语:小程序的终局是"服务插件化"

    当物联网设备突破百亿,XR技术逐渐普及时,小程序形态可能演变为"空间计算时代的服务插件"。企业当下的小程序布局,实质是在为元宇宙时代的服务架构积累组件库。是否开发小程序的根本问题,应升级为如何构建可跨生态移植的服务模块体系。

  • 对于企业来说,开发小程序除了进行宣传推广,提高业务效率,提高自身竞争力之外,更多的是希望通过小程序来获取更多的收益,那么对于企业来说,开发小程序要如何获取收益呢?

    直接变现的方式,比如付费下载、内购、订阅制、广告这些。这些都是比较直接的方法,但各有优缺点。比如付费下载可能在竞争激烈的市场中不太容易,特别是如果小程序不是特别独特的话。内购和订阅制可能更适合有持续内容或服务的小程序,比如工具类或者内容类应用。广告的话,需要一定的用户量,可能适合已经有用户基础的情况。

    接下来是电商和佣金分成,这可能适合有商品或服务销售的小程序。用户可能需要整合支付和物流,这对于个人开发者来说可能有点复杂,但如果能合作的话,分成模式可能更可行。比如外卖、旅游平台的佣金,或者成为分销商,推广别人的产品。

    然后是企业服务,这部分可能用户没想到,但B端市场其实很大。定制开发、技术服务年费、解决方案都是可行的。特别是如果用户有技术背景,为企业做定制开发可能收益更高,但需要销售能力。

    数据变现和增值服务也是一个方向,比如数据分析报告或者会员专属功能。不过要注意数据隐私问题,不能违规。

    流量变现方面,导流到其他平台或者做品牌合作。如果小程序有大量流量,可以引导用户到APP或者网站,或者和品牌合作做推广。联名活动也是个好点子,比如和网红或IP合作,增加曝光。

    运营策略方面,冷启动阶段免费吸引用户,后续推出付费功能。或者用免费增值模式,基础功能免费,高级功能收费。这些策略需要平衡用户体验和收益,不能太激进。

    资源整合方面,联合其他开发者或商家,共享资源,或者提供平台抽成。比如做一个平台,让商家入驻,从中抽成。这可能适合有一定资源整合能力的团队。

    最后,通过小程序获取收益的方式还是很多的,但是现如今大部分用户对于费用都是比较抗拒的,因此一定要尽可能根据小程序的具体情况,决定收费方式,避免对小程序造成过大影响。

  • 在了解小程序定制开发和模板开发有什么区别之前,要先明白这两者之间的概念到底是什么。定制开发应该是指根据客户的具体需求从头开始设计和开发小程序,而模板可能是指现成的、已经开发好的小程序框架,客户可以根据自己的需求进行一些修改和配置。

    首先,定制开发的优势在于完全个性化,可以满足特定的业务需求,功能更加灵活,但成本高,开发周期长。而模板开发成本低,上线快,但功能受限,可能无法满足某些特殊需求,而且界面和功能同质化的问题比较严重。

    另外,还要考虑到后续的维护和升级。定制开发可能需要专门的团队维护,而模板通常由第三方提供维护服务,但可能缺乏灵活性。用户可能还会担心数据安全和隐私问题,定制开发在这方面可能更有保障,因为代码是自主控制的。

    同时,定制小程序可以加入独特的会员体系,而模板可能只能使用预设的功能模块。

    因此,如果是一个初创企业,预算有限,需要快速上线的话,这时候模板可能更适合。但如果用户的企业有独特的业务流程,或者需要与现有系统整合,定制开发可能更合适。

  • 现如今小程序开发已经成为很多企业的首要选择,而在进行小程序开发时,小程序平台的选择也是非常关键的,那么对于小程序来说应该如何选择开发平台呢?

    对于大部分企业来说微信小程序肯定是首选。但如果是支付宝或者抖音的用户,可能需要考虑其他平台。这可能涉及到各个平台的用户基数、覆盖人群,比如微信的用户量最大,支付宝可能更多用于支付场景,抖音适合内容营销。

    接下来是开发成本。不同的平台开发工具和语言不同,比如微信用JavaScript,支付宝也是类似,但字节跳动可能用不同的框架。如果用户已经有技术团队,可能需要考虑他们的技术栈是否匹配。或者如果用户想跨平台开发,可能需要推荐uni-app或Taro这样的框架,节省成本。

    然后要考虑功能需求。比如,如果需要支付功能,微信和支付宝都有成熟的支付接口。社交分享的话,微信的社交链更强。抖音可能更注重短视频和内容传播。电商相关的话,可能淘宝小程序更合适。

    用户体验方面,每个平台的UI设计规范不同,需要遵循各自的标准,确保用户体验一致。同时,性能优化也很重要,比如加载速度、响应时间等,不同平台可能有不同的优化策略。

    维护和更新也是一个因素。各个平台的审核政策、更新频率不同,比如微信审核比较严格,但流程成熟。抖音可能审核更快,适合快速迭代。需要根据项目需求选择适合的平台。

    生态支持方面,微信的第三方服务和插件很多,支付宝在金融领域有优势,抖音可能有更多的流量和内容合作资源。如果有现成的插件或服务可用,开发会更便捷。

    数据分析和运营工具也不可忽视。微信有强大的数据分析后台,支付宝提供交易数据,抖音有内容互动分析。如果需要这些数据来做运营决策,平台的数据支持就很重要。

    因此小程序开发平台之间关各有不同,如果只是想要服务好一个平台的用户的话,微信小程序平台无疑是最好的选择,但要是想要吸引更多用户的话,选择uni-app或Taro这样的框架,能够更好的实现跨平台开发。

029-8929 8792 177 9128 8395 西安嘉瑞德网络科技公司
工作时间:周一到周六 8:30-18:30
邮箱:2528823962@qq.com
QQ:2528823962
地址:陕西省西安市未央元朔路明丰伯马都A座10820室
在线客服系统
  • 微信小程序制作微信二维码
    扫码咨询
Copyright © 2015 西安嘉瑞德网络科技有限公司 陕ICP备2023001199号 网站地图