Questions tagged «bsd-license»

BSD(伯克利软件发行)许可证是许可的开源许可证系列。

2
MIT,BSD和双重许可
我的理解是: MIT许可项目可以在BSD许可项目中使用/分发。 BSD许可的项目可以在MIT许可的项目中使用/分发。 MIT和BSD 2子句许可证本质上是相同的。 BSD 3子句= BSD 2子句+ “无认可”子句 颁发双重许可证允许用户从这些许可证中进行选择,而不必两者都绑定。 如果以上所有方法都正确,那么使用MIT / BSD 双重许可证有什么意义?即使BSD引用了3子句版本,用户也不能合法选择仅遵守MIT许可证吗? 看来,如果您确实希望应用“不认可”子句,则必须仅将其许可为BSD(不是双重许可)。如果您不关心“不认可”子句,那么仅MIT就足够了,而MIT / BSD就是多余的。 同样,由于MIT和BSD许可证都是“ GPL兼容 ”的,并且可以在GPL许可的项目中重新分配,因此MIT / GPL双重许可似乎也很多余。


1
安排第三方图书馆许可“文书工作”的最佳实践是什么?
我正在开发一个小型开源项目。该应用程序使用发行了许多许可证的许多第三方库:Apache,MIT,BSD,LGPL和CDDL。 这些许可证中的每一个都有其自己的“文书工作”要求。例如,Apache许可证v2.0指出: 如果作品包括“注意”文本文件作为其分发的一部分,则您分发的任何衍生作品都必须包括该通知文件中包含的署名声明的可读副本。 MIT许可证包含版权声明,并指出: 以上版权声明和本许可声明应包含在本软件的所有副本或大部分内容中。 BSD许可证还包含版权声明,并指出: 二进制形式的重新分发必须在分发随附的文档和/或其他材料中复制以上版权声明,此条件列表以及以下免责声明。 LGPL v.3说: (您应该)在合并作品的每份副本中都特别注明使用了该库,并且该许可证涵盖了该库及其使用。 LGPL和CDDL许可证还要求提供源代码以及库的二进制形式,因此应在某处提供有关获取源代码的方式的信息。 整理所有这些数据的最佳实践是什么?我是否应该创建一个文本文件并将所有NOTICE文件,MIT和BSD许可证等的内容复制到该文件中?...还是应该为每个库创建一个单独的目录,然后将与该库相关的所有数据放入该目录?… 或者是其他东西? 在已发布的项目中看到此“文书”的任何示例也将很有趣。 更新: 我已阅读您是否必须在每个源文件中都包含许可证声明?,但不能解决我的问题。我的问题与项目中使用的第三方库有关,而该问题与项目自己的源代码中的标头有关。


4
新BSD许可证中“不认可条款”的目的是什么?
注意:此问题与“令人讨厌的BSD广告条款”无关。新BSD许可证不包含该条款,并且与GPL兼容。 我正在为自己的项目在New BSD许可证和MIT许可证之间进行选择。它们基本相同,只是BSD许可证包含以下子句: 未经明确的事先书面许可,<组织>的名称或其贡献者的名称均不得用于认可或促销从该软件派生的产品。 为什么有人要使用此子句?如果有人使用您的代码制作了著名的软件,那臭名昭著怎么办?此外,是否会决定用户可以使用或不能使用您给定的名称做哪些事情超出了知识产权的范围?



2
许可范围内基于ServiceStack的解决方案的未来
我只是希望有人澄清一下以下问题,正如Demis Bellot在几周前宣布ServiceStack即将商业化一样。请参考下面的链接。 https://plus.google.com/app/basic/stream/z12tfvoackvnx1xzd04cfrirpvybu1nje54 (请注意,当我说ServiceStack或SS时,我指的是所有相关的SS库,例如ServiceStack.Text等。) 如果我今天已经有使用ServiceStack开发的解决方案,即使我不将SS二进制文件升级到商业发行版,也必须在SS投入商业使用后购买许可证吗? SS的先前版本(商业许可之前)是否将始终是开源的,并且使用与以前相同的许可? 如果我今天(在获得商业许可之前)在Github上购买SS,那么在SS投入商业运营后再坚持这一做法是否违法? 如果对问题2的回答是“是”,那么在SS投入商业运营后,我仍然能够在不担心商业许可的情况下派生以前的版本吗?

4
将BSD 2/3子句代码许可给GPL
假设我根据新的BSD许可证发布了一些源代码。是否允许其他人采用此代码,对其进行修改并根据GPL条款进行分发?从维基百科: 许多最常见的自由软件许可证,例如原始MIT / X许可证,BSD许可证(当前为2子句形式)和LGPL是“ GPL兼容的”。也就是说,他们的代码可以与GPL下的程序组合而不会发生冲突(新的组合会将GPL应用于整个程序)。但是,某些免费/开源软件许可证不兼容GPL。 我假设这意味着可以将新BSD许可的代码重新许可给GPL?
11 gpl  bsd-license 

3
在实践中,如何结合使用GPL和BSD许可代码来管理许可文件?
我正在编写的代码使用一个具有GPL(不是LGPL)许可的库,以及一个具有3条款BSD许可的库。由于我链接到GPL许可的库,因此我的代码也必须是GPL。实际上,我应该如何处理BSD库中的原始LICENSE.txt? (A)是否可以分发项目,以便主要源代码获得GPL许可,然后某个子目录获得BSD许可? (B)如果我不仅要链接到库,而且要以更复杂的方式使用和组合BSD和GPL代码,那么对LICENSE.txt怎么办? BSD的三节文字说:“源代码的重新分发必须保留上述版权声明,此条件列表和以下免责声明。” 因此,显然我应该在某处保留版权声明和该条件列表。但随后,我还需要将GPL许可证txt文件放在某个地方。 此外,显然,我不需要保留“只要满足以下条件,即允许以原始形式和二进制形式进行重新分发和使用,无论是否经过修改,都允许:” BSD许可文本的一部分,因为它只告诉我保留其他部分。 那么,在实践中,我应该如何以及在哪些文本文件中组织GPL许可证文本以及所保留的BSD许可证和版权的一部分? 编辑:因此,在情况B中,我将采用3条款BSD许可的代码,并根据允许的GPL重新分发它,因为3条款BSD许可与GPL(单向)兼容。我只是问在实践中如何处理许可证文本和文本文件。

2
如何管理来自BSD许可项目的贡献者的版权声明
该LICENSE文件中包含以下BSD许可证: Copyright (c) 2006-2016 SymPy Development Team All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: a. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. …

2
BSD许可的项目是否需要每个贡献者的签名声明?
今天,我读了Fossil SCM的邮件列表: BSD的问题在于,您确实应该从每个贡献者那里获得一份签名表格,说明他们的贡献是BSD。对于GPL,这是自动的,因为在兼容许可证下释放您的贡献是查看GPL中代码的先决条件。这使GPL非常适合具有大量贡献者的高度协作的环境。BSD对读者来说是比较宽松的(负担不大),但这对作家来说有点困难,因为他们现在必须发送一些文件。 有人可以解释为什么吗?如果没有项目贡献者的签名说明,可能会有什么后果?

3
分支获得BSD许可的项目时有哪些法律考虑因素?
我有兴趣分叉以两条款BSD许可发布的项目: 版权所有(c)2010 {版权所有者}保留所有权利。 如果满足以下条件,则允许以源代码和二进制形式进行重新分发和使用,无论是否经过修改,都可以: (1)源代码的重新分发必须保留上述版权声明,此条件列表以及最后的免责声明。二进制形式的重新分发必须在分发随附的文档和/或其他材料中复制以上版权声明,此条件列表以及以下免责声明。 (2)未经明确的事先书面许可,不得使用{版权所有人}的名称或其贡献者的名称来认可或促销从本软件衍生的产品。 免责声明 版权持有者和贡献者按“原样”提供此软件,不提供任何明示或暗示的保证,包括但不限于针对特定目的的适销性和适用性的暗示保证。版权拥有者或贡献者在任何情况下均不对任何直接,间接,偶发,特殊,专有或后果性的损害(包括但不限于,替代商品或服务的购买,使用,数据,或业务中断),无论基于合同,严格责任或侵权行为(包括疏忽或其他方式),无论出于任何责任,无论是否出于使用本软件的目的而作出的赔偿,均已经事先告知。 我以前从没有分叉过一个项目,但是这个项目与我需要/想要的东西非常相似。但是,我不确定会走多远,所以我的计划是从他们的存储库中获取最新信息并开始工作。也许最终,我会把它放到想要的地方,然后能够释放它。这是正确的方法吗? 确切地说,这如何影响项目的分叉?如何跟踪谁拥有哪些组件或部分(一旦我开始踩踏他们的代码库,我的版权是什么,原始创作者的版权是什么)?我可以分叉这个项目吗?在发布之前,以及何时/如果我决定发布从BSD许可的作品中衍生的软件,我必须做什么?

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.