匿名读者 写道 “GitHub
的新服务条款于 3 月开始生效。MirBSD
的开发者在博客发文澳门新葡萄京所有网站,,质疑新版的服务条款与大量项目许可证本身相抵触,可能受到影响的许可证有:任何
copyleft
许可证(GPL、AGPL、LGPL、CC-*-SA)、需要署名的许可证(CC-BY-*、4 言
BSD、带 NOTICE 的 Apache 2)、需要保持代码完整的许可证(LaTeX
许可证),在最坏的情况下,上述许可证将被削弱为两言 BSD 许可证。

澳门新葡萄京所有网站 1

澳门新葡萄京所有网站 2

Debian 前核心开发者 Joey
Hess 回应称,他自己已经从
GitHub 删除所有项目,并自行托管。GitHub
的新服务条例模糊不清,其后果尚不明确,他已经找了一群律师帮忙解决问题。

如今GitHub已成为全球最流行的开源项目托管平台,但也有质疑声音——“Github中的大多数项目并不算是开源项目”。这是因为Github中大多数项目并没有明确声明所使用的许可证。根据版权法规定,如果开源项目中没有包含任何一种OSI批准的开源许可证,那么其他用户将没有权利以任何目的任何形式去使用这些代码或fork这些项目。但是繁多的许可证及条款可能会令开发者迷惑,不知道究竟该选择哪一种。对此,GitHub今天发布了choosealicense.com网站,在呼吁开源项目开发者选择一个许可证的同时,还提供了许可证的一些简要说明。1.
我想要一个简单宽松的许可证
建议:
MIT许可证。这是一个宽松的、简明扼要的许可证,只要用户在项目副本中包含了版权声明和许可声明,他们就可以拿你的代码做任何想做的事情,你也无需承担任何责任。使用该许可证的项目:jQuery、Rails2.
我比较关心专利
建议:
Apache许可证。这类似于MIT许可证,但它同时还包含了贡献者向用户提供专利授权相关的条款。使用该许可证的项目:Apache、SVN和NuGet3.
我关心项目的共享改进
建议:GPL许可证。这是一种copyleft许可证,要求修改项目代码的用户再次分发源码或二进制代码时,必须公布他的相关修改。V3版本与V2类似,但其进一步约束了在某些限制软件更改的硬件上的使用范围。使用该许可证的项目:Linux、Git关于如何选择许可证,详细信息可参阅:
为了使开发者养成选择开源许可证的习惯,Github在创建新库的表单中添加了一个许可证选项。该选项中提供了一组简化的开源许可证,开发者选择后,Github会自动在其库的根目录中创建一个readme文件。如果你不想选择许可证,Github也不会勉强。Github表示,选择许可证只是你的权利,不是你的义务。但是需要注意的是,拒绝开源许可证并不意味着你拒绝了项目版权。没有许可证意味着你默认接受版权法中的规定,比如你可以保留你的项目源码被复制、分发、创建衍生版的权利,但有可能这不是你希望做的。在Github中,如果你的项目以公共库的形式发布,表明你已经接受了Github的服务条款,该条款赋予了其他Github用户一些权利,比如允许他们查看你的项目库或fork等。如果你想与他人分享你的项目,还是建议你选择一种开源许可证。

高度放任只是开源许可证授权模式变革的过渡阶段,最终我们将进入一个全新的时期:无许可证模式。多年以来,开源软件正在从主张“copyleft”的GNU
GPL等开源授权模式向更加开放灵活的Apache风格的授权模式转移。这场变革的主导者是话语权不断提升的开发者,典型的如GitHub一族,正在推动开源软件走向无授权时代。无许可证时代的放纵在自由软件和开源软件的青铜时代,copyleft许可证授权模式占据绝对的主导地位。但是近些年来,一些高度开放的许可证授权方式如BSD和MIT的势头正在上升,Remonk分析师Donnie
Berkholz给出了一个分析图表清晰地描绘了这种趋势:高度放任只是开源许可证授权模式变革的过渡阶段,最终我们将进入一个全新的时期:无许可证模式。正如自由软件倡导者Glyn
Moody所言:“向更加开放的许可证模式的范型转移只有一个逻辑结果:允许做一切事情。GitHub许可证的黑洞正如软件自由法律中心高级职员顾问Aaron
Williamson在今年的LInux协作峰会上所说的,GitHub上的绝大多数项目都没有附加任何许可证条款。众所周知,GitHub是当今开源软件的集散地,但是其中只有14.9%的代码库在顶级目录中包含了许可证授权条款。换而言之,GitHub上的大多数代码即不是开源软件,也不是私有软件,或者别的什么软件,它们仅仅是代码而已。新一代开发者就像论坛发帖一样在GitHub上传代码,对于这些开发者来说,授权许可和管理都是马后炮,代码才是一切。至于原因,Gartner和Forrester两大市场分析机构的研究结论达成了一致:因为开发者需要灵活性。更少的授权许可要求意味着更多的灵活性。授权是否还有必要?去许可证化的趋势并非没有问题,Outercurve基金会的董事Stephen
Walli在推文中指出GitHub为代表的混乱的,缺乏治理和授权模式的代码分享将导致“软件变成疾病”。虽然GitHub一代并不在意,不过一旦他们的项目吸引了买家或者收购者,你们源代码的“纯洁性”问题就将立刻付出水面。根据Black
Duck的研究,开源的合规性在公司收购与合并中受到的关注程度正在不断上升。显然,GitHub一代的“无许可证主义”并未完全失控,Berkholz在分析大量GitHub项目后发现,随着软件项目的成长,开发团队将开始着手肃清许可证问题,这往往是因为他们获得了企业客户,或者团队中增加了专业开发者等。”最终,GitHub的“恣意妄为的无许可证文化”的疯狂,其实有助于开发和验证早期的开源项目,而这些项目最终依然会过渡到Apache风格的授权模式。开源许可证的种类与选择开源软件的许可证比较繁多和复杂,对于我们来说,经常遇到的开源许可证大多是GPL和BSD两种,此外还有
Adobe经常使用的MPL许可证。简单来说,GPL许可证具有相当强的传染性,如果你想要把一份采用GPL许可证的代码经过修改后再次发布二进制版本,
那么你同时也必须再次开放其源代码。而BSD许可证则相对宽松许多,它允许对源代码的修改后再次发布时仅包含许可证而不必再次开放源代码,且可以将修改后的版本专为商业用途。1.
从开源软件开发的角度来看,若只是利用开源程序包作为工具来生产与其分离的作品,那么绝大多数开源许可证都是可以的2.
如果将软件用于商业性发行且不愿意发行自己所修改的源码,那么可以选择BSD许可证,它能使修改保持专有3.
若希望源码总是自由的,GPL许可证及LGPL许可证是最佳选择4.
若想在与其它人共享代码时提供相应的保护,可以选择MPL许可证,该许可证可通过将软件(和任何对它的修改)分为受保护部分和贡献部分,在完全开放的
GPL许可证和封闭的BSD许可证之间架起一座巧妙的桥梁。文章来自IT经理网

MirBSD 开发者的文章大意是:

条款中规定,作者同意在一定情况下放弃署名权,“以便允许代码搜索等基本功能的运作”。如果仅仅是这样,也无可厚非。然而,如果项目另有人参与,上传者自己显然无权代替其他人做出是否署名的决定。更别说
CC 协议不允许 “子许可证”
的存在,使许可证和服务条款相抵触,成为非法的、无效的。

此外,条款还规定,作者需要同意,它人 “use, display and perform”
其作品的权利;以及,作者需要授予 GitHub 在其功能范围之内对作品进行
“reproduce” 的权利。这意味着,GitHub 可以无视所有的 copyleft
许可证中的条件。

最后,GitHub
的条款还允许其删除项目中的文件。这意味着,某些要求保持源代码完整性的许可证也与新条款相抵触。

开发者认为新许可证并非一无是处,确实修正了以前存在的问题。笔者也认为
GitHub 的做法不是恶意。例如,对于没有任何许可证的项目,GitHub
如果不提前主张权利,就会产生大量纠纷,这应该是新使用条款试图避免的。然而,所有
OSS 和 Debian
认可的自由、开源许可证本身已经允许了托管平台的做法,因此 GitHub
完全不应当让画蛇添足,让自己的使用条例凌驾于项目许可证之上。”

稿源:solidot