有谁知道iText的分叉?

Yis*_*hai 45 java pdf itext

现在iText已经走了AGPL,我假设有人会采用旧的(2.1.7或4.2.0)代码并将其分叉以保持LGPL版本的运行.有没有人知道这样的叉子已经开始了?

小智 79

似乎有某种意义,想要使用或继续使用LGPL版本是对布鲁诺的个人冒犯.

人们采用图书馆这一事实怎么样,因为它首先是LGPL?现在,包名称和许可证的更改应该是可以的,我们应该闭嘴并使用它.这就是所谓的诱饵和开关.

布鲁诺可以按照自己的意愿行事,这个男人想要一些钱来做他的努力是可以理解的.如果这是将他的工作货币化的最佳方式,那么他应该这样做.但是,这并不能使那些想要使用原始LGPL版本pariah并希望继续使用该许可代码库的分支的人并不讨厌.


Mar*_*rer 15

您的请求存在许多问题:

  • 可以维护iText分支的人员名单相当短.我碰巧是其中之一.;)
  • 能够维持iText分叉并且愿意接受Bruno努力最终从iText赚钱的人员名单(到目前为止)为零.我当然不是其中之一.

因此,有很多人会喜欢他们的商业应用程序的一些免费(小'f')代码.他们可以使用2.1.7并处理任何错误(以及在itext邮件列表上的冷落),单独行动,分享他们的来源或支付一些钱.

(是的,我意识到维持MPL分叉的虚伪,同时鼓励其他人捏起一些面团.我试图用自己的公司做到这一点,但到目前为止我的努力还没有结果.)

  • 我确实试图进入"掏钱"的方向也是为了弥补布鲁诺的努力.但是,一个小型初创公司的报价甚至没有包括任何支持,远远超出我的预期(单个服务器的最低价格超过2000美元).所以我改变了主意,我认为应该支持一个分叉只是因为99%的客户价格不合理.他们只为那些真正需要大量使用它的大公司提供服务. (53认同)

Yis*_*hai 6

我在博客中讨论了iText AGPL许可证的一些实际问题(从我的SO资料中链接).为什么不直接购买IText?它当然是许多商业PDF库中的一个选项,尽管它们确实需要在竞争中标准化它们的定价.

事实上,我过去从未真正使用过iText.它总是要么缺少某些功能,要么API比其他(非自由)替代方案要困难得多,尤其是对于最小的PDF操作(例如,而不是生成报告所需的PDF操作级别) .

此时,我所知道的唯一获得同等许可的PDF库是ICEPdf,它是MPL 1.1许可证下的,但其商业模式是拥有更多限制版本并收取更多高级功能(例如更多字体支持).

  • 您必须“请求报价”以甚至考虑价格这一事实是荒谬的。 (2认同)