你所说的Qwen 改变协议的问题，我刚才看了一下，我认为像《Qwen Research License》恰恰是因为“不遵守协议精神与恶意钻空子”的行为已经非常猖獗了。才逼得 Qwen 这样的大厂和独立开发者不得不放弃 MIT 协议，改用严格的自定义协议。如果拿这一点来为发帖者辩解，是本末倒置。
开源的本质是建立在社区成员“我给予你极致的自由，你回报我底线的尊重”的默契之上，MIT的内核也理应如此。
1 个赞
哥们你如果是为了抬杠我后面就不回了。
发帖子附带代码需要贴出MIT协议这个超出了一般常识，
按照你的这个标准，论坛的绝大部分分享都是违规
1 个赞
实话说就是打官司原作者确实不一定能赢，但是这里是TRAE社区啊，按你意思就是MIT有漏洞，作者自己活该倒霉。按你意思，以后TRAE社区的活动，直接就去找别人开源的不知道用什么IDE和模型的，然后过个水改一改，一个用gpt astra模型复刻的项目只字不提，硬是包装成很简单用TRAE CODE三两下加上几个提示词就搞定，惊呼一声TRAE 牛逼，想学的人能从头到尾做出来么。
别人发现不了功劳就是自己的就赚到了，别人发现了也没事，道个歉就完事了，那还苦憨憨折腾什么东西，都等着抄就行了，这是你希望看到的TRAE社区么。
除了MIT你有想过著作权么，你有考虑过社区其他回帖称赞这个项目的，到底是因为作者二创改的好，还是本身原项目好么，到底是谁在扣字眼。
绝大部分享是否违规那是你的观点，并且这是社区运营要考虑的问题。如果单纯是分享一个项目，谁愿意还要改成自己的，直接贴出来原作者的仓库就完事了。而且我也不认为绝大多数、特别是TRAE Build爱干这种事情。
像这种包装完了以后拿去投稿的，试试水碰碰运气的，从常情也不是不能理解。但凡原作者不找到社区来，但凡你不给原作者泼一盆冷水，但凡他是在评选前已经知晓此事还能获头奖的，谁爱管这摊子事情，睁一只眼闭一只眼算了。
法律条款和法理那是法庭要解决的问题，你有你的观点无可厚非。但是道德和社会群体标准这些才是社区需要讨论的问题。认为MIT就是可以随便抄随便用，那是你个人的理解。
我不认同你所谓的“改变 MIT 含义”对于论坛及分享不利的说辞，真正改变 MIT 含义、对开源社区造成巨大伤害的，恰恰正是现在这种“强盗逻辑”，逼得原作者不得不放弃开源和分享。
2 个赞
我赞同你的观点，但是做两点补充：
-
用了开源项目二创最好要注明出处，这个算尊重原作者。
-
对开源项目进行二创参与Trae的作品赛项目，应该在1的基础上（确保开源协议合规），体现自己用TraeCode进行有效增量迭代的部分。
1 个赞
感谢字节跳动，感谢版主，感谢TRAE.
1 个赞
关于 RhineLabUI 相关参赛及获奖争议的正式声明
最近，关于某参赛作品基于我的开源项目 RhineLabUI 进行修改并参加有奖征集、最终获奖一事，评论区出现了不少讨论。
其中也有人将这件事理解为：
“既然 RhineLabUI 使用 MIT License，那么作者现在提出异议，就是开源之后反悔了。”
我认为这已经偏离了事情本身，所以有必要完整说明一次我的立场。
一、我从未反悔 MIT，也从未反对任何人使用 RhineLabUI
首先，这一点我希望说得非常明确：
RhineLabUI 采用 MIT License 是我自己的选择，我从来没有反悔。
任何人基于许可证允许的范围学习、使用、修改、二次开发 RhineLabUI，我都没有意见。
我把项目开源，本身就是希望它能够被社区看到、研究和继续创作。
所以这次争议从来不是：
“为什么有人用了我的代码？”
更不是：
“开源以后我又不让别人用了。”
如果只是有人下载 RhineLabUI，自己修改、学习、做个人项目，甚至用于其他符合许可证要求的用途，我根本不会因此发帖。
二、真正的问题，是它被作为参赛作品参加了有奖征集，并最终获奖
这件事真正让我无法接受的地方在于：
这不是普通的开源项目二次开发，而是一个有奖作品征集。
根据我看到并保存的最初版本，该参赛帖最开始并没有明确说明：
该项目是在 RhineLabUI 基础上进行修改和二次开发的。
不仅如此，原帖最初的表述还会让普通读者产生一种非常自然的理解：
这是参赛者本人完成、本人编写和复刻出来的项目。
而 RhineLabUI 本身并不是一个只有几段代码、几个组件或者一个基础模板的项目。
它是一个已经公开发布、具有完整视觉效果、交互和实现基础的项目。
因此，在一个有奖征集活动中，是否基于这样一个现成项目进行开发，是会直接影响评委对：
- 技术实现难度；
- 设计能力；
- 工作量；
- 完成度；
- 原创贡献；
这些内容的判断的。
这已经与“MIT 允不允许使用代码”完全是两个问题。
三、参赛者后来已经承认项目来源，参赛帖也已经修改
目前，相关参赛者已经在评论区明确表示，他确实是在 GitHub 下载了 RhineLabUI 后进行修改。
同时，他也承认最初的帖子中没有标注原项目来源。
之后，参赛帖已经进行了修改，现在能够看到对 RhineLabUI 的来源说明。
对于后续补充来源这件事，我当然认可。
愿意纠正原来的信息，总比一直不修改要好。
但我认为这里有一个非常基本的时间顺序不能被混淆：
现在已经修改，不代表最开始就是这样。
更不能因为帖子后来补充了来源，就反过来说：
“既然现在已经标注了，那之前就没有问题。”
甚至有人认为，对方后来愿意修改，是因为“对原作者有歉意”或者某种额外照顾，所以原作者不应该再追究。
我无法认同这种逻辑。
补充原本缺失的作品来源，是对信息的纠正，而不是对原作者额外施加的恩惠。
我也不认为，一个开源作者在发现自己的完整项目被用于有奖参赛、且最初没有注明来源时，应该因为对方事后进行了修改，就反过来认为自己“欠对方一个人情”。
这件事真正需要讨论的，是作品参加评审和获得奖项时到底处于什么状态。
四、MIT License 与“参赛作品如何展示”是两个问题
我觉得这也是整个讨论里最容易被混淆的一点。
MIT License 解决的是：
别人是否有权使用、修改和分发代码。
而有奖比赛需要解决的是：
参赛者向评委展示的作品到底有多少是自己的工作。
这是完全不同的两个问题。
举一个非常简单的例子。
如果有人找到一个已经完成度很高的 MIT 开源项目：
下载下来以后：
- 修改一些内容；
- 换一些资源；
- 增加一些功能；
- 然后以自己的作品参加比赛。
从许可证角度看，他可能确实有权修改这个项目。
但在比赛中，评委显然还需要知道：
原项目是什么？
原项目已经完成到了什么程度？
参赛者到底增加了什么？
否则评委根本无法正确判断这个参赛作品真正属于参赛者的贡献。
所以：
“有权使用”绝不等于“无需披露来源和贡献边界”。
五、如果这种情况没有问题，那以后是不是只需要找一个没人发现的优秀开源项目？
这也是我认为这件事真正值得主办方认真回应的地方。
假设一个有奖作品征集允许这种情况存在：
一个参赛者找到一个非常优秀、已经相当成熟的开源项目。
在它的基础上修改。
参赛时不主动说明原项目来源。
如果原作者没有看到这个活动，也没有人指出来源，那么作品就继续进入评审，甚至正常获奖。
等到原作者偶然发现以后，再把帖子修改一下，加上项目来源。
那么我想问：
是不是意味着以后参加类似活动，只需要找到一个足够优秀、但原作者恰好没有关注这个活动的开源项目，就可以这样参赛？
如果始终没有人发现，就可以正常获奖？
如果被发现了，再补充来源？
我认为这显然不是一个健康的评审机制。
一个参赛作品是否符合规则，不应该取决于原项目作者有没有恰好发现它。
否则整个规则实际上是在奖励：
“是否能够在没有被发现的情况下使用现成项目参加评审。”
这对真正从头完成作品的其他参赛者同样是不公平的。
六、我现在真正想知道的是：评委在评奖时是否知情
现在这件事已经不仅仅是我和参赛者个人之间的问题。
因为该作品最终已经获奖。
所以我认为真正应该回答的是：
在评委进行评审并确定获奖结果时，是否已经明确知道该项目基于 RhineLabUI 二次开发？
这是最核心的问题。
如果评委当时不知道，那么意味着：
评审是在作品来源信息并不完整的情况下完成的。
如果评委当时知道，那么我希望主办方进一步说明：
对于这类基于第三方成熟开源项目二次开发的作品，评委是如何区分：
原项目已有成果
与
参赛者本人新增成果
并最终作出奖项判断的。
我认为这是一个有奖征集活动应该有能力回答的问题。
七、我的诉求从来不是禁止二次开发
所以最后再总结一次我的立场。
我没有要求别人不能使用 RhineLabUI。
我没有要求别人必须事先征得我的许可才能修改。
我也不会因为这件事把 RhineLabUI 关闭开源。
我真正认为需要讨论的是：
当一个基于他人已有成熟开源项目进行二次开发的作品，被提交到一个有奖征集活动时，参赛者是否有义务明确披露原项目来源和自己的实际贡献范围。
以及：
如果参赛时没有披露，而是在产生争议甚至获奖以后才补充来源，这是否会影响原有的评审结果。
我认为这是一个非常基本的公平问题。
八、希望主办方正式回应
因此，我希望活动主办方能够明确说明：
- 本次活动是否允许基于第三方已有开源项目进行二次开发后参赛；
- 如果允许，参赛时是否需要主动披露原项目名称、原作者及项目来源；
- 是否需要说明参赛者本人实际完成的修改和新增部分；
- 本次作品在进入评审及获奖时，评委是否已经知晓其基于 RhineLabUI；
- 如果评审时并不知道这一事实，在目前相关情况已经得到确认后，是否会重新核查其参赛资格以及获奖结果。
我认为，对这些问题给出明确答案，不只是为了我个人。
也是为了今后所有参加活动的人。
因为真正投入大量时间独立完成作品的参赛者，应该知道自己是在什么规则下与其他作品竞争。
开源作者也应该知道：
自己的作品被用于有奖比赛时，活动如何界定“开源使用”和“参赛者本人的创作贡献”。
最后，我也希望这件事不要演变成人身攻击。
我不希望任何人因为这件事去骚扰相关参赛者。
我只希望大家讨论作品本身、时间线、参赛规则和评审标准。
RhineLabUI 会继续开源。
我依然支持开源，也依然欢迎二次开发。
但我同样认为：
尊重开源，并不仅仅是“许可证允许我使用”。
在涉及署名、作品展示以及有奖评审的时候，对作品真实来源和自身实际贡献进行诚实、清晰的说明，同样重要
1 个赞
感谢你愿意承认问题，也感谢你说明官方在评奖时并不知道这个作品是基于其他项目修改的。
但看完你的回复之后，我还是有几个问题必须说清楚。
首先，你提到“官方也是两难的”，这一点我并不认同。
按照你自己的说法，官方之所以给你 Build 之星，是因为当时并不知道这个作品是建立在 RhineLabUI 基础上修改而来的。
也就是说，评委是在缺少一个非常关键的作品来源信息的情况下完成评审的。
既然现在这个事实已经明确了，我认为正常的处理方式并不是说“奖已经给了，所以官方也很为难”，而应该是把完整事实提交给官方，由官方重新判断：
如果评委从一开始就知道这个作品是基于 RhineLabUI 修改的，它是否仍然会得到同样的评价和奖项？
这才是问题的核心。
而且你自己也说得很清楚，这个作品之所以看起来不错，是“因为原作品很好”。
这其实恰恰说明了为什么这个来源信息对评审如此重要。
RhineLabUI 本身已经是一个完成度很高的项目，视觉、交互、整体结构和大量实现都已经存在。
如果评委不知道这些内容原本就来自一个成熟的开源项目，那么他们很容易把原项目已有的完成度，当成参赛者本人的创作成果。
所以这件事从来不只是“有没有标注一个 GitHub 链接”这么简单。
真正的问题是：
这个奖项到底是在奖励你这次新增的工作，还是实际上把 RhineLabUI 本身已有的完成度也一起算进了你的参赛成果？
我认为一个有奖活动至少应该能够区分这两件事。
开源项目当然可以被二次开发，但奖项应该奖励参赛者自己的实际贡献，而不是把上游项目已经完成的成果一并视为参赛者自己的创作量。
其次，关于奖品，我也想明确说明：
我本人对这个奖品没有任何诉求，也不会接受这个奖品。
我并不在意一个键盘，我在意的是这次评审到底是不是建立在完整、真实的信息基础上。
如果官方在完整了解作品来源和你实际修改内容之后，仍然认为这个作品符合获奖标准，那是官方基于完整事实作出的决定。
如果不符合，就按照活动规则重新处理即可。
我不认为这是什么“给也不是、不给也不是”的两难。
还有一点，也是我目前比较难理解的地方。
你现在多次表示歉意，也说这是你自己的责任。
但如果真的希望解决这个问题，其实你一直都有很多直接联系我的方式。
RhineLabUI 的 GitHub 仓库是公开的，你可以直接发 Issue。
我的 B 站账号和原项目视频也是公开的，你可以私信我。
GitHub 上同样存在可以找到我的公开联系方式。
这些方式都不需要等我在活动帖子里发现这件事以后才开始沟通。
但截至目前，我没有看到你通过这些渠道主动联系我、说明情况或者讨论如何处理这件事的行动。
所以在这种情况下，仅仅在公开评论区说“我很抱歉”“这是我的责任”，坦白说，让我很难感受到你在主动解决问题上的诚意。
我并不是要求你向我支付什么，也不是要求你把奖品给我。
如果你确实认为这件事是自己的责任，那么我认为最直接的做法应该是：
主动把完整情况向官方说明，请官方按照完整事实重新判断这个奖项是否应该保留。
而不是把问题描述成“官方也很两难”。
最后我还是想再强调一次：
我从来没有因为 RhineLabUI 使用 MIT License 而反悔，也不反对任何人使用、学习和二次开发这个项目。
我在意的是一个非常简单的问题：
一个已经高度完成的开源项目，在没有向评委充分披露来源和实际修改范围的情况下，被用于有奖参赛并获奖，这是否公平。
我认为这件事应该由主办方在掌握完整事实之后重新判断。
也希望后续我们讨论的重点能够回到作品来源、实际贡献和评审公平本身，而不是继续把问题简化成“MIT 项目能不能用”。
1 个赞
感谢你愿意把这些话说出来，我基本赞同你的观点。
我其实一直想表达的也不是“MIT 项目别人不能用”，更不是因为别人用了我的开源项目就反悔。
我真正介意的是：
一个本身已经完成度很高的开源项目，被别人拿去包装、修改后参加有奖活动，而且最开始并没有明确说明原项目来源和实际改动范围，最后还获得了奖项。
这和正常的开源使用、学习、二次开发，本质上不是一回事。
你提到“到底是二创改得好，还是本身原项目就好”，我觉得这个问题非常关键。
因为当评委不知道 RhineLabUI 原项目存在时，他们看到的很多视觉、交互、结构和整体完成度，很可能会自然地理解成是参赛者本人完成的。
但实际上，这里面相当一部分本来就是原项目已经具备的。
所以我一直认为，开源项目当然可以用，但只要涉及有奖评选，至少应该清楚说明：
- 原项目是什么；
- 原项目本身已经完成到什么程度；
- 自己到底新增和修改了什么。
否则评委很难真正判断参赛者本人的实际贡献。
我也很赞同你说的另一点：
一个开源作者是否能得到应有的尊重，不应该取决于他有没有恰好发现自己的项目被拿去参赛。
如果原作者没看到，就一路正常评奖；
如果看到了，再补来源、再道歉。
那这样的机制本身就会有问题。
另外，我也不希望这件事最后被简化成“MIT 到底允不允许这样用”。
法律许可是一回事，社区里的基本署名、创作边界和有奖评选的公平性又是另一回事。
如果所有讨论最后都变成一句“MIT 允许”，那反而会让真正愿意开源的人越来越顾虑。
所以也谢谢你愿意从这个角度替开源作者说话。
我不会因为这件事停止开源，但我确实希望这件事最后能让活动方把规则说得更清楚一点：
开源可以被使用，但参赛时应该诚实披露来源；奖项也应该评价参赛者自己的新增贡献，而不是把上游项目原本的完成度一起算进去。
1 个赞
有两个悖论，请带着客观态度阅读
第一个是
楼上提出了“参赛者向评委展示的作品到底有多少是自己的工作”
在现在浮躁的社会，点开划一下特效就关闭网页的人占了多数，
【但是我遍历了其中实际内容】，并且相当认可作者在学生阶段就能做出这个程度的东西
请注意他的网站实际是一个【个人作品展】
而非仅复刻上述特效，其作品包含了编辑器、3D建模等诸多杂项，
并且其中的诸多作品技术【相当扎实】，
其中编辑器、视频工具等的开发时间应不亚于封面特效本身。
我是程序员眼光，认可内容并不包含主页特效，
这是因为打开主页就明显认为这是一个开源或者AI自行发挥效果（尤其是查看时 Opus5.5 发布并在网上充斥近似等级的优质效果）
此3D特效能作为并列的作品之一，而非将其作为主打内容
仅在观众“不看实际内容只看封面”情况下才会成为重头。
对于“有多少是自己工作”，我不做定论，它占用的比例可能要降低。
第二个是关于协议
我把这个例子再具象化一点：
请回答，原作者感谢楼上的同时，是否要感谢 React 和 Node.js？
React 和 Node.js（的核心部分）是和楼上的特效相同的未修改的 MIT
并且明显更难、对这个网站的贡献比特效更大。
如果不需要，那么请重新定义何为“应该感谢的贡献”
我没有什么理由搞事情，
我的论点其实是楼主你把协议改几个字，引用此特效需要署名作者，
这个比发长文更容易维护署名
1 个赞
上文不含贬损此特效的意图
这个特效很厉害。
悖论确实存在，有见解不同欢迎探讨
1 个赞
我现在大概看懂你这段话想表达什么了。
你的意思应该是：
虽然首页这个效果和我的项目高度相关，但你实际看了里面的内容，觉得还有编辑器、3D 建模、视频工具等很多东西，所以综合来看，作者作为一个学生能做到这个程度，已经算很厉害了。
但问题恰恰就在这里：
你似乎默认了你看到的这些“完整度”和“复杂度”，都是他自己做出来的。
实际上并不是。
你提到的很多视觉结构、3D 内容、交互方式以及整体呈现，本来就是我原项目中已经完成的内容。
他并不是从零做了一个完整的“个人作品展”，然后恰好借用了我一个首页特效。
更接近实际情况的是：
他直接建立在我已经完成的作品结构、视觉体系、交互逻辑和现成功能上，替换、填充了自己的内容，再增加了一部分自己的交互，例如视频播放等。
所以你这段论证最有意思的地方就是：
先把我原本已经完成的工作量，一起算进他的“作品完成度”里，
然后再得出：
一个学生能做到这个程度已经很厉害。
那当然显得厉害。
先把原作者的工作量算到他头上，再夸他工作量大，确实很容易得出“很厉害”这个结论。
真正应该问的从来不是：
这个最终页面看起来厉不厉害？
而是：
这个最终页面里，到底有多少是他自己做的？
这也是我从一开始质疑这件事的核心。
你自己后面其实也说了：
对于“有多少是自己工作”，它占用的比例可能要降低。
那这句话本身就已经说明问题了。
既然你连哪些是他的、哪些本来就在原项目里，都还没有完全区分清楚，
那前面直接拿整个最终成品去评价：
“一个学生能做到这个程度已经很厉害”
这个评价本身就已经缺少前提。
然后再说你后面关于 React 和 Node.js 的类比。
这个类比我确实看了好几遍。
你的意思大概是：
既然我的项目也用了 React、Node.js，那么如果要求参赛者说明使用了我的项目，是不是我也应该感谢 React 和 Node.js？
这个类比非常精彩。
因为按照这个逻辑：
使用一个通用框架、运行时、基础设施依赖
和
直接建立在另一个作者已经完成的、具有明确视觉设计、交互逻辑、3D 内容和成品形态的具体作品上进行修改
原来是同一回事。
那以后确实也不用区分什么框架、库、素材、模板、完整项目和二创作品了。
反正只要都属于“用了别人的东西”，就可以全部混为一谈。
但正常人应该都能理解：
React 和 Node.js 提供的是通用技术能力，
而我这里讨论的是一个具体、完整、已经公开发布的作品。
这里讨论的也从来不是：
谁对整个软件生态贡献更大？
而是：
你拿来作为自己参赛作品基础的那份具体作品，到底是谁做的？
举个非常简单的例子：
一个人用 Blender 做了一个完整的 3D 模型。
另一个人拿这个模型改了材质、换了一些内容、补了一些功能，再拿去参加作品比赛。
难道因为 Blender 对这个作品的技术贡献比原模型作者更底层、更基础，
所以第二个人就不需要说明这个模型原本是谁做的吗？
显然不是。
所以把 React、Node.js 搬出来，并不能回答现在的问题。
它只能把一个非常具体的问题，重新抽象成：
“大家不都是用了别人的技术吗？”
然后原本真正需要回答的事情就刚好消失了。
所以我觉得现在真的没必要继续扩展到 React、Node.js、MIT 历史，下一轮再顺便把 Linux 内核、TCP/IP 和冯·诺依曼也请出来。
问题可以非常简单。
先把下面几件事说清楚就够了：
- 这个参赛作品里，哪些视觉、交互、3D 内容和功能本来就在 RhineLabUI 中；
- 哪些内容是参赛者自己新增的；
- 他实际新增部分在整个参赛展示中占多大比例；
- 在参赛帖中，他有没有让普通读者清楚知道这个作品是建立在一个现成开源作品基础上的。
把这些分清楚以后，
再来讨论：
“一个学生能做到这个程度是不是很厉害。”
否则现在这种讨论方式，本质上就是：
先把别人已经做好的部分一起算进他的成绩，再拿这个总成绩证明他很有能力。
这个逻辑，我确实很难认同。
1 个赞
我看了一下，哥们你也是trae社区build，能说出这种谬论挺招笑的。
你是‘程序员眼光，认可内容并不包含主页特效’？你自己说话不滑稽么，还能为了否定而否定。 你自己也说了，浮躁社会大多数人就是看看特效。如果没有原作者的贡献、谁有闲心点进来看这个作品？有多少人能看到你所谓的从技术视角给出来的扎实？
你这段观点表达的逻辑就是抛开A谈B。你自带上帝视角，预设了‘抛开 A’、预设了‘主页不重要’、预设了‘大学生技术标准’，预设了‘专业技术视角’，叠得buff太多了。现实是，这就是一个整体作品。
你还在贬低原作者的劳动成果，说‘这不重要’
其次，别在这用 React 和 Node.js 偷换概念
你拿 React 和 Node.js 写网站的说法也是搞笑，没有任何一个评委或观众会误以为 React 是这个参赛者自己发明的。
但别人点开他这个‘个人作品展’，看到那个 3D 特效，如果什么都不说所有人都会理所当然地认为这是他自己手敲出来的原创核心成果。
最后，你那句‘你把协议改几个字更容易维护署名’绝了，简直是受害者有罪论的典范。
法律规定门锁不防君子也防小人，结果小人把没锁死的门推开了，你反过来怪主人‘你当初怎么不换一把钛合金锁？换锁比你现在出来抓贼容易多了’。
2 个赞
他这回复真给我看笑了，只能说结论四处漏风，最后还说个“我不是来搞事”，纯纯的此地无银三百两，属于是结论太离谱，我都不知道从哪边开始反驳 
1 个赞
我后来专门把两个项目做了一次完整技术审计。
所以现在其实不用继续凭感觉讨论“像不像”，也不用再靠“一个学生做到这样已经很厉害”这种印象判断了。
结果非常明确：
- 视觉设计复用：约 85–95%
- 页面结构复用：约 85–95%
- 交互逻辑复用：约 80–90%
- 3D / 动效复用：约 95–100%
- 代码结构复用：约 80–90%
- 真正属于这个站点的“系统实现原创增量”：约 5–15%
- 就算把作品资料整理、图片视频素材接入、品牌替换这些也全部算进去，整个站点的改造份额大约也只有 15–25%
而且这不是“看截图觉得很像”得出来的数字。
具体技术证据包括：
-
选取的 86 个业务函数 / 方法里，有 58 个与我 9 月 8 日旧版本归一化后完全匹配。
-
核心 38 个可对应方法，按结构比较，相似度约 97.7%。
-
对方站点 390 条 CSS 规则中，有 336 条可以对应我旧版选择器，其中 297 条声明序列完全一致。
-
两套核心 3D 模型虽然文件 hash 不同，但解码压缩后进行几何比较，单体模型 11/11 个材质组的唯一顶点坐标集合一致，拆解模型 10/10 个材质组一致。
也就是说，那些模型并不是“他重新建模做出来的”，而是我原有模型经过压缩、合并等处理后的版本。
- 更关键的是，他站点里还保留了我旧版本才有、后来已经被我改掉的实现特征：
- 旧版 360° 查看器复位逻辑；
- 旧版键盘移动逻辑；
- 旧版品牌排版；
- 旧版黑条标题动画；
- 旧版三开关设置窗口；
- 旧版固定 16:9 舞台方案；
- 旧版固定 9×32 的交互对象池；
- 甚至还有
rhine-saved、window.rhine...这类 RhineLabUI 自己的命名残留。
这些东西组合在一起，已经不是“风格相似”或者“独立复刻得比较像”能解释的了。
审计结论也很明确：
它最接近的不是“独立复刻”，也不是“大量新增后的深度二创”，而是“基于 RhineLabUI 历史版本的轻度改造”。
而且从版本特征看，很可能基于我 9 月 8 日上午那一版附近的实现继续修改。
所以现在回头再看你之前那句：
一个学生能做到这种程度已经很厉害
问题就非常明显了。
你口中的这个“程度”，绝大多数本来就是我已经做到的。
你之前看到：
- 档案阵列；
- 3D 模型；
- 玻璃材质；
- 卡片内构；
- 背景实例化；
- 长焦构图；
- 摄像机运动；
- 选档动画；
- 抽取 / 归位；
- Hover 反馈；
- 数字滚动；
- 详情页左右结构；
- 设置窗口；
- 360° 查看器；
- 拆解 / 重组；
- 查看器进入退出动画；
然后把这些东西一起看成“这个学生做出来的完成度”。
但技术审计之后发现，上面这一整串基本都是 RhineLabUI 原本就已经存在的东西。
所以我之前说你把原作者的工作量算到他头上，并不是一句情绪化评价。
现在已经可以非常具体地说：
你用来证明“他工作量很大、一个学生做到这样很厉害”的绝大多数视觉和技术成果，本来就不是他的新增。
这才是问题。
当然，我也不会说他“一点东西都没做”。
报告也明确识别出了他的真实新增部分：
- 把原来的档案数据替换成自己的 8 个作品；
- 新增图片 / 视频媒体数据；
- 做了媒体画廊；
- 做了图片灯箱；
- 接入了 HTML video 视频播放；
- 加了一些外链；
- 改了品牌文字；
- 对原 GLB 做了压缩；
- 对字体做了子集处理；
- 加了一个简单的 FPS 自动降画质策略；
- 改了一些画质参数和返回逻辑。
这些我完全承认。
但请注意：
承认这些是真实增量，和把整个最终作品的完成度都归到他头上，是两回事。
他的新增主要是在我已经存在的系统内部做内容替换和局部扩展。
审计并没有发现他重新建立：
- 新的页面系统；
- 新的 3D 系统；
- 新的相机系统；
- 新的 Shader 体系；
- 新的核心交互体系；
- 新的视觉设计系统；
- 新的 3D 模型。
所以最后的判断才会是：
系统实现新增约 5–15%。
而不是“这个学生独立做了一个看起来这么完整的网站”。
另外还有一点，我觉得也顺便回应一下你之前关于“编辑器、项目管理器、地图、3D 项目这些内容很多”的说法。
报告专门核实了这一点：
这些东西很多只是作为他的“作品素材”出现在图片或视频里。
比如：
- ASCIIStudio 编辑器，是视频里展示的作品；
- 项目管理器，是图片里展示的作品；
- 地图，是截图里的作品；
- 游戏，是录屏里的作品；
- 所谓点云 / 3D 项目，也是作品内容。
它们并不是 Blue Eagle Archive 这个站点本身新实现出来的编辑器、地图系统、游戏页面或者 3D 引擎。
也就是说，你之前看到“里面内容很多”，然后把这些内容的复杂度也算成这个 Archive 网站本身的开发量，这里又混了两个完全不同的东西：
“他把哪些作品放进这个展示站里”
和
“这个展示站本身有多少是他开发的”。
这两者不能直接画等号。
所以现在其实问题已经非常简单了：
你之前是先看到了一个完成度很高的最终成品，
然后默认：
这个完成度基本都是这个学生做出来的。
于是得出：
一个学生做到这种程度很厉害。
但现在技术审计把这件事拆开以后发现：
这个“高完成度”本身，绝大部分来自 RhineLabUI 已经存在的系统。
而他真正新增的部分，主要是内容迁移、媒体展示和局部功能。
那你原来的评价自然就需要重新建立在真实工作量上。
否则就还是我之前那句话：
先把原作者已经做好的工作量算到他头上，再夸他工作量大，当然很容易得出“很厉害”的结论。
至于 React、Node.js 那个类比，现在就更没必要继续说了。
因为现在讨论的已经不是“大家是不是都用了别人的技术”。
而是：
一个具体参赛作品的视觉系统、页面系统、交互系统、3D 系统、模型资产和核心业务实现，到底有多少已经存在于另一个具体开源作品中。
这两个问题根本不是一个层级。
如果 80%～90% 的页面、交互、代码结构，95%～100% 的 3D / 动效系统，以及核心模型几何都能直接对应到另一个已经先发布的具体项目，那么再拿 React、Node.js 来类比，已经没有什么讨论意义了。
1 个赞
我能理解利己、大家都有虚荣心，在被夸奖的时候不想让别人知道其实是有一份其他人的功劳，或者害怕把自己和其他人放一起比较。
于法，我说了，只谈MIT是没有意义的、还有其他的法律权利的问题，那是法官需要考虑的事情。于请，我也讲了，尊重是最基本的底线。
社区就是应该用来讨论公允，讨论我们作为参与开发的人应该抱有什么样的态度和行为。
3 个赞
我觉得有些意图需要澄清
这个页面的水平我认为对于大学生是超标的（你的这个页面本身质量非常棒）
我在看这个作品时，从开始就没有置信大学生能做出这个，且标题是“仿莱因”，因此第一反应是直接跳过了页面，
当时是Opus5.5的发布期，我默认了这是一个Opus创建的网页，我能为你找你该时段发布的足够水平的视频论证这点。
我带了批判的态度继续查看，因为近期有很多网站由AI生成，且空洞、不包含有用内容。
我查看了该网站希望表达的作品，
在发现首个作品是编辑器时，认为作为毕业生能开发出这些（请注意并非UI，而是求职的实际展示内容）很厉害。
以及我认为自己在大学阶段很难达到对应水平。
这不是一个辩论，我不应认领非自己的观点
你提到“这个完成度基本都是这个学生做出来的。”并非我持有观点。
“一个学生做到这种程度很厉害”我希望表示表示“一个毕业生的技术达到这个程度（其中包含的作品）”很厉害，而非“一个学生自己做了这个UI的意思”
在认为用户”看UI“的同时，请注意也存在我这种希望看看现代大学生会什么技术，拿什么求职的人
你可以向前翻阅我的发言，
从开始并没有向你发表过任何攻击性的言论，
我的论点是“在开源时，协议位置应该附带明确的使用方式”
它是一个提出建议的态度，没有跑题。
我认为比起道德约束，协议更加具有说服力。
此次声索作者明确回复了，其实已经是一个负责表现。
此开源内容，位于github，保持现有协议时，
它仍能被Agent爬取，并根据MIT负责地告知作者可以使用（即使是商用），
Agent会根据协议默认将来源写在源码或该作品的license中。
在这个情况下它变得不是道德合不合理，而是我们必须适应。
如认为对应作品是“免费、开源，但是用于比赛（是否商用与此例无关）那么须署名”
那么这个协议是对特定用途有声索的协议
我不反对“从道义上标记原作者”的行为
在我看来比起发长文声索，在开源的原本内容中明文标记，这是一个高效的行为
1 个赞
感谢澄清。
你这一条至少把前面一个我确实理解错的地方说明白了：
你说“一个毕业生能做到这种程度很厉害”，指的是他作品集中展示的编辑器、项目管理器等实际项目，而不是认为 Blue Eagle Archive 这个 UI / 3D / 交互系统是他独立完成的。
如果是这个意思，那这一点我收回之前针对这句话的批评。
我没有必要认领一个你并没有表达过的观点。
而且如果那些作品确实是他本人独立完成的，那么单独评价这些作品的技术能力如何，本身也和我现在的争议没有冲突。
不过你后半段关于协议的论述，我还是不同意。
因为我们似乎一直在讨论两个不同的问题。
我从始至终都没有主张：
“MIT 不允许他使用我的项目。”
恰恰相反，我已经反复说过：
MIT 当然允许他使用、修改、分发，甚至商用。
所以如果今天的问题只是：
“他有没有权 fork RhineLabUI，然后改成自己的作品展示站？”
答案非常简单：
有。
这件事根本没有争议。
但我现在质疑的不是“使用权”，而是：
当他把这个基于现有完整作品轻度修改后的成果，拿去参加一个有奖作品征集时，他是如何描述它的，以及评委看到的最终完成度中到底有多少属于他的创作。
这是一个完全不同的问题。
举一个极端一点但非常容易理解的例子：
假设有人把一个 MIT 开源游戏完整 fork 下来，
换掉人物名字、图片和部分关卡内容，
加几个按钮，
然后拿这个成品去参加“独立游戏创作比赛”。
从许可证角度：
他当然可以修改。
MIT 并没有禁止。
但比赛主办方仍然完全可以问：
这个参赛作品到底有多少是你做的？
甚至完全可能因为“原创贡献不足”而不予评奖。
这并不意味着 MIT 被违反了。
因为：
许可证是在解决版权所有者允许你怎样使用代码；比赛是在判断这个作品有多少可以作为你的创作成果接受评审。
这是两个评价体系。
所以你说：
如果认为“免费、开源，但是用于比赛那么须署名”，那么这个协议是对特定用途有声索的协议。
这里其实把我的观点改写了。
我没有提出：
“只要用于比赛，就必须根据我的许可证额外署名。”
我提出的是：
如果你参加的是作品创作类评选，那么你应当让评委能够准确判断哪些成果来自既有项目，哪些是你的新增。
这不是我通过许可证给他增加一条新的使用限制。
而是作品评审本身就应该具备的信息透明度。
否则许可证越宽松，反而越容易出现一个很荒谬的结果：
MIT 项目可以合法大量复用，
于是参赛时反而越不需要说明自己的实际贡献。
我认为这显然说不通。
而且这里还有一个非常重要的区别：
“标明开源许可证” ≠ “向评委说明作品贡献构成”。
即使他在源码 LICENSE 里完整保留了 MIT copyright notice，
也只能说明：
这部分代码的授权要求履行了。
它仍然不能自动告诉一个浏览参赛页面的评委：
- 这个 3D 档案阵列是谁设计的；
- 这个模型是谁做的；
- 相机运动是谁实现的；
- 玻璃材质是谁实现的；
- 选档 / 抽取 / 归位是谁实现的；
- 360° 查看器是谁实现的；
- 整套页面结构是谁设计的；
- 他真正新增的是哪些东西。
这也是为什么我后来专门做了技术审计。
最后发现 Blue Eagle Archive：
- 视觉设计复用约 85–95%
- 页面结构复用约 85–95%
- 交互逻辑复用约 80–90%
- 3D / 动效复用约 95–100%
- 代码结构复用约 80–90%
- 系统实现原创增量约 5–15%
真正新增的主要是作品资料、图片 / 视频媒体展示、灯箱、资源压缩、自动画质等局部内容。
所以这里讨论的并不是一个“用了某几个 MIT 函数，要不要感谢作者”的边界案例。
而是：
最终参赛作品绝大部分核心视觉与技术系统，本来就来自一个已经完成的具体作品。
在这种情况下，我认为让评委知道这一事实，是再正常不过的要求。
至于你说：
比起发长文声索，在开源的原本内容中明文标记，这是一个高效的行为。
如果你的意思是：
“以后为了避免类似争议，可以在 README 里进一步说明参赛、二创展示时希望如何注明来源。”
这个建议我可以接受。
我甚至觉得以后可以做。
但这是以后如何减少歧义的问题。
它不能反过来变成：
“因为你当初没有额外写一条‘参加比赛请注明来源’，所以这次参赛时怎么呈现都没有问题。”
这是两个完全不同的结论。
我选择 MIT，是允许别人自由使用我的代码。
并不等于我同时放弃了在一个作品比赛中指出‘这个成品的大部分核心成果并不是参赛者完成的’的权利。
至于 Agent 会如何读取 MIT、如何默认处理许可证，我觉得反而不是这件事的核心。
Agent 可以判断：
“这段代码在法律许可上能不能用。”
但 Agent 不会因此替活动主办方回答：
“这个参赛作品应不应该获奖？”
更不会替评委判断：
“这个参赛者实际完成了多少？”
那是另外一个问题。
所以我觉得我们现在其实可以把分歧缩得非常小：
你强调的是：
从开源许可角度，他有权使用。
这一点我从来没有反对。
而我强调的是：
从作品参赛和评奖角度，他的实际增量应该被清楚披露并据此评价。
如果这两句话能够同时成立，其实我们之间就没有必要继续拿 MIT 本身来回争论了。
1 个赞
我再补充一点，因为你这条里还有两个地方我确实比较难理解。
第一，是你最后把问题落到了：
“如果你不希望开源项目被这样用于比赛，那就应该提前在协议里写清楚。”
“比起发长文声索，在原开源内容里明文标记，是更高效的行为。”
这个说法在我看来其实已经有点责任倒置了。
现在发生的事情是：
一个参赛者大量基于一个现成的完整开源作品进行修改，
然后把最终成果拿去参加有奖作品征集，
而原作者在开奖前已经公开提出了质疑。
在这种情况下，正常应该讨论的是：
- 参赛者有没有充分说明原项目来源和自己的实际增量；
- 官方有没有核实作品真实创作比例；
- 这样的作品是否符合评奖标准。
但你的结论却变成了：
“那原作者为什么没有提前设计一个协议，把这种情况禁止掉？”
这就很奇怪。
我选择 MIT，只代表：
我允许别人使用、修改、分发我的代码。
它不代表：
我有义务提前预判未来所有可能的比赛、征集、评奖场景，并逐条写进许可证里。
更不代表：
如果我没有提前写，就不能在事情发生后指出参赛作品的实际贡献构成存在问题。
否则这个逻辑可以无限延伸：
“你不希望别人轻改以后当主要成果参赛，为什么没提前写？”
“你不希望官方给这种作品颁奖，为什么没提前写？”
“你不希望别人误会这些核心系统是参赛者自己做的，为什么没提前在 README 顶部加粗警告？”
最后就会变成：
只要原作者没有提前预判并禁止所有可能的不当使用场景，出了问题就是原作者自己规则没写好。
我不认为这个逻辑成立。
尤其是我在开奖前就已经公开提出异议了。
所以现在再告诉我：
“比起发长文声索，你应该一开始就写清楚。”
我确实很难不理解成：
事情出了以后，开始反过来检讨原作者为什么没把自己保护得更严。
第二个我更不理解的问题是：
你为什么反复强调这个学生“技术很好”“作品很多”“作为毕业生很厉害”。
我可以非常明确地说：
我完全可以承认他是一个技术能力不错的毕业生。
甚至假设他作品集中展示的那些编辑器、项目管理器、地图、游戏、3D 项目全部都是他独立完成的，而且全部都很优秀。
然后呢？
这和当前争议有什么关系？
当前讨论的是：
他这次拿来参加作品征集的 Blue Eagle Archive，到底有多少核心内容是他自己做的。
而不是：
“这个人总体上是不是一个优秀学生。”
这两件事完全可以同时成立：
- 他是一个能力不错的毕业生；
- 他这次参赛的这个作品，大部分核心视觉、页面、交互、3D 和代码系统并不是他做的。
两者没有任何矛盾。
所以你反复强调：
“我大学阶段很难达到这个水平”
“这些作品作为求职内容很厉害”
我一直没明白它是在回应哪个问题。
如果是在回应：
“这个人有没有技术能力？”
那我从来没有否定过。
如果是在回应：
“这次参赛作品是不是主要由他完成？”
那他其他项目有多厉害，并不能成为证据。
一个人以前做过十个很优秀的项目，
也不能因此自动证明第十一个项目里的工作量就都是他的。
而且我觉得这个叙述方式其实会不自觉地改变问题的性质。
原本讨论的是：
“一个核心系统高度复用现有完整作品的参赛项目，是否充分披露了实际贡献。”
慢慢就变成了：
“一个很优秀的毕业生，只是在开源署名或者协议理解上可能有一点瑕疵。”
这两种描述给人的感受完全不一样。
但“这个人是不是优秀”，本来就不是我提出的问题。
所以如果我们要继续讨论，我觉得其实可以把所有外围内容都先放掉。
不讨论他是不是优秀学生，
不讨论我大学时能不能做到，
不讨论 Agent 怎么理解 MIT，
也不讨论我以后是不是应该改 README。
只回答一个很简单的问题：
一个系统实现原创增量大约只有 5–15%、核心视觉 / 页面 / 交互 / 3D 系统大量直接来自另一个已完成作品的项目，如果参赛页面没有让评委清楚知道这些事实，它是否适合作为参赛者自己的主要创作成果获得作品奖？
这才是我从一开始真正关心的问题。
3 个赞
我希望论证的是你提到的以后如何减少歧义，
它是一个事后避免的廉价过程
我未表达过，也没有那原作者为什么没有提前设计一个协议，把这种情况禁止掉？的事后诸葛亮意图
我觉得澄清了，这部分就算pass了。
后面没说清的问题，即我提到这个作品作为求职内容，或者作者作为大学生很厉害
关于这部分观点
是在89楼论证“参赛者向评委展示的作品到底有多少是自己的工作”
作者的标题包含了“页面”和“3D作品集”
这是一个事实不变基础上的两面认知
- 如果认为此次提交的内容是“页面”，那么如楼上所说，其工作量是一成上下
- 如果认为此次提交的内容是”3D作品集“，那么页面是其作品之一，就变成了主要是作者作品
由于我非常重视实用性（我会在这个论坛多次声讨TrawWork不应该花时间画图标、做网页，应该直接给报告），所以默认从后者理解，
而，网页给人的第一印象，以及楼上作为库作者，当然更关注前者
我不建议在上述明显具有歧义位置做语文争论
且我认为我们已经相互明确了解了观点
同为程序员，尝试通过语言和结构化文档表达和解析观点，本身也是个提高过程，咱们正常交流
楼上表达过诉求，希望得到比赛组织者的态度
我非当事人，也不是比赛组织者，
现在在干水友该干的事情，
目前觉得这个话题继续聊的话太长了。
十一假期后如果官方有跟进，那么前排吃瓜。
1 个赞
我本来觉得这个问题可以到此为止了，但我刚刚重新翻了一下原帖，发现这里其实还有一个很关键的事实。
你现在的说法是：
你主要把它理解成一个“3D作品集”，网页只是其中一个展示载体；
你关注的是里面那些实际项目，而不是这个UI本身。
但我重新看了原帖和评论区以后，我觉得这个说法和你当时实际的评价并不完全一致。
因为你自己在原帖下面留下过一句：
“很棒，几个例子都是视觉效果出色，印象深刻”
也就是说，至少在你第一次看到这个作品时，
页面本身的视觉效果显然就是你形成正面评价的重要部分。
所以现在再说：
“我主要看的是里面的项目，页面只是其中之一。”
这很难完全成立。
而且更关键的是，参赛者自己在原帖里其实已经把这件事说得非常清楚了。
他自己写的是：
“复制页其实是一个半成品。视觉、交互、工程链路都是现成的，差的是三件事，补上就行。”
然后列出的三件事是：
- 换叙事；
- 数据驱动；
- 让作品能被打开。
这其实已经非常直白了。
也就是说，他自己都承认：
视觉、交互、工程链路本身就是现成的。
而他主要做的是：
- 把内容换成自己的项目；
- 把项目数据接进去；
- 加图片、视频、灯箱、外链等展示功能。
这和后来的技术审计结论基本完全一致。
审计结果是：
- 视觉设计复用约 85–95%
- 页面结构复用约 85–95%
- 交互逻辑复用约 80–90%
- 3D / 动效复用约 95–100%
- 系统实现原创增量约 5–15%
所以这并不是我事后为了争议才把他的工作量说小。
连参赛者自己原帖里的描述，都没有把视觉、交互、工程链路认领成自己的原创。
然后再看原帖评论区。
有人说：
“作品集感觉很高级”
有人说：
“非常想复刻你这个，很不错”
你自己说：
“视觉效果出色，印象深刻”
官方运营也在下面互动。
所以很明显：
这个页面本身的视觉、交互和整体完成度，就是这个帖子吸引注意力的重要原因之一。
它并不是一个没人关心、可以忽略掉的“作品集外壳”。
所以我还是坚持前面的观点：
不能在获得关注、获得好评、形成第一印象的时候，
让这个页面的视觉和交互承担大量价值；
等到讨论“这些成果到底是谁做的”时，
又突然把页面降级成：
“只是一个承载作品内容的壳，主要还是看里面的项目。”
这个标准不能来回切换。
我当然不否认他里面展示的项目本身可能有价值。
但同样也不能否认：
这个参赛作品之所以呈现出现在这种“高级”“视觉效果出色”“印象深刻”的完成度，本身就大量来自 RhineLabUI 已经完成的视觉、交互、3D 和工程体系。
如果这些东西在正面评价时算作品价值的一部分，
那么在讨论原创贡献时，它们也必须算进去。
不能只在有利的时候算，在讨论归属的时候又不算。
1 个赞