Although the author has removed his Tweet, I once received the following notification from Twitter:
This isn't really a legal question, because there is freedom of speech, but sometimes I regret that I even bother to look at new questions.
The following insult was written by a Stack Overflow user with a reputation of 1 (meaning that he didn't contribute anything substantial to Stack Overflow yet):
When something like this happens, I don't feel like answering any other question for a while, and people who do have a genuine question often don't get the answer they deserve, because some questions remain unanswered if I don't spend any time on them.
What usually triggers such a situation?
There are three types of questions that trigger a harsh comment or answer.
[1.] Questions that sound like "I have tried X and it doesn't work!"
Questions like this can be OK because software remains software, and it's always possible that something doesn't work because of a bug. However, it is important that you phrase such a question in a way that isn't offensive. I sometimes reuse this quote I found on Stack Overflow:
There is a clear rule when you claim that something doesn't work: you have to provide proof. You can't just declare that something doesn't work and expect every one to believe you. The best way to convince people is by writing a Short, Self Contained, Correct (Compilable) Example, better known as an SSCCE. Without such an example, it is very hard for third parties to check whether or not your allegation is correct. Remember that you are asking a favor: you have a problem and you want other people to solve your problem for free. By not providing some sample code that can be used to reproduce the problem, you are creating a threshold that may be too high for people willing to spend some time on your question, but not too much time. If the problem can be reproduced by compiling and running the SSCCE, you have a better chance at getting people's attention. Many developers on Stack Overflow love solving mysteries. Give them a problem they can reproduce and they'll give you the time they might otherwise spend on a silly Sudoku.
If the problem can't be reproduced by compiling and running the SSCCE, people get frustrated. Especially when you say things such as: "I have read the documentation and the examples don't work." That can easily be interpreted as "The documentation is badly written," resulting in a reply: "Maybe the documentation is badly read. Did you even try to understand the examples?"
You're a developer, not a copy/paste artist. Don't use code you've found somewhere in the wild and expect it to work if you don't understand what the code is for. On several occasions, I have written documentation showing how not to do something versus showing how to do something correctly. You should know which example is which before you start copy/pasting code. Therefore it is important to read the documentation! Some people have no idea how much time and effort is spent on writing documentation, and have no respect at all for the author. Obviously, you are not one of them, as you are reading this book.
[2.] Questions that sound like "I have searched the whole internet and I didn't find a solution!"
Never start a question with a lie that can easily be disproven by a link to the appropriate documentation. It makes for a bad first impression and people will not be inclined to help you.
The main question is: "Did you do an effort?" Whatever you claim about doing research, people can usually tell from the way you phrase your question if you took the time to solve the question yourself, or if you were just lazy and threw the question on Stack Overflow. A great way to answer questions like this, is by using the service let me Google that for you, but it's forbidden to link to that site on Stack Overflow. I do see whathaveyoutried.com in a comment once in a while. When I started my career, I was asked to read "How To Ask Questions The Smart Way" by Eric Raymond. I loved it! You should read it too if you haven't already.
On a side note, I want to mention that it is possible to mark questions as duplicate on Stack Overflow. However, you can only refer to questions that have either been accepted or that have received at least one up-vote. When I read the 1,000+ answers I have posted on Stack Overflow to compile this book, I noticed that many of my answers weren't accepted and received zero up-votes. This is sad, isn't it? It only takes a single click to indicate that an answer was helpful, yet that's already too high a price for receiving a good answer.
[3.] Questions that sound like "I can't upgrade to the latest iText version because we can only use the open source version"
Free software is licensed software. iText is free software. That doesn't mean that iText is for free: iText has always been distributed with a copyleft license.
Some people only read the first part in the definition of "copyleft". They read about receiving "permission to reproduce, adapt or distribute" iText, but they forget about the second part: "as long as any resulting copies or adaptations are also bound by the same copyleft licensing scheme."
iText versions pre-dating iText 5 were versions using a weak copyleft license (more specifically the MPL/LGPL). This means that you can use such a version in an application that isn't bound by the copyleft license. Your only obligation is to distribute the changes you make to iText under the MPL, the LGPL, or the MPL/LGPL. In theory, those versions can still be used inside applications that are not free. In practice, you should no longer use those old versions for both technical as well as legal reasons (as explained in one of the previous questions).
Starting with iText 5, iText has increased software freedom, in the sense that the license was changed to a very strong (some use the word "viral") copyleft license, more specifically the AGPL. When you use iText in an application that you distribute or when you use iText in a web application that allows people to directly use iText (through a SaaS application, on a web site,...), you have to distribute all the source code that touches iText under the same license and under the same license only.
Some people argue: "We do not modify iText, hence we are not bound by the AGPL."
That assumption is incorrect. Writing a web application that uses iText is considered being a modification in the context of the AGPL and putting this application on a web server for people to access is considered being distribution.
Nothing is more annoying than hearing people claim that iText is no longer open source. I'm sorry if I get rude when I hear such lies. iText is still open source software: you can download the source code and take a look inside. The new version of iText leads to more freedom in the sense that almost every snippet of code that touches iText becomes free software too.
If you have customers or an employer who wants a closed source version of your product, you or your employer should buy a commercial license from iText Software. That's only normal: we are continuously investing in research and development. We also spend a lot of time and energy answering questions to help out developers. We are here to help developers. Help us help you.
Don't say: "I didn't make the decision to use an old iText version. Management made that choice and I have no responsibility whatsoever in this matter."
Say: "I didn't make that decision, but I will help iText Software to get in touch with the people that did." I can understand that you aren't as assertive an employee as I used to be before I decided to start my own company, but the least you can do, is to help iText Software explain to your management, CTO to CTO, why using the old iText version is a bad idea.
I was a member of a panel at Devoxx (the largest developer conference in Europe) in 2014. During this panel session, David Blevins (tomtribe.com) made a useful suggestion. A report of this panel session can be found on Geertjan Wielenga's blog. I quote:
"We have this fairytale idea that open source is an infinite resource, but it's not," Blevins said. An approach that was suggested is for developers to approach their organization's CTO and say to them: "Let's outsource all our software development to people we don't know" and then, when the CTO looks surprised and annoyed at the suggestion, say: "That's what we're doing already, shouldn't we get to know the organizations behind the software we're using?" The bottom line reached by the end of the discussions was that organizations need to take responsibility. Figure out who is behind the open source software you're using and then feed the fish in one way or another.
Be a good developer. Know that there's no such thing as a free lunch. Make the choice up-front:
If you choose the first or the second option, you contribute to the project you are using and benefiting from. That's what makes the world turn round and keeps the eco-system alive.
If you choose the third option, you are not helping the open source community at all and you shouldn't expect any sympathy from any one. I know that there are some iText forks around. I call such a fork a gork, because God Only Really Knows what's inside. Usually, these gorks are based on iText 2.1.7 and they are thrown on the internet without the quality control we have in place at iText Software. You'll notice that the people who made these gorks don't maintain them and don't answer any questions. If something goes wrong with such a version, don't blame iText software! Blame the person who published this gork!
If you can't afford a commercial license, it is better to use an official version of iText under the AGPL than to use an unofficial version from a developer you do not know and who is not going to help you when you're in trouble.
Once there was a developer who needed functionality introduced in a 2012 standard (PDF/UA, initially released on July 15, 2012). However: he insisted on using a rogue version of iText dating from 2009. Ignoring that the version of iText was three years older than the standard he wanted to support (a technical argument), he demanded a solution for free.
I explained that the development cost to support PDF/UA was fairly high and that he probably wouldn't receive any other answer. If he didn't wanted to pay, his best option was to use the AGPL version:
Although my answer was correct (pdfua.pdf was exactly what he needed), I received a down-vote and the following reply:
Note that the same person also wrote this:
Seriously? People like this remind me of the proverb: Givers have to set limits because takers rarely do. This person went on, claiming there was a conflict of interest on my side and complaining that price is a technical constraint:
To which I replied:
Some people say that I have an attitude problem, but I say: it's a gratitude problem. If that makes me a dick, so be it.