Closed rogers0 closed 3 years ago
所以是,一开始 @rprx 根本不知道 Debian 那些普通人觉得过于挑剔的 policy,以「常识」去推测别人的规则,甚至不知道 Debian 打包有什么用。然而 Debian 打包者混迹于自由软件世界多了,也不会想到有开发者不知道 Debian 打包是在干什么,请求许可协议变更的时候没讲清楚。最终造成了误解。
见证了一次自由软件世界与私有软件世界的冲突呢。
PS: 打符合 Debian policy 的包可复杂了,各种规则还没个好的文档,以至于我根本不想弄。
I think maybe v2fly should improve the building configuration that allows builders to easily select modules they need, and easily integrate proprietary modules. That would prevent similar events like this in the future.
@rprx @xiaokangwang
所以现在的事情是,v2ray因为有一部分私有代码,所以被要求所有代码都开源的Debian源拒绝了,是吗? 如果是这样的话,直接在协议里拒绝这种类型的要完全开放的源就好了,github release 最新版本统一,不用每个源都有不同的版本不是更好吗? v2ray这种类型的代码就是拼速度,慢了就被封了,就是要最新的啊! 我是直接github release,源里的都太旧了,又不会及时更新
@rprx 支持你,自己的私有代码怎么搞都行
我感觉最令人奇怪和愤怒的是,他是先要求你修改协议,被拒绝了才说要从源里移除。(感觉像威胁) 一般来说,你不符合规定,我先告知你规则是什么,违反了什么,将要做出什么的行动,而不是反过来 https://github.com/XTLS/Go/issues/9#issuecomment-723412711
如果他一开始说的是:
你好, Debian源要求所有的代码都是完全开放的,因为从V2ray新版本(4.31.3)后带有xtls,而xtls并不是完全开放的。 所以根据规定,我们不能打包新版本,并可能需要从源里删除V2ray。 在此告知,也希望找到一个workaround的办法,谢谢
那就完全不同了 也许他只是太心急?但这种沟通方式真的很难令人接受
所以现在的事情是,v2ray因为有一部分私有代码,所以被要求所有代码都开源的Debian源拒绝了,是吗? 如果是这样的话,直接在协议里拒绝这种类型的要完全开放的源就好了,github release 最新版本统一,不用每个源都有不同的版本不是更好吗? v2ray这种类型的代码就是拼速度,慢了就被封了,就是要最新的啊! 我是直接github release,源里的都太旧了,又不会及时更新
@rprx 支持你,自己的私有代码怎么搞都行
我也同意这种做法,分为两个分支,一个为v2ray主线,在github release。另一个分支为v2ray代码完全开源的那些部分,去除掉不开源的功能,提供debian软件包
所以现在的事情是,v2ray因为有一部分私有代码,所以被要求所有代码都开源的Debian源拒绝了,是吗? 如果是这样的话,直接在协议里拒绝这种类型的要完全开放的源就好了,github release 最新版本统一,不用每个源都有不同的版本不是更好吗? v2ray这种类型的代码就是拼速度,慢了就被封了,就是要最新的啊! 我是直接github release,源里的都太旧了,又不会及时更新 @rprx 支持你,自己的私有代码怎么搞都行
我也同意这种做法,分为两个分支,一个为v2ray主线,在github release。另一个分支为v2ray代码完全开源的那些部分,去除掉不开源的功能,提供debian软件包
这样当然最好 但是人家又不是收钱的,真的是不好意思叫别人这样做 这样做的话,开发者要维护两个版本,还要维持一致性,这样工作量太大了
而且在什么情况下会需要用到debian软件包之类的源去下载使用? 一种情况是在墙内没有任何工具联网,需要用源之类的东西做代替 但是在墙内下载这些,速度不是慢到无法忍受,就是下到一半就断线之类的吧,还是dead end 最后还是需要一个能正常联网的工具
如果要考虑所有的情况去做事的话,那将有庞大的工作, 而且对于不盈利的东西,最大的好处之一就是不用满足每一个使用者的要求
补充一句,我在朋友电脑安装这些的时候,墙内上github下载就从未成功过 不是4kb/s,就是下了两三个小时20%断线 还是要通过自己的服务器中转才能下回来 🤪
现在都有监测的,是这些就劣化你链接
补充一句,我在朋友电脑安装这些的时候,墙内上github下载就从未成功过 不是4kb/s,就是下了两三个小时20%断线 还是要通过自己的服务器中转才能下回来 🤪
墙内我一般是下载好然后上传到服务器上
补充一句,我在朋友电脑安装这些的时候,墙内上github下载就从未成功过 不是4kb/s,就是下了两三个小时20%断线 还是要通过自己的服务器中转才能下回来 🤪
墙内我一般是下载好然后上传到服务器上
对啊,墙内的话就是要用工具下好了才能用 鸡蛋问题,反正你都要有一个才能用
而且在什么情况下会需要用到debian软件包之类的源去下载使用? 一种情况是在墙内没有任何工具联网,需要用源之类的东西做代替
尊重作者的选择,但是想不明白为啥要让v2进各种源给自己戴上镣铐,至少身边所有人都用github的脚本安装和更新的 哪天要是真一点工具都没了,那也能用tor/i2p下吧...
@Yochee
根据我目前的了解,debian 应该是最严格的源,之前的确没人推动过 v2 进 debian,它是几个月前自己出现的,也很少人知道。
不过这里的事情更像是一个导火索,加上之前在一些事情上和团队里一些人意见有些分歧,发展到后面就是另一个矛盾了。
作为一个规避审查且需要随时更新的软件,只要本身源码公开可审查,不违反上游协议不就可以了,又不追求商业化,为什么要被各种开源协议绑住手脚。自由软件世界与私有软件世界的冲突在这类软件上没必要存在吧。 当然宽松的LICENSE确实能吸引更多人来维护,期待maintainer的xray-core及早上线,社区会用脚投票的。
不是真正的开源软件就把它剔出去呗,让它自己提供bin,或者第三方库。因为私有代码被t的还少吗?adobe flash player,nvidia 驱动……
首先,感谢作者的贡献。我觉得,作者对于LISNECE方面的知识不是很丰富,也不是很注重。所以,有需要的话可以咨询有经验的人,没需要的话是无所谓。但是LISNECE不管你在不在乎,它都是个正经的东西,和法律相关的东西。人们只会根据现行法规告诉你要么合法,要么违法,请你不要当成威胁,但你的确要承担相对后果。如果你相信法治的话,劝你花点心思好好想想选择何种证书,不是为了V2ray也不是为了Debian,而是为了你自己,开发也不是光考虑代码的问题,还有很多其他问题也是需要认真考虑的。
首先,感谢作者的贡献。我觉得,作者对于LISNECE方面的知识不是很丰富,也不是很注重。所以,有需要的话可以咨询有经验的人,没需要的话是无所谓。但是LISNECE不管你在不在乎,它都是个正经的东西,和法律相关的东西。人们只会根据现行法规告诉你要么合法,要么违法,请你不要当成威胁,但你的确要承担相对后果。如果你相信法治的话,劝你花点心思好好想想选择何种证书,不是为了V2ray也不是为了Debian,而是为了你自己,开发也不是光考虑代码的问题,还有很多其他问题也是需要认真考虑的。
首先你要考虑“违法”怎么定义,如果按中国的法律开发翻墙软件本身就是“违法”。而且因为项目的特殊性,rprxx事实上并不能获取任何法律支持。(License的问题早就解决了,剩下的问题与开源社区无关,可以散了)
首先,感谢作者的贡献。我觉得,作者对于LISNECE方面的知识不是很丰富,也不是很注重。所以,有需要的话可以咨询有经验的人,没需要的话是无所谓。但是LISNECE不管你在不在乎,它都是个正经的东西,和法律相关的东西。人们只会根据现行法规告诉你要么合法,要么违法,请你不要当成威胁,但你的确要承担相对后果。如果你相信法治的话,劝你花点心思好好想想选择何种证书,不是为了V2ray也不是为了Debian,而是为了你自己,开发也不是光考虑代码的问题,还有很多其他问题也是需要认真考虑的。
首先你要考虑“违法”怎么定义,如果按中国的法律开发翻墙软件本身就是“违法”。而且因为项目的特殊性,rprxx事实上并不能获取任何法律支持。(License的问题早就解决了,剩下的问题与开源社区无关,可以散了)
我猜 Debian的“法律问题”应该是规避一切可能导致被起诉的问题?所以对于License要求较为严格, 而本项目中的部分文件并没有使用开源许可证,可能有风险,所以才过来要求修改许可证的。
为了防止别人成为破娃,首先自己成为破娃……这一手操作秀到我了。 🤣
破娃的争议是在于他对上游没有一点贡献。而rprxx对core的贡献都是有目共睹的,分家是最后的结果而不是开始的目的。(xtls被移除是因为团队内部矛盾,而不是授权问题)
为了防止别人成为破娃,首先自己成为破娃……这一手操作秀到我了。 🤣
现在的结果是改协议为MPL,fork出来一个带XTLS的内核进行维护,同时还有一个新的推翻重来的Xray-Next在准备开发(与v2ray无关),这是啥破娃,别带节奏了
为了防止别人成为破娃,首先自己成为破娃……这一手操作秀到我了。 🤣
现在的结果是改协议为MPL,fork出来一个带XTLS的内核进行维护,同时还有一个新的推翻重来的Xray在准备开发(与v2ray无关),这是啥破娃,别带节奏了
这不是本末倒置了吗,最根本的问题:
V2ray最主要/核心的目标/目的是什么? 就是为了越过GFW,那为了达到这个目标,所有的技术都应该是可选择的,而且应该选择最有可能达到目标的方向。 其他次要目标不应与主要目标相违背,如果是,那应该是次要目标围绕这主目标改变,而不是反过来
回到V2ray,Xtls是目前最有发展潜力的,针对最主要的目标(翻墙)来说 而其他的次要目标,如这次的协议问题,那是应该为项目的主要目标做workaround
所以,如果有人需要一个协议是完全开放的,那就应该在V2ray项目的基础上frok出去, 然后在这个分支里,只使用完全开放的代码 那样,就可以既不和主目标冲突的情况下,实现这个次要目标 现在这种情况就是所谓的本末倒置了
As a redhat related developer, I would like to give my 2 cents here.
First of all, @rprx is free to re-license his derivative work with any other licence, even with a proprietary one, given the original work is BSD-licensed. Re-licensing a BSD-licensed work is totally legimate and very common in the open source world. Simply because BSD licence allows you to do that, as long as you retain the original licences in given parts (see how Kotlin did it).
Secondly, @rogers0 's concern is reasonable. When @rprx stated "Only for compiling executables usage for now" in the licence, that implied this is a proprietary software, you can only compiling it but without the permission of modification, redisturbution, etc.. That means Debian simply cannot take your code and repackage it because "You Don't Allow Them to Do So", which seems not the authors' intention to me.
That's why @rogers0 kindly asks @rprx to "fix" the licence otherwise they cannot package it. I don't think that's a threatening (威胁) but the way open source works. Again, Debain is not allowed to package XTLS because of the "Only for compiling executables usage for now" statement.
Thridly, I am not judging @rprx 's refusal to change in the first place. He is free to do whatever he perfers. The fuxk-it-debain-I-don't-care attitute is completely fine to me. But that just hurting V2ray users relies on debain packages, as the packages have to be removed from the debian repo.
Lastly, now that all the issues have been resolved. XTLS is completely removed from V2ray and release with a different fork called Xray under MPL licence. Although I am not sure that a good idea for both developers and users.
For developers, that means the people behind XTLS has to maintain another fork which claimed to be compatible with V2ray. That's a lot of work to keeping update with the upstream involving tons of merging, fixing conflicts etc.. It's not an easy job considering the already small V2ray/Xray teams.
For users, it's rather confusing. Most of them are already using V2ray and the transition from V2ray to Xray may never happen for them as long as V2ray still "works". That hurts the user base of XTLS a lot in the first place. We have to admit that the amount of user base means a lot to an open source project.
In short, I respect @rprx 's freedom to chose another licence he prefers. Although that would inevitabley leads to the partaway between XTLS and V2ray.
作为与Redhat相关的开发人员,我想在这里给我2美分。
首先,鉴于原始作品是BSD许可的,@ rprx可以自由地将其衍生作品与任何其他许可(即使是专有许可)一起重新许可。重新获得BSD许可的作品是完全合法的,并且在开源世界中非常普遍。仅仅因为BSD许可证允许您执行此操作,只要您将原始许可证保留在给定的部分中即可(请参阅Kotlin的做法)。
其次,@ rogers0的关注是合理的。当@rprx在许可证中声明“仅用于编译当前使用的可执行文件”时,表明该软件是专有软件,您只能对其进行编译,但未经修改,重新发行等许可。这意味着Debian根本无法接受您的代码。并重新包装它,因为“您不允许他们这样做”,这似乎不是作者对我的意图。
这就是为什么@ rogers0请@rprx来“修复”许可证,否则他们将无法打包许可证。我认为这不是威胁,而是开源的工作方式。同样,由于“仅用于编译可执行文件的用法”语句,不允许Debain打包XTLS。
第三,我并不是在判断@rprx首先拒绝更改。他可以自由地做自己想做的事。不用担心,我不需要理会服装。但这只是伤害了V2ray用户,它依赖debain软件包,因为必须从debian存储库中删除软件包。
最后,现在所有问题都已解决。XTLS已从V2ray中完全删除,并使用MPL许可下的另一个名为Xray的分支发布。尽管我不确定这对开发人员和用户都是一个好主意。
对于开发人员来说,这意味着XTLS背后的人们必须维护另一个声称与V2ray兼容的分支。要保持与上游的更新(涉及大量合并,修复冲突等),需要进行大量工作。考虑到已经很小的V2ray / Xray团队,这并不是一件容易的事。
对于用户而言,这相当令人困惑。他们中的大多数人已经在使用V2ray,并且只要V2ray仍在“起作用”,从V2ray到Xray的过渡可能永远不会发生。首先,这极大地损害了XTLS的用户基础。我们必须承认,用户数量对于一个开源项目而言意义重大。
简而言之,我尊重@rprx选择他喜欢的另一个许可证的自由。尽管这不可避免地导致XTLS和V2ray之间的分离。
在core中移除xtls不仅仅只是授权问题,是v2ray选择移除xtls,而非许可证不兼容。
作为与Redhat相关的开发人员,我想在这里给我2美分。 首先,鉴于原始作品是BSD许可的,@ rprx可以自由地将其衍生作品与任何其他许可(即使是专有许可)一起重新许可。重新获得BSD许可的作品是完全合法的,并且在开源世界中非常普遍。仅仅因为BSD许可证允许您执行此操作,只要您将原始许可证保留在给定的部分中即可(请参阅Kotlin的做法)。 其次,@ rogers0的关注是合理的。当@rprx在许可证中声明“仅用于编译当前使用的可执行文件”时,表明该软件是专有软件,您只能对其进行编译,但未经修改,重新发行等许可。这意味着Debian根本无法接受您的代码。并重新包装它,因为“您不允许他们这样做”,这似乎不是作者对我的意图。 这就是为什么@ rogers0请@rprx来“修复”许可证,否则他们将无法打包许可证。我认为这不是威胁,而是开源的工作方式。同样,由于“仅用于编译可执行文件的用法”语句,不允许Debain打包XTLS。 第三,我并不是在判断@rprx首先拒绝更改。他可以自由地做自己想做的事。不用担心,我不需要理会服装。但这只是伤害了V2ray用户,它依赖debain软件包,因为必须从debian存储库中删除软件包。 最后,现在所有问题都已解决。XTLS已从V2ray中完全删除,并使用MPL许可下的另一个名为Xray的分支发布。尽管我不确定这对开发人员和用户都是一个好主意。 对于开发人员来说,这意味着XTLS背后的人们必须维护另一个声称与V2ray兼容的分支。要保持与上游的更新(涉及大量合并,修复冲突等),需要进行大量工作。考虑到已经很小的V2ray / Xray团队,这并不是一件容易的事。 对于用户而言,这相当令人困惑。他们中的大多数人已经在使用V2ray,并且只要V2ray仍在“起作用”,从V2ray到Xray的过渡可能永远不会发生。首先,这极大地损害了XTLS的用户基础。我们必须承认,用户数量对于一个开源项目而言意义重大。 简而言之,我尊重@rprx选择他喜欢的另一个许可证的自由。尽管这不可避免地导致XTLS和V2ray之间的分离。
在core中移除xtls不仅仅只是授权问题,是v2ray选择移除xtls,而非许可证不兼容。
I certainly don't have the full picture of what is going on. As a user and script maintainer, I just feel sad :disappointed_relieved: about the partaway.
在core中移除xtls不仅仅只是授权问题,是v2ray选择移除xtls,而非许可证不兼容。
I certainly don't have the full picture of what is going on. As a user and script maintainer, I just feel sad 😥 about the partaway.
Limited by the current v2ray framework,the UDP's performance is always a big problem, and rprx is planning to start a whole new project named Xray-Next to solve it, so, just give him some time, i think he won't let us down. And, v2ray team is also realizing another XTLS plan. Everything will be fine.
在core中移除xtls不仅仅只是授权问题,是v2ray选择移除xtls,而非许可证不兼容。
I certainly don't have the full picture of what is going on. As a user and script maintainer, I just feel sad 😥 about the partaway.
Limited by the current v2ray framework,the UDP's performance is always a big problem, and rprx is planning to start a whole new project named Xray-Next to solve it, so, just give him some time, i think he won't let us down. And, v2ray team is also realizing another XTLS plan. Everything will be fine.
Good to know. Again, really appreciate all the hard work and devotion every developers put in. Keep it up guys :wink:.
Wish everything will be fine.
所以现在的事情是,v2ray因为有一部分私有代码,所以被要求所有代码都开源的Debian源拒绝了,是吗? 如果是这样的话,直接在协议里拒绝这种类型的要完全开放的源就好了,github release 最新版本统一,不用每个源都有不同的版本不是更好吗? v2ray这种类型的代码就是拼速度,慢了就被封了,就是要最新的啊! 我是直接github release,源里的都太旧了,又不会及时更新
@rprx 支持你,自己的私有代码怎么搞都行
我感觉最令人奇怪和愤怒的是,他是先要求你修改协议,被拒绝了才说要从源里移除。(感觉像威胁) 一般来说,你不符合规定,我先告知你规则是什么,违反了什么,将要做出什么的行动,而不是反过来 #9 (comment)
如果他一开始说的是:
你好, Debian源要求所有的代码都是完全开放的,因为从V2ray新版本(4.31.3)后带有xtls,而xtls并不是完全开放的。 所以根据规定,我们不能打包新版本,并可能需要从源里删除V2ray。 在此告知,也希望找到一个workaround的办法,谢谢
那就完全不同了 也许他只是太心急?但这种沟通方式真的很难令人接受
这是翻译问题吧。。。
debian 是唯一一个自由的发行版, 唯一一个不会受到美国出口限制的发行版 这是一个承诺问题, 一开始v2ray就表明了自己是一个开源软件, 然而作为后续维护者却在这个开源软件里加入私有软件导致v2ray不再被认为开源软件, 这破坏了v2ray开源使用者的信任
@shynome
我发现一个人有一个想法,有不同的出发点,很有趣。
现在是这样的情况,这类软件很多人需要,尤其是码农群体。但说到开发,来来去去就没几个人,没多少人愿意持续开发,要么就是转向闭源,例子就不举了。为什么会这样?因为开发这类软件完全是负收益:花很多脑力、时间,且不能有经济收入,有的是什么?有随时消失的风险。那么问题来了,如果再动不动就受到各种约束和随便哪个人的指责,还有人开发吗?
我也是真的烦了这些事情,随便一个人都能踩我一脚,真的是日了。 这个 issue,以及更深层次的问题已经通过分裂来解决了,若无必要就别再纠结了,非常影响心情。
debian 是唯一一个自由的发行版, 唯一一个不会受到美国出口限制的发行版 这是一个承诺问题, 一开始v2ray就表明了自己是一个开源软件, 然而作为后续维护者却在这个开源软件里加入私有软件导致v2ray不再被认为开源软件, 这破坏了v2ray开源使用者的信任
恕我无知,请教一下几个问题
debian 是唯一一个自由的发行版, 唯一一个不会受到美国出口限制的发行版 这是一个承诺问题, 一开始v2ray就表明了自己是一个开源软件, 然而作为后续维护者却在这个开源软件里加入私有软件导致v2ray不再被认为开源软件, 这破坏了v2ray开源使用者的信任
恕我无知,请教一下几个问题
- 这里“自由的发行版”的定义是什么,如果我没记错的话大部分发行版都是开源的吧,难道只是开源的话算不上“自由的发行版”吗?
- 这里“私有软件”的定义是什么, xtls 是以 mpl 开源的吧,必须与原项目许可证一样或是使用 bsd 才能不算是“私有软件吗”
自由软件和开源软件的区别可以看下. 对的 只是开源的话算不上“自由的发行版”, 像centos opensuse fodera都算不上自由的发行版, 都受到美国出口之类的限制
我的表述有不对的地方, 因为我只记得v2ray是一开始是以MIT协议宣传的, 所以上面说它是以开源作为口号宣传不是很好, 应该说它以自由软件的口号宣传自己 私有软件也是不对的, 我的意思是指污染了自由软件自由的事物
@SekiBetu 我知道现在是自由软件了啊, 我只是在想没有利益你会做这件事? 怎么把自己说的是个受害者一样? 信仰就不是利益了?
@SekiBetu 我知道现在是自由软件了啊, 我只是在想没有利益你会做这件事? 怎么把自己说的是个受害者一样? 信仰就不是利益了?
极端开源主义不可取,尊重他人的想法很重要,世界上不应该只存在一种开源协议
debian 是唯一一个自由的发行版, 唯一一个不会受到美国出口限制的发行版 这是一个承诺问题, 一开始v2ray就表明了自己是一个开源软件, 然而作为后续维护者却在这个开源软件里加入私有软件导致v2ray不再被认为开源软件, 这破坏了v2ray开源使用者的信任
维护者已经分裂了 用户群也分裂了 再来纠缠我觉得只自讨没趣 圈地自萌不好吗
debian 是唯一一个自由的发行版, 唯一一个不会受到美国出口限制的发行版 这是一个承诺问题, 一开始v2ray就表明了自己是一个开源软件, 然而作为后续维护者却在这个开源软件里加入私有软件导致v2ray不再被认为开源软件, 这破坏了v2ray开源使用者的信任
恕我无知,请教一下几个问题
- 这里“自由的发行版”的定义是什么,如果我没记错的话大部分发行版都是开源的吧,难道只是开源的话算不上“自由的发行版”吗?
- 这里“私有软件”的定义是什么, xtls 是以 mpl 开源的吧,必须与原项目许可证一样或是使用 bsd 才能不算是“私有软件吗”
自由软件和开源软件的区别可以看下. 对的 只是开源的话算不上“自由的发行版”, 像centos opensuse fodera都算不上自由的发行版, 都受到美国出口之类的限制
我的表述有不对的地方, 因为我只记得v2ray是一开始是以MIT协议宣传的, 所以上面说它是以开源作为口号宣传不是很好, 应该说它以自由软件的口号宣传自己 私有软件也是不对的, 我的意思是指污染了自由软件自由的事物
上纲上线?v2ray啥时候宣传过自己了?你不觉得你过分了吗?Debian源不是官方加进去的,上来就戴帽子。翻陈年旧账有意思?我倒看不懂你的目的了,是为了满足自己的精神洁癖?
@KyonCN @guanhemeng 嘚, 你们爱做啥做啥, 我管不着也懒得管, 各有各的目标群, 各安天命吧
@SekiBetu 说实在的如果没有这些自由软件斗士, 我今天可能都不会在这里和你说话, 这里的大部分人也许都成不了开发者. 但这些都没有意义, 因为现在就 "足够" 好了
@SekiBetu 说实在的如果没有这些自由软件斗士, 我今天可能都不会在这里和你说话, 这里的大部分人也许都成不了开发者. 但这些都没有意义, 因为现在就 "足够" 好了
NGL,从我这几年的经历来看,自由软件斗士可真是个流氓群体,要把世界变为非黑即白的人,懂得都懂 程序员不拿工资写程序,后面的人拿着理想、自由的鞭子抽,换我我直接给你闭源了,给脸不要脸,什么毛病
那你闭源吧, 不对, 你压根就没有开源过
嘚, 你爱做啥做啥, 我管不着也懒得管, 各有各的目标群, 各安天命吧
@SekiBetu 说实在的如果没有这些自由软件斗士, 我今天可能都不会在这里和你说话, 这里的大部分人也许都成不了开发者. 但这些都没有意义, 因为现在就 "足够" 好了
NGL,从我这几年的经历来看,自由软件斗士可真是个流氓群体,要把世界变为非黑即白的人是怎样的人?懂得都懂。 程序员不拿工资写程序,后面的人拿着理想、自由的鞭子抽,换我我直接给你闭源了,给脸不要脸,什么毛病
题外话: 个人理解的open source=open source code +使用许可,却需要一个OSI组织来 ~钦点~ 认证一个协议是不是开源的,这个组织甚至把SSPL列入了非开源协议,为什么,因为开源在OSI的定义里面第一条就是你的代码必须可以在商业用途被使用且不能收取任何费用,不然这个协议是无法通过审核的(你不仅要open source,还要额外提供商业用途的许可),是不是很眼熟:
so this becomes not open source anymore.
当然,这只是我对OSI的偏见,事实上大众所定义的开源并不是字面意思的开源,而是OSI这个组织所规定的符合一系列 Debian Free Software Guidelines (DFSG) 条件的"开源"。 开源已经变成集权组织所控制的东西了,所以就是个游戏而已,别太当真了
Debian 要求 OSI 認證過的授權是個無奈之舉,他必須保護自己來規避可能面臨的法律問題。 對於一個好幾張 DVD 才能完整收錄的發行版來說,這是有必要的。 否則,耗費心力去一個一個審查各種授權,需要相當高的成本。 至少,它得找一狗票的律師來研究審查相關的授權以及各國法律,勞民傷財(這些錢拿去給攻城獅買肥宅快樂水不好嗎?)。
法律、條款這些都是方便主義,怎麼方便怎麼來,差不多能達成目的就好,而 DFSG 主要目的就是為了「省事的保護整個 Debian」。 想要讓自己的東西被 Debian 收錄就 follow 它、作者認為無所謂當然也就無所謂了。
而 @rprx 選擇使用 OSI 以外的授權來發布他的成果也是作者的個人自由(至少,並不超出上層授權範圍)。
我個人是不知道其他地方有沒有針對本議題的討論,不過這個 issue 看下來是覺得大家都情緒化了。 雙方的出發點不同、得到的結論當然也就不同,遺憾的是沒能得出一個廣泛認同的最佳解而已。
希望無論如何大家都能相互理解,理解萬歲 :-D
作为一个非软件行业从业者,我也发表一下我个人的看法:
翻墙对我个人来说是一个硬需求,从最早的 GoAgent、寻找可用 IP、修改 DNS,到后来的 shadowsocks、VMess、VLESS,我选择这些工具的理由无非是——它是否能够突破GFW越来越高的封锁解决我的上网问题。
对于每个有翻墙需求的人来说,「可用性」永远是第一位的。安全性、是否开源、是否符合开源协议等等,这些都要排在后面。
开源翻墙软件(工具/协议,我混着说吧,反正意思大家都懂)永远处在劣势的位置,因为技术细节可查,分散的「民间」资源提供有限的支持,还在中国「违法」;而 GFW 永远处于强势的位置,有强大的国家机器提供资金、人员、技术、设备等等全方位碾压式的支持。
为什么我很反感上面很多人一再强调是否符合开源协议? 因为确实如上面有人提到的,揪着协议不放这就是本末倒置。
据我说知,最新的 VLESS、XTLS 协议还处于公测阶段,还在发展和优化,很多人一上来就炮轰作者,我作为一个外行是想不明白的,不是先把这个东西弄好了,能够非常好地对抗 GFW 的封锁,再考虑其它?
为什么做事情之前,要先给自己套上一层层的镣铐?
**我觉得事情的优先顺序应该是这样的:
首先,发展和优化现有工具和协议,达到可以放开普及的程度; 其次,考虑安全性、开源性、协议完备性、普通用户使用的简易性……**
最新的 VLESS + XTLS 组合不仅让我摆脱了不能上网的困境(之前使用 shadowsocks),还大幅提高了翻墙上网速率(差不多翻倍),除了客户端工具支持不完善,我觉得「破网」这件事情已经做得很漂亮了!
最后,感谢作者 @rprx 的付出。
开源的规则就是规则,这应该遵守。debian制订这些规则有它的考虑,维护debian包的个人也希望按规则办事。
对于分家,深表可惜。凝聚成一个拳头,未来可期。
作为一个非软件行业从业者,我也发表一下我个人的看法:
翻墙对我个人来说是一个硬需求,从最早的 GoAgent、寻找可用 IP、修改 DNS,到后来的 shadowsocks、VMess、VLESS,我选择这些工具的理由无非是——它是否能够突破GFW越来越高的封锁解决我的上网问题。
对于每个有翻墙需求的人来说,「可用性」永远是第一位的。安全性、是否开源、是否符合开源协议等等,这些都要排在后面。
开源翻墙软件(工具/协议,我混着说吧,反正意思大家都懂)永远处在劣势的位置,因为技术细节可查,分散的「民间」资源提供有限的支持,还在中国「违法」;而 GFW 永远处于强势的位置,有强大的国家机器提供资金、人员、技术、设备等等全方位碾压式的支持。
为什么我很反感上面很多人一再强调是否符合开源协议? 因为确实如上面有人提到的,揪着协议不放这就是本末倒置。
据我说知,最新的 VLESS、XTLS 协议还处于公测阶段,还在发展和优化,很多人一上来就炮轰作者,我作为一个外行是想不明白的,不是先把这个东西弄好了,能够非常好地对抗 GFW 的封锁,再考虑其它?
为什么做事情之前,要先给自己套上一层层的镣铐?
**我觉得事情的优先顺序应该是这样的:
首先,发展和优化现有工具和协议,达到可以放开普及的程度; 其次,考虑安全性、开源性、协议完备性、普通用户使用的简易性……**
最新的 VLESS + XTLS 组合不仅让我摆脱了不能上网的困境(之前使用 shadowsocks),还大幅提高了翻墙上网速率(差不多翻倍),除了客户端工具支持不完善,我觉得「破网」这件事情已经做得很漂亮了!
最后,感谢作者 @rprx 的付出。
我认为技术细节可查并不算劣势,防火墙的维护者在审查了源代码后仍不能封锁该协议才能证明该协议是相当可靠的。
@SekiBetu 我知道现在是自由软件了啊, 我只是在想没有利益你会做这件事? 怎么把自己说的是个受害者一样? 信仰就不是利益了?
极端开源主义不可取,尊重他人的想法很重要,世界上不应该只存在一种开源协议
我认为到处批判开源软件不够自由的人应该叫“极端自由主义者”。开源这个词我一直当成开放源代码来理解,rprx写的协议显然也可以说是开源协议。
不过你抨击自由软件的观点我并不认同,因为要是没有那么多自由软件,上班的时候想抄代码就没那么好抄了。
debian 是唯一一个自由的发行版, 唯一一个不会受到美国出口限制的发行版 这是一个承诺问题, 一开始v2ray就表明了自己是一个开源软件, 然而作为后续维护者却在这个开源软件里加入私有软件导致v2ray不再被认为开源软件, 这破坏了v2ray开源使用者的信任
恕我无知,请教一下几个问题
1. 这里“自由的发行版”的定义是什么,如果我没记错的话大部分发行版都是开源的吧,难道只是开源的话算不上“自由的发行版”吗? 2. 这里“私有软件”的定义是什么, xtls 是以 mpl 开源的吧,必须与原项目许可证一样或是使用某特定许可证才能不算是“私有软件”吗
rprx一开始使用的协议应该算是私有软件开源协议,但并不影响他是开源协议。不过因为他的性质属于私有,所以就不算自由软件。不是非要一起打包进debian的话就没必要纠结这个问题,因为对于普通用户来说这些协议根本不重要。就算退一步讲,协议影响了用户自行修改源代码来优化或者提交PR,那用户自己私下悄悄改不进行分发就好了。
@SekiBetu 我知道现在是自由软件了啊, 我只是在想没有利益你会做这件事? 怎么把自己说的是个受害者一样? 信仰就不是利益了?
极端开源主义不可取,尊重他人的想法很重要,世界上不应该只存在一种开源协议
我认为到处批判开源软件不够自由的人应该叫“极端自由主义者”。开源这个词我一直当成开放源代码来理解,rprx写的协议显然也可以说是开源协议。 不过你抨击自由软件的观点我并不认同,因为要是没有那么多自由软件,上班的时候想抄代码就没那么好抄了。
自由软件大多数是有收益的,不是免费开源的,给你抄是有钱赚的,抄着抄着,诶,安卓市场占有量就起来了,我给你默认植入GMS,你不听话,给你GMS去了
对于用户和抄的人来说是免费,GMS这个属于安卓生态问题。AOSP并不内置GMS,而且AOSP发行版没有得到Google授权也不允许内置GMS。
内置GMS都是厂商主动去找Google要授权的。
@SekiBetu 我知道现在是自由软件了啊, 我只是在想没有利益你会做这件事? 怎么把自己说的是个受害者一样? 信仰就不是利益了?
极端开源主义不可取,尊重他人的想法很重要,世界上不应该只存在一种开源协议
我认为到处批判开源软件不够自由的人应该叫“极端自由主义者”。开源这个词我一直当成开放源代码来理解,rprx写的协议显然也可以说是开源协议。 不过你抨击自由软件的观点我并不认同,因为要是没有那么多自由软件,上班的时候想抄代码就没那么好抄了。
自由软件大多数是有收益的,不是免费开源的,给你抄是有钱赚的,抄着抄着,诶,安卓市场占有量就起来了,我给你默认植入GMS,你不听话,给你GMS去了
对于用户和抄的人来说是免费,GMS这个属于安卓生态问题。AOSP并不内置GMS,而且AOSP发行版没有得到Google授权也不允许内置GMS。
这就对咯,看懂这游戏怎么玩的了吧
问题在于GMS的事和安卓系统本身没有关系啊,GMS本身就是私有的,但是它好用。GMS又不是什么核心依赖,像这种私有套件都是需要用隐私换方便的用户比较依赖。
说白了整个手机只有系统是开源的,但是这个开源系统让用户体验得到了很大的提升。正是因为AOSP,即使手机厂商停止了对硬件的支持,用户也可以自行修改AOSP源代码来更新自己设备的系统。
GMS算是一个私有闭源软件套装,根本扯不上AOSP。如果谷歌没有开源安卓,那群魔乱舞的时候,用户的体验不是更差?
谷歌即使不开源安卓,也可以做一个合作伙伴计划,授权手机厂商使用安卓系统。(比如Windows phone)
一个类似的事,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
debian 是唯一一个免费的发行版,唯一一个不会接触美国出口限制的发行版, 这是一个承诺问题,一开始 v2ray 就证明了自己是一个开源软件,但在这个开源软件中加入智慧软件导致v2ray不再被接受公开软件,这破坏了v2ray开放读者的信仰
arch:??
一个中文 一个英文 语言博大精深啊
整篇看下来,有一个问题的答案没有看到: 为什么XRay的作者@RPRX选择了私有开源协议。也就是说,为什么不愿授权他人对代码的更改、使用及商业化。 协议的设置当然是作者的自由,但是任何的协议设置都有其背后的考虑和理由。那么这个考虑和理由是什么呢?
从突破墙限制的角度考虑,自由软件是有优势的。每一次的新软件、每一次的迭代(从v2ray到v2fly、从v2fly到xray、从trojan到trojan-go)都是或多或少的借助了自由软件的授权。这个授权保证了当原作者消失时,新的作者可以继续前者的项目;保证了当有人有新的想法时,可以高效的使用前人的代码来实现;也使得新的技术新的项目能够快速被商业化的机场、软件所使用(adoptation)。现在v2在很多机场普及的原因,其一就是自由软件。这样的普及使得更多的普通用户,甚至不懂怎么直接使用这些FQ项目的用户,能够因此受益。
从我能想到的理由看,@RPRX将XTLS做成私有代码可以帮助作者对使用代码的商业项目收取授权费(例如可以向ios shadowrocket收费)。那么这也无可厚非,大家都要吃饭,也不是什么不道德的事情。如果是这个考虑,大可以大方讲出来。如果是这样,那么其实可以把XTLS做成一个v2fly的插件的形式,由用户自由安装。毕竟目前XRAY的文档维护就差了v2fly一大截,而且是XRay本身也是在使用v2fly的代码。这么做的好处,一是v2fly的实用使用方面的自由度更高,二是XTLS也可以被作为其他项目的插件使用,利于更多的盈利。 当然这些都是一些猜测和设想,未必与事实相符。 但是我看下来,争论的主要原因,其实是@RPRX一直没有讲,为什么要坚持这个私有开源协议不改成自由软件协议;或者说,为什么对于其他开发者要求改成自由软件协议这件事,情绪上反应比较大。 事情讲清楚了,未必能一定解决问题,但是大部分时候,都能让大家理解,不产生不必要的情绪主导的矛盾。
我是检索两者区别无意中看过来的。作者的代码授权自然是由作者全权决定,旁人只能提建议。而自己的“孩子”只让自己“带大”这种心情我很能理解,不过就此分裂有点过激了,在我看来有一丢丢情绪在里边。楼上有个建议是弄成插件,我觉得可以呀。就算收费也是名正言顺的,让出力的人得到回报是非常道德的一件事,尽管作者可能并非此意。
btw: 我还是头一次看到英文和中文争得面红耳赤,而且互相能感受到语气和情绪……
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!