itext mentions on its website (http://itextpdf.com/AGPL ): "The AGPL license comes with the following restrictions. The points below are not exhaustive, but merely the most important restrictions: You may not deploy it on a network without disclosing the full source code of your own applications under the AGPL license. You must distribute all source code, including your own product and web-based applications. You must disclose any modifications made to iText.You must prominently mention iText and include the iText copyright and AGPL license in output file metadata. " It is questionable that imposing such output restriction is permissable as a restriction, however the more troubling part is "You can be released from the requirements of the license by purchasing a commercial license. Buying such a license is mandatory as soon as you develop commercial activities involving the iText software without disclosing the source code of your own applications. These activities include: offering paid services to customers as an ASP, serving PDFs on the fly in a web application, shipping iText with a closed source product." This is certainly additional restrictions compared to AGPL which is not reflected in the ebuild LICENSE="AGPL-3". Discussion found at https://lists.fedoraproject.org/pipermail/legal/2011-June/001656.html
I don't see this as additional restrictions (which would not be allowed by clause 7 of the AGPL) but merely as a comment. Their license header clearly says: "This program is free software; you can redistribute it and/or modify it under the terms of the GNU Affero General Public License version 3 [...]"
/var/tmp/portage/dev-java/itext-5.5.4-r2/work/source/com/itextpdf/text/LICENSE.txt: In accordance with Section 7(b) of the GNU Affero General Public License, a covered work must retain the producer line in every PDF that is created or manipulated using iText. You can be released from the requirements of the license by purchasing a commercial license. Buying such a license is mandatory as soon as you develop commercial activities involving the iText software without disclosing the source code of your own applications. These activities include: offering paid services to customers as an ASP, serving PDFs on the fly in a web application, shipping iText with a closed source product.
Debian discussed this issue in thread at https://lists.debian.org/debian-legal/2011/03/msg00010.html
To be clear, this only goes to the :5 slot, the older branch is GPL
There are some ways around this. The developers of iText worked on a 4.x branch that they never released. It's the same exact licensing as 2.x that's in portage. It looks like they changed license and released it as iText 5. However, the 4.2.0 branch remained, so people forked it. This has a lot of bug fixes over the 2.x branch and should be a drop in replacement, but I need to test this theory as there may be some changes that make it incompatible, which may or may not be easy to fix. However, iText version 5.0 breaks binary compatibility by changing package names from com.lowagie to com.itextpdf. To make a program that wants iText 5 to be compatible with iText 4.2, then just replace itextpdf with lowagie in the programs source code. Or, by having iText 4.2.0 code patched to change the names from lowagie to itextpdf and call it something like itext5-compat, or whatever, I'm tired. :P The license says that the source code to a program that uses iText 5 needs to be available, so I don't think there will be a pre-compiled binary case for having the itext5-compat layer. The original upstream code in the pure form is forked here, so no updates: https://github.com/ymasory/iText-4.2.0 There is a bug fix version that needs BouncyCastle and PDFRender depends (which are not in portage) here: https://github.com/kulatamicuda/iText-4.2.0 NOTE: I think there is still an ANT build for this, but this is where they start adding in Maven, and this is no longer worked on. However, the third option is the new fork that is currently in development, is LibrePDF. There is no ANT build, but it maintains compatibility with 4.2.0, thus also the 2.x versions of iText. Also, it needs BouncyCastle and PDFRender which are not in portage. If this works with all programs needing iText 2.x and 5.x then iText can be completely removed from portage since 2.x will not receive bug fixes or future java version compatibility. I want to create an ebuild for LibrePDF and test with all things needed iText, but I first need to learn how to use java-minimal things. Unless someone wants to help me. The port can be found here: https://github.com/LibrePDF/OpenPDF Personally, if LibrePDF/OpenPDF can work out with everything, then it is the right way to go since it is being developed, where as the first two forks are no longer active. Also, the LibrePDF version is more modular, with things that may not be needed broken out, so it can be use flag controlled. Note: This affects me as TuxGuitar needs iText 5, so I need to try to make it compatible with the decision of this bug report.
Any update from maintainers on this issue?
Yes, Jon kindly completed his ebuild work this week. I shall try to get it into the tree this weekend and I'll see whether OpenPDF works as a replacement for all the revdeps.
Has there been any movement on this issue?
Package removed.
