日期:2014-05-16  浏览次数:20378 次

使用ext-2.1,将js文件压缩是否违反GPL协议。
给js加上GPL协议似乎没有必要,用户浏览网页的时候,所有js源码都会下载到客户机解释执行。不过为了减少网络开销,咱们一般要在系统发布时对所有js进行压缩,去掉注释,去掉无用的空白,甚至对局部变量名进行混淆。这种压缩方式从某种意义上起到了源代码加密的功能,使js代码的可读性变差了,尤其是对局部变量名混淆这一步,让人们很难通过变量名去猜测该变量的功能。

其实还有一种方法,把js文件转换成eval的形式,但听说有性能问题。这种加密方式在网上随便就可以找到解密的脚本,将代码转换到“混淆局部变量”的阶段,所以咱们把这种当作“混淆局部变量”来讨论应该也没什么问题。

现在的问题是,如果使用了ext-2.1就需要将html和js依据GPL协议开源。如果只提供压缩后的js源代码,是否符合GPL协议。压缩后的js源代码也算是源代码的一种形式吧?

如果别人来索取源代码,我能不能声称:“有注释,未压缩的js是我们内部使用版本,不是发布版本,所以不使用GPL开源。”


问题重点在于,我是否可以只提供“压缩后的js代码”,我是否可以拒绝其他人索取“有注释,未压缩的js代码”的要求。
1 楼 hax 2008-05-07  
这两个问题是没有直接关系的。
2 楼 csf178 2008-05-08  
出现了一个准备钻空子的 哈哈
这样是不行滴
3 楼 chinata 2008-05-08  
xyz20003 写道
给js加上GPL协议似乎没有必要,用户浏览网页的时候,所有js源码都会下载到客户机解释执行。不过为了减少网络开销,咱们一般要在系统发布时对所有js进行压缩,去掉注释,去掉无用的空白,甚至对局部变量名进行混淆。这种压缩方式从某种意义上起到了源代码加密的功能,使js代码的可读性变差了,尤其是对局部变量名混淆这一步,让人们很难通过变量名去猜测该变量的功能。

其实还有一种方法,把js文件转换成eval的形式,但听说有性能问题。这种加密方式在网上随便就可以找到解密的脚本,将代码转换到“混淆局部变量”的阶段,所以咱们把这种当作“混淆局部变量”来讨论应该也没什么问题。

现在的问题是,如果使用了ext-2.1就需要将html和js依据GPL协议开源。如果只提供压缩后的js源代码,是否符合GPL协议。压缩后的js源代码也算是源代码的一种形式吧?

如果别人来索取源代码,我能不能声称:“有注释,未压缩的js是我们内部使用版本,不是发布版本,所以不使用GPL开源。”


问题重点在于,我是否可以只提供“压缩后的js代码”,我是否可以拒绝其他人索取“有注释,未压缩的js代码”的要求。


应该是可以,虽然这个如果人家要告你的话,处于灰色地带。
重要的是你必须证明这个代码是可以运行的,因此你必须提供编译或者使用说明(否则你怎么证明代码和源码一致呢?)
如果你在乎维护2套源码又愿意用这种无聊的东西来浪费时间,也随便你