No. That is the case of Linus Torvalds not using the standard "or later" clause. He has his (bad) reasons.
The incompatibility is caused by "lack of restrictions" clause. Without that, GPL becomes essentially BSD with all the corporate thievery that entails.
So what's the solution? You can use a permissive licence which has a huge "backdoor" allowing derivatives to turn up under any licence, including GPLv3 (or v4). Or you can use GPLv2 with no "or later" clause which means you get situations like this.
This incompatibility is a unique feature of GPL. Wherever it goes, it's incompatible with something (in this case, with itself). You could use MPL or CDDL and, as long as GPL isn't involved, you won't have problems with license compatibility.
However, in the case of the Linux kernel (which "perf" is distributed with) changing the license is not an option --- no CLA and, even if it was practical to ask so many people for permission, many contributors are dead now. So here the only option is using dependencies which are compatible with GPLv2. So maybe we need a new library to replace libbfd, which would be more permissively licensed.
It's not a feature of GPL, it's an unfortunate side-effect of copyleft. If you have a better way to "disable" copyright than copyleft then I'm sure it would supersede the GPL.
> If you have a better way to "disable" copyright than copyleft then I'm sure it would supersede the GPL.
In absence of copyright anyone could publish binaries build on GPL code without sharing the sources. So a central feature of the GPL would cease to be if copyright was in any way disabled. Saying the GPL is about disabling copyright is about as true as McDonalds being about healthy diets.
Well, I don't think I agree with him and would licence GPL code with the "or later" clause, but he has a very reasonable and convincing argument against it.
"or later" is a hack to get around the fact that the GPL is basically incompatible (I need a better word because this is overloaded) with itself if you change the name. If you want to use GPL and GPLRenamed libraries in the same project the only option is to relicence the project under both licences. This may be possible if you have few dependencies and few authors. But if you want to depend on a new library after some authors have become uncontactable you basically can't.
> That is the case of Linus Torvalds not using the standard "or later" clause. He has his (bad) reasons.
Linus does not think GPLv3 is a good or fitting license for the Linux-kernel and that it changes too much things to be considered a new version of the same license as GPLv2.
So he refuses to add the “or later” backdoor which would effectively relicense “his” kernel with a license he does not approve of.
MIT, X11, BSD (2- or 3-clause), and more similar ones I can't name off the top of my head: these are the basic do-what-you-want license, the only requirements are things that every (good) license already has, such as standard limitation-of-warranty clauses and retention of copyright notice requirements.
Apache (v2): This is the next stage up, which means that the text is lengthier and somewhat denser legalese, but also covers more topics such as trademarks and especially patents. The patent clause here includes a provision that any patent licenses are revoked if you sue the authors for patent infringement.
MPL (v2): This is a weak copyleft requirement, which means that you must provide any changes to the source code when you distribute the binary and additionally the resultant code must be licensed under the same terms, although it only applies on a per-file basis. EPL, CDDL are broadly similar to the MPL, with a few differences in the legal minutiae.
LGPL: Weak copyleft again, except now it's on a per-library basis. [Although, to be honest, the definition of per-library basis isn't entirely clear for non-C/C++ code.]
GPL: Strong copyleft, which means that you pretty much have to use GPL if you reuse the code.
AGPL: Even stronger than GPL, you have to distribute sources to anyone who uses your code over the network.
With the GPL family, there's a distinction between version 2.1 and version 3 that retains relevance, because some people objected to the changes in GPLv3 (notably the anti-Tivoization clause and patent clause changes) and refused to move to GPLv3, with the Linux kernel being the most notable project to refuse to do so.
As for relation, well, any license more complicated than Apache includes lots of legal minutiae that makes it somewhat hard to render judgement if two licenses are compatible or not. In general, though, you can usually use an earlier license in this list in a project that uses a later license, but usually only if both licenses are the latest version (as the most recent updates added some compatibility escape hatches).
One thing worth noting about AGPL, is that it also changes the definition of "derived work" to also include "accessing code over the network", so that if you operate a SaaS that includes an AGPL service in your network diagram, your entire SaaS has to be opened.
IMO, the gist of the GPL boils down to:
> If you "distribute" a "derived work" of this code, you have to release your code as well (under the same terms.)
AGPL not only interprets "distribute" to mean "offer up as a service over the network", but it also interprets "derived work" the same way. This is why anyone who uses (say) MongoDB in a company basically has to pony up for the commercial license, lest they be required to open source huge parts of their company.
Facebook uses your code. Facebook wants to sue you for patent infringement. Doing that makes them no longer have the right to use your code, so they're deterred from suing you.
The incompatibility is caused by "lack of restrictions" clause. Without that, GPL becomes essentially BSD with all the corporate thievery that entails.