I would like to see the wording of "Companies that distribute software cannot bring a legal claim against the software users" changed to a non-negative, "Companies that distribute software CAN bring a legal claim against the software users." It may seem pedantic, but the "Yes/No" arrows are ambiguous because if you answer the "question" with arrows, it would be "Yes, companies that distribute... cannot bring a legal action..." just sounds confusing.
While LGPL and MPL are similar, there are differences and they should not be lumped together.
The biggest difference is that MPL allows static linking while LGPL does not. While in the past this wasn't a big deal, it is important for iOS development since you cannot dynamically link to libraries in iOS apps.
Agreed. Flowcharts also assume that there is some sort of decision hierarchy that will be followed. Who's to say that derivative works are the most important thing here? Maybe some company/person needs to cover their ass in another way first.
This list is less a description and more a taxonomy, which means that it's not valuable to anyone new to these licenses. When starting a project, it's best to convey the benefits of each license in a straightforward manner to whoever the decision maker is. A tree like this will only confuse and ensure that an ill-fitting license is chosen from the onset.
It does allow static linking---from section 4, paragraph d:
"d) Do one of the following:
"0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
"1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version."
You just have to allow relinking in some form. Admittedly, this is easier with dynamic linking, but the LGPL doesn't restrict static linking per se.
Yes. It's like saying humans can fly, if thrown out of an airplane. Asking developers to distribute all the object files of their proprietary software is not realistic. And even if one developer accepts that condition, most developers won't, sending any open source software that she releases and that depends on an LGPL library directly into oblivion (again, in a context where dynamic linking is not possible).
The whole point of the GPL is that if you use software, you deserve to have access to its source code. It originated in an era where there was little software in use that lived on someone else's servers which you never touched. And so ignoring that didn't affect the GPL's intended purpose.
With the rise of the web, it is now very common to be dependent on software that you only interact with remotely, through a website. The Affero GPL returns the original intent of the GPL. It puts websites on the same grounds with respect to the GPL that native applications have always been. Every argument you can come up with against the Affero GPL was already made about the original GPL.
If you don't like the intent of the GPL, don't apply it to things that you create. If you don't like the effect of the GPL, don't use GPLed code in your software. In the meantime don't bother complaining that it does exactly what it was intended to do.
Otherwise, awesome infographic.