开源软件有漏洞,作者需要负责吗?是的!

开源软件有漏洞,作者需要负责吗?是的! 近日,禅道创始人王春生在开源中国发布的一篇引起了众多同行的围观,原因是他分享了一个开源协议在中国面临的 bug:开源软件许可协议通常会表明作者不对用户使用该开源软件所造成的任何问题负责。但是!这种条款,在中国,是违法的

相关推荐

封面图片

这个作者以一己之力加开源项目模式,估计要颠覆翻译软件这个行业了。

这个作者以一己之力加开源项目模式,估计要颠覆翻译软件这个行业了。 你只要一个openai的key,其他都是免费的,我想说这很web3,为爱发电,自由奉献。 一路看这个软件走来,从最初的bob插件,到Chrome插件,再到独立的app本地划词,现在这个软件已经支持本地客户端且跨平台(mac、win、Linux) 我也提了一些思路的pr。如果有空应该也会贡献一些代码。 我提了一个本地单词本的实现思路,数据存在用户本地。如果作者会实现,那就最好了。基于该项目的开源协议,在上面还可以衍生出非常多有意思的项目。 基于该项目是MIT, 希望看到该项目的人不要作恶,好好维护开源社区的氛围。 还是回到最初的思考,希望软件版本一次付费(作者现在没有收费,但是我们可以打赏),数据归用户所有(本地存储),而你只需要再提供一个有魔力的openai key。 项目地址:

封面图片

开源音乐软件 MusicFree

开源音乐软件 MusicFree 插件化播放器,支持添加音源。插件支持的功能:搜索(音乐、专辑、作者、歌单)、播放、查看专辑、查看作者详细信息、导入单曲、导入歌单、获取歌词等。 示例音源:https://gitlab.com/acoolbook/musicfree/-/raw/main/music.json 音源使用方法:进入软件 - 插件管理 - 从网络安装,填入音源地址即可 GitHub:https://github.com/maotoumao/MusicFreeDesktop #实用网站推荐 #音乐 #资源下载

封面图片

马斯克回应OpenAI拒绝开源:世界上最安全的软件是开源的

马斯克回应OpenAI拒绝开源:世界上最安全的软件是开源的 硅谷风投大佬马克·安德森转发了OpenAI曝光的公司联合创始人伊尔亚·苏茨克维(Ilya Sutskever)的一封邮件的截图,并评论称:“如果你相信这一点我不相信你怎么可能不要求这些实验室立即国有化和军事化?”前微软高管、现任风投公司Andreessen Horowitz董事会合伙人的Steven Sinofsky评论称:“值得注意的是,你们肯定知道,这是与安全性相关的反对开源的经典论点。开源不安全的想法,因为‘坏人’可以看到源代码来利用弱点。闭源可以防止这种情况。这是完全错误的。”安德森回应称:“世界上最安全的软件是开源的。多数人关注,多数bug得到修复。QED(证明完毕)”马斯克回应称:“千真万确。”             ... PC版: 手机版:

封面图片

开源软件程序员对 OpenAI 和 GitHub 数字版权索赔被驳回

开源软件程序员对 OpenAI 和 GitHub 数字版权索赔被驳回 开源软件程序员指控 OpenAI Inc. 和 GitHub Inc. 在没有适当的版权声明和许可信息的情况下复制了他们的代码。当地时间周五,法官 Jon S. Tigar 以违反《数字千年版权法》为由驳回了程序员的申诉,裁定他们未能证明他们的代码被完全复制。但法官确实允许程序员对科技公司违反开源许可协议的指控继续进行。

封面图片

阿里云发表关于开源社区Apache log4j2漏洞情况的说明

阿里云发表关于开源社区Apache log4j2漏洞情况的说明 Log4j2 是开源社区阿帕奇(Apache)旗下的开源日志组件,被全世界企业和组织广泛应用于各种业务系统开发。 近日,阿里云一名研发工程师发现Log4j2 组件的一个安全bug,遂按业界惯例以邮件方式向软件开发方Apache开源社区报告这一问题请求帮助。Apache开源社区确认这是一个安全漏洞,并向全球发布修复补丁。随后,该漏洞被外界证实为一个全球性的重大漏洞。 阿里云因在早期未意识到该漏洞的严重性,未及时共享漏洞信息。阿里云将强化漏洞管理、提升合规意识,积极协同各方做好网络安全风险防范工作。 阿里云计算有限公司

封面图片

开源许可的种类与区别 开源许可证是指软件开发者将其代码公开,并允许他人使用、修改和发布的许可证。

开源许可的种类与区别 开源许可证是指软件开发者将其软件代码公开,并允许他人使用、修改和发布的软件许可证。 1⃣ MIT License 特点:非常宽松和简单。允许几乎任何用途,只要保留原作者的版权声明和许可证。 使用场景:适合希望最大程度推广软件使用的项目。 限制:几乎没有限制,不要求发布修改后的代码。 2⃣ GPL-2.0 (GNU General Public License v2.0) 特点:强制开源。要求所有修改和衍生作品也必须开源,并以相同的许可证发布。 使用场景:适合希望确保软件及其修改版本始终保持开源的项目。 限制:强制性的开源要求,适用范围广,可能不适合商业软件。 3⃣ GPL-3.0 (GNU General Public License v3.0) 特点:在GPL-2.0的基础上增加了一些新的条款,如防止“反锁”(Tivoization)和软件专利条款。 使用场景:与GPL-2.0类似,但适合对防止硬件限制和专利诉讼有额外需求的项目。 限制:更严格的开源要求和条款。 4⃣ Apache License 2.0 特点:允许几乎任何用途,但要求保留版权声明和许可证,提供修改记录,并且有专利授权条款。 使用场景:适合希望对专利问题有保障的项目。 限制:要求明确修改和保留原作者声明。 5⃣ BSD License (Berkeley Software Distribution) 特点:与MIT许可证类似,非常宽松,允许几乎任何用途,只需保留版权声明。 使用场景:适合希望最大程度推广软件使用的项目。 限制:几乎没有限制,不要求发布修改后的代码。 6⃣ LGPL (Lesser General Public License) 特点:与GPL类似,但对与非开源软件一起使用时更宽松。允许在非开源软件中使用开源库。 使用场景:适合希望其库在开源和非开源项目中都能使用的开发者。 限制:要求修改后的库依旧开源,但允许链接到非开源项目。

🔍 发送关键词来寻找群组、频道或视频。

启动SOSO机器人