首页 文章 精选 留言 我的

精选列表

搜索[分支],共10000篇文章
优秀的个人博客,低调大师

Neo4j 开源转闭源企业版被分支,法院:开源宣传为虚假广告

OSI 发表了一篇博客称“Stop saying Open Source when it's not”。缘于美国第九巡回上诉法院最近确认了下级法院的一项判决,得出了一项结论:如果一个公司声称其软件是“开源”的,但并没有根据开源协议获得许可,那就是虚假宣传。 事件起因在于,开源的高性能的 NoSQL 图形数据库 Neo4j 及其瑞典子公司在 2018 年和 2019 年以商标和版权侵权等为由,起诉了Graph Foundation、PureThink 和 iGov 公司及其负责人。 Neo4j 提供了免费开源的社区版(采用 GPLv3协议)和付费的企业版Neo4j EE。而 Neo4j EE 在 2018 年 5 月发布 3.4 版本时放弃了原本的 AGPL 协议,变更为更为严格的 AGPLv3 +CommonsClause 双重许可;这个新许可条款禁止该软件的非付费用户转售代码或提供一些支持服务。同年 11 月,Neo4j产品副总裁Philip Rathle 又宣布从Neo4j 3.5 版本开始,企业版将仅在商业许可下提供,不再在 GitHub 上提供源代码。 在此背景下,被起诉的三方则提供了一个名为Open Native Graph Database (ONgDB) 的产品 —— 基于 Neo4j EE 分叉出来的;并开始以仅 AGPLv3 许可的形式分发其版本,将 ONgDB 宣传为“免费和开源”、“100% 自由和开放”和“100% 开源”,与Neo4j 形成了市场竞争。 法院受理此案件后,Graph Foundation 根据判决表示将不再声称其 Neo4j EE 分叉的 ONgDB 的特定版本是 Neo4J EE 的"100% 免费和开源版本"。去年 2 月,该组织宣布停止了对 ONgDB 3.4、3.5 和 3.6 版本的支持;并以 AGPLv3 许可的 Neo4j EE 3.4.0.rc02 版本的分叉形式发布了 ONgDB 1.0 来代替它们。 与之相对应,PureThink 和 iGov 也被法院裁决要求做出类似的让步。去年 5 月,法院在审理针对 PureThink 和 iGov 的索赔案时初审判决,禁止被告侵犯 Neo4j 的商标,同时禁止被告宣传 ONgDB 是 Neo4j EE 的免费和开源替代品......之后被告提出上诉,美国第九巡回上诉法院则于今年 2 月确认了下级法院的裁决,即该公司“关于 ONgDB 是 Neo4j EE 的‘免费和开源’版本的声明是错误的”。 法院认为,被告删除 Commons Clause 是不恰当的,因此被告在广告中声称其 ONgDB 软件是开源的,属于虚假宣传。 就虚假广告索赔而言,商业广告中必须有虚假陈述,而且该陈述必须具有实质性的欺骗性。初审法院认为,将"Commons Clause"下的软件描述为"自由和开源"是虚假的,这种欺骗行为也是实质性的。"由于被告将 ONgDB 错误地表述为根据 APGLv3 许可的 Neo4j EE 的免费版本,毫无疑问,这种价格差异(免费与付费)可能会影响客户的购买决定。因此,法院认为,被告人暗示客户可以获得 Neo4j EE 的'免费和开源的替代品'的声明是实质性的。" OSI 称: 法院只证实了我们已经知道的 —— “开源”是针对已根据特定类型许可获得许可的软件的专业术语,而许可证是否是 OSI 批准的许可证是用户采用软件的一个至关重要的因素。如果被告希望将其软件授权给仅 AGPLv3 是被允许的,那么其“100% 开源”的主张就不会是虚假的,也不会有虚假广告。但是加入非自由的 Commons Clause 后,就形成了一种不同的许可,使该软件不能被定性为"开源",在这种情况下这样做是非法的虚假宣传。 此外,该案例还有一个有趣的点。即,尽管 AGPL 有一个条款专门允许下游接收者删除“进一步的限制”,如 Commons 条款;但法院却阻止了被告这样做。 针对法院的这一判决,开源运动的发起者之一Bruce Perens在给 The Register 的一封电子邮件中指出:"这很有趣,因为法院执行了'开源'一词,尽管它没有在美国专利商标局注册为商标(当时我们没有律师的帮助,也没有钱)。但这承认了它是一种技术性的主张,在被滥用时可以被视为是欺诈性的"。 并补充称,法院不允许删除 Commons 条款也并不奇怪。"尽管 AGPL 有一些允许这种删除的措辞,但许可证不是万能的。它们实际上只适用于强制执行,如果一方不遵守条款,他们就是版权侵权者。而版权持有人本身不能成为他们拥有的作品的侵权者,只能是其他人的作品的侵权者。"

优秀的个人博客,低调大师

ApiBoot v2.3.x 分支初版发布,走出重构源码架构设计第一步

ApiBoot 是什么? 官方文档:https://apiboot.minbox.org 学习教程:https://blog.yuqiyu.com/apiboot-all-articles.html ApiBoot是接口服务的落地解决方案,提供了一系列开箱即用的组件,通过封装来简化主流第三方框架的集成,从而提高开发者开发效率、学习成本、降低入门门槛,真正的实现开箱即用!!! ApiBoot角色类似于SpringBoot,用于集成各种第三方框架,也会针对相同类型的框架进行归类,而它所属的开源组织minbox-projects内也会开源一些基础的框架,针对这些基础框架ApiBoot同样会做出集成。 更多开源信息请访问:https://blog.yuqiyu.com/opensource/ ApiBoot所属minbox-projects开源组织: 对SpringBoot简单了解的开发者就可以编写安全稳定的接口服务,可为移动端、网页端等多个端点提供丰富的安全接口。 ApiBoot依赖于SpringBoot,完全遵循SpringBoot自定义Starter的规范实现,可以使用ApiBoot构建独立的Java应用程序,主要的职责是封装并且落地项目中常用到的第三方依赖,未来会接入越来越多优秀的开源项目,提供统一的SpringBoot集成解决方案。 愿景: 为Java开发者提供低门槛第三方框架集成解决方案,让复杂的框架集成使用的门槛更低。 开箱即用,内部封装了主流框架,只需添加依赖、简单配置即可使用。 各个组件可独立使用,不再冗余你的应用程序。 可简单快速的构建安全的restful资源接口服务。 可用于构建SpringCloud微服务服务实例。 如果您想要系统的学习ApiBoot可以访问我的博客:https://blog.yuqiyu.com/apiboot-all-articles.html或者官方文档:https://apiboot.minbox.org v2.3.0 更新日志 ✨ 变更项目根模块的 "artifactId" 为 "api-boot-build" 新增 "api-boot-project/api-boot" 模块 将 "api-boot-plugin-alibaba-oss" 模块代码逻辑迁移至 "api-boot"模块 将 "api-boot-plugin-mail" 模块代码逻辑迁移至 "api-boot" 模块 将 "api-boot-plugin-sms" 模块代码逻辑迁移至 "api-boot" 模块 将 "api-boot-plugin-datasource-switch" 插件从项目中抽离作为独立项目存在 [#37] 将 "api-boot-plugin-http-convert" 模块代码逻辑迁移至 "api-boot" 模块 将 "api-boot-plugin-message-push" 模块代码逻辑迁移至 "api-boot" 模块 将 "api-boot-plugin-quartz" 模块代码逻辑迁移至 "api-boot" 模块 将 "api-boot-plugin-rate-limiter" 插件从项目中抽离作为独立项目存在 [#34] 将 "api-boot-plugin-oauth" 插件从项目中抽离作为独立项目存在 [#41] 将 "api-boot-plugin-sequence" 插件从项目中抽离作为独立项目存在 [#39] 将 "api-boot-plugin-security" 插件从项目中抽离作为独立项目存在 [#42] 将 "api-boot-plugin-resource-load" 插件从项目中抽离作为独立项目存在 [#35] 将 "${project.groupId}" 变量替换为 "org.minbox.framework" 分组 "api-boot-dependencies" 固化版本的依赖列表 配置banner使用 "${api-boot.version}" 变量,保持输出版本号与项目一致 新增 "api-boot-tools" 模块,提供常用工具类,如:ApplicationContextTools、BeanFactoryTools... "api-boot-mybatis-enhance-maven-codegen" 插件新增 "TypeMapping" 配置项,可配置Jdbc与Java类型的映射

优秀的个人博客,低调大师

[ 📣 Teanary 1.4分支发布]想听一线外贸从业者的需求,把你想要的或者想像中的能力说出来

📣 Teanary 共建招募 面向一线外贸从业者,一起把「AI + 跨境电商」做对,而不是做炫。 讨论地址:https://gitee.com/teanary/teanary_service/issues 🧩 我们是谁? Teanary 是一个持续演进中的 开源电商后端项目, 专注于 跨境 / 多语言 / 多节点部署 的真实业务场景。 📦 基于 Laravel 的后端架构 🌍 面向全球多站点、多币种运营 🧠 在 Teanary 1.4 中全面迈向 AI 原生、可运营的电商架构 📄 开源协议:AGPL-3.0 如果想快速了解项目整体定位与架构,可以先参考: 根目录 README.md:Teanary 1.4 概览与定位 docs/ARCHITECTURE.md:系统架构与数据流程图 docs/VISION.md:AI‑Native 电商基础设施愿景(英文) 这意味着什么? ✅ 项目长期开放、代码透明 ✅ 没有「闭源核心 + 开源壳」 ✅ 不会把社区想法拿走做闭门产品 ⚠️ 如果有人基于 Teanary 提供网络服务,必须开放修改后的源码 Teanary 不是「我们做,你们用」 而是「一起共建,一起决定方向」 📄 关于开源协议(给非技术同学看的解释) Teanary 使用的是 AGPL-3.0 开源协议,可以简单理解为: ✅ 你 可以免费使用 这个系统的源码 ✅ 你 可以改代码、做二次开发,用于自己的业务 ✅ 你 可以基于它提供线上服务(比如 SaaS 系统) 但有一个非常重要的前提: ** 只要你基于 Teanary 做了修改,并且把它拿去对外提供网络服务, 你就必须把「修改后的那一份代码」也开源出来。** 用更接地气的话说: 可以拿去用、可以拿去改、可以拿去赚钱 但不能把「改过的版本」锁在自己公司里不让别人看 你享受了开源社区的成果,也需要把自己的改动反哺给社区 这对非技术同学意味着: 如果你只是作为「用户」在用 Teanary 部署电商站点,不需要担心什么法律条款 如果你准备把 Teanary 改造成一个对外收费的 SaaS 产品, 那么需要接受一个前提:你改过的那部分代码,也必须公开 我们选择 AGPL-3.0,是为了保证: 一线共建者、使用者的经验,不会被「关进一个私有版本」里 社区一起打磨出来的能力,长期对所有人开放 🎯 我们正在解决什么问题? 从 v1.4 开始,Teanary 不只关心「功能是否齐全」, 而是更在意一件事: 电商系统,如何真正「好运营」? 我们在系统层面探索: AI 如何参与 数据分析、异常发现、运营建议 在跨境、多站点环境下,AI 该看什么、不该碰什么 哪些环节应该自动化,哪些环节 必须由人来拍板 如何通过能力封装(而不是「直接给数据库」)让 AI 在安全边界内工作 结合当前的架构设计(详见 docs/SYNC.md、docs/ARCHITECTURE.md), 我们更关注: 多节点、多站点下,运营决策的数据从哪里来、可信度如何 订单 / 库存 / 促销 / 流量这些数据,如何对运营真正有用 系统如何为 AI 暴露「能力」,而不是裸露「数据表」 ⚠️ 有些事我们明确不会做: ❌ 全自动调价机器人 ❌ 黑盒式自动决策 ❌ 「看起来很聪明,实际很危险」的无人值守自动化 🙋 为什么要找你? 我们非常清楚一件事: 不做外贸的人,永远设计不出真正好用的外贸系统。 市面上已经有太多: 「程序员想象中的外贸」 「PPT 里的智能运营」 「脱离一线的 AI 自动化幻想」 而 Teanary 想做的是: 在 架构设计阶段 就把真实业务经验拉进来 让一线的痛点,直接塑造成系统里的「第一等公民能力」 👀 我们希望谁来参与? 如果你是以下任何一种角色,我们都非常欢迎: 🌍 外贸老板 / 创始人 📈 跨境电商运营人员(站点负责人、类目负责人等) 📦 物流 / 仓储 / 供应链从业者 💰 负责定价、利润、促销策略的人 🧾 每天盯着报表,但「看不出结论 / 看不出动作」的人 你不需要: 懂 AI 会写代码 看得懂架构图 你只需要真的干过、真的被折磨过。 💬 你可以提供什么? 不需要写方案,也不需要懂技术, 我们真正需要的是「真实世界的问题」: 你在跨境电商中最痛的 1~3 个问题 哪些数据你每天都在看,但「看了也不知道下一步怎么办」 在多国家 / 多站点运营中,最容易出问题的地方 你希望 AI 帮你做什么(提醒、诊断、汇总、对比……) 你坚决不希望 AI 碰什么(价格、库存、结算、合规等) 哪怕只是一句吐槽: 「这事如果能提前提醒我就好了」 对我们来说都非常有价值。 🤝 我们会怎么用你的反馈? 你不是「被调研对象」,而是共建者: 你的问题会进入 Teanary 1.4 的设计讨论 你的痛点有机会被抽象成 系统级能力(而不是临时脚本) 你可以完全否定我们的某些想法 你可以指出哪些方向 从实战角度看永远不应该做 如果这些能力最终在系统里落地: 你会是最早一批真正受益的人 你的经验会被沉淀成长期可复用的运营工具 🎁 你能获得什么? 根据你参与的深度不同,你可能会获得: 提前体验 / 验证新能力的机会 针对你业务场景的配置建议与参考实践 在文档或版本说明中记录你的贡献(如你愿意署名) 一套真正「从一线出发」的 AI + 电商基础设施 我们更在意的是: 这个系统能不能帮你少踩坑、少返工、少熬夜。 📮 如何参与共建? 你可以选择任何你舒服的方式: 在 GitHub Discussions / Issues 留言(公开、可跟踪) 仓库地址见根目录 README.md 与 docs/READMEEN.md 私下交流(可匿名,只分享场景与问题本身) 用一段文字描述一段真实经历或一个典型问题 不需要格式,不需要包装。 越「真实、具体、难受」,越有价值。 📝 最后一句真心话 我们不想做一个 「看起来很先进,但一线没人用」的 AI 电商系统。 我们更想做的是: 一个由真实外贸经验塑造的、长期可靠的运营型电商后端。 如果你愿意把真实问题放到桌面上, 我们愿意把它变成真正有用的系统能力。 欢迎你,一起共建 Teanary。

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

用户登录
用户注册