Can iText 2.1.7 / iTextSharp 4.1.6 or earlier be used commercially?

A version of this question was originally posted on StackOverflow on Sep 6, 2014 by Devendra Sharma, however, it has since been removed. As it remains a common question, we have answered it here, and included the response from the original iText author for posterity. The original post can be viewed on the Wayback Machine.

We strongly advise against using any version of iText earlier than the latest patch release of iText 5.5.13. While iText 2 and iText 5 are both EOL, we still provide support and regular security updates for iText 5. Since the final version of iText 2.x/iTextSharp 4.x was released in 2009, there could be many undisclosed vulnerabilities, in addition to the disclosed CVEs patched in later iText releases.

In addition, there are potential intellectual property issues with proprietary code used in iText 2.x and earlier versions. After a comprehensive code review, iText/iTextSharp version 5 was released in 2009 under a dual AGPLv3 and commercial license model. Due to its high level of API compatibility with iText 2, it is beneficial to migrate existing projects to iText 5 to resolve these security and IP issues. For more information, refer to the iText 2 legacy product page.

For new projects, we strongly recommend using the latest iText version to take advantage of the greatly improved API and features.

Below is the answer from iText’s original author in 2014, when iText 5 had replaced iText 2.1.7 five years previously. Bruno Lowagie explains in more detail the IP concerns which lead to the code review being carried out.

The first iText company was founded in 2008. The purpose of this company was to put all the Intellectual Property of the code into one legal entity. This was achieved by identifying [1.] every third party project from which code was borrowed, as well as [2.] every individual developer who contributed code.

[1.] Some code snippets were borrowed from projects with an ambiguous license. For instance: we had a snippet that was released under Sun's Example License (which allowed us to use the code), but in the comment section of the class, it said that the code was proprietary to SUN (which prevented us to use the code). Which of both prevailed? Being an ignorant developer at that time, I thought the Example License was the one I could use, just like some people claim that you can use iText 2.1.7 today. Lawyers however, disagreed: they said that the most strict license was the valid one.

We solved these problems by (1) asking permission to use code with ambiguous licenses, (2) refactoring code if we didn't get permission, (3) removing code we couldn't refactor.

We did the same with contributions from individual developers.

[2.] The IP from individual developers was transferred to iText Group NV (formerly known as 1T3XT BVBA) by asking every developer who contributed 20 lines of code or more to sign a Contributor License Agreement.

Two problems arose:

1. Individual developers could not be reached. For example: we dropped the RTF package completely because we couldn't find a couple of the core developers of the RTF functionality.

2. In a couple of cases, we had to negotiate about the CLA. For example: one company didn't like the CLA. Instead, this company released the contribution of its employees under an MIT license, so that we could use it anyway. Another organization was really slow in agreeing with the CLA. It took us until September 2009 before we received formal approval. Only after this approval, we switched to the AGPL. I can't disclose the document (it was different from the CLA), nor the name of the organization (I hope I don't break the NDA just by writing this). I can only say that we only had full coverage of the code base after that document was signed.

Ignorant developers claim that the LGPL/MPL header "protects" them, but what if some proprietary code was accidentally added to a class with such a header? Does this make that proprietary code "available under the MPL/LGPL"? If it did, it would be sufficient to take proprietary code, add an MPL/LGPL header and publish it. Doing this on purpose would be illegal. Doing this out of ignorance can be pardoned if there is a willingness to fix the issue.

In the early years of open source, it did occur that proprietary code got mixed into an open source project by accident. At iText, we have invested a lot of time and effort into cleaning up the code base. Since that exercise, we are very disciplined with respect to code contributions. This is one of the core tasks of a professional open source company.

After we fixed all the issues, we removed all copies of those old iText versions from our servers to make sure we were in the clear. If a company decides to use some rogue version of iText 2.1.7 that is outside of our control, this company does so willingly and knowingly, in other words: at its own risk! There is no way such a company can claim: "We didn't know there was a possible IP issue with the code."

If you want to use iText 2.1.7, you need to do the exercise we have done between 2007-2009 at your own expense. This will cost you more than the price of a license. For instance: the individual developers gave permission to iText Group NV to do business with iText, but will they give that permission to you? How will you identify those individual developers?

Moreover: iText 2.1.7 dates from July 2009, meaning that it is more than 5 years old. Many bugs have been fixed since that date. Should you knowingly introduce those bugs into the code base of your customer, then your customer may claim that you had an alternative: you could have used a more recent version of iText...

As for your question "what about the investment one might have done in his commercial project using iText 2.1.7 or earlier?" That investment must have been done at least 3 years ago, because we've been informing people that they should upgrade for at least that long. Upgrading to a recent version is an investment that should be categorized as a maintenance cost. It should be an affordable cost because whoever has been using iText 2.1.7 for that long in a commercial project has been making money thanks to iText for that long. Claiming that "iText has now changed its mind" is not correct unless now is marked as a synonym of 5 years ago in your dictionary.