@wevsty #5 TP 家官网上更新包一大堆，各种型号的都有，只不过基本都是修功能 bug 的，极少有功能升级的

@XIVN1987 #4 主要是体积贼小
至于难用这方面，配合一些纯 python 的开源库，可以做到极少代码生成 UI （非复杂类型）
最终用极小的体积实现了不小的功能

@refeng #25 因为它们藏起来的大多数食物会丢失、找不到、被抢被偷，再退一步讲那是人家活命的资源

@renmu123 #5
@stoneabc #4
你们说的应该是类似 LGPL 这样的，GPL 只要碰了就传染，甚至部分人的观点是，哪怕从套接字里流过的数据格式符合 GPL 程序中的独有格式，也算是“衍生”

@stoneabc #4
@renmu123 #5

https://zh.wikipedia.org/wiki/GNU%E9%80%9A%E7%94%A8%E5%85%AC%E5%85%B1%E8%AE%B8%E5%8F%AF%E8%AF%81#%E9%8F%88%E6%8E%A5%E5%92%8C%E6%B4%BE%E7%94%9F%E4%BD%9C%E5%93%81

链接和派生作品
争议：非 GPL 软件是否可以合法地链接或动态地链接到 GPL 库

据 FSF 称，“GPL 不要求您发布修改版本，或其任何部分，您可以自由地进行修改和留作私人使用，而无需发布。”然而若是向公众发布 GPL 许可的实体，则有链接的问题：换言之，“使用 GPL 库的专利程序是否违反了 GPL ？”

这个关键的争议的重点是“非 GPL 软件是否可以合法地链接或动态地链接到 GPL 库”。这个问题有不同的看法。GPL 清楚地表明，GPL 下的所有派生作品代码都必须属于 GPL 。关于使用 GPL 库和将 GPL 软件捆绑到更大的包中（可能通过静态链接混合成二进制文件），会出现歧义。这最终不是 GPL 本身的问题，而是著作权法如何界定派生作品。有以下观点存在
观点：动态和静态链接违反 GPL

自由软件基金会（其拥有若干著名的 GPL 软件产品和许可文字本身的著作权）声称，使用动态链接库的可执行档确实是派生作品。然而，这不适用于彼此通信的单独程序。自由软件基金会还创建了 LGPL，LGPL 与 GPL 极为相似，但额外允许以“使用库”为目的的链接。理查德·斯托曼和自由软件基金会特别鼓励库作者根据 GPL 来进行许可，以便专有程序无法使用 GPL 库，透过为自由软件世界提供比专有世界更多的工具来保护自由软件世界。
观点：静态链接违反 GPL，但动态链接则有待厘清

有些人认为，当静态链接产生派生作品时，不清楚动态链接到 GPL 代码的可执行档是否应被视为派生作品（请参阅 Weak Copyleft ）。Linux 作者 Linus Torvalds 同意动态链接可以创建派生作品，但在这种情况下不一致。一位 Novell 律师写道，动态链接不算是派生作品的观点合理但是不够明确，专有的 Linux 内核驱动程序就是善意的动态链接的一大明证。在 Galoob 对任天堂案中，美国第九巡回上诉法院将派生作品定义为具有“形式”或“永久性”，并指出“侵权作品必须以某种形式包含一部分受著作权保护的作品”，但是没有明确的法院裁决来解决这一特定的冲突。
观点：链接无关

根据 Linux Journal 的一篇文章，Lawrence Rosen （一次性开源计划总顾问）认为，链接的方法与一个软件是否是派生作品的问题大不相干; 更重要的是关于软件是否旨在与客户端软件和 /或库连接的问题。他指出：“新程序是否是派生工作的主要指示是原始程序的源代码是否以[复制粘贴方式]使用，以任何方式进行修改，翻译或以其他方式更改新程序，如果没有，那么我会认为这不是派生工作“，并行出了关于意图，捆绑和联动机制的许多其他观点。 他进一步在他公司的网站上论证，这种“以市场为基础”的因素比链接技术更重要。

还有一个具体问题是，一个插件或模块（如 NVidia 或 ATI 显卡内核模块）是否也必须是 GPL，如果它可以合理地被认为是自己的工作。这个观点表明，如果工作是 GPLv2，则可以根据任意许可证，为设计使用插件的软件提供合理的单独插件或插件。特别感兴趣的是 GPLv2 段落：
“ 您可以修改本程序或其任何部分的副本或副本，从而根据本程序形成工作，并根据上述第 1 节的条款复制和分发此类修改或工作，前提是您也符合所有这些条件：……

b ）您必须将您分发或发布的任何作品全部或部分包含或派生自本计划或其任何部分，根据本许可证的条款无偿授予所有第三方。 ...这些要求适用于整体修改后的工作。 如果该作品的可识别部分不是源自该程序，并且可以被合理地视为独立和独立的作品，则本许可证及其条款在将其作为单独作品分发时不适用于这些部分。 但是，当您分发相同的部分作为基于程序的工作的整体的一部分时，整体的分布必须符合本许可证的条款，其许可证持有人的权限将扩展到整个，和每个部分，无论谁写的。
”

GPLv3 有一个不同的条款：
“ 您可以根据第 4 节的条款，以源代码的形式传达基于本程序的工作，或从程序生成的工作，只要您也符合以下所有条件：……

c ）您必需根据本许可将整个作品整体许可给任何拥有副本的人。 因此，本许可证连同任何适用的第 7 条附加条款适用于整个工作及其所有部分，无论其包装方式如何。 本许可证不允许以任何其他方式许可该作品，但如果您已单独收到，则不会使该许可无效。……与其他单独和独立的作品的汇编，而不是其涵盖的作品的性质延伸，而不是与其组合，以形成更大的程序，在一个或多个如果汇编及其产生的著作权不被用于限制编辑用户的访问权限或合法权限超出个人作品允许的范围，则称为“汇总”。 合并中的被覆盖的工作不会导致本许可证适用于合并的其他部分。
”

作为一个案例研究，一些据称为 GPLv2 CMS 软件（如 Drupal 和 WordPress ）的专有插件和主题 /外观已经受到打击，双方均被采纳[62][63]

FSF 区分插件如何被调用。如果通过动态链接调用插件，并且它对 GPL 程序运行函数调用，那么它很有可能是派生工作。[64]
与非 GPL 程序的通信和绑妥

与其他程序通信的行为本身并不要求所有软件都是 GPL; 也不用 GPL 软件分发 GPL 软件。但是，必须遵循较小的条件，确保 GPL 软件的权利不受限制。 以下是 gnu.org 的 GPL FAQ，该常见问题解答介绍了允许软件与 GPL 程序进行通信和绑妥的程度：
“ Q：“合辑”（ Aggregate ）与其他类型的“修改版本”有什么区别？

A：“合辑”由多个单独的程序组成，分布在同一个 CD-ROM 或其他媒体上。GPL 允许您创建和分发合辑，即使其他软件的许可证是非自由的或 GPL 不兼容的。 唯一的条件是，您不能根据禁止用户行使每个计划的个人许可证授予他们的权利的许可证发布合并。

Q：两个单独的程序之间的区别在哪里，一个程序有两个部分？

A：这是一个法律问题，最终法官会决定。 我们认为适当的标准取决于通信机制（ exec，pipes，rpc，共享地址空间中的函数调用等）和通信的语义（哪些信息被互换）。如果模块包含在相同的可执行文件中，则它们在一个程序中被明确地组合。 如果模块设计为在共享地址空间中连接在一起运行，那么几乎肯定意味着将它们组合成一个程序。相比之下，管道（ pipe ）、接口（ socket ）和命令行参数是通常在两个独立程序之间使用的通信机制。 所以当它们用于通信时，模块通常是单独的程序。 但是，如果通信的语义足够亲密，交换复杂的内部数据结构，那么也可以将这两个部分合并成一个更大的程序。
”

因此，FSF 想在“库”和“其他程序”之间透过以下两种方式划清界线：1 ）信息交换的“复杂性（ complexity ）”和“亲密程度（ intamacy ）”； 2 ）信息交换的“机构（ mechanics ）“，而不是“语义（ semantic ）”。但让问题不明确，而又复杂的情况下，交由判例法来决定。

全文手滑，是 GPL 不是 GNU
全文手滑，是 GPL 不是 GNU
全文手滑，是 GPL 不是 GNU

好在大家都能看懂……

@ixiaohei #1 调用的是库

相比于 seafile 这样的，互有哪些长短？

@liu35118665 #40 减缓用户流失吧应该是

@Perry #3 鱼多好啊

@anaf #2 一步到胃暴露性癖

最简单的办法就是装个火绒
windows 要求系统中有个安全软件
那你就给它一个

@x86 #16 这 B 站舞蹈区露一辈子骚不过油管上的“年龄限制”类内容啊

草，才发现挖坟了

上面有笔误，以高为基准是-2:1440，以宽为基准是 2560:-2

-vf scale=用的没错，不过建议把 -1: 改成 -2:
-2 能保证伸缩后的边长是 2 的倍数
因为不少编码器不支持奇数的边长，要求偶数
搞不好还有要求是 4 的倍数的（这是我猜的）
总之 -1 换成 -2 基本可以满足绝大多数情况

如果你不是批量跑，其实也可以计算器算好了手动制定 -s 2560x1440 （举例）
批量跑，不确定源分辨率，有需要自动保持画面比例，那就 -vf scale=-2:1440
-2:1440 表示伸缩时以高为基准，宽会以高为基础保持比例调解
也可以以宽为基础，那就是 -2:1440

其实 scale 保持比例自动伸缩的话是分 4 种情况的：
以长边为基准，以短边为基准
而在横屏和竖屏下宽高长短的关系正好对调
所以是 4 种情况
如果只缩不伸的话，还要先判断一下分辨率有没有超过
你不需要全自动话，就不用考虑这么复杂

我自己用 python 写了 ffmpeg 的封装脚本，主要是满足自用需求
https://github.com/mo-han/mo-han-toolbox#wrapffmpeg-aliases-ffmpeg-ff
里面包含了全自动的输出画面按比例缩小
目前只有两挡：缩小到全高清 1920x1080 以内，和高清 1280x720 以内
因为我自己平常不输出全高清以上的分辨率，所以没有写更高分辨率的情况
但是代码很简单，可以很容易加上
我这就去加上

试试非硬件加速的编解码器看还会不会这样

我自己拿 python 写的脚本 mykit.py
https://github.com/mo-han/mo-han-toolbox/blob/master/mykits/mykit.py
可以手动制定源文件，也可以缺省从剪贴板获取源
既支持单个源文件、多个源文件，也支持源目录（搜索目录下所有视频文件）


批量转换成.mp4 的功能我还没加进去，但是很好弄
这个脚本是通过预设的关键字采用对应参数的
比如我自己常用的 mykit ff -k smallhd，其实是 -crf 25 -c:v hevc，并且把输出分辨率缩小到内切 1280x720

指定输出文件格式确实是个有必要的功能，我这就去加个 mp4 的关键词