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

Can iText 2.1.7 (MPL/GPL) licence be used in commercial projects?

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.