gifsicle 协议冲突

[seven332]

Nimingban 中所使用压缩 gif 图片的工具 gifsicle 是以 gpl 2.0 协议发布的，而 Nimingban 的协议为 Apache 2.0，两者相矛盾。由于 Nimingban 使用了诸多以 Apache 2.0 协议发布的库，所以难以转为 gpl 2.0。

目前我想到两个解决方法：

1. 发布的 apk 文件中不包括由 gifsicle 源文件编译而成的 so 文件，而由用户手动选择下载；
2. 寻找其他压缩 gif 图片的工具。

[seven332]

https://github.com/ibaaj/awesome-gif

[seven332]

若是仅包括并调用 gpl 可执行文件，并不要求项目为 gpl。故需恢复之前状态，集成可执行程序并通过 Runtime.getRuntime().exec(params) 调用。同时需要 fork 一个 gifsicle，并添加 Android.mk。

[seven332]

修改后的项目地址 https://github.com/seven332/gifsicle/tree/android

[Artoria2e5]

同时需要 fork 一个 gifsicle，并添加 Android.mk。

问题是原版 gifsicle 本来就是单独的默认静态的命令行程序啊……硬改出 so 折腾 JNI 不是和自己过不去吗。（顺便既然都想用命令行了，干脆安利一下 giflossy 这个支持高效有损压缩的改版吧（注意用 git HEAD）。）

[seven332]

这问题恐怕没有这么简单。 首先编译脚本也是项目的一部分，没有这个就无法编译，所以我觉得这个也要遵循 gpl。 其次 Android 有多个 abi，也就是要编译多份可执行文件供不同指令集的处理器使用，这样一来到底选择哪个可执行文件就是个问题了，我的解决方法是将可执行文件的文件名改成动态链接风格，并放在动态链接目录里让系统自动选择。 最重要的是 pie 问题，Android 6 开始，所有的可执行文件编译时强制要求加入 pie 参数，而 pie 参数仅从 Android 4.1 开始支持。Nimingban 所支持的系统是 Android 4.0 至 Android ∞，这就意味着我要单独为 Android 4.0 弄一个可执行文件，这会使得最终 apk 文件体积增大不少。我的解决方法是将原 gifsicle 编译成动态链接库，再上一个可执行文件的壳，壳体积会很小，所以弄两个也没太大影响。

fork的项目地址 https://github.com/seven332/gifsicle/tree/android

[seven332]

lossygif 看起来要厉害些

[Artoria2e5]

而 pie 参数仅从 Android 4.1 开始支持

linker 坑爹啊，唔。话说 PIE 其实就是带 main() 的 so，嘛反正那就这样吧。

首先编译脚本也是项目的一部分，没有这个就无法编译，所以我觉得这个也要遵循 gpl。

实现某个功能无法避免的日常代码我记得不在美国版权法管的范围内。

lossygif

就是查 LZW 字典的时候允许像素颜色有些偏差的那种意思。

[seven332]

协议这东西涉及法律，细节方面我就弄不清楚了，总之我放源码，作者不找我麻烦就行了，刺儿头也没办法找我麻烦。