- 浏览: 1704668 次
- 性别:
- 来自: 杭州699号
文章分类
最新评论
-
莫莫摸:
为什么不用dubbo
RCP数据传输模型回顾 -
大胡子爸爸:
String, Class 都实现了Serializable接 ...
RPC框架几行代码就够了 -
lss598018587:
谢谢大神分享,比起新手看复杂的dubbo框架还不如看大神的这一 ...
RPC框架几行代码就够了 -
15606915740:
你好,请问一下。<dubbo:consumer filt ...
Dubbo文档 -
joqk12345:
...
一些设计上的基本常识
来源:网络
(1)Contributors 和 Recipients
Contributors 指的是对某个开源软件或项目提供了代码(包括最初的或者修改过的)发布的人或者实体(团队、公司、组织等),Contributors 按照参与某个软件开源的时间先后,可以分为an initial Contributor 和 subsequent Contributors 。
Recipients指的是开源软件或项目的获取者,显然,subsequent Contributors 也属于 Recipients之列。
(2)Source Code 和 Object Code
Source Code 指的是各种语言写成的源代码,通过Source Code,结合文档, 可以了解到整个软件的体系结构及具体到某个功能函数的实现方法等。
Object Code 指的是Source Code 经过编译之后,生成的类似于“类库”一样的,提供各种接口供他人使用的目标码,按我的理解,它就是像常见的DLL、AtiveX、OCX控件性质的东西。(不知道这样理解对不对)分清楚这两个概念的目的在于,有些开源,只发布Object Code ,当然,大多数发布的是Source Code。很多协议也对 “你发布的是哪种Code的时候应该怎样”,有着明确的约束。
(3)Derivative Module 和 Separate Module
Derivative Module 指的是,依托或包含“最初的”或者“从别人处获取的”开源代码而产生的代码,是原“源代码”的增强(不等于增加)、改善和延续的模块,意为“衍生模块”。
Separate Module 指的是,参考或借助原“源代码”,开发出的独立的,不包含、不依赖于原“源代码模块”,意为“独立的模块”。理解这两个概念的目的在于,很多协议对涉及到商业发布的时候,会有哪些是衍生的,哪些是独立的,有着明确的商业发布规定。
接下来,说说常见的几种协议吧。其实上面我给出的几篇文章的链接里面对一些常见的开源协议已经有比较清晰的描述了,我这里也只是加人了个人的一些理解,希望对接触得少的人有一定的帮助吧。
GPL(Gun General Public License) vesion 2.0 1991
最常见的开源协议,使用它作为授权协议的有大名鼎鼎的 Linux 。GPL最显著的两个特点就是网上称为的“病毒性传播”和“不允许闭源的商业发布”。
所谓的“病毒性传播”,指的是,GPL规定,所有从GPL协议授权的源码衍生出来的(即上面提到的DerivativeModule),或者要跟GPL授权的源码混着用的Project,都要遵循GPL协议,就像病毒一样,粘上了关系,就“中毒”了。GPL这样规定的目的是,保证在GPL协议保护下的产品,不会再受到其他协议或者授权的约束。即让跟GPL有关系的源码都能免费获取。举个例子,如果你的改进的Linux中使用了GPL授权下的开源模块(也必须使用,你不可能自己重新去做个内核吧,如果做出来了,你也没必要叫Linux了。),那么你整个Linux产品也必须遵循 GPL协议去开源,不能以其他方式去开源发布,更不允许闭源发布。这样一来,就不会出现这样一个Linux--这个功能是GPL协议授权的,可以免费获取源码,而另外一个功能是其他协议下的,拿不到源码。这点规定对使用或者研究该产品的人来说,是一个极大的便利。
而“不允许闭源商业发布”指的是,在 GPL授权下,你的软件产品可以商业发布,拿去卖钱,但是在这同时,你也必须将该产品的源码以GPL协议方式开源发布出去,供他人免费获取。也许有人会迷惑,拿去卖,又同时开源,那谁来买阿?这个产品怎么赚钱呢??这就涉及到开源产品的商业模式的问题了,想了解相关一些信息的话,可以看看以上我给出链接的一些文章。至于后面,可能会写一篇关于开源项目的商业模式的随笔。
GPL协议下的商业发布的一个关键点就像 Java 视线论坛的 Robbin所说的,GPL是针对软件源代码的版权,而不是针对软件编译后二进制版本的版权。你有权免费获得软件的源代码,但是你没有权力免费获得软件的二进制发行版本。GPL对软件发行版本唯一的限制就是:你的发行版本必须把完整的源代码一同提供。
BSD(Berkeley Software Distribution)
跟GPL有很大的不同,BSD协议是给予人很大的自由的一种开源协议。其最大的特点是,Recipients 几乎可以对源码“为所欲为”,可以自由地修改,自由地使用,修改后再以其他方式再发布(商业或者开源)。但,你做这些事情的时候,还是得遵循以下规则:
1. 如果再发布的产品中包含原“源代码”,则在原“源代码”中必须带有原来代码中的BSD协议。
2. 如果再发布的只是二进制类库/软件(Object Code / Product),则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
3. 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。
其实这几个规则约定的目的也只是达到一个目的:是他人的东西,别人以BSD开源了,你就不能不做任何声明而占为己有,更不能用他人的名义来做商业推广。你只对你自己的东西拥有绝对控制权。
举个例子,你用开源代码(A)修改或做其他增添之后,产生了产品B,这时候,你对B的控制由你自己决定,你可以用任何协议再开源,也可以闭源商业发布。但,因为如果B中包含了A或A的一部分(一点都不包含就不叫修改了),那你在B产品的版权声明中,必须有提到你有使用到A ,并且附带上 A 的开源协议。而且不能做商业推广的时候 将 B 冠以 原开源作者的名义以促进商业推广。
BSD代码鼓励代码共享,但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码,也允许使用或在BSD代码上开发商业软件发布和销售,因此是对商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选BSD协议,因为可以完全控制这些第三方的代码,在必要的时候可以修改或者二次开发。
Apache Licence vesion 2.0
Apache Licence 是著名的非盈利开源组织 Apache 采用的协议。该协议和BSD类似,同样鼓励代码共享和尊重原作者的著作权,同样允许代码修改,再发布(作为开源或商业软件)。需要满足的条件也和BSD类似:(配备英文原文,方便更准确理解)
1. 需要给 Recipients 一份Apache Licence
(You must give any other recipients of the Work or DerivativeWorks a copy of this License)
2. 如果你修改了代码,需要在被修改的文件中进行说明。
(You must cause any modified files to carry prominent noticesstating that You changed the files)
3. 在Derivative Module中(修改和包含源代码而衍生的代码)需要带有原来代码中的协议,商标,专利声明和其他原来作者规定需要包含的说明。
(You must retain, in the Source form of any DerivativeWorks that You distribute, all copyright, patent, trademark, and attribution noticesfrom the Source form of the Work, excluding those notices that do not pertain to anypart of the Derivative Works)
4. 如果再发布的产品中包含一个Notice文件,则在Notice文件中需要带有Apache Licence。你可以在Notice中增加自己的许可,但不可以表现为对ApacheLicence构成更改。
Apache Licence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。
LGPL
LGPL 是GPL的一个为主要为类库使用设计的开源协议。和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。LGPL允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。
但是如果修改LGPL协议的代码或者衍生,则所有修改的代码,涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用,但不适合希望以LGPL协议代码为基础,通过修改和衍生的方式做二次开发的商业软件采用。
CPL(Common Public Liecense) vesion 1.0
CPL 是 IBM 提出的并通过了OSI(Open Source Initiative)批准的开源协议。主要用于一些IBM 或跟 IBM 相关的开源软件 /项目中。如 很著名的Java开发环境 Eclipse 、RIA开发平台Open Laszlo等。
CPL也是一项对商业应用友好的协议。它允许 Recipients 对源码进行任意的使用、复制、分发、传播、展示、修改以及改后做闭源的二次商业发布,这点跟BSD 很类似,也属于自由度比较高的开源协议。但是,需要遵循:
1.当一个Contributors 将源码的整体或部分再次开源发布的时候,必须继续遵循CPL 开源协议来发布,而不能改用其他协议发布。除非你得到了原“源码”Owner 的 授权。
2.CPL协议下,你可以将源码不做任何修改来商业发布。但如果你要将修改后的源码其开源,而且当你再发布的是ObjectCode 的时候,你必须声明 它的Source Code 是可以获取的,而且要告知获取方法
3.当你需要将 CPL 下的源码作为一部分跟其他私有的源码混和着成为一个 Project发布的时候,你可以将整个Project/Product 以私人的协议发布,但要声明哪一部分代码是CPL下的,而且声明那部分代码继续遵循CPL。
4.独立的模块(Separate Module),不需要开源。
(1)Contributors 和 Recipients
Contributors 指的是对某个开源软件或项目提供了代码(包括最初的或者修改过的)发布的人或者实体(团队、公司、组织等),Contributors 按照参与某个软件开源的时间先后,可以分为an initial Contributor 和 subsequent Contributors 。
Recipients指的是开源软件或项目的获取者,显然,subsequent Contributors 也属于 Recipients之列。
(2)Source Code 和 Object Code
Source Code 指的是各种语言写成的源代码,通过Source Code,结合文档, 可以了解到整个软件的体系结构及具体到某个功能函数的实现方法等。
Object Code 指的是Source Code 经过编译之后,生成的类似于“类库”一样的,提供各种接口供他人使用的目标码,按我的理解,它就是像常见的DLL、AtiveX、OCX控件性质的东西。(不知道这样理解对不对)分清楚这两个概念的目的在于,有些开源,只发布Object Code ,当然,大多数发布的是Source Code。很多协议也对 “你发布的是哪种Code的时候应该怎样”,有着明确的约束。
(3)Derivative Module 和 Separate Module
Derivative Module 指的是,依托或包含“最初的”或者“从别人处获取的”开源代码而产生的代码,是原“源代码”的增强(不等于增加)、改善和延续的模块,意为“衍生模块”。
Separate Module 指的是,参考或借助原“源代码”,开发出的独立的,不包含、不依赖于原“源代码模块”,意为“独立的模块”。理解这两个概念的目的在于,很多协议对涉及到商业发布的时候,会有哪些是衍生的,哪些是独立的,有着明确的商业发布规定。
接下来,说说常见的几种协议吧。其实上面我给出的几篇文章的链接里面对一些常见的开源协议已经有比较清晰的描述了,我这里也只是加人了个人的一些理解,希望对接触得少的人有一定的帮助吧。
GPL(Gun General Public License) vesion 2.0 1991
最常见的开源协议,使用它作为授权协议的有大名鼎鼎的 Linux 。GPL最显著的两个特点就是网上称为的“病毒性传播”和“不允许闭源的商业发布”。
所谓的“病毒性传播”,指的是,GPL规定,所有从GPL协议授权的源码衍生出来的(即上面提到的DerivativeModule),或者要跟GPL授权的源码混着用的Project,都要遵循GPL协议,就像病毒一样,粘上了关系,就“中毒”了。GPL这样规定的目的是,保证在GPL协议保护下的产品,不会再受到其他协议或者授权的约束。即让跟GPL有关系的源码都能免费获取。举个例子,如果你的改进的Linux中使用了GPL授权下的开源模块(也必须使用,你不可能自己重新去做个内核吧,如果做出来了,你也没必要叫Linux了。),那么你整个Linux产品也必须遵循 GPL协议去开源,不能以其他方式去开源发布,更不允许闭源发布。这样一来,就不会出现这样一个Linux--这个功能是GPL协议授权的,可以免费获取源码,而另外一个功能是其他协议下的,拿不到源码。这点规定对使用或者研究该产品的人来说,是一个极大的便利。
而“不允许闭源商业发布”指的是,在 GPL授权下,你的软件产品可以商业发布,拿去卖钱,但是在这同时,你也必须将该产品的源码以GPL协议方式开源发布出去,供他人免费获取。也许有人会迷惑,拿去卖,又同时开源,那谁来买阿?这个产品怎么赚钱呢??这就涉及到开源产品的商业模式的问题了,想了解相关一些信息的话,可以看看以上我给出链接的一些文章。至于后面,可能会写一篇关于开源项目的商业模式的随笔。
GPL协议下的商业发布的一个关键点就像 Java 视线论坛的 Robbin所说的,GPL是针对软件源代码的版权,而不是针对软件编译后二进制版本的版权。你有权免费获得软件的源代码,但是你没有权力免费获得软件的二进制发行版本。GPL对软件发行版本唯一的限制就是:你的发行版本必须把完整的源代码一同提供。
BSD(Berkeley Software Distribution)
跟GPL有很大的不同,BSD协议是给予人很大的自由的一种开源协议。其最大的特点是,Recipients 几乎可以对源码“为所欲为”,可以自由地修改,自由地使用,修改后再以其他方式再发布(商业或者开源)。但,你做这些事情的时候,还是得遵循以下规则:
1. 如果再发布的产品中包含原“源代码”,则在原“源代码”中必须带有原来代码中的BSD协议。
2. 如果再发布的只是二进制类库/软件(Object Code / Product),则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
3. 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。
其实这几个规则约定的目的也只是达到一个目的:是他人的东西,别人以BSD开源了,你就不能不做任何声明而占为己有,更不能用他人的名义来做商业推广。你只对你自己的东西拥有绝对控制权。
举个例子,你用开源代码(A)修改或做其他增添之后,产生了产品B,这时候,你对B的控制由你自己决定,你可以用任何协议再开源,也可以闭源商业发布。但,因为如果B中包含了A或A的一部分(一点都不包含就不叫修改了),那你在B产品的版权声明中,必须有提到你有使用到A ,并且附带上 A 的开源协议。而且不能做商业推广的时候 将 B 冠以 原开源作者的名义以促进商业推广。
BSD代码鼓励代码共享,但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码,也允许使用或在BSD代码上开发商业软件发布和销售,因此是对商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选BSD协议,因为可以完全控制这些第三方的代码,在必要的时候可以修改或者二次开发。
Apache Licence vesion 2.0
Apache Licence 是著名的非盈利开源组织 Apache 采用的协议。该协议和BSD类似,同样鼓励代码共享和尊重原作者的著作权,同样允许代码修改,再发布(作为开源或商业软件)。需要满足的条件也和BSD类似:(配备英文原文,方便更准确理解)
1. 需要给 Recipients 一份Apache Licence
(You must give any other recipients of the Work or DerivativeWorks a copy of this License)
2. 如果你修改了代码,需要在被修改的文件中进行说明。
(You must cause any modified files to carry prominent noticesstating that You changed the files)
3. 在Derivative Module中(修改和包含源代码而衍生的代码)需要带有原来代码中的协议,商标,专利声明和其他原来作者规定需要包含的说明。
(You must retain, in the Source form of any DerivativeWorks that You distribute, all copyright, patent, trademark, and attribution noticesfrom the Source form of the Work, excluding those notices that do not pertain to anypart of the Derivative Works)
4. 如果再发布的产品中包含一个Notice文件,则在Notice文件中需要带有Apache Licence。你可以在Notice中增加自己的许可,但不可以表现为对ApacheLicence构成更改。
Apache Licence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。
LGPL
LGPL 是GPL的一个为主要为类库使用设计的开源协议。和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。LGPL允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。
但是如果修改LGPL协议的代码或者衍生,则所有修改的代码,涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用,但不适合希望以LGPL协议代码为基础,通过修改和衍生的方式做二次开发的商业软件采用。
CPL(Common Public Liecense) vesion 1.0
CPL 是 IBM 提出的并通过了OSI(Open Source Initiative)批准的开源协议。主要用于一些IBM 或跟 IBM 相关的开源软件 /项目中。如 很著名的Java开发环境 Eclipse 、RIA开发平台Open Laszlo等。
CPL也是一项对商业应用友好的协议。它允许 Recipients 对源码进行任意的使用、复制、分发、传播、展示、修改以及改后做闭源的二次商业发布,这点跟BSD 很类似,也属于自由度比较高的开源协议。但是,需要遵循:
1.当一个Contributors 将源码的整体或部分再次开源发布的时候,必须继续遵循CPL 开源协议来发布,而不能改用其他协议发布。除非你得到了原“源码”Owner 的 授权。
2.CPL协议下,你可以将源码不做任何修改来商业发布。但如果你要将修改后的源码其开源,而且当你再发布的是ObjectCode 的时候,你必须声明 它的Source Code 是可以获取的,而且要告知获取方法
3.当你需要将 CPL 下的源码作为一部分跟其他私有的源码混和着成为一个 Project发布的时候,你可以将整个Project/Product 以私人的协议发布,但要声明哪一部分代码是CPL下的,而且声明那部分代码继续遵循CPL。
4.独立的模块(Separate Module),不需要开源。
发表评论
-
以HTTL为例讲讲模块分包&领域模型&扩展框架
2011-10-09 20:08 16816注:该博客内容已加入 ... -
CommonTemplate增加HTML标签版语法外套
2008-09-09 10:33 2980CommonTemplate(http://www.commo ... -
CommonTemplate访问者设计思考
2008-09-03 10:45 1809经过多个版本的调整, CommonTemplate(http: ... -
CommonTemplate发布0.8.6版本
2008-08-26 20:49 1809CommonTemplate发布0.8.6版本 ... -
CommonTemplate发布0.8.5版本
2008-08-04 13:23 1910CommonTemplate发布0.8.5版本(2008-08 ... -
CommonTemplate加入代码生成器
2008-07-21 13:15 2255模板引擎经常被用于做代码生成, 为此, CommonTempl ... -
加入对YAML数据格式的支持
2008-07-01 12:41 4013CommonTemplate(http://www.commo ... -
嵌套注释语法思考
2008-06-29 14:40 4040主流的C/C++/Java/C#等语言,都将注释语法设计成不可 ... -
CommonTemplate完成查看器Viewer.exe(及安装程序)
2008-06-04 15:12 1885完成查看器初始版本. 实现功能: 双击*.ctl文件, 自动读 ... -
CommonTemplate完成外部构建树或表达式接口
2008-05-31 11:01 1960CommonTemplate: http://www.comm ... -
CommonTemplate异常国际化完成
2008-05-26 11:48 1935周未把一个累活给干了, 就是异常信息的国际化. 总共有220多 ... -
CommonTemplate加入对无穷数的支持.
2008-05-23 11:07 2751用"*"号表示无穷数, 常在下标号中使用, ... -
CommonTemplate导出模板所需变量结构
2008-05-12 18:28 2270在velocity的邮件列表中收到下面的邮件: Simon G ... -
CommonTemplate完成$snatch指令
2008-05-06 09:20 1915CommonTemplate(http://www.commo ... -
关于CTE当前API无法支持从非引擎方式构建模板树
2008-04-28 17:20 1804因隐藏了模板树的实现, 现在CommonTemplate(ht ... -
CommonTemplate完成DEBUG单步调试
2008-04-21 09:56 2540CommonTemplate(http://www.commo ... -
CommonTemplate准备加入$breakpoint指令
2008-04-19 10:30 2226准备在CommonTemplate( http://www.c ... -
很高兴桂林兄加入CommonTemplate的开发
2008-04-05 20:49 2941桂林的blog: http://jasongreen.itey ... -
展开式序列实现
2008-03-31 22:47 2126现在CommonTemplate(http://www.com ... -
CommonTemplate 0.8.3 版本发布
2008-03-31 15:05 2218项目地址: http://www.commontemplat ...
相关推荐
开源协议是连接开发者与用户之间的桥梁,它定义了软件可以如何被使用、修改和分发。本篇文章将深入探讨Python开源协议的相关知识。 首先,我们需要了解什么是开源协议。开源协议(Open Source Licenses)是一系列...
主开源协议栈是实现EtherCAT通信的核心软件组件,允许开发者在不同的硬件平台上构建EtherCAT节点。 在STM32微控制器上移植EtherCAT主开源协议栈,是为了利用STM32的强大处理能力和丰富的外设接口,构建高效、灵活的...
### 开源协议详解 #### 一、概述 开源协议是软件开发者为了促进技术交流与合作,将自己开发的软件以特定的方式公开,并规定了其他人如何使用这些软件的规则。开源协议确保了软件的开放性、可修改性和可分发性等...
《SimpliciTI-IAR-1.2.0开源协议栈详解》 SimpliciTI-IAR-1.2.0是一个专为轻量级无线通信设计的开源协议栈,它为开发者提供了一种高效构建实时通信网络的解决方案。这个协议栈尤其适用于那些需要在资源受限的设备...
### 五种开源协议的比较 #### 引言 随着技术的发展与开放文化的普及,越来越多的企业和个人选择将软件代码开源,以促进技术创新和社区发展。Adobe、Microsoft、Sun等巨头企业的加入更是加速了这一趋势。在众多开源...
DPDK技术峰会PPT讲稿 DPDK开发者大会讲稿 文档讨论了腾讯的开源协议栈F-Stack,设计原则、架构、主要组件、性能及其在腾讯公司内的发展历史,F-Stack, a Full User Space Network Service on DPDK – Haigong Wang @...
10. **许可协议**:开源项目通常会遵循某种开源许可协议,如MIT、Apache 2.0等,理解这些协议对合法使用和分发代码至关重要。 通过研究这个开源项目,开发者不仅可以学习到Java编程技巧,还能深入了解文件压缩的...
### Java程序员必须了解的七大开源协议 在软件开发领域,开源协议扮演着极其重要的角色,它们不仅定义了软件如何被使用、修改和分发,还为开发者提供了合法使用开源组件的基础。对于Java程序员而言,了解并熟悉常见...
### 几种开源SIP协议栈对比 随着VoIP(Voice over Internet Protocol)技术和下一代网络(NGN)的发展,通信领域正经历从H.323标准向SIP(Session Initiation Protocol)标准的转变。SIP作为一种更简单、更灵活的...
"KNX协议第三方开源库"指的是由非官方组织或个人开发的,支持KNX协议的软件开发工具包,这些库通常是免费提供的,并且允许开发者在自己的项目中使用和修改源代码。 在描述中提到的"tuwien.auto.calimero"是一个具体...
"Zigbee完全开源的协议栈"指的是Zigbee协议栈的源代码是公开的,允许开发者自由查看、修改和分发,这为开发人员提供了更大的灵活性和定制能力。 Zigbee协议栈通常包括几个关键组件: 1. **物理层(Physical Layer, ...
3. **CANOpen堆栈**:开源的CANOpen协议实现,通常会包含一个C或C++编写的CANOpen堆栈,实现了NMT(Network Management Transport)、SDO(Service Data Objects)、PDO(Process Data Objects)等核心功能。...
本文将分析几种常见的开源协议,包括GPL、BSD、MIT、Mozilla(MPL)、Apache 2.0和LGPL,帮助开发者理解它们的特点和适用场景。 首先,BSD开源协议赋予了使用者极高的自由度。它允许使用者自由地使用、修改源代码,...
"完整开源ZigBee协议栈C语言代码"是一个重要的资源,因为它提供了一个详细的实现参考,可以帮助开发者理解和掌握ZigBee协议的工作原理。C语言是系统编程的常用语言,因此这个开源项目特别适合硬件开发者和嵌入式系统...
Open NFC 是一个专门为硬件开发者和系统集成商设计的开源项目,它提供了一个独立的近场通信(Near Field Communication, NFC)协议栈。NFC 技术允许设备在短距离内进行无线通信,常用于移动支付、数据交换、智能卡...
ZigBee开源协议栈MpZBee是一个用于开发ZigBee无线网络应用的开放源码项目。这个协议栈全面实现了ZigBee协议的各个层次,为开发者提供了便捷的工具来构建基于ZigBee标准的物联网解决方案。ZigBee是一种低功耗、低数据...
3. **开源MAC实现**: 开源MAC层实现为开发者提供了透明度和灵活性,可以自由定制和扩展协议功能,适应各种应用场景。openmac项目是一个这样的实现,它为802.15.4标准提供了一个开放源代码的MAC层,允许用户进行二次...
本文将分析五个开源的TCP/IP协议栈:BSD TCP/IP、uC/IP、LwIP、uIP以及TinyTcp,探讨它们的特点、适用场景以及选择考虑因素。 1、**BSD TCP/IP协议栈**: 源自Berkeley Software Distribution (BSD),它是其他商业...
免去了研究那些专业的许可条款的麻烦 更方便的对开源项目贡献出自己的代码 能保护你作为作品的原创作者 确保你至少拥有由于贡献参与而带来的署名荣誉 阻止其他人企图声明对你的作品拥有所有权的行为
这个开源资料包含源码、原理图和PCB版图,为理解并实现USB转CAN提供了完整的参考资料。 1. **USB转CAN的基本原理** USB转CAN设备的核心是将USB接口的数据转换成CAN协议的数据,反之亦然。USB接口通常用于连接到...