License issue #9
Comments
|
BSD 是 Go 的开源协议，XTLS 基于 Go 的 而仓库里的 LICENSE 文件是 XTLS 新增代码自身的 LICENSE，目前是自定义的，的确不属于 BSD 协议 其实这里没有待解决的 license issue，因为它们是不冲突的：如你所见，这里只是遵循 BSD 的规则，附带了 Go 的 LICENSE-Go |
|
事实上，这个提交并没有修改 LICENSE。相反地，此项目的 LICENSE 是逐渐宽松的，您可以查看 LICENSE 文件的 history 此外， |
|
Dear maintainer, There're some misunderstanding here, I guess.
If you consider this project is still under BSD-style license, removing two above won't bother you as I estimate. |
|
这里的确有 misunderstanding，因为 XTLS 项目本身从一开始就不是 BSD-style license，关于这一点，您可以查看 commits history 辛苦您的跟进，但目前不考虑进一步放宽 LICENSE，也暂时没有成为 debian/ubuntu package 的必要。 |
|
Dear maintainer, Since this library is the new dependency for v2ray, which is already in debian/ubuntu. I'm sorry to hear the appended part of this library is not licensed under BSD, or other open source license. Cheers, |
|
众所周知，Linux 本身遵循 GPL 协议，但这并不影响它运行在非完全开源硬件上、使用那些 CPU 的指令集。 |
|
另外，我想提醒你，我随手找了 v2ray 的另一个依赖项，比如 https://github.com/xiaokangwang/VSign 它早就是 v2ray 的依赖项之一，但没有任何 LICENSE，即默认完全私有，请问你有把它打包成 Debian 的 package 吗？ 我甚至没有见到你询问它的 short description，不得不怀疑你在这里的真实目的。 最后请回答我：Debian 的人都这么流氓吗？不好意思，我本来就更喜欢 Red Hat 系。 如果大家都这么流氓，v2ray 有什么必要再保持 MIT 呢？ |
|
this is not a dependency for v2ray, at least for v4.28.2 |
|
Interesting. https://github.com/v2fly/v2ray-core/blob/v4.28.2/go.mod 众所周知，这个版本的 v2ray 严重依赖 v2ctl，仍需要通过它来读取配置文件。 |
我认为你哪凉快待哪去。 |
|
首先你要知道，我只是 Refresh 了仓库，并没有修改 XTLS 的 LICENSE，它从一开始就不是 BSD，唯一一次修改还是放宽限制。 其次你要知道，XTLS 的 LICENSE 并不禁止它被当作依赖来使用，主要目的是不允许修改它的源代码并二次分发。 最后你要知道，v2ray 这种软件需要不断迭代，且有官方维护的 Linux 安装脚本，几乎没有人会通过发行版源来安装（Arch 除外 |
|
这里的问题不是Debian、Ubuntu、openSUSE还是Arch。问题也不是BSD License。这里的问题是这个项目是否为开源软件。即使用 GPL 等更激进的License它也还是开源软件。 而"是不允许修改它的源代码并二次分发"这一条款使得这个项目不是开源软件了。 PS：这里说的开源软件为 OSI 定义的开源软件，而不是指公开源代码的软件。 |
|
但这的确是客观事实，另外无需担心，会有人继续维护的，或者是独立源。 |
|
是的，与 v2ray 不同，此项目从未宣称是完全开源项目，但这与 v2ray 的 MIT 并不冲突，且任何人都可以审计 XTLS 的代码。 现在的情况是这里出现了令人不齿的道德绑架。此外，MPL 协议的代码算是开源吗？这似乎是个更好的选择。 |
然而任何人用v2ray时需要引入xtls，也就是要引入一个不开源的软件。
是的，在 https://opensource.org/licenses/category 这个列表里都是符合开源软件定义的License。MPL 见https://opensource.org/licenses/MPL-2.0 |
|
我们已经在 v2ray 内部群广泛讨论了这件事，首先是虽然没有绝对必要，但我们不介意开个 GitHub Actions 来继续维护 debian/ubuntu 源。独立源是可能的另一个选择，如果最终决定推出，也是由我们维护，所以无需担心安全性问题。 另外你也无须担心 XTLS 的安全问题，因为所有代码都是公开可见可审计的。至于 LICENSE，我可能会选择 MPL，或者保持现状。但这与今天的事情无关，主要原因是 v2ray 在检查依赖授权情况，需要保证 v2ray 确实得到 XTLS 的使用授权。 |
|
就目前的情况而言，XTLS 并不是不开源，而是不完全开源，至少任何人都可以审计 XTLS 的代码，所以这里没有风险。 下游的开源协议对上游的确没有约束能力，比如你可以在 GPL 项目中依赖 MIT，但却不能要求它也改为 GPL。 |
这里的“开源”定义大家理解不一样，对于大部分的Linux发行版来说，他们的定义与OSI定义基本一致，而不是只要能看到代码就可以了。可以在 https://opensource.org/osd-annotated 看到，这里定义的“开源”有很多条款。比如有一条就是“The license must allow modifications and derived works”就是说要允许修改，还有一条“No Discrimination Against Persons or Groups”，即这个License不能是针对特定受众的，比如不能只针对v2ray进行授权。 |
|
是的，作为 v2ray 的主要维护者之一，我可以明确表示：v2ray 之前没有非要符合 OSI 的这种洁癖，事实是，我们之前并没有在意这个方面。但你提出这一条有帮助
因为团队内考虑过这种授权方案，虽然我觉得比较麻烦，且可能会导致其它软件从一开始就不敢使用此项目。 |
|
I appreciate your contribution to the project and open source community. For the repo you mentioned: https://github.com/xiaokangwang/VSign As author you can decide the license for your code, and I cannot force to change it for sure. |
Hi, I am the developer and one of maintainer of V2Fly, and support the Open Source project to the furthest extent. I can help you with continuing to package V2Ray without copyright issue. VSign is used for verifying the release binary from V2Fly Github Release. It is not useful for Debian distribution since Debian have its own signing and secure verification process, and do not generate a V2Ray Release Signature file in the build process. It is not removed for licensing reason. Debian version of V2Ray removes VSign with script provided in the source tree https://github.com/v2fly/v2ray-core/blob/master/release/mutilate/removeVSign.sh . I could provide you a similar script to remove non-free code from V2Ray and continue to package V2Ray as a free and open source software. The reason VSign is not released under open source license is entirely unintentional, it have been open sourced as the same license as V2Ray(v2fly/VSign@6e7f926). Xiaokang Wang |
|
In fact it's not a moral issue, but a legal issue. Open source software are copyrighted. That's why the author has full right to choose the license of the work. Therefore, when the licenses are mutually incompatible, you can't come into an agreement. Otherwise, you simply violate other's copyright which is illegal and can be practically sued. |
|
之前过于生气，把整个 issue 区关了，现在重新开放。 但现在想到还是很生气。 我花时间、冒着众所周知的风险写软件，一群自以为是的人挑随手写的 LICENSE 的刺，比如什么“不给复制“、”不给运行”。 是都吃得太饱了是吧？ 而这个项目本身，它涵盖了一些技术突破，我不要钱，但也不希望很快就有人拿它魔改、不当获利，然后这也成了问题。 回到这个争执本身，老子他妈的本来就是刷新个仓库：全部删掉，重新上传，没改协议。 之前协议唯一一次修改还是放宽，没有意外的话，就是逐渐放宽的。 然后就有个人过来，非说我改了协议。 这个项目中有 Go 的 BSD 只是按要求附带，LICENSE 文件才是本项目的协议，从一开始就不是 BSD。 自己眼睛有问题，现在成我的错了？ 一开始还不说清楚情况，非让我移除那个 LICENSE，这 TM？？？ 而且我作为开发者之一，之前都不知道 v2ray 要遵守 debian 的规则？？？甚至，我都不知道 debian 是什么规则。 最让人气的还是 这 TM 直接把我架到 BSD 的烤架上了，我成了万恶之源？？？再说一遍，一开始就 TM 不是 BSD 然后还是坚持让我移除 LICENSE，搞笑呢？ 这么做的本质，参考楼上的发言。 然后就威胁说要移除 debian 的 v2ray 了？？？如我所说，我根本就不知道什么时候多出了这种条条框框。 为什么说是“流氓”呢？因为这个项目从一开始就不是 BSD，来了一个人非要说我改了 LICENSE，然后强行让我改，道德绑架一样。 最后，不要认为所有人都知道 debian 的规则，以后最好一开始就把所有话说清楚。 |
|
另外，我知道看到这个 issue 的，多是 debian 群里的人，还有其他的，比如至少自以为对开源协议很有研究的人。 所以你们发表态度时，有没有站在当事人的角度考虑？？？ 我也不讨厌开源软件，但不要自己把 debian 当信条，就可以直接去不理解别人的认知，以及进行道德绑架。 以及，我是冒很大风险的，本来就随手写一行 LICENSE，这里并不是重点，鸡蛋里挑骨头的人究竟想过没？？？ |
|
@Fei1Yang 说出你的想法。 |
|
这里的规则很简单，你发表了态度，就要说清楚原因，否则只是小人罢了。 |
|
一个类似的事，handbrake源代码里include了fdk-aac，fdk-aac的许可和gpl是不兼容的，但是handbrake也没有直接移除fdk-aac相关代码，只是不在二进制分发内包含fdk-aac。。。所以这个下游分发出问题反过来要求上游确实有点逾矩 |
|
On Sun, Jul 25, 2021 at 02:18:23AM -0700, maz-1 wrote:
一个类似的事，handbrake源代码里include了fdk-aac，fdk-aac的许可和gpl是不兼容的，但是handbrake也没有直接移除fdk-aac相关代码，只是不在二进制分发内包含fdk-aac。。。所以这个下游分发出问题反过来要求上游确实有点逾矩
在我看来，po主只是善意的通知和建议，只是没表述清楚作者误解了。
…--
Best regards,
lilydjwg
|
arch:?? |
|
一个中文 一个英文 |
|
整篇看下来，有一个问题的答案没有看到： 从突破墙限制的角度考虑，自由软件是有优势的。每一次的新软件、每一次的迭代（从v2ray到v2fly、从v2fly到xray、从trojan到trojan-go）都是或多或少的借助了自由软件的授权。这个授权保证了当原作者消失时，新的作者可以继续前者的项目；保证了当有人有新的想法时，可以高效的使用前人的代码来实现；也使得新的技术新的项目能够快速被商业化的机场、软件所使用（adoptation）。现在v2在很多机场普及的原因，其一就是自由软件。这样的普及使得更多的普通用户，甚至不懂怎么直接使用这些FQ项目的用户，能够因此受益。 从我能想到的理由看，@RPRX将XTLS做成私有代码可以帮助作者对使用代码的商业项目收取授权费（例如可以向ios shadowrocket收费）。那么这也无可厚非，大家都要吃饭，也不是什么不道德的事情。如果是这个考虑，大可以大方讲出来。如果是这样，那么其实可以把XTLS做成一个v2fly的插件的形式，由用户自由安装。毕竟目前XRAY的文档维护就差了v2fly一大截，而且是XRay本身也是在使用v2fly的代码。这么做的好处，一是v2fly的实用使用方面的自由度更高，二是XTLS也可以被作为其他项目的插件使用，利于更多的盈利。 |
|
我是检索两者区别无意中看过来的。作者的代码授权自然是由作者全权决定，旁人只能提建议。而自己的“孩子”只让自己“带大”这种心情我很能理解，不过就此分裂有点过激了，在我看来有一丢丢情绪在里边。楼上有个建议是弄成插件，我觉得可以呀。就算收费也是名正言顺的，让出力的人得到回报是非常道德的一件事，尽管作者可能并非此意。 btw: 我还是头一次看到英文和中文争得面红耳赤，而且互相能感受到语气和情绪…… |
|
marked |
最近才看到这个争论，可能已经晚了。 自从ubuntu开始流行并以绝对的用户量优势碾压debian以后，debian社区就开始疯狗起来了（不限中文圈，英语圈也一样） 建议：爱用不用，授权就这样了 debian社区重新定义了开源，我以前一个小开源项目被他们喷过（好在现在已经交给社区组织维护了，我只有个白嫖copilot的权益，七年没贡献代码了），因为不是翻墙这种小众需求，受众更大，挨喷的更多，反正在debian人的眼里，不能放到debian版本库里的协议都不是开源协议。 一句话：debian开源警察滚 |
我估计就是来晚了，来晚了也得支持一下嘛。 我当年被喷的比这还狠呢，把我一个铁杆debian教徒给喷退教了 而我那个项目不是因为自己愿意才收紧授权的，是因为引用了其他授权的实现（那个年代还不是通过外联依赖，是sf的一个项目不在github不好引用，我直接拷的），不能拷贝就不尊重原始授权啊 实在跟他们玩不起，我还在debian的QQ群里有号，id能对应上，指名道姓喷的，qq邮箱喷的，跟现在你去小妹妹圈子里喷了一下肖战的效果差不多………… 然后我就把那个项目丢给组织维护了 |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
要说重新定义开源软件，还是 fosshub 功力深厚。 |
233，本来看见前面有被抽楼的不打算发言的，不过既然这样反而安全了点（？）。 （这谁 marked as off-topic 的啊，明明超 on topic 的好不。） @realpg 跟开源警察没关系，我想这里早有人是想说法盲滚粗，没明说罢了。 一个常识：如果没明确 LICENSE ，按版权法默认条款用户的权利会受限。LICENSE 被普遍认为必要，隐含版权法默认在这里目标用户面前都是限制都是超出合理限度的。（题外话，要我说，其实光是看管财产权不管人身权死活的盎-萨版权法传统，那就是妥妥的恶法了。） 但不管如何对 LICENSE 需要有的实质内容如何认知，不管是对专有、开源还是自由软件的涉众，一个大前提：同意这里普遍的程序正义仍然高于个别的事实正义，不管内容如何，至少先要遵守法律且不能诉诸无知（“我不懂法我有理”），之后再考虑打算解决什么争议。表现出没有 LICENSE 或者随手一句瞎写的条款反而更理直气壮，那么要么是在无视法律，要么是在无视用户对明确权利和义务的诉求。 既然作者看来没打算明摆着就跟用户对着干（“我就是特么不尊重我这个 copyright owner 以外你们所有人对权利的预期你们来咬我啊”）而甚至能成功分裂出来一些人，那么造成这样局面的理由，大概就是法盲了——漠视惯了正式法律文件的低位和/或自己想当然误解法律如何运作，顺带不拿别人遵守规则的努力当回事儿。
这是这楼里最离谱的误解。事实上各种宽松开源软件许可的共通精神就是“爱用不用”，不管是授权还是免责条款。 反而这里的 "All rights reserved" + "Only for compiling executables usage for now." 恰好是对“爱用不用”的精神的彻底打脸和背叛——显然 usage 给了极大的限制，甚至比版权法的默认条款还严格，明摆着就是“不自肃吃官司活该”的臭脸。除了口嫌体正直给了源码（否则可能用户根本不知道有这茬），哪来的“爱用不用”？ 搞清楚，法律意义上的“用”本来就包含了复制和修改后再分发这些操作，特别你还分发的是技术上根本不限制修改后分发的源代码。（其实版权法默认普遍不管你软件做成二进制的“使用”，只有《中华人民共和国软件著作权保护条例》之类有规定用户发现侵权后应当停止“使用”这样的少数的例外。） 如若不是如此，那就是在日用户脑壳里对“爱用不用”的语文理解了，法外鄙视再加一等。 至于什么 Debian ，who cares？自由软件小将我都不怎么搭理。但即便是这些人，也没表演自己是法盲+秀优越。 而 @f2sky 所谓“本末倒置”的论调就是另一个次元上的可笑了。你到底是不是真的在怀疑强权（物理规律除外）先于法制的表演者和实践者市面上很紧俏，差你一个？ 比起让某些人成气候，多一个少一个具体的软件甚至具体的作者，怕还真没那么重要。 说实话，我不太在乎在这些话题上抒发反感的情绪，不过如果都集中注意力在乎想要排除这种“反感”这么一团和气上，剩下的东西就真让人作呕了。
@wc7086 @simplerick-simple 这根本就不是什么私有开源协议，因为这压根就不是开源协议。 这就是明确强调所有权并限制用户不得享有类似所有者的绝大多数权利的**专有(proprietary)协议，跟私有(private)**是两回事。（财产私有权一样是法律普遍默认的。） 知道什么开源的抄一个协议改改容易得很，非得拒绝理解什么叫开源随手改成这样就根本是另一回事了。 说白了这里特别值得鄙视的就是睁眼说瞎话（不管是不是法盲导致的）。
所谓的个人理解是不需要人背书的，也因此对多数人的共识没什么用。 为什么需要 OSI ？因为需要提供一个有效的实体能代表了发明和（早期）使用这个术语的人群的共识。发明所谓“开源”之类简单说法的人就没义务也没能力让你能一定理解初衷——倒不是他们故意的，而是自然语言在此无法确保容易精确理解的无能这个局限性是不以人为意志转移的客观限制。不理解这种公开历史背景而望文生义的用户，本就该自负歧义的风险，而不是把锅甩回去。毕竟，先来后到。 “个人理解”的瞎闹问题在自由软件上有更大的影响，因为“自由”这个词的歧义更加混乱（特别是原文），以至于 RMS 有专门解释过。 既然类似 FSF 和 OSI 的解释已被多数涉众接受，那么个人理解的偏差就更没什么存在的余地。你可以 diss “开源”“自由”这词选得不好，但除非真是你行你上——选出一个明摆着对谁都更合适的替代说法并被接受，你就现实地没资格把当前你个人的误解/知道错了死活不改正的鸡儿理解强行安排在其他所有人的脑子里替换掉现有共识并自居正义。 至于关心所谓“认证”资格的问题，倒不如质疑为何需要选择 GPL 等一些 or later 的许可直接让 FSF bypass 原始许可文本的问题——那是更实在的法律“漏洞”风险。（……也是能让吃瓜群众看到 Torvalds v. 抠脚皮大汉的前提。） 执意选择不开源的许可证是所有者的自由。行使这种自由并没什么大不了的，即便不开源又如何？都不同意 OSI 划分门槛的哲学，干嘛非得热脸蹭冷屁股抱“开源”大腿？这反而显得更加动机不纯、别有用心。 类似地，这里的专有许可证也不是让人拒绝的理由，也有不同的人多次表明尊重作者这点。会成为拒绝采用的理由是具体许可证条款的限制让下游实质有更多麻烦的工作，那还不如不要了（真要紧到不能没有的，大不了再找人 clean room 重新实现一个——不过要花费资源重新实现而不是直接 fork ，已经说明可用性近乎传统专有软件一样低劣了）。 这么现实的问题都不容易理解，只能说明距离日常会拿“开源”干活的人太远了。既然是外行，就不要在这种无聊的话语权私货上添乱，只会显得更有民科范儿地浪费所有人的时间。（当然，趁早划清界限圈地自萌止损仍是被鼓励的，有能力起得来社区的人真发自真心在乎“分裂”的并不多。）
DFSG 跟 OSD 比起来就不算哪根葱。 没 Debian 开源还是开源，没 OSI 就得另外有备胎来收拾历史上下文，避免别有用心的成本过低而导致“开源”变成谁都可以乱 bb 拿来当幌子骗人的有害废话。 @lilydjwg fosshub ？远没 GitHub 上的开源小将有存在感的。 这就是社交网站能薅用户羊毛，在道义上得到更多不当得利的一个典型例子了（暴论 |
一個 tunnel 協議的實作什麼時候變成了違法項目？？？ |
可能。 比如你违反沙里亚法，不见得在不适用沙里亚法的管辖区无法维权。 比如新西兰不承认软件专利，不见得别的专利就不能依照新西兰的法律维权。 如果非得要放之四海皆准的强制力，那只有放弃法律了，好朋友怕是只有物理定律（
很抱歉，你的个人喜欢毫无卵用。要让你的个人喜欢代替共识，实际上怕是只有一条极端化路线可走。 另外，基本上，你要是没有核弹，想让已经有核弹的在是不是能有核弹的问题上闭嘴是天方夜谭。
给出可信来源。 |
关于法律的适用，实际的问题还要更加复杂一些。 特别地，同一部法律也可能变更保护范围，而使同一类行为的性质的认定依赖更具体的背景。 举一个和这里更相关的例子：《中华人民共和国著作权法》曾规定：“依法禁止出版、传播的作品，不受本法保护。”但是，2010 年的修正案删去了这一条款。可见，作品是否违反其它法律的禁止性规定不影响是否侵犯著作权的判定。 不过在此之前，我建议视图对着 一个常识：刑事制裁不保证蕴含禁止当事人主张民事权利。
我还以为你获知了什么新的官方表态，结果还是臆断。 OSD 第 5 条禁止“对人和团体歧视”，但没有排除对非特定实体设置门槛。 否则，按你的设想，GNU GPL 也不符合 OSD ，因为它明确“歧视”了不愿意遵循 copyleft 要求的实体使用该许可证。这显然是荒谬的。 实践上，反歧视条款针对的是拉清单式的排除，比如“禁止微软使用”。 SSPL 明确不符合 OSD 的第 6 条，大概他们的人也知道有问题，所以放弃了“认证”。 这里讨论的其它许可证没有应用领域的差别，所以第 6 条不适用。 |
我不太知道你是如何得出“活用”的余地的。 这类许可证没有强迫你接受的能力。它的作用在于，若选择当做一纸空文，那么法律的默认条款会发生效力。根本上，许可证不是无中生有地添加限制，而是提供（带有条件的）豁免。 因此，在没有其它授权时，装作没有违反许可证的条件是不够的，实务上只能承认并接受许可证。 而核查是否违反条款和纠正侵权行为，就完全不是伪装者可以控制的独断权利了。 顺带可以多提一下，OSD 第 5 条和第 6 条也算是体现“爱用不用”的精神：我们明确没兴趣陪你们玩站队；想站队的，要么抱（钻）法律大腿（空子），要么就不要蹭热度僭称“开源”。 ——这种统战策略是基本的共识，没有后世阴谋家见缝插针的余地。 |
这不是某个许可证条款内置的清单或附件；也没有其它证据表明这是许可证条款适用的前置条件。这份文件内容也很明确地说明，“维护本列表的目的在于为《中华人民共和国劳动法》的执行提供参考依据”，而非给个别法律文件特供。 IANAL ，依照现行有关法律，不保证可以向你提供完全的支持。如何在法律程序上提供具有效力的证明，以及有关的代理业务，请咨询专业人士。 |
感觉你才是不懂基本社会运行规则的一个。 代码作者有权采用任何不违反上游限制的许可。 对于被喷退网的作者，还是我，是不是开源不重要。 你们愿意用就用，不愿意用就滚。没人强迫你用这个。 你不能因为作者采用的license不合心意就变着法的去要求作者做什么。 |
你的言论让你表现得恰好相反。这个先放着。
没看到有人反对这个。
对工作流被作者阻塞的用户，比如这个 issue 的作者，他们不得不关心作者的意见。还有有少数人因为个人理由关心作者的意见。 但大部分人都没理由有必要关心作者或者你或者这里某些个别人的意见，至少没有理由支持这里一些关于“开源”的没有事实理由支撑的离大谱意见。 （也有人自供自己就是对 OSI 有偏见。但有偏见，之后又能如何，除了制造混乱，能改变得了主流意见？确信这到底是在跟 OSI 还是和主流涉众对立？）
这是废话。
这只能说是建议，你也强迫不了。 况且用不用和是否参与这里的讨论本就没有因果关系，因为许可证的影响一目了然，根本不用遵循都能看出问题。 即便这里的讨论早就超出作品本身的范畴了，关于作者对用户请求权利的回应态度发表意见，也没法算跑题。
这个是强词夺理。这里的用户没有显示出违反 GitHub ToS 或者和作者事前约定的行为。作者可以不接受甚至不理会请求，但是反过来以自身的立场质疑这个请求的合理性是毫无道理的，动辄上纲上线划分阵营，反而显示对当前业界的一般基本操作欠缺基本了解，以至于不能理解 issue 作者和不少围观群众的动机。 CC: @maz-1 这哪里“逾矩”？哪个“矩”要求用户不能或者不应该这样做？ 如果这算逾矩，我还想说一大堆 BSD 覆盖的代码里混了一撮专有许可条款又不事前准确明示，这种让加大复用代码工作量的行为才是逾矩。 ——这当然不是实际情况，因为用户本来就需要仔细看清楚许可（类似用户没有脸认为我不懂法我有理）；但这就更没法指责 Debian 系对待许可证的审慎习惯和严格要求了——正是因为这样，才更容易及早发现稀里糊涂事后给人添乱的成分而减少损失。 不过，许可证原则上跟版本匹配，用户没有义务审查仓库历史。“我只是 Refresh 了仓库”不是用户有必要了解的，“首先你要知道”这点就很离谱。真正需要知道的是“主要目的是不允许修改它的源代码并二次分发”，结果就是有用户（因为 Debian 需要审查许可）清楚了，自然地作出了反应而已。 （至于“几乎没有人会通过发行版源来安装”，只是个拙劣的借口；“至少任何人都可以审计 XTLS 的代码”，也只是能获取源代码、被“开源”涵盖了的次要好处，但远远不足以涵盖通常认知中“开源”能提供的所有保证。） 这里对专有许可证条款不满的用户，集中不满的就是这个限制，因为这不可变通的形式架空了公认开源许可证都存在的主要权利（虽然有些许可证可能带有别的附加条件），冲击了公认的“开源”的认知，篡改了他们对权利的公共主张。这反而被轻描淡写地带过了。 毫无疑问，不论“开源”对这个项目是否重要，对这些用户是重要的。再具体点，为什么需要 OSD ？因为“开源”的用户一开始就要求有类似的保证（但又不满只有 FSF 的那些定义），这就是一系列基础需求的概括。即便你不声称开源，不会使“不允许修改它的源代码并二次分发”的目的和“开源”的定义冲突，这些用户还是不会容忍这样的限制。 作为作者，自然没义务满足用户的任意需求。但是本来一句话就能说明立场，非得带节奏臆测用户的动机，这是什么居心？反过来还要在“开源”的定义上扯皮，强调不应该是这样应该是自己想象的这样，暗示自己比一开始发明出“开源”的用户更加有权钦定什么叫开源，就更加是不着边际的挑衅了。 还“令人不齿的道德绑架”。谁在绑架对“开源”的理解，谁在试图消除分歧，不一目了然？ “本来就随手写一行 LICENSE，这里并不是重点，鸡蛋里挑骨头的人究竟想过没” 还好意思对自己的毫无自觉洋洋自得。如 @zhsj 说过的，这就是“问题”，只不过口气婉转，没明确要求同意“这就是重点”，并且退了一步，只是说出分歧暂时允许某些人重新定义什么叫“开源”了，没是说你那么区区一点理由篡改开源的认知对理解什么是开源的既有人群来讲，是一种难以让人容忍的、装内行的、祸害公众的无知。 对原本和 OSI 或者相近的既有团体一道支持“开源”的用户来讲，这种煽了大部分许可的形式，自然就是和专有软件近似的、限制权利的冒牌货；要是知道这样，怕是一开始就不会多关注，直接当你是空气。不过真要这样，反倒不会有冲突了。 所以到底是谁在挑事？
最后再说这个。 “Debian 的人都这么流氓吗？不好意思，我本来就更喜欢 Red Hat 系。” 不说自己站队，这直接就要求他人把 Debian 和 Red Hat 放在对立面上：这种不容置喙的口气，仿佛这已经是不用辩驳的真理。然而实际如何？ 这里有谁自认为有资格这样挑唆的，站出来，信不信大把人高兴喷到你退网？ （这个回复上的引文和反对意见也相当典型地体现了围观群众的态度。） 基本社会运行规则之一就是各人对言论负责，而不是错了不认账，口嗨一击脱离。 另一个常识，是要知道怎么统战。 臆造出一个 Debian 开源警察的阵营烘托自己是受害者，却没事拿开源的定义口嗨，挑拨远不限于 Debian 的相关人士早就有的共识，却又没能力在混淆视听和发表冒犯性言论以外更进一步。这是单纯嫌热闹不够事大？ |
这方面我只能建议别拿肖战当回事儿。肖战的影响力主要也是因为背靠的资方，不依赖自身的多少斤两；所谓开源的小将在这方面怕是还没资格跟 Gie Gie 相提并论的。 拿开源的定义口嗨尤其不智。这个许可证明确和 OSD 第 5 条冲突而算不上开源许可证，说白了这就决定了它跟开源没几毛钱关系。（同时我很怀疑它如何能在同一个衍生作品中另外的 GPL 合法共存，恐怕要给人用，至少有一个得是摆设。） |
在小圈子内，这或许是比较有影响力的项目（不过据我所知，早就算不上是最有影响力的）；而且，最有影响力的这部分项目只是用了正经的许可证。就使用自制许可证的作品的流行程度，还是用户群体的规模，根本算不上在开源界有多少影响力；即便真有到了近似 SSPL 的影响力的程度，也会被 OSD 一下爆杀。 这种情况，愿意圈地自萌的就自嗨，拎不清楚什么东西是自己能说了算的话，陡作法自毙耳。 |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
人家都退网了 还来这喷，你们都积点德吧 |
|
https://lists.debian.org/debian-vote/2022/10/msg00000.html |
这只能算特例吧，胳膊扭不过大腿的妥协罢了 |
|
@FrankHB |
Debian 的人都这么流氓吗? 哈哈, 嘴上无毛的小儿, 总是充满了流氓的气质. |
and others
As stated in #6, I'm trying to package this library to debian/ubuntu, as this is a new dependency for v2ray.
However, the license is not compatible with other open ones.
While most files are BSD, file conn.go has a different license header attached, pointing to the LICENSE file.
And that one simply says "All rights reserved" and "Only for compiling executables usage for now.", which is clearly not BSD-style.
Could you kindly removing those statement, or working with us to think out a better plan for current one?
Thank you!
The text was updated successfully, but these errors were encountered: