I am not a legal guy but lots of discussion threads suggest that there is no issue using the earlier version (2.1.7) of iText in commercial projects as that version is bounded with terms & conditions governed by MPL/GPL license.
However, if we look at iText's official website, it says as the licence has been upgraded to AGPL licence, one has to buy the software before commercially using it. See the topic entitled Why shouldn't I use iText 2.x (or iTextSharp 4.x)?
LEGAL REASONS: Older versions of iText under the free model may contain code fragments that infringe other people's copyrights or intellectual property rights. iText Software Group has done a significant investment in identifying and eliminating all those cases as of version 5.1. which is one of the reason why it is now a paying commercial version. We do not recommend the use of versions prior to 5.1 for commercial projects as your company could be liable for copyright or IP infringements.
Of course, this seems a warning only. Discouragement of not using iText with earlier version due to Technical reasons could be understood but Legal reasons are not worth. What about the commercial projects who have been using iText 2.1.7 before the licence upgrade happened in iText? Would they now have to change their whole project planning because iText has now change his mind to not to distribute it commercially? Of course iText might has done significant investment in upgrading the version technically but what about the investment one might have done in his commercial project using iText 2.1.7 or earlier?
Please someone who understands legal implications of both the licences clarify this confusion. iText can use such warning to encourage its sale but is there anything substantial in such warning? Can one use iText with version 2.1.7 or earlier commercially? Comments from Mr. Bruno Lowagie, the original author of iText are highly appreciated.
Posted on StackOverflow on Sep 6, 2014 by Devendra Sharma, but the question was removed. Its original URL was https://stackoverflow.com/questions/25696851
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:
- 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.
- 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.
This answer is also applicable to iTextSharp versions lower than iTextSharp 188.8.131.52. Some people claim that they use iText 4.2.0, but that version has never been officially released. For more info about iText 4, read My Maven build is broken, what should I do?