开放源码是开源软件吗？

Open Source的来历

1997年，埃里克·雷蒙(Eric Raymond)出版其著作《大教堂和市集》，探讨黑客社区与自由软件原则。1998年初，该论文受到极大的关注，为促成网景通讯公司将其受欢迎的互联网套装软件《网景通讯家(Netscape Communicator)》释放成为自由软件的因素之一。这些代码即为今日大家熟悉的Mozilla Firefox与Thunderbird。

网景的行动激起雷蒙及其伙伴深入研究如何将自由软件基金会的自由软件概念及优点带入商业软件产业。他们查觉基金会的社会活动不如网景等公司的行动来得吸引人，因而试图重新包装自由软件运动，以强调分享与协作软件源代码的潜在商机。他们选用的新名称为“开放源代码”（open source），很快地布鲁斯·佩伦斯(Bruce Perens)、出版家提姆·奥莱理(Tim O'Reilly)、林纳斯·托瓦兹(Linus Torvalds,)及其他人支持新名称。开放源代码促进会于1998年2月创建，以推动使用新名称，并宣扬开放源代码的原则。

注：以上介绍来源于中文维基百科《开源软件》词条

OSI对开源的定义

开放源代码的定义由Bruce Perens（Debian的创始人之一）定义如下：

自由再散布（Free Distribution）：允许获得源代码的人可自由再将此源代码散布。

源代码（Source Code）：程序的可执行文件在散布时，必需以随附完整源代码或是可让人方便的事后获取源代码。

派生著作（Derived Works）：让人可依此源代码修改后，在依照同一许可协议的情形下再散布。

不得对任何人或团体有差别待遇（No Discrimination Against Persons or Groups）：开放源代码软件不得因性别、团体、国家、族群等设置限制，但若是因为法律规定的情形则为例外（如：美国政府限制高加密软件的出口）。

对程序在任何领域内的利用不得有差别待遇（No Discrimination Against Fields of Endeavor）：意即不得限制商业使用。

散布许可协议（Distribution of License）：若软件再散布，必需以同一条款散布之。

许可协议不得专属于特定产品（License Must Not Be Specific to a Product）：若多个程序组合成一套软件，则当某一开放源代码的程序单独散布时，也必需要匹配开放源代码的条件。

许可协议不得限制其他软件（License Must Not Restrict Other Software）：当某一开放源代码软件与其他非开放源代码软件一起散布时（例如放在同一光盘），不得限制其他软件的授权条件也要遵照开放源代码的授权。

许可协议必须技术中立（License Must Be Technology-Neutral）：意即许可协议不得限制为电子格式才有效，若是纸本的许可协议也应视为有效。

注：以上介绍同样来源于中文维基百科《开源软件》词条

从词语分析的角度，讨论“access to the source code”、“open-source”、“开放源代码”、“开源”

在OSI的开源定义的文本中，开宗明义的第一句话就是：“Open source doesn't just mean access to the source code. ”甚至在后面的文字里，直接将open-source连接起来，表示这是一个词，而不是2个词组成的词组。

所以，与此类似的，在中文里，我们可以认为：“开放源代码”是一个动词+一个名词。而“开源”则是一个特定的词汇。作为动词，我们说将某某软件开源，是一种行为。作为形容词，我们称某某软件是一个开源(的)软件，不仅仅是指我们能够获取到他的源代码。

从严格意义上来说：当我们判断某某软件是否开源时，首先需要检查的，是他的授权协议，是否符合OSI对于开源的定义。最好，他的授权协议已经获得OSI的认证，我们就不必仔细去分析他的条款了。

但是，如果我们看到一个软件，不含任何授权协议的文本，我们可以确定：“这只是一堆代码，虽然我可以获得代码，但是不是可以任意使用，都无法明确。更不要说算是开源软件了。”

为什么开放源代码，还需要有一个授权协议？

当我将自己的源代码放到某个地方，供人公开下载。接下来会发生什么事情？如果我是一个老手，由于见多识广的原因，我会估计到，也许会发生很多不同的事情。有些事情，我乐于见到。比如某人给我发邮件，提交bug或者patch。有些事情，我无所谓（或者也没办法干涉），比如某人在自己家里修改了代码，然后自己使用。有些事情，我认为侵犯了自己的权益，比如别人拿了我的代码，却号称是自己开发的，并且删除了所有能够证明是我的劳动的证据。还有些事情，我也很在意，比如：虽然没有侵犯我的权益，却潜在的侵害了这个软件的用户的权益等等。

总之，当一个项目的源代码被公开，哪些事情，我希望发生。哪些事情，我不希望发生。这就需要在一个协议里，被明确的规定下来。

如果发布源代码的人，对此毫不在意，甚至由于“根本没仔细思考过会发生什么”，那么我们会认为，这样的“开源”，的确是不够认真。

在我曾经翻译的一篇《开源项目成功的十条准则》里，第二条就明确写到：“以相同方式共享”是开源的安全带。在遇到严重的事故之前，你大可吹嘘自己完全不需要它。一旦出现事故，你就会发现自己满脸污垢，或者‘轻微擦伤’，不要成为一个“伤员”。使用“以相同方式共享”的许可证吧，如果你觉得GPL/LGPL太过于政治化，那就用MPLv2。

老司机的教训，要认真的听啊！

太过于政治化的许可证，是怎么回事？

在开源（Open Source）之前，其实另外还有一个重要的先驱，自由软件（Free Software），在自由软件的定义中，维护软件用户的自由是正义的，限制（剥夺）软件用户的自由是非正义的。

自由软件用户的四项自由是指：

自由度0：无论用户出于何种目的，必须可以按照用户意愿，可以随时随处自由地运行该软件。

自由度1：用户可以自由地学习并修改该软件，以此来帮助用户完成用户自己的计算。作为前提，用户必须可以访问到该软件的源代码。

自由度2：用户可以自由地分发该软件的拷贝。

自由度3：用户可以自由地分发该软件修改后的拷贝。借此，用户可以把改进后的软件分享给整个社区令他人也从中受益。作为前提，用户必须可以访问到该软件的源代码。

正如自由软件的官方文档中所说的：“一个软件只有提供了以上所有的自由给它的用户，才可以被成为自由软件。否则，它就是非自由的。尽管我们也可以比较非自由软件为其用户提供的自由度，但是我们认为，无论如何，非自由软件本身是不道德的。”  参考链接

是的，自由软件的核心，在于其包含严厉的道德判断。事实上，在绝对的软件用户的自由背后，开发者的自由，被道德绑架了。

再引用一段：“无论在哪种情况下，只有所有用户使用的代码都满足了这四项基本自由，该程序才能被视作自由软件。例如，有两个程序，甲程序运行的时候会自动调用乙程序。发布甲程序意味着用户必须使用到乙程序，那么必须甲乙两个程序都是自由的，甲程序才是自由的。如果通过修改甲程序，使其不再依赖乙程序，那么仅仅以自由软件的形式发布甲程序即可。”

相比之下，开源软件的相关定义是：“许可协议不得限制其他软件（License Must Not Restrict Other Software）：当某一开放源代码软件与其他非开放源代码软件一起散布时（例如放在同一光盘），不得限制其他软件的授权条件也要遵照开放源代码的授权。”

仔细的阅读开源软件的定义，我们就能发现，较之自由软件，“开源”是道德中立的。虽然RMS非常痛恨这样的行为，但是我们应该承认，更加宽松的、非道德化的开源标准，更加有助于开发出更多、更好的软件。

然而，开源同样被罩上了道德的光环

Open-source是一个好词，虽然没有像Free Software那样标榜自己的道德属性，这同样是一个好词。open-source是一种值得赞赏的行为，即使最终因为开源，企业能够赚得更多，但是在开源的那一刻，企业是放弃了一部分潜在利益的。

至于个人的开源，那就大多数是无利可图，也就更加值得钦佩了。

在这种情况下，不仅仅是社会上对于开源有诸多褒扬，一旦企业决定开源，肯定会加入到歌颂开源，标榜&自我标榜的行列之中。既然都已经放弃了一部分潜在的“利”，当然得在“名”上面努力的赚回来呀。

于是，整个IT圈子里，会有这种一种氛围：只要一个企业愿意开源，就值得称赞。而且，企业开源，也成为这个企业，变得更加开放，更加“尊重社区”的象征。更进一步的，如果大家发现，这个企业，并非真正开源，只不过赚了名声，却完全没有牺牲利益时。一种感情受到伤害的心态，油然而生。

“伪开源”的道德谴责，也由此而生。

企业开源，不是一种道德行为，而应该是一种商业行为

我们曾经听过一句话：“免费的其实是最贵的。”同样的理由：“当一家企业跟你谈情怀，最终他还是想赚你的钱。”所以，如果一家企业声称自己的“开源”或者“赞助开源”，完全不是为了自己的商业利益。我反正是不信的。

相反，我宁愿一家企业，真的理解了以开源为基础的商业模式，并且通过成熟、有效运作，借助商业赚取了更多的利益。这种光明正大的赚钱，值得所有人敬佩。包括商业眼光、技术实力与市场手段！

假设真的有企业家，出于情怀而开源。我倒是会内心充满疑虑。这种事情，他们家真的想明白了？真的能持久？他们的开源软件，真的能够放心使用？

开发者（尤其是企业）可以选择任何一种协议开源

如果我们不但承认用户的自由，也承认开发者的自由。如果我们不但支持用户的利益，也支持开发者的利益。如果我们承认不同的软件，面对着不同的技术与市场状况。如果我们承认，应该尊重开发者对于自身利弊的判断。

那么，开发者（尤其是企业）选择以何种协议开源，是首先应该被尊重的自由。无论他选择GPL、Apache License还是MIT中的任何一种，都不会比选择其他协议，更加道德，或者更加不道德。更明确的表达是：并不是一个企业牺牲得越多，就越道德，反之亦然。

更进一步，如果他选择的不是任何一种已有的开源协议，而是自行草拟了一份协议。并以此来捍卫自己的特别重视的利益。这也同样无可厚非，无可指责。

因此，当我们声称：某某软件并不是符合OSI定义范畴的开源软件。也仅仅是一种事实陈述，而非道德谴责。

是否存在OSI定义之外的开源软件？

这是一个很有趣的话题，我们可以以非常学究的方式来分析，也可以以较为轻松愉快的方式来研究一下。在写这篇文章的时候，我发现了两种许可协议，都非常有趣。

WTFPL（Do What The Fuck You Want To Public License，中文译名：你他妈的想干嘛就干嘛公共许可证）

大概意思是：你他妈的想干嘛就干嘛，以及，如果你改了这个协议，请不要再用这个名字。来源介绍

还有一种协议，叫做BEER-WARE LICENSE，你可以使用此软件做任何事。如果我们在某一天相遇了，而且你认为此软件很有价值，你可以为我买一瓶啤酒来答谢。来源介绍

这两种协议，看上去都非常乱来。更加有趣的是：他们都经过了FSF（自由软件基金会）的认证，确认他们是兼容GPL的自由软件许可证。

但是，他们却没有获得OSI的认证。因此，按照OSI的定义，如果有软件使用了这样的许可证，是不能称之为开源软件的。

因此，泛泛而论：我们可以认为存在狭义的（符合OSI定义的）开源软件，与广义的开源软件。

但是：我没办法准确的定义“广义的开源软件”。因为太难了！

有中国特色的开源

当开源软件进入中国，当中国的个人与企业，也开始参与开源，甚至发起开源项目的时候，事情变得更加复杂了。

先说说法律问题：在中国，目前“貌似能够”保护开源软件的，是两部法律：《著作权法》与《计算机软件保护条例》，但是在这两部法律中，都没有明确的开源软件的定义。而且，在《计算机软件保护条例》中，还认为“同一计算机程序的源程序和目标程序为同一作品。”但是，发布目标程序与同时发布源程序，明显是两种差异巨大的行为。

在软件著作权人依法享有的权力中，虽然包含修改权。但是，如果在发行或网络传播的时候，不提供源程序，事实上是无法转让或授予他人修改权的。（非编译型的脚本语言，混淆以后的源代码，又是两种需要分析的特殊情况）

再者，“保护条例”中所说的：“软件著作权人可以全部或者部分转让其软件著作权，并有权获得报酬”，其中的部分转让，是否包含“修改权的部分转让”？例如，虽然允许修改源代码，但是代码中关于许可证的注释内容，能不能被删除或修改？

还有就是外国开源软件，包括开源软件的许可协议，是否受到中国法律保护的问题。更进一步，直接采用国外的开源软件的常用许可协议的国产开源软件，是否也能受到中国法律的保护呢？

在这种现实情况下，一个中国企业选择开源，的确是要冒着“被侵权之后求告无门”的风险的！在放出自己的源代码时，选择更加严格的措辞，更加严格的授权，甚至明明是开源，也先写一句“保留所有权利”，也就可以理解了。

正面回答问题

关于文章开头提出的问题，我的回答如下：

从严格意义上来说：开源软件是一个专有名词，特指选择了符合OSI定义的授权协议的软件。

另外还有大量的未选择明确的授权协议，或者自行拟定开源授权协议，并开放源代码的软件，同样也是广义的开源生态圈的一部分。

在国内的法律环境对于开源软件的保护，逐步健全起来之前，盲目要求个人或企业，严格按照OSI的定义开源，甚至严格按照FSF的定义开源，并不妥当。以是否道德来绑架，更不应该！

无论当前的法制环境如何，选择经过反复锤炼的，成熟的开源协议，其实是对自身开源行为，更加审慎的态度。（如果它保护不了你，你的条款再严格，它也保护不了。但是，如果你自己发明的条款有漏洞，国家法制就算健全也帮不了你。）

将开源与道德脱钩，既不以道德相标榜，也不以道德相指责。这是对于开源软件，最好的态度！

开发者 TCP/IP

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。