使用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代码”的要求。

评论

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套源码又愿意用这种无聊的东西来浪费时间，也随便你

2 楼 csf178 2008-05-08  

出现了一个准备钻空子的 哈哈
这样是不行滴

1 楼 hax 2008-05-07  

这两个问题是没有直接关系的。