React: 考虑重新授权给 AL v2.0,就像 RocksDB 刚刚做的那样

创建于 2017-07-16  ·  128评论  ·  资料来源: facebook/react

你好呀,

Apache 软件基金会法律事务委员会宣布,不再允许将所谓的“Facebook BSD+专利许可”用作 Apache 项目的直接依赖项。

这在 Apache 社区中引起了很多不满和沮丧,特别是来自需要类似许可代码作为直接依赖项的项目 - 其中主要是 RocksDB。

然而,我们(Apache 软件基金会)刚刚收到消息, RocksDB 将在双重 Apache License v2.0 和 GPL 2 许可下重新许可他们的代码

作为 ASF 顶级项目 (Apache CouchDB) 中 React.JS 的用户,请考虑在类似条款下重新许可 React.JS。 否则,许多 ASF 项目(例如我们自己的项目)将不得不停止依赖和构建 React。

之前的错误 (#9760) 建议我在询问许可问题时在此问题中提及@lacer ,所以我这样做了。

非常感谢您的考虑。

最有用的评论

大家好,感谢您的耐心等待。 本周即将结束,但不幸的是,我还没有给你任何解决方案。

不过,我想指出,内部讨论背后有真正的动力。 下周将举行更多会议,将此事上报给工程总监。 正如你想象的那样,他们很忙,所以这比我们想象的要花费更多的时间。

同样,我不能向你保证任何具体的结论,也不清楚这将在哪里落地。 但请知道有人正在努力让您的声音被听到。

所有128条评论

据我所知,FB 对追求 BSD+专利许可的更严酷的可能性不感兴趣。 如果这是真的,那么 BSD+专利和 Apache 许可证之间实际上几乎没有区别。 因此,重新许可对 Facebook 几乎没有实际影响。

然而,这样的变化将使谨慎的下游企业更容易。 请考虑进行更改。

@lacker不再在 Facebook 工作。 我在弄清楚谁最适合将此路由发送给我时遇到了一些麻烦,但我会在周一再次查看。 谢谢你提出这个!

RocksDB 现在是双 Apache 2.0 和 GPL v2 许可的https://github.com/facebook/rocksdb/pull/2589

与其将许可证切换到 Apache 许可证 2.0 (ALv2),这不是很多人喜欢的,与 GPLv2 不兼容)和/或双重许可 ALv2 + GPL 混乱,Facebook 会考虑再次更改 PATENT 许可证以使终止条款看起来更像是 ALv2 中的专利许可授权:

如果您对任何实体提起专利诉讼(包括诉讼中的交叉索赔或反索赔),声称该作品或包含在该作品中的贡献构成直接或共同的专利侵权,则根据本许可授予您的任何专利许可工作自提起诉讼之日起终止。

这会让 ASF 人满意吗?

只是为了发表意见,在我和我公司的软件项目中,我避免使用使用 ALv2 的依赖项,并且我反对从类似 BSD 的许可证中重新授权。 我更希望 ASF 重写他们的软件,不使用他们的律师说不能使用的依赖项,而不是说服他们不能用来更改许可证的每个项目。

我们只是询问该项目是否会考虑更改许可证。 如果需要,Apache CouchDB 和其他人将不再使用 react。 我们宁愿不这样做,很多工作都没有真正的收获,但我们别无选择。 更改许可证很简单(RocksDB 在一天内完成了更改)。

我们只是询问该项目是否会考虑更改许可证。

我明白。 我的观点是,ASF 和 Facebook 是否会努力达成可接受的专利文件,而不是更改许可证?

(顺便说一句,除了作为用户之外,我与 React 项目或 Facebook Inc. 没有任何关系。)

很好的问题,需要 ASF 法律部门的人员来回答。 如果可以的话,我会把它们指向这里。

@dchest贵公司认为有必要在反应许可证中尚未存在的 ALv2 中避免的具体内容是什么?

现有的 PATENTS 文件令许多人感到震惊,而不仅仅是 ASF。 我认为此请求的目的是减轻许可问题,这些问题会导致采用过程中出现不必要的障碍。

@nevetS由于Oracle America, Inc. 诉 Google, Inc.我避免在公开场合或通过电子邮件讨论任何许可决定的任何细节,因此我将把它留给其他勇敢的灵魂和/或律师。 我只是决定在这里发表我的意见,因为我没有看到反对意见,而实际上有反对意见。

该问题涉及通过使用该组织编写的许可证(当然,它是 OSI 批准并广泛使用的)重新许可来改变现状以满足一个组织的需求(但我相信还有其他组织),具有疏远其他开源(和“自由软件”)项目。 我不希望这种情况发生在 React 上,所以我试图通过更改 PATENTS 文件来看看是否存在中间立场,这种方式将同时满足 Facebook 和 ASF。

由于 PATENTS 文件,许多人不使用 React(和 Immutable 等)。 最简单的解决方案是将其从所有 Facebook 存储库中删除。

修改了类似 GPL 的类似共享专利条款?

最近,医学研究机构重新意识到开源许可合规性。 开源软件合规性的法律审查通常明确要求 Apache 2.0 许可证,正是因为它的构建合理并且包括公平的专利授权。 由于美国大学依赖专利许可作为其立法授权的技术转让计划的一部分,因此它们在尽职调查中变得更加谨慎。 出于这个原因,在一些大学,用 React 编写的软件可能会被回避。 使用 React 软件的现有项目可能会被要求删除 React 软件软件依赖项。 请强烈考虑这个提议,因为我们的 RexDB 工作在主要大学使用,我们不希望返工使用 React 替代品。

@clarkevans感谢您对讨论的贡献! 正如您所说,审查的目的是确保合规性,即保护自己免受诉讼。 对于任何组织来说,这都是一个有价值的目标,但我怀疑是否考虑了许可证对开源生态系统的影响,我认为这种影响非常重要。 众所周知,简单的类似 BSD 的许可证可以减少开源项目的摩擦。 如果 Facebook 授予额外专利权(与版权许可分开)这一事实给某些组织带来了问题,我认为值得考虑通过专利授予来解决问题,而不是切换到包含它的许可。

这是我认为可能适用于所有人的专利许可示例: https :

@dchest我不是律师,但我不确定您是否可以认为 BSD 许可证独立于额外的专利授权,它与意图有关,而专利文件会改变意图。 甚至 Facebook 的博客 [1] 也将他们的许可称为 BSD+专利,“我们使用标准 BSD 许可,并为我们的大多数开源项目提供额外的专利授权。为简洁起见,我们将这种组合称为 Facebook BSD+专利许可。 ” 最近有消息称 GPL 可以作为合同强制执行 [2],这让情况变得更加复杂。 请注意,在开源计划中有足够的异议,CC0 未被批准为开源许可证 [3]。 因此,我认为一旦添加了额外的专利许可,您就不能独立查看 BSD,因为您不能再假设存在隐含的专利授权。

虽然 Apache 2.0 许可证可能并不完美,但为了统一许可证,它比添加另一个许可证要好得多。 如果有人提议,OSI 肯定会拒绝 Facebook 的 BSD+专利许可。 因此,实际上,由于此添加,您可能希望明确地将 React 视为“非自由”。 许多人在 BSD 许可证中添加额外的非自由条款,并每年向 OSI 提出建议,几乎在所有情况下,该许可证都因不符合开源标准而被拒绝。

[1] https://code.facebook.com/pages/850928938376556
[2] https://perens.com/blog/2017/05/28/understanding-the-gpl-is-a-contract-court-case/
[3] https://opensource.org/faq#cc -zero

进一步说明,作为加入 CNCF 的一部分,谷歌的 gRPC 被重新授权到 Apache-2.0。 他们在这里解释了他们的推理: https :

OSI 批准的 Facebook 许可证+授权组合的替代方案还包括 UPL[1] 和 BSD+专利 [2],这两者都可能与 Apache 的许可证兼容。 在可能的情况下,我建议避免发明更多的法律语言。

[1] https://opensource.org/licenses/UPL
[2] https://opensource.org/licenses/BSDplusPatent

对于@dchest所说的匿名人士的模糊恐惧,与当前的 Apache 许可证建立明确的兼容性正是 GPL v3 的主要原因之一。

更具体地说,编写另一个许可证让人们必须跟踪和分析简直是愚蠢的。 如果您在 BSD 模型之上编写了一种“就像”Apache 语言一样的专利语言,那么这一点尤其如此,而 BSD 模型也“就像”Apache 语言一样,除了 Apache 许可证是根据主管法律顾问的反馈更新的.

@nevetS

我认为@dchest从未说过他的公司发现 Apache 许可证有任何问题。 他只是说他在工作中尽量避免这种情况。 那是完全不同的。

我(不知情的)猜测是他的公司对 Apache 没有任何问题,除了来自 Dmitriy 本人的问题。

Minio 团队希望看到这种变化发生。 我们的对象存储浏览器 UI 基于 react,并且我们已获得 Apache 2.0 许可。

迁移将是不幸且耗时的,但我们将不得不这样做以代替有关 Apache 不兼容的新信息。 请考虑重新许可 React。

谢谢您的考虑。

@harshavardhana我想你误解了这种情况。 当前许可证与 ALv2兼容。 情况是 Apache 软件基金会的律师(更正:政策制定者)​​声明他们的项目不会使用任何获得 BSD+Facebook 专利许可许可的依赖项,因此他们的人提交了这个问题,以说服 Facebook 在 ALv2 下重新许可。 许多其他人认为当前的许可和专利授予有问题,一些公司也因此禁止 React。 然而,React 被更多没有问题的公司使用。 另见https://github.com/omcljs/om/issues/882#issuecomment -315664114

关闭,@dchest。 做出这个选择的不是我们的律师,而是我们的政策决定,禁止将 FB/BSD+专利许可混入基金会向用户发布的软件中。 而且我认为没有人期望重新获得许可。 此更改是作为围绕此特定许可的政策的“内部”更改而公布的。

当前许可证与 ALv2 不兼容。

来自apache 的讨论

Roy T. Fielding 添加了评论 - 17 年 6 月 12 日 13:50
我已经与 Facebook 的法律顾问讨论过该许可。 它不是 BSD(依赖于隐含的专利授权)并且故意与 Apache 许可证不兼容。

重新许可的请求是礼貌地提出的, @gaearon 也同样礼貌地提出了

Apache CouchDB 方面没有改变的期望,但肯定有很大希望实现重新许可。 我希望 Dan 可以与@daveman692 之类的人

@wohali当然可以,我希望我的评论不会被认为是不礼貌的,如果是这样的话——抱歉,这不是我的本意。 需要注意的是,ASF 意见在开源社区中受到高度重视,因此当您提出问题时只是简单而礼貌地请求更改许可,但事实上该请求是由 ASF 政策立场引起的——重新许可,否则我们将停止使用它 - 有一个副作用,让其他人害怕当前的许可证。

我希望 Facebook 和 ASF 达成双方都能接受的条款,但是我希望看到以当前 BSD 许可证加上更改的 PATENTS 文件而不是 ALv2 的形式进行妥协。 我也希望 ASF 自己提出这个作为一个选项。

(这就是我要说的几乎所有内容,所以我取消订阅此线程。)

为了给你一个小的更新,大约一周内会有更多关于这个的内部讨论。 这就是我能说的。 我不会对 React 的这种变化过于乐观,但我们会看到。 @daveman692已同意在这些讨论结束后提供更新。

所以在这里澄清一下,有很多相互矛盾的信息。 如果软件包含 BSD+Patents 依赖项,是否可以不在 Apache-2.0 下获得许可? 或者这是否是 ASF 的内部政策让人们感到紧张,因为这是一个受人尊敬的基金会的公开批评声明,其律师了解开源许可证?

这就是我所理解的问题:React 许可证的专利授权范围比 Apache-2.0 的要窄,因为它禁止针对 Facebook 的专利诉讼,而 Apache-2.0 则不会。 许可证仍然兼容,因为它们可以在同一作品中一起使用。 然而,由于 React 的专利限制,该工作的整体许可(称为 Apache+React)不如 Apache-2.0 宽松。 Apache 软件基金会的政策是不分发不能根据 Apache-2.0 条款整体获得许可的软件。 因此,它不会在自己的项目中接受 React 许可,因为它会使项目的许可比 Apache-2.0 更加严格。

@samuelhorwitz我认为以下链接可能会有所帮助:

ASF 关于 Facebook 专利+BSD/ROCKSDB 许可的法律声明

阐明此政策对特定项目的意义

我不相信除了“我们不能使用此许可证托管任何依赖项”和“我们不能允许我们开发的软件完全依赖于使用此许可证的软件”之外,没有其他判断或批评。

由于潜在的混淆,嵌套具有不同许可证的依赖项是一项艰巨的任务。 此时,Apache 软件基金会内的项目可以利用 react,但前提是最终用户单独下载 react,并且只有在有替代方案的情况下。 这并不理想。 鉴于 RocksDB 的许可证被更改,并且至少给人的印象是 BSD+Patents 许可证背后的意图与 apache 许可证非常相似,似乎是为了确定这种情况是否可以解决(潜在的)通过采用 RocksDB 最近采用的不同许可证的方式)。

@copiesofcopies把这一切

该请求是由 ASF 政策立场引起的 - 重新许可​​,否则我们将停止使用它 - 具有使其他人害怕当前许可的副作用。

人们_应该_害怕它。 如果您构建的软件依赖于 React、Immutable 等,那么很多人将无法使用该软件。 PATENTS 文件通过进入依赖项的依赖项,毒害了开源生态系统。

React 最初是在 Apache 2.0 许可下发布的。 有些人在开始使用 React(可能是 Automattic for Calypso )时可能依赖于该许可证。

因此,人们通常要求的基本上只是 React(和相关项目)在首次发布时处于原始许可之下:
https://github.com/facebook/react/blob/75897c2dcd1dd3a6ca46284dd37e13d22b4b16b4/LICENSE

我不知道 Facebook 为 React 授予原始 Apache 许可证的专利含义是什么,但它们可能值得思考。

在我们讨论的同时,我们是否也可以将GraphQLRelayReact NativeFlow放入讨论中,因为它们也具有相同的许可证 + 专利格式。
虽然它们不如 React 流行,但它们对开源社区和使用它们的人同样重要,并且经常与 React 一起使用。

编辑:将 Flow 添加到列表中。

其他大公司,比如我的(Adobe),出于同样的原因,不能使用 React、Pop 等。 我们很乐意参与该项目,为每个项目做出贡献等等。但 Facebook 的严厉专利条款是一个亮点。

在罗马时... https://github.com/facebook/jest 也请:)

出于这个原因,即使是像我这样的中型公司(ViaSat)也开始禁止使用 Facebook 的“开源”项目。 我们想构建 React 网络和原生应用程序,但似乎任何明智的法律部门都会建议不要同意 Facebook 的非对称专利授权。

如果我们正在编制一个列表,Google 也会因为这个 PATENTS 废话而在内部禁止使用 React(尽管许多团队想要采用它)。 (这可能在我离开后发生了变化。)对于一个以其他方式鼓励社区采用的项目来说,这是一个荒谬的障碍。

新的专利授权(更改过一次)是根据 Google 的反馈专门创建的,最后我听说他们的律师对此很满意。

所以不考虑我们其他人的律师对此不满意吗?

我不确定这有多大可能,但是在 PATENTS 文件添加之前分叉 React 的核选项呢:

https://github.com/facebook/react/commits/master/PATENTS

似乎是一种巨大的浪费,但如果 Facebook 不想打球,人们还能做什么?

我是 Project Jupyter 的指导委员会成员,这是一个构建 Jupyter Notebook 的开源项目 (http://jupyter.org/)。 我们希望在许多 Jupyter 存储库中使用 react/immutable,而 FB 许可的专利条款继续给 Jupyter 的企业/组织用户带来问题。 对于很多这样的用户来说,这不是问题(他们已经在使用 react),但是对于很多人来说,他们感到沮丧的是他们必须让他们的律师参与评估使用 Jupyter 的风险(如果我们使用 react)。 在一个开源已成为许多领域事实上的选择的世界里,回到“我们必须先与我们的律师交谈......”的土地真的很痛苦。

Jupyter 领导层并不相信 FB 专利条款存在实际问题,但仅仅因为这会给 Jupyter 的机构用户带来摩擦这一事实就是一个巨大的问题。 它还人为地限制了该许可下 react 和其他库的采用和使用。

我只想放弃我对这个问题的个人意见。
我个人认为开源世界是现实生活中的公共图书馆。
在这里,任何地方的任何人都可以自由访问、获取知识,并且可能无需承担任何义务,以回报他们的知识。
人们通过分享知识互相帮助,让世界变得更美好。
我知道这是非常乐观的,但这就是我的感受。
我喜欢使用开源项目,作为回报,我自己创建了数十个开源项目,并使用 MIT 许可证授权所有这些项目,这对于像我这样没有任何法律背景的人来说似乎是最简单和最常见的选择。
当然,如果我能从他们那里得到一些东西就好了,但事实上,我已经做到了。
我一直在使用许多其他开源项目,这已经是我的收获。 我只是想回馈社会。 我觉得这是正确的做法。
我真的希望这个 React 许可问题不会成为 Facebook 与某些大型组织(如 ASF 或 Google)重新调整其许可的方式,而是更多地了解正确的做法。
我喜欢 React 和 Facebook 的其他项目,但我情不自禁地觉得 Facebook 正试图通过添加 PATENTS 子句来从中获取一些东西,即使它们只是按照建议的防御性条款。
这就像在公共图书馆最受欢迎的书中找到一张小纸条,上面写着“如果你读过这本书,将来……”。
或许超过90%的人不应该担心它,但它仍然是一件令人不快的事情。
我喜欢 React 并希望每个人都可以无忧无虑地自由使用它。

所以不考虑我们其他人的律师对此不满意吗? 形式不佳。

对不起,我是在回复上面专门针对 Google 的

我知道每个人都对这个问题感到沮丧。 就个人而言,将时间、精力和情绪健康花费在阻止人们使用 React 的合法笨拙上,我也同样感到沮丧。 我更愿意把这段时间花在共同努力上,让它变得更好。

但这种情况的现实是 React 的维护者(像我这样的人在问题跟踪器上进行交互)不是做出这些决定的人。 我们每个人都在尽我们所能向能够做出这些决定的人展示对这个问题的不同观点,我们也感谢您的反馈。 但是,只有每个人都保持文明和尊重,我们才能保持讨论的开放性。 谢谢。

@gaearon - 理解我误解了您评论的意图。
感谢澄清(和你的努力)。

只是为了确保这有点扎根,Apache 2.0 许可证的专利授权条款与现有的 Facebook 专利授权政策没有实质性的不同。 当然,使用更标准化的东西会更好,但任何关心今天使用 React 的人可能都应该对所有 FOSS 软件同样关心。 主要区别在于 Facebook 的撤销条款在哪些类型的知识产权诉讼将激活它方面更为广泛,但功能上的区别非常小。

也就是说,srsly 使用标准化的东西,让双方的生活更轻松。

我一生中从未对任何项目写过这样的评论。 我不确定点击“评论”按钮是否是个好主意。 请尊重我在下面所说的一切。 React 是一个美妙的生态系统,我们都想要最适合它的东西,我真诚地相信每个人(包括 Facebook)都在尽其所能。

就我个人而言,我同样感到沮丧的是,将时间、精力和情绪健康花费在阻止人们使用 React 的合法笨拙上。

但是,只有每个人都保持文明和尊重,我们才能保持讨论的开放性。

不用说,保持文明和尊重的讨论是最重要的。 很明显,这种情况对任何人来说都不好玩(包括 facebook 的开发人员和律师,React 及其生态系统的所有贡献者,当然还有像我这样的开发人员,他们因专利情况而无法使用 React/React Native) .

也就是说,我在上面引用的句子中表达的情绪正是这种情况如此不平衡和有问题的核心。

坦率地说,这被认为是合法的笨拙的巨无霸是令人恐惧的。 React 的生态系统已经滚雪球,它对几乎所有软件开发的未来都非常重要。 软件开发从未如此重要,它以真实的方式影响着真实的人。 Facebook 是一股强大的技术力量,进而影响到整个世界。 随着 Facebook 作为主导者扩展到更多平台,并将 React 保持在这些扩展的中心,专利情况的真正问题出现了。

例如,如果 Facebook 以封闭的围墙花园主导 VR(正如他们所定位的那样),并且他们碰巧决定必须使用 React 为 Facebook 的 VR 平台进行开发,则必须放弃(公司范围内!)任何有关以下方面的法律地位专利 vs. Facebook(世界上最强大的公司之一!),以便为当今的主导平台进行开发。 就好像在 Microsoft 的统治时代,为了创建 Windows 应用程序,必须放弃所有针对 Microsoft 的合法专利。 我觉得自己就像一个愚蠢的担心疣,甚至把它打出来,但如果你从逻辑上思考这一切,这就是我们今天所处的情况。

最后,如果围绕这个问题的讨论基调升温,所有讨论都将被压制,这种建议令人不寒而栗。 我们都对软件充满热情,我们显然都喜欢反应,否则我们就不会在这里,而且我们中的许多人已经投入了无数个小时的工作,如果这种情况没有改变,这些工作将不得不被抛弃。 这是一个极其复杂的情况,有很多不同的方面,有很多不同的关注点。 事情变得激烈是绝对可以预料的,因为我们都很关心。 我恳求每个人保持讨论文明和成熟,但是如果他们不讨论这个讨论将被沉默并且这个项目将在绝对不可接受的现状上继续下去的建议是一件令人不安的事情。

坦率地说,这被认为是合法的笨拙的巨无霸是令人恐惧的。

我认为你错过了盖伦的观点。 他并没有忽视法律问题,只是表示他不得不一次又一次地处理同样的争论,这让他非常沮丧。 他没有改变任何事物的魔力,就像他一样神奇。 相反,他必须经受住因无法控制的事情而带来的挫折风暴。

就个人而言,我建议我们离开此线程以获取有关线程主题的实质性更新:React 是否会被重新许可。 有很多平台(推特、媒体、电子邮件 Facebook 法律顾问、黑客新闻、reddit 等)来表达我们的热情; 我在我的公司花了很多时间来解决这个问题。 问题跟踪器是一个糟糕的工具,用于跟踪该主题可能产生的广泛讨论,就像过去发生的那样

我并不是有意要驳回这个问题。 如果我之前的评论是这样写的,我深表歉意。 我想说的是,这是一个错误跟踪器,而不是法律讨论的最佳场所。 尤其是因为我认为我们大多数人都不是律师。 您可能会将此线程视为对 Facebook 说些什么的一种方式,但您是在与像您这样的软件开发人员组成的团队交谈。

我们目前保持这个问题开放,因为有一个正在进行的讨论。 如果有任何更新,我们会通知您。 但是,我们过去总是在初步讨论后关闭此类问题。 这不是因为我们想让你沉默,而是因为永远保持开放并不能达到任何目的。 我们很好地听取了您的意见,我们已经转达了您的担忧。 但是在不同的线程中一遍又一遍地重复相同的观点无助于推动这一进程,并且会给已经对你的事业产生共鸣的维护者造成很大的噪音和压力。

过去发生的更新(例如更新资助以回应谷歌和其他公司最初的担忧,或发布常见问题解答以消除常见的神话)在经过多次内部讨论后发生在 GitHub 问题之外。 法律团队每隔一段时间都会重新评估这些决定,我们将确保他们听到您的声音。 我所要求的只是我们相互尊重,并在我们等待他们的决定时保持冷静的讨论。 谢谢。

@gaearon ,是否有进行此类许可讨论的可用场所?

我知道这可能不是进行此类讨论的最佳场所,但它是开放的,并且像您这样的人会积极响应。 我不知道这样的对话是否还有其他选择。

虽然我很感激 Facebook 就此事进行了内部讨论,但我希望 Facebook 的法律小组有一个开放的论坛,与 React 社区就许可进行交流。

@csepulv法律团队 ( legalus humanus ) 是一种难以捉摸的类型,通常在他们自然的私人办公室栖息地中找到,经常离开只是为了寻找食物或为他们提供住所......

@coderanger

只是为了确保这有点扎根,Apache 2.0 许可证的专利授权条款与现有的 Facebook 专利授权政策没有实质性的不同。 当然,使用更标准化的东西会更好,但任何关心今天使用 React 的人可能都应该对所有 FOSS 软件同样关心。 主要区别在于 Facebook 的撤销条款在哪些类型的知识产权诉讼将激活它方面更为广泛,但功能上的区别非常小。

我(非律师)对区别的理解是 Apache 2.0 说“本许可授予您根据本许可的条款使用本软件中获得专利的任何内容的权利”以及“如果您试图就本软件中的任何内容提起专利诉讼此软件,那么您将失去本许可授予您的所有专利权”。

而争论点是 BSD+Patents 条款说得更多,“如果你试图对 Facebook 提起专利诉讼,那么使用该软件所持有的潜在专利的所有权利都将丢失”。 这种不对称是人们所担心的,因为有关各方认为这与说“你的所有专利以换取使用 React”是一样的,因为即使“专利是邪恶的等等”,公司也可能希望提出合法的专利声明反对 Facebook 或某些附属公司的某些观点。

公平地说,Facebook,我真的怀疑这源于某种恶意,更多的是作为对当今荒谬的专利诉讼状态的防御措施,但这也不会改变人们的合理担忧。

无论如何,再一次,不是律师,但我想我应该清楚,在 GPL 阵营和其他反商业开源阵营之外,Apache 许可证被认为是一个非常好的商业开源许可证,因为它是明确的(对称的)专利授权/诉讼保护条款以及明确的商标保护条款,这两者通常都缺乏其他好的许可证,例如 MIT(并且许可证修改要么昂贵,要么由非律师的人​​完成,并做出贡献许可生态系统的复杂性)。

@qxqxqxqx我认为将这个问题视为“让 FB 改变”是不礼貌的。 我们希望他们这样做,但这不是我们要求的地方。

我真的希望 fb 能够响应社区要求遵守 react-js 和相关库以获得 Apache 许可证的请求,这可能会成为所有使用 react-js 的人的障碍,无法对其进行反应。

@gstein我只是想让他们知道我们对此感到担忧,如果我的表达方式有问题,我深表歉意。

@gaearon首先,感谢您的回应并保持建设性。 请让我补充一点,作为面向开发人员的开源软件的维护者,我同情您希望讨论代码和功能而不是许可证。

话虽如此,开源软件不仅仅是代码、问题跟踪器和发布。 开源软件的一个关键组成部分是许可。 所以,当你写

您可能会将此线程视为对 Facebook 说些什么的一种方式,但您是在与像您这样的软件开发人员组成的团队交谈。

感觉像是一种简化。 许多对此问题的评论者不想在 Facebook Inc. 公司发表声明。 他们想讨论 React 的一个重要方面,即框架。

现在,我明白像我们这样的软件开发人员不是讨论法律细节的最佳人选。 然而,合乎逻辑的结果是,做出此类决定的 Facebook 法律团队会在这个论坛中变得活跃吗? 与一个开源软件有关的所有相关细节

如果已经提出以下问题,我深表歉意。
我觉得奇怪的是,在广泛使用的许可证之上的 _additional grant_ 如此大惊小怪。
为什么这个帖子中提到的所有这些公司的所有合法部门都不担心_所有其他_在 BSD、MIT、GPLv2 等下获得许可的项目? 如果他们担心这项特别的拨款不够用,为什么似乎_根本没有拨款_可以?
也许我错过了什么?

也许我错过了什么?

如果没有明确授予专利的许可带有隐含的许可,并且有些人认为它确实如此,那么正在进行一般性讨论。

@cardamon保持简短。 IANAL,但是是的,你(似乎还有很多其他讨论,包括#7293 中提到的那些),都缺少那些其他项目(可能)拥有的隐式专利授权的概念,但是这里没有,因为授权是明确的。 请参阅http://en.swpat.org/wiki/Implicit_patent_licence

@cardamon我认为这就是为什么首选 Apache 许可证的原因。

BSD、MIT 等将是一个宽松的许可证,但不会授予 Facebook 可能拥有的涵盖 React(或任何其他项目)的任何专利。

Apache 是一种许可许可,但它具有专利大条款,该条款授予用户 Facebook 持有的任何相关专利的许可,保护他们免遭专利侵权。

Apache 专利授权与 Facebook 的 BSD + 专利许可(据我所知)之间的区别在于,Facebook 的专利授权更倾向于 Facebook 实际上可以访问您的专利,因为如果您起诉 Facebook,您将失去对 Facebook 可能的 React 专利的许可对于_任何_专利侵权。 如果您根据与许可项目直接相关的任何专利提起诉讼,Apache 只会取消专利授权。

本质上:

  • Apache 最适合大多数公司。
  • Facebook 目前的许可证很像 Apache,但语言更广泛。

@mitsuhiko @alexanderkjeldaas @matt-oakes 感谢您的澄清。

我认为技术公司评估此许可证的一个主要问题是合规性需要繁重的——也许是不可能的——程度的努力。

假设您是 Cisco,并且您路由器部门的一些前端开发人员在路由器的管理界面中使用 React。 一年半之后,您的 WebEx 部门注意到一家新的网络会议初创公司(称为 ConfCo)似乎正在使用您已申请专利的压缩技术。 你起诉初步禁令。 在发现过程中,您了解到 ConfCo 从 Facebook 子公司 QuickFire 获得了其压缩代码的许可。 Facebook 转而提出反诉,声称您之前在路由器中使用 React 的许可侵权,因为当您“针对任何一方 [ConfCo] 提起诉讼时,如果此类专利主张全部或部分出现,您的专利许可已终止来自 Facebook 或其任何子公司或公司附属公司的任何软件、技术、产品或服务。”

如果您是 Cisco 的专利律师,这就是您在阅读 React 许可证时所设想的那种场景。 既然您了解了风险,那么您需要在您的组织中建立什么样的系统来确保 WebEx 律师在提起 ConfCo 诉讼之前了解风险?

@cardamon @matt-oakes @mitsuhiko @alexanderkjeldaas

我在 LinkedIn 的团队在使用 React 进行内部项目时也遇到了法律问题。 我们希望看到这方面的变化。

大家好,感谢您的耐心等待。 本周即将结束,但不幸的是,我还没有给你任何解决方案。

不过,我想指出,内部讨论背后有真正的动力。 下周将举行更多会议,将此事上报给工程总监。 正如你想象的那样,他们很忙,所以这比我们想象的要花费更多的时间。

同样,我不能向你保证任何具体的结论,也不清楚这将在哪里落地。 但请知道有人正在努力让您的声音被听到。

@gaearon可能最大的痛点是@copiesofcopies在这里描述的场景。 是否有可能得到澄清?

感谢您跟进并听取我们的意见,@gaearon!

@gaearon无论结果如何或任何人的立场如何,都非常感谢接受任何形式的交流以表明此问题正在受到关注。

它对社区造成了很大的破坏,我担心将来社区会分裂。

这样的事情可能会发生,但没有人会喜欢它:

React = Oracle JDK
Preact = OpenJDK

但我们不能责怪facebook,因为它的合法权利是毋庸置疑的。

它对社区造成了很大的破坏,我担心将来社区会分裂。

我认为这不是真的......我们在 React 和那里有专利条款已经有几年了,但没有任何东西阻止了它的发展,许多大公司(有严肃的法律部门)正在使用它,很多人也在使用它。 . 我的观点是,所有这一切都只是对可能发生的事情的“恐惧”,或者只是人们认为 Facebook 有某种“阴谋计划”。

请不要误会我的意思..我相信 React 社区会在没有这种“恐惧”的情况下处于更好的位置,但是说社区会因此而分裂只是对这种“恐惧”的另一种探索最大的问题只是喜欢戏剧的人。

让我们希望facebook会改变React的License/Patent,所以我们终于可以说这里没有“阴谋论”或“世界统治计划”。

好吧,当然,但人们无法预见未来。 如果没有那个专利条款,每个人都会很高兴,将来不会发生“险恶”的事情。
有了该条款,人们真的无法确定。
但如果最坏的情况发生,你会怎么做?
我认为这种恐惧是一种健康的感觉。 如果没有,请以 Oracle 与 Google Java 传奇为例。

为了在火上提供更多信息,如果有人好奇,这是我的看法。 (tl;dr 有很多糟糕的法律建议和太多的偏执。我们谈论的是一个 JS 框架,它接受函数并返回(几乎)HTML。这不是 ARM 许可证)

https://medium.com/@dwalsh.sdlr/react -facebook-and-the-revokable-patent-license-why-its-a-paper-25c40c50b562

+1

@LawJolla不幸的现实是,这个世界上有很多律师,我很确定他们并不都同意。 :)

@CoreyDotCom那么在律师不同意的情况下,是否有可能采取最大风险的不利立场的解决方案? 或者是了解问题并采取最合理立场的解决方案?

也许它会效仿事实上的标准开源许可证并避免争用。

@CoreyDotCom Apple 使用类似的术语。 你的回复没有解决我的问题。

@LawJolla您的论点在某些情况下是很好的论点。 但是当主题是一个没有大量资金的小型创业公司时,这就很棘手了。 重写产品以去除 React 对于可能已经用它构建产品的小型初创公司来说并非易事。 我将使用 WordPress 作为示例。 如果 WordPress 采用 React,他们目前正在使用 React 来构建 Gutenberg 项目,这是 WordPress 中主编辑器的计划替代品,它可能会对商业 WordPress 产品的整个 WordPress 生态系统产生影响。 是的,其中许多是小型企业。 但是,其中许多也被更大的企业收购。 如果 WordPress 采用 React 并且该初创公司产品建立在 WordPress 之上……那些较大的企业可能会退出收购,因为他们的法律团队在对 React 条款的尽职调查期间提出了危险信号。 我们已经知道有些公司因为这个原因而回避 React。 如果他们不得不剥离我们的 React,这基本上意味着重写它,此时 Co Lang 可以决定建立自己,而不是收购另一家公司。 如果 WordPress 采用它,这些公司是否会因为使用 React 来实现主要功能而回避 WordPress? 当您肯定负担不起诉讼时,您会希望采取风险最大的不利途径。 有时,最合理的路径风险太大。 我希望 FB 只是更新许可证,所以没有人需要知道它是否是纸老虎。

@carlhandcock我的论点适用于所有公司。 初创公司没有可以起诉 Facebook 的专利组合。

人们似乎一直没有抓住重点……要发生任何事情,您都需要起诉 Facebook。 如果你对他们有很好的专利要求,并且有钱提起诉讼,你就有钱把 React 拿下。 (或者不。假设 Facebook 拥有任何保护 React 的专利——他们肯定没有——他们不能显示利润损失或合理的版税)

@LawJolla此外,作者以某种方式假设 React 没有专利,我怀疑这是真的。 此外,这个问题比 React 更大。 它适用于所有使用相同 Facebook BSD+专利的开源库。 而且,我很确定为这些库申请了许多专利。

你有钱把 React 拿走。

这是金钱、精力和时间的问题。 如果您看到 ASF 的评论,ASF 表示他们不想这样做。 如果有必要,我相信他们有钱。 但是,这并不意味着他们喜欢这样做或对他们或任何其他使用 ASF 产品的公司有任何好处。 如果这种非标准许可的趋势持续到其他大公司及其所有开源项目,那么开源项目将失去其真正意义。

@joonhocho我是作者。 我没有假设。 我看了。 在 10000 次阅读之后,没有一个人提出了合理的专利。

@LawJolla - 你写道这是一个“无牙”的主张,只适用于你_认为_没有相关专利的 React。 但是 PATENTS 文件可以在大多数 Facebook 存储库(Immutable、GraphQL、Jest、Flow、Hack、HipHop 等)中找到,并且它正在成为依赖项的依赖项的一部分。 如果它是一个危险文件,那么整个自由软件生态系统就会遭到破坏。

我认为您没有在帖子中解决所有情况。 此外,一些大大小小的科技公司似乎不同意,或者至少他们还没有准备好冒险。

@LawJolla即使你说的是真的,它已经并且正在生态系统中制造很多摩擦,无论它是否只是偏执狂。 一个明显的例子是过去几年 HN、Reddit、GitHub 上与 React 的 BSD+专利相关的这个帖子和许多其他帖子。
出于这个原因,包括大公司在内的许多公司都回避使用 React。 ASF 目前正在挑战它。 这里的人们正在努力改变它,我希望它会改变。

@joonhocho我不能不同意这一点。 争取更多的开放许可证,即使理由是毫无根据的偏执,也不是一件坏事。

@j127有大量糟糕的法律建议和无知的偏执狂,因此有些人不会冒险的事实并不令人惊讶。

@LawJolla - 您的论点并未涉及 Immutable、GraphQL、Jest、Flow、Hack、HipHop 以及文件出现的所有其他地方。

@LawJolla我没有错过你的观点。 我在回复中概述了一个示例,说明它如何从收购的角度影响企业。 小型企业不必拥有专利组合。 有兴趣收购小企业的大企业可以拥有专利组合并选择不收购小企业,因为他们不想处理令人头疼的问题,因为正如你所说......他们可以去掉 React 那么为什么不呢?只是自己编写而不是购买您必须重写并从中剥离 React 的产品? 仅供参考,来自 Automattic 的律师专门谈到 Calypso 和 Automattic 作为一项业务——并表示他们无论如何都没有任何专利。 但是 Automattic 不是 WordPress 开源项目,有多少拥有专利组合的企业使用 WordPress? 很多。 如果他们引入用 React 编写的关键功能,那么有多少人会使用开源项目重新考虑 WordPress,这看起来像是 Beta 版的 Gutenberg 项目的可能性? 我不知道答案。 但就像你说的,小企业不太可能拥有专利组合。 但大企业也使用 WordPress。

很明显,锡箔帽子、荒谬的假设统治了这个问题,进一步的常识尝试将被有偏见的确认性置若罔闻。 祝你在 React 许可证、UFO 和假登月方面好运。 🤗

丹尼斯,

那真的没有必要。 也没有帮助。

GitHub 问题是讨论法律理论的糟糕场所。 这也有损于最初的要求:Facebook 是否愿意将 React 重新授权给 FB/BSD+Patents 以外的其他东西?

在这种情况下,实际上没有什么可讨论的。 真正的讨论是 Facebook 内部的,我们可以/应该只是等待他们的决定和/或明确要求进一步的社区反馈。

昨天晚上熬夜看React教程,如果Facebook不改授权协议,我只想说一句话:“打死你个龟孙!”。

@kideny
这对脸书不公平。

我也不喜欢 React 的专利,以及所有带有它的 facebook Repos。

但对于开发和部署它的facebook来说,这是正确的。

GraphQL 怎么样? 反应原生? 和更多?

Weex包括Yoga ,但Yoga也包括专利。

或许在未来,大部分repos都会包含大企业的专利。

☹️

Vuejs是一个不错的选择,它是一个 MIT 许可的开源项目。 它免费且易于使用。

Preact怎么

但是没有Preact-Native ...

😂

来吧人们,让我们继续讨论这个话题……

FWIW,我公司的法律部门认为我们在当前的许可计划下推进反应没有问题。 我想这取决于你的产品是什么。

毫无疑问,这个线程有被关闭的危险。 我们能不能坚持手头的话题。 这对我们中的很多人来说都是一个非常重要的问题,React 团队正在为我们提供一项服务,让我们可以继续在这里进行交流。 让我们尽量不要添加无意义的输入,否则可能会阻碍任何进展或导致我们失去这个渠道。

FWIW,我公司的法律部门认为我们在当前的许可计划下推进反应没有问题。 我想这取决于你的产品是什么。

关于这个问题有很多混乱和误导性信息,而且随着它在 HN 和 Reddit 以及新闻网站上爆炸,情况只会变得更糟。

今天的 React 许可/专利情况与一个月前没有什么不同。 如果您已经在使用 React,则无需离开 React。 贵公司是否因其许可证/专利而允许使用 React 的问题是贵公司律师的问题。

唯一发生的事情是 Apache 软件基金会的律师说他们认为许可证不适合他们的项目。 因此,Apache 软件基金会已指示所有项目在 8 月 31 日之前放弃 Facebook BSD+专利代码。

这确实影响了几个 ASF 项目,包括 CouchDB、Cordova 和 Superset(孵化器)——这就是这个问题被打开的原因——但它与非 ASF 项目无关(即使它们是在 Apache 2.0 许可下获得许可的)。

我真的不认为这个问题应该变成关于许可情况的民意调查。 有些人已经无法使用 react 但想要使用,还有一些人由于 ASF 的变化而现在对此有问题。 这个问题已经被讨论到死。

我很确定我不是唯一一个订阅此问题以接收许可情况更新并且不会让我的收件箱充斥着有关它的更多意见的人。 也许关于有用与否的实际讨论可以在其他地方进行?

所以这个问题是请求重新许可,还是只是抱怨? 或者找到一个成功的理由?

我无法从中获得有价值的东西。

这个问题只是我们(CouchDB PMC)询问 Facebook 是否会考虑将许可证更改为 Apache 软件许可证 2.0。

如果没有发生这种情况,我们必须要么删除项目中使用 React 的部分,要么将它们移植到其他地方。 如果许可证更改为 ASF 接受的许可证,我们更愿意继续使用 React,如果是 ASL 2.0 许可证,则简单得多。 我们没有提出要求或威胁,我们甚至没有在这个论坛中评论更广泛的社会或法律方面,尽管它们很有趣。

我们真正等待的唯一回应是来自 Facebook(直接或通过 React 团队的适当授权成员)。

对该线程有许多出色的评论,这有助于看到其他人也感受到了这里的关注,但对于一个人来说,我希望线程更接近最初的目标。

我认为这被低估了,因为它只影响了“少数 ASF 项目”。 它会影响在后端或前端使用 React 的每个开源项目,包括 WordPress。 我们不能指望我们项目的用户尊重专利附加条款。 如果任何依赖项的许可证在 X 列表中,您就不能将您的项目发布为 BSD。 所以基本上你不能在 Facebook 的许可下许可你的项目。

@victoriafrench这不完全正确。 您可以根据您想要的任何许可证发布您的软件。 您的许可不会影响 React 获得许可的条款。 您的软件的许可适用于您的软件用户被允许使用它的方式。 React 的许可证会影响您使用 React 的方式,而不是您的用户使用您的软件的方式。

@JayAndCatchFire这不是真的。 如果您要在 BSD 下发布 Wordpress 并且它使用 GPL 组件,那么您将成为 GPL。 现在,任何为 Wordpress 创建任何形式的插件的开发人员现在也是 GPL。 这就是现实。 你不能在 X 下使用许可证而不在相同的许可证下分发你的产品,它从那里向下链接。 这是标准的版权许可法,每个律师都会告诉你同样的事情。

让我们把它移到电影上。 我使用的视频剪辑具有非影院许可,我在我的 After Effects CGI 模板中使用了该许可,并将其许可为 CC。 Marvel 来使用我的 CGI 模板。 漫威无法在影院上映这部电影,因为非影院许可会向上传播。

它被称为“标题链”,适用于所有文案。

@victoriafrench我完全同意 GPL 的情况。 GPL 是一种病毒式许可证。 此外,Wordpress 已经获得 GPL 许可。 但是本次讨论中涉及的软件(React、Apache 基金会的软件和各种公司的专有软件)都没有获得 GPL 许可。 我们谈论的是 APL 和 BSD,它们都不是病毒式许可证。 PATENTS 文件不会改变这一点。

Apache 的律师做出了决定——许可证不兼容。 根据 apache 邮件列表上的公开讨论,Facebook 的律师也说了同样多的话。 (上面链接在我之前的评论之一中)。

这是更改许可证的请求。

关于许可证的含义总是有很多猜测。 有很多不同的意见。 Facebook 有关于许可证澄清帖子

根据上述评论,此请求正在 Facebook 内部进行讨论。 他们很快就会决定做什么。

个人、项目和公司可以决定使用具有此许可证或任何其他许可证的软件是否是一个好的决定。 在比 github 问题更合适的论坛中,有许多关于此主题的

如果您由于与许可证相关的法律原因而同样难以利用 React,那么将这些信息添加到问题评论中将是一个很好的信息。

如果您想改变人们对如何解释许可证的看法,那么这里不适合。

我会警告任何人不要利用此问题讨论中的法律意见。 大多数参与者不是 Facebook 员工,也没有人在此线程中发表过官方声明澄清许可证的参数。

此外,拥有 github 帐户的律师并不多。

@nevetS澄清:基金会没有透露许可证是不兼容的。 ......基金会表示,其项目不能依赖于使用 FB/BSD+Patents 许可证的组件,因为它会引入高于/高于 ALv2 的要求。

在本次讨论(此处/其他地方)的过程中,几位律师表示许可证并非不兼容。 这仅仅是双方合并成一个更大的工作意味着你有两套要求(ALv2和FB / BSD +专利)。 一些开发人员及其发布的软件完全可以接受更大的需求集。

根据政策,基金会不接受这种组合。 就那么简单。

开源不应该依赖赞助人的同情,这种同情可以在任何冲突迹象时撤销。 要么开源项目并公开协作,要么保持闭源。 用 Frankenstein 许可证软化这一点会适得其反,而且极其危险——如果这是一个先例,并且你必须为你使用的每个开源项目接受额外的条款,我们都会遭受巨大的痛苦。 该建议对每个人来说都是一个更清洁的解决方案。 如果这个条款只是像一些声明那样的纸老虎,它就不应该存在,如果不是,那么这个项目是不开放的,在大多数情况下必须非常谨慎地对待。 简而言之:虽然我很抱歉添加另一个意见,但重新许可的建议似乎很有根据。 由于这个原因,我们最近不得不决定反对 React,这很遗憾。

Apache Superset 上的活跃提交者(正在孵化) https://github.com/apache/incubator-superset和前 Facebooker。 像 CouchDB 一样,我们陷入了 Facebook/ASF 的交火中,并且只想使用 React 来构建和共享 [真正无限制、无意外的] 开源软件。

无论专利条款的合法性、真实含义和适用性如何,我们都希望 Facebook 与开源领域的其他人一样,按照相同的规则行事,为 React 制作标准的、无条件的 BSD 许可证。

当团队为 Superset 选择 React 时,我基本上没有意识到这个问题,如果我们在 ASF 或 React 方面回溯将极其适得其反。 或者更糟糕的是,另一种选择可能是谨慎行事,不在我们的版本中分发 React,让用户自己构建软件以推迟责任 [不是一个选项]。

就我个人而言(基于我对法律含义的有限理解),我认为 Facebook 通过其流行的开源软件为自己购买某种专利诉讼豁免权是不道德的。

[也相关] 如果 Facebook 坚持当前的专利条款,我希望看到npm许可证元数据更改以反映Conditional BSD或明确表明它不是很好的东西BSD ,所以当我们使用包管理器导入库,并通过依赖项递归以了解许可含义树时,不知何故这会冒泡为重要的东西,需要我们的律师和软件来理解、研究和验证基础。

@gstein不确定你的意思,Facebook 被告知基金会成员不兼容

@johnament我认为 Greg 指的是定义兼容性,即如果没有合乎逻辑的方法将两个许可证下的软件组件组合在一起,则两个许可证不兼容。 例如,CDDL 和 GPL 在这种情况下是经典的,因为它们都限制了衍生作品必须如何获得许可,并且这些限制没有交集。

兼容性还有另一个定义,即上游策略兼容性。 这就是 Apache 的问题。 我们不允许(正如您比我更了解的那样)允许抑制使用领域或其他使用方面的依赖项。 因此,BSD+Patents 上的专利附加条款与 Apache 的政策不兼容。

但是,没有什么说我不能将 Apache 许可的组件与 react 一起使用,如果我对此感到高兴的话。 我只会得到一个衍生作品,它对我的​​用户强加了相同的专利行为。 我不能把这个组合带回 Apache 并建议它是一个项目。 但我可以在 Apache 的政策范围之外使用它。

总而言之,我同意你们两个。 :-)

@tdunning可能是。 我会让 Greg 评论他的意图,但我对 Roy 评论的阅读是,许可证本身彼此不兼容(例如,您不能在两者下使用双重许可证代码)。 推测,这是因为 ALv2 包括不可撤销的声明,而 FBPL 包括明确的撤销条款。 这也可能是我们不能在其根源处包含它的原因,因为存在可能可撤销的部分代码。

很简单, @johnament ...我说@nevetS断言“Apache 的律师已经做出决定——许可证不兼容”是不正确的。 ......我们的律师没有做出这样的声明。 被提及的 ASF 成员不是律师,更不用说代表基金会的人了。

基金会已经表示,出于政策原因,它不会允许 FB/BSD+Patents(我必须看看,但我什至认为我们的律师根本没有权衡)。 它与兼容性无关,基金会没有对兼容性做出任何断言或声明。

为在那个@gstein上搅动锅而

如果像 ASF 这样拥有法律团队资源的人能够以某种方式公开讨论这个话题,那就太好了。

不用担心, @nevetS ......很容易澄清。

不幸的是,ASF 无法提供法律建议。 法律职业的疯狂之处在于,任何律师也不会提供此类建议,除非并且直到您成为他们的委托人协议所涵盖的客户。 这就是为什么你会看到评论 [来自律师] 被标记为意见,并在他们的第二次呼吸中告诉你聘请自己的律师寻求建议:-)

+cc 顶级贡献者@zpao@spicyj@sebmarkbage@gaearon

ASF 的多个项目(CouchDB、Cordova 和 Superset)都处于不确定状态,我们中的许多人都希望 Facebook 进行沟通并澄清是否:

  • 在专利条款上的立场是坚定的,不会改变
  • 人们在 FB 内部进行辩论,并将提出澄清(ETA 会很棒!)
  • 事情正在朝着标准的方向发展,ASF 批准的许可证 (?!)

我个人 ❤️ React、❤️ ASF 和 ❤️ 开源软件。 请允许我们分享建立在 React 之上的东西!

我已经等了两个多星期了,现在感到非常失望。 我们什么也改变不了,只能走开。 再见反应&&你好角度。

我很确定由于公司-企业礼仪,直到 8 月 31 日才会有公开决定

冷静。 至少 Facebook 法律团队 (!!!) 正在调查此事。 这本身应该被认为几乎是神的干预。 在那之后,这将是一场等待的游戏,任何与法律工作相关的事情都应该如此。 我们中的任何人现在在这里都做不了多少,只能坐等。 如果你不能坐等,去学习 Vue,或者在此期间学习一些东西。 它不会杀了你。

在这一点上,你的抱怨只会让事情变得更糟。 他们已经知道我们不喜欢现在的情况。 他们明白了。 我相信他们厌倦了听这个话题。 如果这个帖子里还有更多无意义的评论,你打赌这个帖子会被锁起来,塞进阁楼里收集灰尘。

我也分享@mistercrunch@OlegLustenko的想法/担忧。 我们可能需要等到 8 月 31 日才能从 Facebook 听到有关此事的消息。

任何进展?

大家好 - 感谢您耐心等待。 我们现在还没有什么要宣布的,但我们会在此更新。

来 Facebook,做正确的事!

来 Facebook,做正确的事!

请停下。

如果你不能坐等,去学习 Vue,或者在此期间学习一些东西。 它不会杀了你。

当然有些人可以坐等,但是当您拥有生产代码时,时间就是金钱。 对于一家公司来说,仅仅因为你必须改变你的框架而重写代码可能会变得非常昂贵。 想象一下,您聘请了 React JS 开发人员,您是保留他们并希望他们学习另一个框架,还是寻找其他员工。

@ coding102您可以根据preact ,与preact-compat的应该是完全兼容的反应。

我同意spicyj:请停止。 这些讨论当然有其一席之地(例如论坛),但被错误地放在 Github 问题中,该问题仅处理非常具体的请求。 此外,我们已经到了等待特定响应的地步。 你的评论是善意的(我自己也在不耐烦地等待结果),但这应该在其他地方讨论,例如这里这里这里。 我们之前也提到过两次 preact - 重复没有任何贡献。

正如亚当今天提到的,我们希望能够开源技术,这是我们最成功的产品的一部分。 这就是为什么我们必须重新考虑如何在不进一步让自己面临琐碎的诉讼的情况下处理我们的许可实践,以及为什么它会继续存在。 很抱歉,这在社区中引起了如此多的骚动。 有些人甚至觉得他们必须因此停止使用 UI 框架。

我了解一些组织原则上可能会选择针对此类许可制定政策。 我喜欢我们清楚地在我们的回购中包含专利许可。 IMO 如果更多公司也选择这条路线就好了。 我对 ASF 的决定感到惊讶,因为我们的许可证多年来一直没有改变。 我认为这很不幸,因为它不利于公司在保护其业务的同时进行开放。 它还为人们构建和结合伟大的技术创造了大量的流失。 我希望这是正常化的。

我想继续努力为具有许多不同实现的想法提供更多保护。 让我们为此创造一个环境。 我会暂时结束这个,但让我们继续进行更广泛的讨论。

我们正在 MIT 许可下重新授权 React、Jest、Flow 和 Immutable.js。
我希望这能解决您的疑虑。

https://code.facebook.com/posts/300798627056246/relicensing-react-jest-flow-and-immutable-js/

React Native(包括 Metro、Fresco 和 Yoga)也被重新授权为 MIT。

https://github.com/facebook/react-native/commit/26684cf3adf4094eb6c405d345a75bf8c7c0bf88

此页面是否有帮助?
0 / 5 - 0 等级